Internet Explorer internal resolver cache

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I'm testing use of UltraDNS for automatic site failover from a production to
a hot site facility using DNS. I've found that if I open a site through IE
and then change the IP to which that site resolves IE will take approx. 30
minutes to recognise the new IP. If I open a new instance of IE, that
instance will load the new IP right away. I don't have this problem with
Mozilla-based browsers. MS article ID 263558 indicates that this is due to
internal resolver cache behavior and suggests two registry changes to change
the behavior. These changes do seem to resolve the problem. I guess my
question is why does MS set the resolver cache timeout so high by default? It
seems like the downside is much greater than the upside.
 
Steve Cook said:
I'm testing use of UltraDNS for automatic site failover from a production
to
a hot site facility using DNS. I've found that if I open a site through IE
and then change the IP to which that site resolves IE will take approx. 30
minutes to recognise the new IP. If I open a new instance of IE, that
instance will load the new IP right away. I don't have this problem with
Mozilla-based browsers. MS article ID 263558 indicates that this is due to
internal resolver cache behavior and suggests two registry changes to
change
the behavior. These changes do seem to resolve the problem. I guess my
question is why does MS set the resolver cache timeout so high by default?
It
seems like the downside is much greater than the upside.
Click to expand...

Seems like a reasonable time to me. Very few sites change their IP address
that often.
 
The issue isn't really one of frequently changing IPs, though. The issue is
being able to change the IP that a url resolves to at all within a single
browser session. If a user has a browser opened to a site in my production
facility and that facility is destroyed, I want that user to continue to be
on the site, but now hosted through a different facility. DNS is one way to
accomplish this (Sitebacker through UltraDNS monitors A records and can
modify A record priority if a site fails). If the browser independently
caches DNS records for 30 minutes, that browser will get a 404 even though
the site is up and running on the new IP. Mozilla-based browsers do not show
this behavior. It seems very odd that the browser is caching independent of
the OS and completely independent of the TTL.
 
In a case like that, the IP change may easily take 24 hours to propogate to
the DNS server they are using.
 
I agree that that would be the case if I were transferring authority for the
domain, since the root servers are on a 24-hour cycle. However, with the TTL
on the A record set to 300 seconds, most DNS servers will expire the record
after a 5 minute cache. Propagation times for a modified A record have been
less than 8 minutes in testing.
 
(cross-post added to XP Networking)
Steve Cook said:
I'm testing use of UltraDNS for automatic site failover from a production to
a hot site facility using DNS. I've found that if I open a site through IE
and then change the IP to which that site resolves IE will take approx. 30
minutes to recognise the new IP. If I open a new instance of IE, that
instance will load the new IP right away. I don't have this problem with
Mozilla-based browsers. MS article ID 263558 indicates that this is due to
internal resolver cache behavior and suggests two registry changes to change
the behavior. These changes do seem to resolve the problem. I guess my
question is why does MS set the resolver cache timeout so high by default? It
seems like the downside is much greater than the upside.
Click to expand...


Which OS? I suspect the answer may have more to do with the OS
and the way it caches lookups than anything IE does. E.g., it seems
to me that that article should at least refer to NT5x dnscache service.

If your OS is NT5x do you still see a problem if you use nslookup
to check when the changed lookup is available and then use
ipconfig /dnsflush before trying to reaccess the site with IE?

Does your obvservation mean that FireFox bypasses the dnscache
somehow too? Or that it uses it differently? You might try using
ipconfig /displaydns and comparing results with the two browsers.

I think that this question may be better answered by someone
from the XP Networking newsgroup, so I'm cross-posting
this reply there.


HTH

Robert Aldwinckle
---
 
I've tested this on XP SP1 and W2K3SP1. The behavior appears to be
independent of the dnscache service and specific to IE (and browsers that
emulate IE, like SlimBrowser). IPCONFIG /displaydns shows the correct
information. NSLOOKUP shows the correct information. IE goes to the wrong
URL. IPCONFIG /flushdns has no effect on this behavior. Mozilla-based
browsers appear to use the operating system's dns cache, while IE ignores it.
MS article ID 263558 documents this behavior.
 
Didn't see the original question, so I'm second-guessing here ;-)

However, from what you say I think the issue here is nothing to do with DNS
caching, but rather that browsers don't bother to do DNS queries for pages
which are in their history-list. In fact, I'm pretty sure the IP of the page
is in the history database, and that's where it's got from. IE, Firefox and
Gecko-based browsers all do this.

Topical subject as today I was on a site where several people reported
inability to browse, but others reported no problem. The site's DNS server
was completely down, as nslookup confirmed, and those who reported ability to
browse were of course visiting pages they regularly use.
 
This may very well be directly or indirectly related to the browse History,
although as near as I can tell the history is URL-based. Microsoft indicates
that IE has an internal resolver cache mechanism. Documentation of how this
mechanism is used appears to be sparse.

"In earlier versions of Internet Explorer (Internet Explorer 3.x), DNS host
entries are cached for 24 hours by default. In many cases, this is too long.
During this period, some host entries stop working because of change in the
IP address of the remote server that was initially resolved.

Internet Explorer 4.x and later versions modify how DNS host entries are
cached by decreasing the default time-out value to 30 minutes.

In some cases, this new time-out setting is too short. If your environment
has a number of clients that are connecting and are all performing DNS
lookups every 30 minutes, you may experience an unwanted increase in network
traffic. To modify this behavior, make the following registry change:

1. Start Registry Editor.
2. Locate and click the following key in the registry:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet
Settings
3. On the Edit menu, click Add Value, and then add the following registry
values:
Value Name: DnsCacheTimeout
Data Type: REG_DWORD
Radix: Decimal
Value: (time in seconds)

Value Name: ServerInfoTimeOut
Data Type: REG_DWORD
Radix: Decimal
Value: (time in seconds)
4. Quit Registry Editor.

For example, to set the time-out value to 10 minutes, use a value of 600
seconds.
Note You must use both the registry values listed in step 3 to control the
Internet Explorer internal resolver cache mechanism."

Making these changes appears to resolve the resolution issue where the IP
for the URL is changed. Microsoft's logic of setting the cache timeout higher
within the browser than it is within the OS makes little sense. Their stated
goal of reducing DNS query traffic does not appear to justify the disjoin
between the OS and the browser logic for DNS caching.
 
Back
Top