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/
