On Wed, Sep 11, 2019 at 2:32 PM Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote: > > > On Sep 11, 2019, at 12:13 PM, The IESG <iesg-secretary@xxxxxxxx> 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. >
