At 6/22/02 6:29 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. > >If it's not done that way, then there is another big mystery as to why it >would not work, with all >ISP's like they do with the bigger ones.
There is no mystery; it is the very nature of DNS that each ISP will "see" the new data at a different time, and it has nothing to do with large or small ISPs. You really should read the book "DNS and BIND" to learn how DNS works; if you're a technical person in this business, it's some of the most important information you can have. But, here's a simplified explanation.... First of all, it has nothing to do with anybody at the ISP level updating a copy of all the DNS domain name information onto a server. There is no central copy of all DNS information. It is *intentionally* scattered around all over the Internet. Let's say you're looking up "www.ab4.com" (chosen at random because its DNS settings make it a good example). A DNS resolver (such as the nameserver at your ISP) first consults one of the "root" servers and is told the address of another server that knows about ".com" domains. Then the resolver contacts that server and is told the address of another server that knows about "ab4.com". The resolver contacts that server (which, since ab4.com was registered through OpenSRS, will be one of the nameservers entered into the manage interface) and is told the address of "www.ab4.com". "All those separate lookups for a single query?", you're asking. "It must take a long time!" You're right, so the system uses caching to minimize the time taken to do the same lookup in the future. The caching is what is responsible for the delay in propagation. Caching works like this: at each of the lookup stages mentioned above, the server will return not only an answer such as "you can find out more about ab4.com from the nameserver at ns1.directnic.com", but ALSO information saying "and you can count on that being the case for the next 2 days (or whatever) without asking again, so please remember it." So let's say that I lookup www.ab4.com by asking the DNS resolver at my own ISP. The resolver has never heard of www.ab4.com before, and it doesn't have a database of all the names, so it has to start asking other servers: 1. The first lookup to the root servers tells it to contact the server "a.gtld-servers.net" to learn more about domains ending in ".com" -- and oh, by the way, if it's looking up another domain name ending in ".com" in the next 6 days, just use that same server without asking again. 2. The second lookup to a.gtld-servers.net tells it to contact "ns1.directnic.com" for more information about ab4.com, and that it doesn't need to ask again for two days. (This two day "time to live", or cache expiration time, is the same for every .com domain.) 3. The third lookup to ns1.directnic.com tells it that the address of www.ab4.com is 66.79.10.216, and that it doesn't need to ask again for one day. Fine. We're all set -- we've found out the address of www.ab4.com, and the DNS resolver at our ISP has also cached some information that will allow it to avoid a number of lookups if the same resolver needs to do lookups for www.ab4.com, ab4.com, or any zone ending in .com in the near future. Now, let's say that the owner updates the nameserver for ab4.com at OpenSRS to be "ns1.example.com", right after we do our lookup. This will have the effect of updating the information that a.gtld-servers.net will return in step 2 (although it will take between 3 and 24 hours before Verisign updates the gtld-servers.net servers). Okay. So 1 day, 23 hours after the first lookup, we do another a lookup of www.ab4.com. The resolver has forgotten that the address of www.ab4.com is 66.79.10.216 (that information has "expired from the cache"), but it DOES know that it can find information about ab4.com from ns1.directnic.com, because it was told to remember that for 2 days. So it uses that outdated information even though an actual lookup at a.gtld-servers.net would now tell it to use ns1.example.com. And ns1.directnic.com still tells us that the IP address of www.ab4.com is still 66.79.10.216 (even though it's probably not what the owner wants), and that it should again cache that for a day (because nobody's made a change at ns1.directnic.com -- the change was at a.gtld-servers.net, but we didn't check there again). So then we do yet another lookup for www.ab4.com 23 hours later -- it's now been 2 days and 22 hours since the nameservers were updated. But the resolver still remembers that the IP address of www.ab4.com is 66.79.10.216 -- giving us information that is three days out of date! The consequences of this behavior are that after you update the DNS nameservers for a domain, you can't rely on DNS working until the total time of ALL THESE THINGS ADDED TOGETHER has elapsed: 1. The time required for Verisign to actually update all the gtld-servers.net servers (12 to 24 hours); 2. The time required for the cached gtld-servers.net information to expire from previous lookups (2 days); 3. The time required for the cached final nameserver lookup (ns1.directnic.com in the example above) to expire (a few minutes to 2 days or more, depending on what the person running that server set). Add those together and you've easily got four days if the resolver previously looked up the domain and cached all that information right before the nameservers were changed. However, if the resolver doesn't have it in the cache from a previous lookup, it might work as little as 4 hours after the nameserver update. It depends entirely on what's previously happened at the resolver (for example, did any customer of this ISP try to lookup this name in the last two days?). The result could obviously be different for each ISP's resolver, which answers your original question: >WHY some ISP's can see a new nameserver within 24 hours, and others >cannot for up to 3 or 4 days. In a nutshell, the more recently a resolver has done a lookup for a name, the longer the users of that resolver will have to wait before subsequent lookups make the resolver contact all the servers in the chain and guarantee they get current information. It's nothing to do with the ISP reloading anything; it's entirely to do with how recently someone else at the ISP has done a similar lookup. (That said, you can actually calculate the worst case before you update the nameservers if you do some dig lookups, so you can tell the customer that it will take no longer than X days, although they should then restart their computer, too, because MSIE and Windows do their own extra caching...) This also explains the "watched pot never boils" phenomenon where it seems that the owner of a domain name is always the last one to see the the propagation take effect: the owner sits there doing a lookup every few minutes in the hope that it works, forcing all the soon-to-be-outdated information to be cached. -- Robert L Mathews, Tiger Technologies "A professional in an ape mask is still a professional." -Marge Simpson
