My friend registered a domain recently. But they said the domain name
will take minimum 24 hours to 48 to update all around the world. But I
want to update all the DNS servers aroung the world in 5 minutes or
less. Can you tell me, Is there anyone providing the service for fast
update in DNS, as fast as I need it ?

---

Clarification of Question by nkans-ga on 18 Jul 2002 16:37 PDT

Why such a delay in the fast moving world? Is there really any
security reason or anything behind it? As soon as a domain is modified
all dns servers can be updated around the world right instantly which
is possible. Doesn't think bring a delay in doing business in web
community. Also this does not ends here, whenever a site is also
changed to a new place or a new hosting provider this cycle follows.
Does't this really a drawback to the web community or is there any
work going on this to reduce the delay?

---

Clarification of Question by nkans-ga on 24 Jul 2002 22:50 PDT

I'm still not satisfied with this DNS architecture for the delay in
DNS updates. When something can be done fast why not it cannot be
done. As per with the discussion I understand, that there are two
things involved.

* One it TTL cache time
* Second the 13 main root servers were updated only twice a day.

Is there any other reason involved for casuing such a delay of minimum
12 hours ?

There's no way for you to 'pay' for this service. Each ISP server is
run by a different administrator in a different location, and each ISP
updates their DNS servers at a different time, let's say once a day.
There's no way to expidite this.

skermit-ga

Even if it was immediately posted on the registration server (which it
often is)
ech of the thousands of DNS servers around the world have to be
updated, and pass on their updates, which they typicaly do once or
twice a day, sometimes one or more are down and miss a cycle, so it
takes time.  You may find that some people can find the updated site
info in a matter of minutes, if their ISp uses the same server as the
registration service, but to be assured of complete coverage count on
a couple of days.

One quick work-around when moving a site is to set up the new host
location before the change, and to have your old site re-directed to
the new location.
That would send users over immediately and as the update circulates,
they would automaticly go to the new one.

Zoneedit.com have a service where a domain name can be mapped to a
dynamic IP connection for hosting your own site via your DSL line, and
the change takes only a few seconds. I'm not sure how this works, but
it seems to work and be visible right after adopting the new IP
address. However this only works with a domain name that is already on
their nameservers. A fresh domain registration or transfer to their
nameservers still has to propogate throughout the internet 12- 48
hours.

There are currently over 20 million .com domains registered, and all
these are registered in the 13 known DNS root-servers. You can imagine
the load put on those servers!

Each time a new top-level domain is registered, it must be added to
all the root-servers. To minimize the disturbance on these, their
database are updated no more than two times a day.

But the real reason updates are slow, are due to DNS caching. It would
be a terrible waste of resources to always ask an authoritative
nameserver over and over for the same data. Therefore each little bit
of DNS data has associated with it a time-to-live (TTL) value, which
tells how long that answer is valid and may be used until a nameserver
should be consulted again.

Add to this the fact that nameservers form a hierarchy, and you have a
pretty complicated situation to fully understand. When your computer
requests the IP-number for www.google.com, it probably asks the
nameserver of your ISP. Unless the data is found in its cache, it must
be resolved. The resolving can in the worst case go back up via a
root-server. I.e. ask the root-server for a .com nameserver, ask that
.com nameserver for a nameserver for .google.com, and finally ask that
nameserver for the address of www.google.com. Each step in this chain
can be found in a nameservers cache, or it can be resolved giving a
TTL value specifying how long it can be cached.

If you already have a domain and plan to make some drastic change to
it, e.g. move your www-server to a new ip-number, there are some
tricks you can do to speed up the propagation of the updated data.
Well in advance of the change, say a week before, you begin by
lowering the TTL value of the DNS A-record for your www-address, say
to 10 minutes. This means any nameserver must refetch the data from
your nameserver if their cached data is older than 10 minutes. No need
to go an disturb any higher-level nameservers, because nothing there
has changed!

After you have switched the IP of your server, the changes should be
updated very quickly throughout the world. Immediately after the
switch, you can increase the TTL back to a higher value (a few days or
perhaps a week), otherwise you get unnecessary traffic to your
nameserver.

So, if you are in control of the DNS servers for your domain, you can
indeed make changes to your own domain and have those changes
propagate fairly quickly. It just needs some anticipation so you get
the lower TTL values in place and fully propagated before you make the
changes that need quick propagation.

Hope this clarifies some things!

Each DNS servers, including the arpa ROOT servers, cache information. 
They rely on the 'authoritative' DNS master of record. So the first
time a DNS server caches a name lookup, it keeps the entry based on
the ttl or time to live from the lookup. Until the ttl expires, 
depending on what the webmaster/sysadmin set it to of course, you're
outta luck. That's the reason why it takes time to propagate around
the world. The best you can do is set your ttl's to a very short
time span, like a few seconds - that will force a new lookup of your
site every time, but since you're forcing it you won't gain the speed
benefit of having it cached around the world.

Jack