NS records with different TTL

Barry Margolin barmar at alum.mit.edu
Tue Mar 30 21:29:00 UTC 2004


In article <c4cj4e$mer$1 at sf1.isc.org>,
 "Gaurav Pathak" <gaurav.p at directi.com> wrote:

> Note the TTL value in response, it's the TTL of the first NS record. So
> what bind is doing here is parsing the TTL of first NS record and taking
> the same value as the TTL value for all the NS records. My question is:
> 
> 1) Why does bind behave in such fashion?
> 2) Is it possible to have 2 or more NS records for a zone with different
> TTL values?

RFC 2181 "Clarifications to the DNS Specification" says:

5.2. TTLs of RRs in an RRSet

   Resource Records also have a time to live (TTL).  It is possible for
   the RRs in an RRSet to have different TTLs.  No uses for this have
   been found that cannot be better accomplished in other ways.  This
   can, however, cause partial replies (not marked "truncated") from a
   caching server, where the TTLs for some but not all the RRs in the
   RRSet have expired.

   Consequently the use of differing TTLs in an RRSet is hereby
   deprecated, the TTLs of all RRs in an RRSet must be the same.

So it's not specific to NS records, it happens with records of any type.

> 3) Is this a thumbrule that 2 or more NS records MUST have the same TTL.
> If not then how can I make my bind understand different TTLs for NS
> records?

Why would you want to do this?  During the period between the two TTLs, 
you'll have no nameserver redundancy.  It won't go to the parent server 
until both records' TTLs expire.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***


More information about the bind-users mailing list