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