Caching

Kevin Darcy kcd at daimlerchrysler.com
Wed Aug 16 21:13:03 UTC 2000


RFC 2181, Section 5.4.1, "Ranking Data". The NS'es from the root servers
are non-authoritative, so the NS'es from the authoritative server will
replace them. That's why it's important for the zone NS'es to be correct
and to be either identical to, or a superset of the delegation NS'es.

Just to give a real-world example, we recently encountered a trading
partner who had used an IP address instead of a name for their one-and-only
NS record. Since we cached that bogus record, we couldn't resolve the
MX record for the zone, and as a result mail would only go through once a
day, when their one-day TTL expired and we got a fresh set of delegation
NS'es from the .com servers.


- Kevin

mkontos at my-deja.com wrote:

> If a recursive server receives a query for www.domainA.com and goes to
> the root servers for the for the authoritative servers for domainA, the
> response is cached, correct? The server will then go to one of the
> authoritative nameservers returned by the root server.  The
> authoratitive server returns the answer to the query as well as the NS
> records for domainA, correct?  At this point what will the cache contain
> on the recursive server for domainA, the IP for www.domainA.com and
> which NS records?  From the original root query or the response?
>
> The issue is the NS records in the zone file should be identical to
> those of the root servers, however when this is not the case, which NS
> records remain cached?
>
> MK
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.






More information about the bind-users mailing list