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

[Puneet Sood <[e-mail]>]

On Wed, Sep 11, 2019 at 2:32 PM Viktor Dukhovni <[e-mail]> wrote:
>
> > On Sep 11, 2019, at 12:13 PM, The IESG <[e-mail]> wrote:
> >
> > 'Serving Stale Data to Improve DNS Resiliency' <draft-ietf-dnsop-serve-stale-07.txt>
>
> It looks to me like the list of resolvers that implement "Serve Stale"
> in Section 3 contains a typo.  Should "Know" be "Knot"?
Done

>
>                                                 A number of recursive
>    resolver packages (including BIND, Know, OpenDNS, Unbound) provide
>    options to use stale data.
>
> 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).

Discussed separately.

>
> Finally, in security considerations, there's no mention of
> the potential security impact of stale negative responses.
> Specifically, stale denial of existence of newly published
> TLSA records can delay their visibility to clients, and
> degrade transport security until the fresh records are
> finally available.  With RFC7672 MTA-to-MTA SMTP, a ServFail
> answer would avoid the downgrade and either use a different
> MX host or defer the delivery until such time as fresh records
> become available.  That said, this exposure exists only in a
> limited time window when TLSA records are initially published.

Added wording for negative caching to the first paragraph of "Security
Considerations".

-Puneet

>
> --
>         Viktor.
>