On Mon, 01 Sep 2003 14:45:07 +0000 Shane Hollis <[EMAIL PROTECTED]> wrote:
> > > On Mon, 1 Sep 2003, Shane Hollis wrote: > > > The DNs is a semi heiracrchical system from my understanding. The master > > > DNS ( to use a phrase loosely) are based in the states. My provider in > > > the states is on the main backbone. Therefore changes get sent out much > > > more rapidly and from a centrally located place, not from a little > > > backwater like NZ. > > > > > > If I change a DNS here in NZ, it is like injecting an agent into tip of a > > > whales tail. It takes along time to propogate through the system. If I > > > inject into the heart it is sent out a lot more quickly and spreads like > > > a ripple from the centre of the pond, not from the edge. (some very mixed > > > similes here). > > > That's not how the DNS works. > > > The DNS is organised as a heirachy purely for the purpose of splitting out > > where answers come from into seperate entities, so that there is no single > > central set of servers who are responsible for "all" answers. > > > The root servers only know about domain names which are at the global > > level, and that knowledge is limited to where to find answers. The servers > > they point to have knowledge about the deeper parts of the DNS, and in > > turn may point to other servers which inturn know more about even deeper > > parts. > >.... > > I've simplified it, because the queries are not exactly that, but the net > > effect is the same: We keep looking for an authorative server deeper and > > deeper into the name. > > > > Now, the problem with this system is it takes a while (not long, seconds, > > but long enough) and that it involves a lot of queries and network traffic > > as a result. So the answers given are _cached_, which means you get > > answers quicker, and there's less traffic which means the 'net will > > actually function. :) > >...> > > Thus, how long it takes for a change to propogate has nothing to do with > > the depth in the tree, it depends on what parts of the answer are cached, > > and how long they are cached for. > > Which is what I was pointing at with my whale analogy ... the more authorative > or better connected a server the more DNS servers it has asking it for > changes to information. A little server asks a bigger server which asks a > bigger server and so on. There is no ultimate server for DNS but the better > connected and more central a server is the better it is for propogating > changes.... If there are two little servers, say one on my desk and one on > your desk and they are both connected to the same ISP.... If I change a dns > entry on my desk when your server goes to ask for changes it wont ask mine, > it wil ask the ISP's server. no it won't it will ask [a-m].root-servers.net, who will refer it to the authoritative server for the top level of your domain, and so on down the chain. It will only ask your isp if it is set up to be a caching-only dns server (which is really only a proxy) (ie a dns server that only queries one up the chain, the isp's server will then query [a-m].root-servers.net etc etc. unless it has itself got the answer cached within the TTL. The only difference in being close to a root-server is the time for the packets to fly over the southern cross cable, which IMHO is insignificant compared to the TTL in most cases (not sure what the minimum TTL is, but if everyone made them in the same order of magnitude as the time it takes for a dns query, all hell would break loose as no caching would be done at all). >Now you will still have an incorrect DNS entry > until my server updates the ISP >which in turn is eventully asked by your > server again which then gets the correct answer. Now, if I had updated the > ISPs DNS server first then there would have been less of a time lag for > changes to propogate through the system. > > The above example is only for two computers, try multiplying that by all the > dns servers connecting to an ISP. They all have to get changes from the ISP. > Then the ISP has to share te changes with say, another ISP above it ( take > the Telecom monopoly as an example as they distribute Jetstream and Jetstart > ip's ) which in turn has to be connected to by other ISPs which in turn > updates maybe Waikato which then heads out to update .AU or .US DNS servers > which then go to the world (depending on the level of caching and what domain > or IP section has been changed.). > > My small example above showed it makes sense to updatea bigger server and > propogate changes down not the other way around.... Hit the biggest cache > with the most influence. > look if you have an address like the one in my earlier example www.clug.geek.nz, ANY dns server anywhere on the net has to go through a four level query, accessing up to 4 different servers [a-m].root-servers.net to find the auth server for .nz .nz auth server for to find the auth server for .geek.nz .geek.nz auth server to find the auth server for .clug.geek.nz .clug.geek.nz to find the address for www.clug.geek.nz unless there is a very slow link to one of those four dns servers its still four queries, four round trips. as I say, insignificant compared to even a 60 sec TTL. see here http://www.tldp.org/HOWTO/DNS-HOWTO-5.html > > The important thing to understand is that it DOES NOT MATTER where you are > > in the network, the propogation time is entirely based on caching of the > > answers, and nothing else. > Yes it does ... see above. The time to refresh the cache on one server must be > considered along side all the other times to refesh for a complete > propogation to take place. I am not interested in just changing my small > section of the network, I want to change lookups all over the world. > > In the example above the server on your desk checked with the ISP which is > the way it often happens for most users. what if your server looked up > another DNS ( I don't just rely on Paradise for my DNS entries as that would > put all my eggs in one basket in case of failure ) then you would be even > more screwed when trying to pick up changes > > Shane Hollis > Notes Unlimited New Zealand > Ph: 021 465 547 > Email: [EMAIL PROTECTED] > -- Nick Rout <[EMAIL PROTECTED]>
