> 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"?
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).
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.
--
Viktor.
