NS records with different TTL

[Kevin Darcy]

Gaurav Pathak wrote:

>Hi,
>
>I have a question regarding TTL and NS records. I conducted following
>tests on my dns server and found the following.
>
>When you specify 2 NS records as different TTL as below:
>
>xyz.com.        1D      IN      NS      ns1.xyz.com.
>xyz.com.        2D      IN      NS      ns.xyz.com.
>
>The dig response is as follows:
>
>xyz.com.                86400   IN      NS      ns1.xyz.com.
>xyz.com.                86400   IN      NS      ns.xyz.com.
>
>When the NS records entered as below:
>
>xyz.com.        2D      IN      NS      ns1.xyz.com.
>xyz.com.        1D      IN      NS      ns.xyz.com.
>
>The dig response is as follows:
>
>xyz.com.                172800  IN      NS      ns.xyz.com.
>xyz.com.                172800  IN      NS      ns1.xyz.com.
>
>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?
>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?
>
 From RFC 2181:

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.

   Should a client receive a response containing RRs from an RRSet with
   differing TTLs, it should treat this as an error.  If the RRSet
   concerned is from a non-authoritative source for this data, the
   client should simply ignore the RRSet, and if the values were
   required, seek to acquire them from an authoritative source.  Clients
   that are configured to send all queries to one, or more, particular
   servers should treat those servers as authoritative for this purpose.
   Should an authoritative source send such a malformed RRSet, the
   client should treat the RRs for all purposes as if all TTLs in the
   RRSet had been set to the value of the lowest TTL in the RRSet.  In
   no case may a server send an RRSet with TTLs not all equal.

							- Kevin