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

[Viktor Dukhovni <[e-mail]>]

On Wed, Sep 11, 2019 at 08:22:37PM +0100, Tony Finch wrote:

> 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.
> [...]
>
> 4.1.3. Resource record format
> 
> 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.

These are the wire format for "TTLs in motion" (on the wire, in DNS
*messages*), where the residual TTL of a cached record could perhaps
become negative (and yet, sent in an answer).  Yes, it is unfortunate
the RFC1035 has two conflicting definitions.

If we allow unsigned TTLs in excess of 68 years for "TTLs at rest"
(in authoritative zone files), then I guess we're compelled to
tolerate them when copied into "TTLs in motion" in messages on the
wire, but my preference (had I the cycles to follow the WG phase
of this draft) would have been to make TTLs signed both at rest and
in motion, at the cost of ruling out use of TTLs >= 2^31s in zone
files.

That is, it may be safer to treat 68+ year TTLs (don't do that!)
as already expired, than to treat potentially "negative" TTLs as
large positive TTLs.

-- 
	Viktor.