[hrpc] Applying RFC8280 to draft-ietf-dnsop-serve-stale

[Karan Saini <[e-mail]>]

Hi all,

This email documents some of the learnings from the application of the 
questions in RFC8280 and draft-irtf-hrpc-guidelines to 
draft-ietf-dnsop-serve-stale.


“Serving Stale Data to Improve DNS Resiliency” 
(draft-ietf-dnsop-serve-stale) [0] discusses recursive DNS resolvers 
serving “stale” data, along with use cases and considerations, and an 
example implementation for the same. In the context of this draft, 
“stale data” is used to refer to DNS records for which the specified TTL 
have elapsed, and where no authoritative server can be reached 
immediately for retrieving a fresh answer. A stated motivation behind 
implementing serve-stale is that of making the DNS “more resilient to 
DoS attacks.”


Connectivity

------------


Serving DNS records past their TTL can have positive implications when 
recursive resolvers cannot immediately reach an authoritative server for 
refreshing cached data. The rationale behind serving stale relies on the 
presumption that the underlying information will be identical to that 
which is stored in the recursive resolver’s cache. Thus, serving stale 
data can act as a failover mechanism for failures or downtime on part of 
authoritative servers.


If implemented properly, serve-stale should not have a detrimental 
effect on DNS resolution times for clients.


Security

--------


Stale records can allow malicious actors to keep “keep their [command 
and control] systems artificially alive even if the parent has removed 
the C&C domain name,” as pointed out by Ray Bellis. [1]


In the same email, Bellis also stated that serving stale records “must 
be predicated on the presence of a valid delegation from the parent 
zone.” [1] The presence of this delegation would provide a layer of 
agency to the operators of a given parent zone.


Another concern raised by some [2] was that DNS attacks, such as traffic 
hijacking, tampering or spoofing could potentially be prolonged if 
serve-stale is used, and that such attacks may potentially be encouraged 
by the publication of the document.


These concerns are broadly acknowledged in the “Security Considerations” 
section of the draft.


Conclusion

----------
This document presents a practice of some major DNS operators, who have 
had operational benefits from serving stale DNS data. The intended 
status for this document is that of a “Proposed Standard.” (See 
[RFC7127] for a definition)


Davey Song had previously raised the concern that serve-stale may be 
better suited for publication as an informational or experimental 
document, rather than it being a part of the standards track [2]. I 
initially agreed with this point [3], however, considering that the 
intended status for serve-stale is that of a Proposed Standard, which 
[RFC7127] defines as a specification that is “stable, has resolved known 
design choices,” which “has received significant community review, and 
appears to enjoy enough community interest to be considered valuable,” I 
believe that the current intended status of the RFC is suitable and 
appropriate.

This, however, has led to an interesting learning that can potentially 
be adapted to draft-irtf-hrpc-guidelines. The guidelines may benefit 
from a section exploring the different impacts a specification may have 
with consideration the intended status of publication.


Publication of a particular RFC under a certain status has certain 
consequences. For instance, publication as an Internet Standard as part 
of the Standards Track may signal to implementers that the specification 
has a certain level of maturity, operational experience, and consensus. 
Similarly, publication of a specification an experimental document as 
part of the non-standards track would signal to the community that the 
document “may be intended for eventual standardization but [may] not yet 
[be] ready,” [BCP9].


[BCP9] further defines when a document should be considered for 
publication as “experimental” (section 4.2.1) or “informational” 
(section 4.2.2). I believe the guidelines draft may benefit from the 
inclusion of text exploring considerations for the intended status of a 
specification.


[0] https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/

[1] https://mailarchive.ietf.org/arch/msg/dnsop/7lvN6sLwNzkxWh48wPelAFqWTAg

[2] https://mailarchive.ietf.org/arch/msg/dnsop/MENMA0etqVTIcBBnpc7RiWhJVqk

[3] https://mailarchive.ietf.org/arch/msg/dnsop/Zxa8EcjlaQtz4z-h7b3bgfyTux0

[RFC7127] https://tools.ietf.org/html/rfc7127

[BCP9] https://tools.ietf.org/html/bcp9

Regards,
Karan Saini