1.5 Some OS's will maintain an internal cache of nameservers. If it's in there, it will return that immediately. Not too big of a problem in-and-of itself, except for Win95, which doesn't expire the cache whilst it's running. Fortunately, this was fixed for Win98.
And as for why it can 'magically' start working, could be the ISP the fellow was using decided to restart the caching nameservers... Mark. On Sat, 22 Jun 2002, wxWeb.com wrote: > Saturday, June 22, 2002, 6:29:45 PM, POWERHOUSE wrote: > > > More like UPDATING the database, that would answer the question as to WHY > > some ISP's can see a new nameserver within 24 hours, and others cannot for > > up to 3 or 4 days. > > The ISPs do not need to update any database. They do not store a > master database of domain names. They simply hold pointers to the > root servers, nothing else. > > I am sorry that the "clueful" people at AOL told you otherwise, but > that is not how the DNS works. > > (This is not my work, but the copy sent to me was not attributed) > > 1. The Client types in a web address or clicks on a link. Some ".com" > address. > > 2. His PC's TCP/IP stack sends a DNS query to the first DNS server > listed in his configuration, the ISP's DNS server. > > 3. The ISP's DNS server looks in its cache to see if it has the IP > address (this is likely for names like www.Yahoo.com or > www.Microsoft.com). > > 4. If it has the address in its cache, it sends it back to the > requesting Client. All done! > > 5. If not, then it looks at all of the domains it host DNS for, > primary or secondary. > > 6. If it has the address from those, it sends it back to the client. > All done! > > 7. If not, it sends the query to A.Root-Servers.Net, or other Root DNS > server if that one is not available. (This depends on the order of > records in the DNS server's cache file. Most of the time it starts > with "A") > > 8. The Root DNS server looks into its records for the zone "com". > > 9. It finds the record for the destination zone. > > 10. It send the NS records for that destination zone (primary > secondary, and more if available) back to the requesting DNS server, > your ISP's DNS server. > > 11. The ISP's DNS server now has the address of the DNS server for the > destination domain it has a query pending for. > > 12. The ISP's DNS server sends its query, for "www.somedomain.com", to > that destination DNS server. > Note: If the primary DNS server is down, the DNS server should attempt > the secondary. This may not be the case with MS DNS on NT 4.0. It has > been my experience that it will not look for the secondary DNS server > and will fail the query. > > 13. The DNS server for the destination domain "somedomain.com" says, > "Hey, that's me! I'm authoritative for that domain. I've got that > record for 'www'!" (In the case of the secondary, it says, "Well I'm > not authoritative, but I know the address because I have it in my zone > files. Here it is.") This also counts for situations where the name is > www.other.somedomain.com or www.long.name.other.somedomain.com. The > root servers only care about the second level domains, anything > further is handled by the DNS server for the second-level domain. > > 14. The somedomain.com DNS server sends back the IP address of the IP > address for the "www" host to your ISP's DNS server. > > 15. Your ISP's DNS server now caches that IP address it just got back > since it is logical to assume that it may need it again. > > 16. Your ISP's DNS server then sends the IP address back to the Client > PC. All done! > > > So to paraphrase, the ISPs never have to update their database, or > download a master database, from Verisign, ICANN, or anyone else. > > What happens is usually a cache issue. Some (Poorly informed) dns > administrators set excessively long TTL times in their dns zones that > result in some ISPs caching the data for much longer periods than is > advisable. They think it helps them reduce server load or network > traffic. What it DOES do, is cause problems anytime that data needs > to be changed. > > So what you are seeing is the customer's ISP having cached the data > for a long period of time, because the previous administrator of the > DNS they were using set an excessively long TTL period for that dns > zone, resulting in caching of the data for a much longer than normal > period. > > It has nothing to do with the ISP needing to do an update or download > anything. > > -- > Best regards, > William X Walsh <[EMAIL PROTECTED]> > -- > OpenSRS installation and customizations > Payment Processing Integration > Apache Installation and Support Services > http://www.wxsoft.com/ > > >
