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

[Joseph Lorenzo Hall <[e-mail]>]

I definitely think some considerations in the guidelines document about intended status sounds good... it's something that I trip up on and would be good to write down for this audience. best, joe

________________________________________
From: hrpc <[e-mail]> on behalf of Karan Saini <[e-mail]>
Sent: Tuesday, October 29, 2019 9:05 AM
To: [e-mail]
Subject: [hrpc] Applying RFC8280 to draft-ietf-dnsop-serve-stale

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