Date: Sun, 11 Jul 2004 20:46:31 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Len Conrad <LConrad@Go2France.com> Cc: freebsd-questions@freebsd.org Subject: Re: DNS server Message-ID: <20040711194631.GA86108@happy-idiot-talk.infracaninophile.co.uk> In-Reply-To: <6.1.1.1.2.20040711134443.035b7ba8@81.255.84.73> References: <5ef172bb040711092955912d06@mail.gmail.com> <200407111256.09120.ecrist@secure-computing.net> <6.1.1.1.2.20040711130345.0434ea48@81.255.84.73> <200407111328.28485.ecrist@secure-computing.net> <6.1.1.1.2.20040711134443.035b7ba8@81.255.84.73>
next in thread | previous in thread | raw e-mail | index | archive | help
--lrZ03NoBR/3+SXJZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Jul 11, 2004 at 01:53:22PM -0500, Len Conrad wrote:
=20
> >a domain needs to be added to before it will function correctly.
> >This is known as propagation.
>=20
> the misnomer propagation is used by people who think DNS data needs time =
to=20
> be available, to "propagate", over several days or a week, for all of=20
> Internet. This is pure BS. There is no such concept in DNS.
For a brand new domain, you are exactly correct, or indeed for an RR
added to an existing domain. For modification to any RR within a
previously existing domain there may well be a delay perceived by the
end user while waiting out the TTL of any old data cached in various
servers between him and the authoritative servers. Those TTLs are
typically somewhere between an hour and several days. It's not
actually a propagation delay, but the effect is much the same.
As the administrator of a zone, you can avoid or mitigate the delay by
dropping the TTL on any zone sufficiently far in advance of any
important changes. You will see DNS traffic to your server increase
somewhat as network caches invalidate their stored data more often,
but that's the price of getting the fresh data out there promptly.
The worst case is where the NS records in the parent zone are modified
to point to a new set of authoritative servers, but the previous
authoritative servers are neither shut down nor loaded with the up to
date zone data. A cache may keep referring back to the old servers
and refreshing itself with what it has no way of telling is old data
for some time. It's a good idea when changing the servers for a
domain to make sure both the old and the new servers carry the latest
zone data for some suitable overlap period.
Cheers,
Matthew=09
--=20
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
--lrZ03NoBR/3+SXJZ
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFA8ZkXiD657aJF7eIRAkMSAJ9ot97G9rm/Jh6nz3ORdfGOgd+oSwCgk9bU
Z1+X23Vbem6LW80nom8d/zc=
=690j
-----END PGP SIGNATURE-----
--lrZ03NoBR/3+SXJZ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040711194631.GA86108>