If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#16
|
|||
|
|||
Why does Firefox not respect the HOSTS file in Windows
On Wed, 29 Jun 2016 21:53:51 +0000, Stormin' Norman wrote:
Interesting, I have not used that group, maybe I will take a look, sounds right up my alley. As for Firefox, did you try disabling the keyword search as mentioned at the link I posted above? The group alt.home.repair fun group to follow, especially a religious guy named "Chris" who goes by the nick of "Stormin' Norman". http://tinyurl.com/alt-home-repair As for Firefox, I disabled over 30 things, so time will tell if that worked. |
Ads |
#17
|
|||
|
|||
Why does Firefox not respect the HOSTS file in Windows
On Wed, 29 Jun 2016 18:02:41 -0400, Mayayana wrote:
| 10. I just recently learned of Firefox DNS prefetching: | So I turned it off, changing network.dns.disablePrefetch;true to | network.dns.disablePrefetch;false | I hadn't noticed that one. The default seems to be true, which seems to make sense. Why do DNS lookups for sites you might not visit? You must be correct. I was going crazy turning stuff from true to false, but this is one that is probably best left at false if we're trying to eliminate Firefox going to domains that we didn't explicitly state. So I'll change it back to the default! BTW, with regard to the whole "DNS caching thing" I am not the expert, so I can only conjecture how I think it works. 1. You type www.somewhere.com along with http (i.e., port 80) 2. Firefox checks the Firefox DNS cache, but it's not there 3. Firefox checks the Windows DNS cache, but it's not there 4. So Windows first checks the HOSTS file, but it's not there 5. Then Windows checks the Windows DNS cache, but it's not there 6. So Windows checks what the DNS server is 7. For me, that's gonna be set to the router 192.168.1.1 8. So Windows asks 192.168.1.1 who the DNS Server is 9. The router returns the Google DNS Server 8.8.8.8 10. So Windows sends a port 53? DNS request to 8.8.8.8 11. (It actually follows a hierarchy so let's simplify here.) 12. 8.8.8.8 returns the IP address 1.2.3.4 to the DNS cache 13. 1.2.3.4 is handed back to to Windows from 8.8.8.8 14. Windows puts www.somewhere.com=1.2.3.4 into the Windows DNS cache 15. Windows hands Firefox that information 16. Firefox puts www.somewhere.com=1.2.3.4 into the Firefox DNS cache 17. Firefox sends the port 80 request to 1.2.3.4 18. And 1.2.3.4 returns the information to Firefox Upon the *next* invocation of the same URL... 1. You type www.somewhere.com along with http (i.e., port 80) 2. Firefox checks the Firefox DNS cache, and finds 1.2.3.4 17. Firefox sends the port 80 request to 1.2.3.4 18. And 1.2.3.4 returns the information to Firefox That's how I *think* it goes. The Firefox cache skips steps 3 to 16 above. However, the whole firefox cache thing is confusing. So this is just a guess. I throw it out there for someone who actually knows what they're talking about to clarify. |
#18
|
|||
|
|||
Why does Firefox not respect the HOSTS file in Windows
On Wed, 29 Jun 2016 17:50:40 -0400, Mayayana wrote:
These 3 relate to cahing: | network.dnsCacheExpirationGracePeriod;60 [set to 0] | network.dnsCacheExpiration;60 [set to 0] | network.dnsCacheEntries;400 [set to 0] | network.dns.offline-localhost;true ? | network.dns.localDomains; ? | network.dns.ipv4OnlyDomains; | network.dns.get-ttl;true ? | network.dns.disablePrefetch;false [I set this to true. Prefetch is a ridiculous, privacy-compromising function to download files from links at pages you visit, just in case you decide to click those links!] | network.dns.disableIPv6;false [probably fine] | network.dns.blockDotOnion;true ?? | In addition to the 30 things done already, I have now added your suggestions above: 31: I changed from network.dnsCacheExpirationGracePeriod;60 to network.dnsCacheExpirationGracePeriod;0 32. I changed from network.dnsCacheExpiration;60 to network.dnsCacheExpiration;0 33. I changed from network.dnsCacheEntries;400 to network.dnsCacheEntries;0 34. And I returned disable prefetch to the default setting of true: network.dns.disablePrefetch;true |
#19
|
|||
|
|||
Why does Firefox not respect the HOSTS file in Windows
On Thu, 30 Jun 2016 04:45:14 +0000, Jannah Jankowski wrote:
The group alt.home.repair fun group to follow, especially a religious guy named "Chris" who goes by the nick of "Stormin' Norman". http://tinyurl.com/alt-home-repair As for Firefox, I disabled over 30 things, so time will tell if that worked. Op. I mean Stormin Mormon |
#20
|
|||
|
|||
Why does Firefox not respect the HOSTS file in Windows
|
| BTW, with regard to the whole "DNS caching thing" I am not the expert, so | I can only conjecture how I think it works. | | 1. You type www.somewhere.com along with http (i.e., port 80) | 2. Firefox checks the Firefox DNS cache, but it's not there | 3. Firefox checks the Windows DNS cache, but it's not there | 4. So Windows first checks the HOSTS file, but it's not there | 5. Then Windows checks the Windows DNS cache, but it's not there | 6. So Windows checks what the DNS server is | 7. For me, that's gonna be set to the router 192.168.1.1 | 8. So Windows asks 192.168.1.1 who the DNS Server is | 9. The router returns the Google DNS Server 8.8.8.8 | 10. So Windows sends a port 53? DNS request to 8.8.8.8 | 11. (It actually follows a hierarchy so let's simplify here.) | 12. 8.8.8.8 returns the IP address 1.2.3.4 to the DNS cache | 13. 1.2.3.4 is handed back to to Windows from 8.8.8.8 | 14. Windows puts www.somewhere.com=1.2.3.4 into the Windows DNS cache | 15. Windows hands Firefox that information | 16. Firefox puts www.somewhere.com=1.2.3.4 into the Firefox DNS cache | 17. Firefox sends the port 80 request to 1.2.3.4 | 18. And 1.2.3.4 returns the information to Firefox | | Upon the *next* invocation of the same URL... | 1. You type www.somewhere.com along with http (i.e., port 80) | 2. Firefox checks the Firefox DNS cache, and finds 1.2.3.4 | 17. Firefox sends the port 80 request to 1.2.3.4 | 18. And 1.2.3.4 returns the information to Firefox | I think that's generally true, but as far as I know there's no Windows DNS cache. Nor does Windows get involved, per se. http://webcache.googleusercontent.co...&gbv=1&ct=clnk (That's the MS info page as Google cache, bypassing their blocking of anyone who disables javascript.) From what I've been able to find, the Firefox cache is set by default to expire in one hour. Your setting of 60 would imply one minute. But I think that must be wrong. As I described earlier, I went several days awhile back, unable to reach several sites. It was only when I set cache to 0 that I was able to reach them again. (Someone had suggested that. Previously I was unaware that Firefox/Pale moon was caching.) I assume, also, that FF has a session cache. I don't think it's making 15 DNS calls for all the different files at a somewhere.com webpage. So that's another indicator that 60 may be something like 60 days rather than 60 seconds. In any case, I have all the caching set to 0 and most pages load almost instantly. What I think happens is that Firefox either uses a Windows sockets method to get the IP address or gets the DNS IP directly with a call to the GetNetworkParams function in iphlpapi.dll, then makes its own port 53 DNS call. Either is feasible. Firefox *should* be checking the HOSTS file before it proceeds. Then it can either make the 53 call itself or use a winsock method like gethostbyname or getaddrinfo. I'm guessing those methods make the call directly, so that Windows is not "making a decision" in the matter. HOSTS may be checked as part of that call. I don't know. getaddrinfo actually takes a port number parameter, which would be 53, implying that it's just a wrapper around the remote winsock call, but I don't find any clear explanation in MSDN of how it actually works. This is mostly of only technical interest, but it does reflect on Firefox. Firefox is/should be responsible for respecting HOSTS and not just expecting Windows to somehow handle that. My tests showed that as well. When I go somewhere with Pale Moon and run Filemon, only the Pale Moon process reads HOSTS, and it reads it several times. Is that palemoon.exe reading it, or is it the winsock DLL running in the PM process? I'm not sure. Either way, PM is responsible, in the end, for respecting HOSTS. None of that actually answers why you have heavy activity when you start FF. My guess would be that it's software on your system calling home. The URLs -- cloudfront, amazonaws and akamai are all middleman traffic and storage rental services. As I noted in the other group, even Microsoft uses Akamai. It's sort of like having a contract with an equipment company. If you just need to shovel snow occasionally you buy a shovel. In the same way, most smaller companies just host their website, on their own computers or on a service. If you own a mall and need to shovel the snow quickly, you might contract with an eqipment company that can send over 3 plows and 6 snowblowers at a moment's notice. In that analogy, it allows MS to handle things like a DDoS attack or a sudden run on 6 GB SDK downloads easily. Akamai manages the traffic load transparently. Unfortunately, that seems to get around HOSTS because there's no DNS lookup involved. So you need to research from your end to figure out what's going out without asking. Maybe your AV software? These days it could be almost anything. The typical amount of "un-permissioned" online communication is extreme if you don't control it. |
#21
|
|||
|
|||
Why does Firefox not respect the HOSTS file in Windows
On Thu, 30 Jun 2016 04:46:52 +0000 (UTC), Jannah Jankowski
wrote: BTW, with regard to the whole "DNS caching thing" I am not the expert, so I can only conjecture how I think it works. 1. You type www.somewhere.com along with http (i.e., port 80) 2. Firefox checks the Firefox DNS cache, but it's not there 3. Firefox checks the Windows DNS cache, but it's not there 4. So Windows first checks the HOSTS file, but it's not there 5. Then Windows checks the Windows DNS cache, but it's not there 6. So Windows checks what the DNS server is 7. For me, that's gonna be set to the router 192.168.1.1 8. So Windows asks 192.168.1.1 who the DNS Server is 9. The router returns the Google DNS Server 8.8.8.8 10. So Windows sends a port 53? DNS request to 8.8.8.8 11. (It actually follows a hierarchy so let's simplify here.) 12. 8.8.8.8 returns the IP address 1.2.3.4 to the DNS cache 13. 1.2.3.4 is handed back to to Windows from 8.8.8.8 14. Windows puts www.somewhere.com=1.2.3.4 into the Windows DNS cache 15. Windows hands Firefox that information 16. Firefox puts www.somewhere.com=1.2.3.4 into the Firefox DNS cache 17. Firefox sends the port 80 request to 1.2.3.4 18. And 1.2.3.4 returns the information to Firefox Upon the *next* invocation of the same URL... 1. You type www.somewhere.com along with http (i.e., port 80) 2. Firefox checks the Firefox DNS cache, and finds 1.2.3.4 17. Firefox sends the port 80 request to 1.2.3.4 18. And 1.2.3.4 returns the information to Firefox That's how I *think* it goes. The Firefox cache skips steps 3 to 16 above. However, the whole firefox cache thing is confusing. So this is just a guess. I throw it out there for someone who actually knows what they're talking about to clarify. You can view the Windows DNS cache with the following command: ipconfig /displaydns By repeatedly running the following command, which simply pulls out the Time To Live (TTL) values for easier visibility, you can see the TTL starting values as well as seeing the TTL count down toward zero. When it hits zero, the DNS entry is removed from the cache. ipconfig /displaydns | find "Time To Live" Lastly, for testing purposes, you can clear the Windows DNS cache with the following command: ipconfig /flushdns There are no ill effects as a result of clearing the cache. It simply rebuilds over time, as necessary. -- Char Jackson |
#22
|
|||
|
|||
Why does Firefox not respect the HOSTS file in Windows
On Thu, 30 Jun 2016 11:24:48 -0500, Char Jackson wrote:
You can view the Windows DNS cache with the following command: ipconfig /displaydns By repeatedly running the following command, which simply pulls out the Time To Live (TTL) values for easier visibility, you can see the TTL starting values as well as seeing the TTL count down toward zero. When it hits zero, the DNS entry is removed from the cache. ipconfig /displaydns | find "Time To Live" Lastly, for testing purposes, you can clear the Windows DNS cache with the following command: ipconfig /flushdns There are no ill effects as a result of clearing the cache. It simply rebuilds over time, as necessary. I have wiped out both the Windows and Firefox DNS cache. For example, on Windows, I ran: c:\ ipconfig /displaydns c:\ ipconfig /flushdns And, on Firefox, I changed the network.dnsCacheEntries and a few other related settings. On Windows, using "Process Hacker", I turned off the service "Dhcp client" (aka C:\WINDOWS\System32\svchost.exe -k netsvcs) and I changed the Firefox DNS cache from 400 (which is the default) to 0. I am testing it all now, as I made over 40 related changes in the past day, and Firefox seems to have quieted down greatly with respect to both CPU intensity consumed and rogue web sites visited without my knowledge - but time will tell as sometimes small wins are fleeting. |
#23
|
|||
|
|||
Why does Firefox not respect the HOSTS file in Windows
In message , Jannah Jankowski
writes: On Wed, 29 Jun 2016 18:02:41 -0400, Mayayana wrote: | 10. I just recently learned of Firefox DNS prefetching: | So I turned it off, changing network.dns.disablePrefetch;true to | network.dns.disablePrefetch;false | I hadn't noticed that one. The default seems to be true, which seems to make sense. Why do DNS lookups for sites you might not visit? You must be correct. I was going crazy turning stuff from true to false, but this is one that is probably best left at false if we're trying to eliminate Firefox going to domains that we didn't explicitly state. Surely if you don't want it to prefetch, then disablePrefetch should be true? [] -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf Don't hit the keys so hard, it hurts. |
#24
|
|||
|
|||
Windows DNS cache (was: Why does Firefox not respect the HOSTS file in Windows)
In message , Char Jackson
writes: [] You can view the Windows DNS cache with the following command: ipconfig /displaydns Thanks, interesting. By repeatedly running the following command, which simply pulls out the Time To Live (TTL) values for easier visibility, you can see the TTL starting values as well as seeing the TTL count down toward zero. When it hits zero, the DNS entry is removed from the cache. ipconfig /displaydns | find "Time To Live" Lastly, for testing purposes, you can clear the Windows DNS cache with the following command: ipconfig /flushdns There are no ill effects as a result of clearing the cache. It simply rebuilds over time, as necessary. I did it, and (I'm running XP) it said Successfully flushed the DNS Resolver Cache. I then did ipconfig /displaydns | find "Time To Live" again, and it looked to still have the same number of lines; doing it without the pipe to "find" (piping to "more" instead) looks the same, too. -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf Don't hit the keys so hard, it hurts. |
#25
|
|||
|
|||
Why does Firefox not respect the HOSTS file in Windows
In message , Jannah Jankowski
writes: On Wed, 29 Jun 2016 17:50:40 -0400, Mayayana wrote: These 3 relate to cahing: | network.dnsCacheExpirationGracePeriod;60 [set to 0] | network.dnsCacheExpiration;60 [set to 0] | network.dnsCacheEntries;400 [set to 0] [] 31: I changed from network.dnsCacheExpirationGracePeriod;60 to network.dnsCacheExpirationGracePeriod;0 [] Of those three, I only _have_ the first one (GracePeriod), which is currently at its default of 2592000; has the unit of measure changed at some point (Firefox version)? What do the three things mean? (Provided it "runs down" in a reasonable period, say a minute or few, I can't see a problem with caching DNS data: prefetch, indeed, could be not a good idea. I have _that_ one turned off [...disablePrefetch set to true].) -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf Don't hit the keys so hard, it hurts. |
#26
|
|||
|
|||
Windows DNS cache
J. P. Gilliver (John) wrote:
I did it, and (I'm running XP) it said Successfully flushed the DNS Resolver Cache. I then did ipconfig /displaydns | find "Time To Live" again, and it looked to still have the same number of lines; doing it without the pipe to "find" (piping to "more" instead) looks the same, too. Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es \DNSCache\Parameters Data: MaxCacheEntryTtlLimit (DWORD) Default value is 86,400 seconds (1 day) How long a positive DNS query remains locally cached. Data: NegativeCacheTime value (DWORD) Default value is 300 seconds. How long a negative DNS query (failure) remains cached. Defaults get used if the registry entry is not defined. Setting MaxCacheEntryTtlLimit to 1 effectively disables the local DNS cache (TTL is only 1 second). This is what Microsoft recommends. Don't know what happens if you set it to 0 (sometimes endpoints in a range have special meaning so maybe 0 means indefinite caching time). You could also disable the "DNS Client" service (stop and set to Disable startup mode) and then also flush the current cache contents. Of course, that means if a web page has hundreds of hostnames all of which need to be resolved (they are absolutely pathed to the same or different domain versus relatively path to the same host) then you will be making a lot more DNS requests outside your host to whatever DNS server you use. Firefox has its own internal DNS cache. To disable it, set network.dnsCacheExpiration to 0 (zero) - which means you would use Windows local DNS cache unless that was also disabled which means you would also issue DNS requests to an outside DNS server for every non-relatively pathed resource in a web page (which could be scripts, CSS, and other non-ad/tracking resources). Note: Just because an old setting is still listed in about:config does not mean Firefox still honors it. I've read contradicting articles dated July 2016 claiming that a "new version" (not mentioned) has Firefox using the local DNS cache in the OS. In FF 47.0.1, the about:cache page is still defined (and mine shows non-zero values), so maybe some near-future version is going to drop the internal DNS cache. |
#27
|
|||
|
|||
Windows DNS cache (was: Why does Firefox not respect the HOSTS file in Windows)
On Sat, 2 Jul 2016 09:31:22 +0100, "J. P. Gilliver (John)"
wrote: In message , Char Jackson writes: [] You can view the Windows DNS cache with the following command: ipconfig /displaydns Thanks, interesting. By repeatedly running the following command, which simply pulls out the Time To Live (TTL) values for easier visibility, you can see the TTL starting values as well as seeing the TTL count down toward zero. When it hits zero, the DNS entry is removed from the cache. ipconfig /displaydns | find "Time To Live" Lastly, for testing purposes, you can clear the Windows DNS cache with the following command: ipconfig /flushdns There are no ill effects as a result of clearing the cache. It simply rebuilds over time, as necessary. I did it, and (I'm running XP) it said Successfully flushed the DNS Resolver Cache. I then did ipconfig /displaydns | find "Time To Live" again, and it looked to still have the same number of lines; doing it without the pipe to "find" (piping to "more" instead) looks the same, too. The primary intent of that command string was to highlight the TTL of the various cache entries and to illustrate how the TTL decrements to zero, followed by the cache entry being removed. Having said that, if there are cache entries that are simply waiting to time out (not corresponding to any current network activity, for example), then a flush should clear them and they won't immediately reappear. However, if you have current network activity, then clearing the cache might indeed appear to be very temporary. I'd expect to see a refresh of the TTL, though. The command string above would highlight that. -- Char Jackson |
#28
|
|||
|
|||
Windows DNS cache (was: Why does Firefox not respect the HOSTS file in Windows)
| You can view the Windows DNS cache with the following command:
| | ipconfig /displaydns | | Thanks, interesting. ...... | I did it, and (I'm running XP) it said | | Successfully flushed the DNS Resolver Cache. | I was wondering what all this talk was of Windows DNS Cache. I'd never heard of it. It should be clarified that "Windows DNS Cache" is actually the DNS Client service. It doesn't need to be enabled at all for most people. It's possible that people on a network with Active Directory may need it. I'm not familiar with that. I suspect they don't and that it will only save on a few intranet calls. I've had DNS Client disabled for years and see no reason to enable it. |
#29
|
|||
|
|||
Windows DNS cache
On 04/07/2016 15:38, Mayayana wrote:
| You can view the Windows DNS cache with the following command: | | ipconfig /displaydns | | Thanks, interesting. ..... | I did it, and (I'm running XP) it said | | Successfully flushed the DNS Resolver Cache. | I was wondering what all this talk was of Windows DNS Cache. I'd never heard of it. It should be clarified that "Windows DNS Cache" is actually the DNS Client service. It doesn't need to be enabled at all for most people. It's possible that people on a network with Active Directory may need it. I'm not familiar with that. I suspect they don't and that it will only save on a few intranet calls. I've had DNS Client disabled for years and see no reason to enable it. You don't need it if you LAN has it's own DNS cache but I guess it might be worth saving the 12MB of RAM it uses to save doing unnecessary DNS lookups over the Internet. -- Brian Gregory (in the UK). To email me please remove all the letter vee from my email address. |
#30
|
|||
|
|||
Windows DNS cache
Brian Gregory wrote:
Note: I'm not going to reconstruct the attribution lines that Mayayana discards in his replies. So I only quote Brian's post in my reply in this subthread. You don't need it if you LAN has it's own DNS cache but I guess it might be worth saving the 12MB of RAM it uses to save doing unnecessary DNS lookups over the Internet. Pages nowadays have resources across many and far flung sites. The content of a page can have ad resources on CDNs (content delivery networks), scripts on tertiary domains (same or different owner than the visited domain), CSS files on other servers, etc. All those resources require DNS lookups. With some pages having hundreds of externally linked resources, there can be hundreds of such DNS requests in just one page. Rarely do sites use IP addresses for their external resources. Some resources may be relatively pathed (i.e., under the same domain as visited) but many sites incorporate off-site or external resources. Having a local cache to shortcut the DNS lookups by finding the IP address for a previously visited site will speed up all those DNS lookups. The positive lookups (those that succeeded) are cached for only a day, by default. The negative lookups (that that failed) are cached for only 4 hours, by default. Registry entries can be used to alter those retention intervals. If the local DNS caching client is disabled, ALL those hostnames (even those on the same domain) will have to get looked up by issuing DNS requests out to the network, out to the Internet, to the specified DNS server (which the user can specify or use the one assigned to them by whatever upstream DHCP server they use which is often their ISP's). All that DNS network traffic takes time. The time for hundreds of DNS lookup requests and waiting to get back a response (the IP address for the external resources on a page) is very short. Whether you use a DNS caching client or not, speeding that up will not alter the time it takes for those external resources to deliver their content for that page. That's why many users use adblockers to eliminate the time to download the unwanted content. You can use GRC's DNSbench to see what are the request and acknowledge times for DNS lookup requests. Different DNS server will have differing response times, and that includes the hops between your endpoint and the targeted DNS server. https://www.grc.com/dns/benchmark.htm I would suggest editing their install-time list of DNS servers as there are *many* that are of no use to you or will never be considered for use. This tool will also indicate which servers will redirected failed lookups to their "help" redirection site (for which they get clickthrough revenue) and which will break some webcentric apps that actually expect a negative (failed) DNS lookup to return a code rather than a success code when reaching their redirection page. Some DNS servers include some filtering, like eliminating or blocking known malicious sites (but there are always a few false positives in those blacklists). For me, I configured the IP protocols on my PC to use the following DNS servers in the following order: Google DNS (8.8.8.8 and 2001:4860:4860::8888), OpenDNS (208.67.222.222 and 2620:0:ccc::2), and my router's internal DNS server (10.0.0.1 and 0:0:0:0:0:ffff:a00:1). This is the preference or fallback order: first to last. OpenDNS includes a malicious site filter that you cannot disable (unless you enlist as a reporter with them). However, I found them (according to DNSbench) to be a tad slower overall than Google's. My router's internal DNS server is not really a server. It is a transparent proxy that merely passes all DNS requests up to its upstream DNS filter. The router is configured to use DHCP which means the router will use my ISP's DNS server; however, that is only used if the prior DNS servers listed in preference order are unreachable (fallback order uses the router last). Remember to do the static DNS server config for both IPv4 and IPv6 addressing. The only time it is recommended to disable the DNS Client server (the local DNS cache) is when using pre-compiled and HUGE 'hosts' files. The 'hosts' file entries are used before using the local DNS cache. In 9x-based Windows, it was noticed the DNS Client could add overhead to using a huge 'hosts' file (I'm talking about the thousands of entries in the 'hosts' file versus the few to a couple hundred for which that text file opened on every DNS lookup and read sequentially line by line was designed for). However, those huge pre-compiled 'hosts' files (used for ad and tracking blocking) add more overhead than does the DNS Client's caching. Those pre-compiled 'hosts' file are huge. The one from MVPS is over *14 THOUSAND* lines long. The 'hosts' file is not cached into memory. It is opened (file I/O API system call) and read one line at a time to sequentially scan the text file for a matching entry on a hostname. It only works on hostnames, not domains, and why there are dozens and dozens of entries for just one resource (e.g., 117 for doubleclick in the MVPS pre-compiled 'hosts' file). I don't believe the DNS Client has incurred overhead on a prior 'hosts' success lookup for a long time in NT-based Windows. As with any process, the DNS Client service will consume resources (CPU and RAM) but it's been awhile since users are still using such ancient processors with tiny system RAM and a slow data bus on the mobo. However, the user might wish to tweak the DNS Client's settings in the registry to immediately flush negative (failed) DNS lookups. The default is 900 seconds (15 minutes). The site may fix a problem but the user will continue to get failed lookups due to the local DNS caching still listing a negative result for that host, but 15 minutes isn't very long. It eliminates you (or external resource links in a delivered web page) from wasting time to query a DNS server only to get back yet another failed result. See Microsoft's KB 318803 (http://tinyurl.com/ybjwbc37). 86400 seconds (24 hours) is the default cache time for positive results. If you often visit flaky or unreliable site or the type that move around a lot, you might want to shorten this to, say, 4 hours which is probably longer than your web sessions in your HTTP client. Because these registry tweaks are under the HKEY_Local_Machine hive, changes there will affect all users accounts in that instance of Windows. If the settings are absent in the registry, the defaults get used. I've left the positive cache set to the 24-hour expiration. I don't leave the web browser open all day but I may load it several times per day and often revisit the same sites (or different sites often access the same off-domain resources; e.g., the Google site for jquery). Since I'm using the defaults, negative results are cached for 15 minutes. I don't visit sites by hostname that move around that often, and if I get a negative DNS result then it is cleared in 15 minutes which is probably longer than me figuring out the cause of the problem with the site being faster than that to correct the problem. There is also the issue that many ISP's operate caching DNS servers. This is to quickly return a positive result for the same lookup request from hundreds, or more, of their customers. Server-side caching helps but you have no control over their positive and negative cache expirations. The GRC DNSbench tool will measure the difference between raw or uncached DNS lookup requests versus those return due to server-side DNS caching: red = cached DNS lookup time, green = uncached DNS lookup time, blue = dot.com lookup time since .com is the most widespread TLD [top-level domain]. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|