Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-stale-07.txt> (Serving Stale Data to Improve DNS Resiliency) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote:
>
> I am a bit puzzled by the lack of text that motivates treating TTLs
> with the high bit set as positive?  Why is this desirable, and why
> in this draft?  What is the connection between TTLs with the high
> bit set and Serve Stale?  If some resolver inadvertently returns
> stale data whose TTL has expired, it might return a negative TTL,
> and treating that as "0" seems safer than as 137 years (likely
> then capped to 7 days).

I guess this change is a result of trying to fill in the missing parts of
what a TTL means. I don't think this change is necessary: the draft could
be a bit less fussy without it.

The draft says:

   [RFC2181] aimed to provide "the precise definition of the Time to
   Live", but in Section 8 was mostly concerned with the numeric range
   of values and the possibility that very large values should be
   capped.  (It also has the curious suggestion that a value in the
   range 2147483648 to 4294967295 should be treated as zero.)

Which implies to me that the authors didn't spot the TTL bug in RFC 1035
that RFC 2181 was fixing with the curious suggestion.

RFC 1035 is inconsistent about the signedness of TTLs, so RFC 2181 fixed
it by specifying that TTLs are to be treated as unsigned (as usual for DNS
data) but must only use the range of positive signed 32 bit numbers.

Quoting from RFC 1035 to point out the curious copy and paste bug:

[ snip ]

3.2. RR definitions

3.2.1. Format

All RRs have the same top level format shown below:

[ snip ]

TTL             a 32 bit signed integer that specifies the time interval
                that the resource record may be cached before the source
                of the information should again be consulted.

[ snip ]

4.1.3. Resource record format

The answer, authority, and additional sections all share the same
format: a variable number of resource records, where the number of
records is specified in the corresponding count field in the header.
Each resource record has the following format:

[ snip a second copy of the same info ]

TTL             a 32 bit unsigned integer that specifies the time
                interval (in seconds) that the resource record may be
                cached before it should be discarded.

[ snip ]

Tony.
-- 
f.anthony.n.finch  <dot@xxxxxxxx>  http://dotat.at/
Rattray Head to Berwick upon Tweed: Southwesterly veering northwesterly later,
4 or 5, increasing 6 at times, becoming variable 3 or 4 for a time in south.
Slight or moderate, occasionally smooth in south. Rain later, otherwise mainly
fair. Good, occasionally poor later.




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux