In message <barmar-aafd0c.23180418062...@news.eternal-september.org>, Barry Mar
golin writes:
> In article <mailman.1066.1340036045.63724.bind-us...@lists.isc.org>,
> Phil Mayers <p.may...@imperial.ac.uk> wrote:
>
> > On 18/06/12 16:49, Alexander Gurvitz wrote:
> >
> > > with each query gets new NS record, and... refreshes the NS TTL ?
> >
> > No, that's not how TTLs work. They always count down.
>
> Didn't this used to be a problem? When the caching server queries the
> cached nameservers, the response would include the old NS records in the
> Authority section. The caching server would then replaced the cached NS
> records with these records, resetting the TTL to its full time. As long
> as it continued performing queries against the old servers before the NS
> records timed out, the TTLs would keep getting reset, and never expire.
>
> I remember many people having trouble trying to get everyone to follow
> their delegation changes when they changed DNS providers, and it was
> because the old provider didn't remove the zone from their servers.
>
> Are recent versions of BIND better about this? What about other caching
> DNS implementations?
It was partially fixed in 2002 which addresses the host provider
just keeps serving the old zone.
NS RRsets were only replaced if they changed (ignoring ttl) or had
higher credability.
The current releases address the issue where the zone's operators
are attempting to get new NS records cached by continually changing
their content.
3282. [bug] Restrict the TTL of NS RRset to no more than that
of the old NS RRset when replacing it.
[RT #27792] [RT #27884]
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
