Internet Engineering Task Force S. Huque Internet-Draft Salesforce Intended status: Informational M. Andrews Expires: 7 January 2027 Internet Systems Consortium 6 July 2026 Greasing Protocol Extension Points in the DNS draft-ietf-dnsop-grease-03 Abstract Long term evolvability of the Domain Name System (DNS) protocol requires the ability to support change. Greasing is one technique that exercises the regular use of unallocated protocol extension points to prevent ossification of their current usage patterns by middleboxes or DNS implementations. This document describes considerations and proposals for applying grease to the DNS protocol. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-grease. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Huque & Andrews Expires 7 January 2027 [Page 1] Internet-Draft DNS Greasing July 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Greasing Opportunities . . . . . . . . . . . . . . . . . . . 3 4. Randomized or Reserved code points . . . . . . . . . . . . . 5 5. Reserved Code Point Values . . . . . . . . . . . . . . . . . 7 6. Sampled Selection of Traffic . . . . . . . . . . . . . . . . 7 7. Telemetry and Results Evaluation . . . . . . . . . . . . . . 7 8. Detailed Behavior . . . . . . . . . . . . . . . . . . . . . . 7 9. Greasing Initiated By DNS Responders . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 12.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Long term evolvability of the Domain Name System (DNS) protocol requires the ability to support change. Greasing [GREASING] is one technique that exercises the regular use of unallocated protocol extension points to prevent ossification of their current usage patterns by middleboxes or DNS implementations. Greasing was originally developed for the TLS protocol [RFC8701]. Ongoing discussion of improving the technique as well as applying it more generally to other protocols continues in the IETF. This document outlines considerations and proposals for applying grease to the [RFC1034][RFC1035] Domain Name System (DNS). Huque & Andrews Expires 7 January 2027 [Page 2] Internet-Draft DNS Greasing July 2026 2. Background Historically, DNS protocol evolution has encountered some significant barriers. There are various reasons, including outdated systems, inertia, faulty implementations of DNS servers, middleboxes that have actively blocked the deployment of new protocol features, etc. Over time as some of these impediments have been uncovered and repaired, progress has been possible. However, a more systematic approach to ensure future progress is desirable. Remarkably, the Extension Mechanisms for DNS (EDNS) specification, originally published in 1999 [RFC2671] and later updated by [RFC6891], is still not universally deployed, and often deployed incorrectly or incompletely. This eventually resulted in the exercise of a DNS Flag Day effort [FLAGDAY] to identify and eradicate implementations and network paths not compliant with the specification. Tools like ednscomp.isc.org [EDNSCOMP] have been testing this and other protocol defects in deployed infrastructure for many years. Even then, some level of incorrect behavior remains prevalent, necessitating probing and pre-arrangement of the use of some extension features like [RFC7871]EDNS Client Subnet and [RFC7873]DNS Cookies. 3. Greasing Opportunities The DNS has a number of protocol elements where the greasing of unallocated code points could be employed. Some of them are listed in the table below. Huque & Andrews Expires 7 January 2027 [Page 3] Internet-Draft DNS Greasing July 2026 +==================+============+===================+=============+ | Protocol Element | Field Size | Total Code Points | Unallocated | | | | | (approx.) | +==================+============+===================+=============+ | DNS Header Flags | 1-bit each | 7 flag positions | 1 | +------------------+------------+-------------------+-------------+ | Opcode | 4-bit | 16 | 10 | +------------------+------------+-------------------+-------------+ | EDNS Version | 8-bit | 256 | 255 | +------------------+------------+-------------------+-------------+ | EDNS Header | 1-bit each | 16 flag positions | ~14 | | Flags | | | | +------------------+------------+-------------------+-------------+ | Class | 16-bit | 65,536 | ~65,530 | +------------------+------------+-------------------+-------------+ | Resource Record | 16-bit | 65,536 | ~64,700 | | Type | | | | +------------------+------------+-------------------+-------------+ | EDNS Opt Code | 16-bit | 65,536 | ~65,000 | +------------------+------------+-------------------+-------------+ Table 1 The unallocated column indicates roughly how many code points are currently available for greasing, and it varies enormously across protocol elements. Note that the header flag fields are not single multi-bit code points but collections of independent 1-bit flags, so their totals count flag positions rather than 2^n values. These counts are approximate and subject to change as IANA allocations proceed. The elements listed above are ones whose unknown values a conforming receiver is expected to tolerate transparently, which makes them suitable candidates for greasing. Some other DNS protocol elements are deliberately omitted. In particular, the RCODE and Extended RCODE fields are only meaningful when set by a responder, and altering them changes the querier's assessment of the status of the response; greasing these is therefore fraught and of little value. The goals of periodically exercising the use of unallocated code points are (1) to discourage and prevent middleboxes and DNS implementations from hardcoding notions of what are the only allowable protocol parameter values, and (2) to prevent future extensibility failures by not causing them to malfunction in the presence of new values when they are defined. Huque & Andrews Expires 7 January 2027 [Page 4] Internet-Draft DNS Greasing July 2026 If and when encrypted transports are common on the DNS resolver to authoritative server path, middleboxes will have less capability to interfere with DNS traffic. Greasing would still however continue to be useful for identifying deficient DNS proxies, load balancers, authoritative servers, etc. Note that EDNS [RFC6891] options have a more complex structure involving both a code point and data. So greasing EDNS options would also require generating some random option data. Correctly implemented DNS servers will ignore these values and interoperate. Servers that do not tolerate unknown values will fail to interoperate and return an error (or may fail to respond). These failures could be logged and be used to identify broken implementations in the field that could be targeted for repair. DNS resolvers should generally retry such failed queries without the unallocated extension, except for greasing operations where new queries are constructed (for example, greasing new resource record types). Where the additional latency of retrying failed queries is a concern, a resolver could instead issue the queries in parallel: a regular query without any greasing, alongside a separate greased query. The response to the regular query is used to serve the resolution as usual, while the outcome of the greased query is recorded purely for telemetry purposes. This avoids adding latency to the resolution when a greased query fails, at the cost of additional query volume. As with the sampled approach described in Section 6, only a small fraction of queries need be duplicated in this way to obtain a useful picture of non-compliant servers. 4. Randomized or Reserved code points DNS resolver implementations are proposed to periodically advertise unallocated code points at random in requests that they send out. The choice between reserving a dedicated range of code points for greasing and simply selecting at random from the unallocated space involves several competing considerations, and the right answer may differ from one protocol element to another. Arguments in favor of reserving a range include: Huque & Andrews Expires 7 January 2027 [Page 5] Internet-Draft DNS Greasing July 2026 * *Detectability.* If a receiver actively special-cases and ignores a known reserved grease range, that behavior becomes observable, whereas an implementation that silently drops any unknown value is harder to distinguish from one that is behaving correctly. In this sense, a receiver that mishandles the reserved range is itself a useful signal that greasing is doing its job. * *Avoiding collisions with real values.* Selecting at random from the entire unallocated space risks exercising a code point that is later allocated for genuine use. Deployed software that has learned to ignore that value during greasing may then mishandle it once it carries real meaning. A reserved range quarantines greasing values away from points that may be assigned in the future. Arguments against reserving a range include: * *Ossification of the reserved range itself.* If implementations hardcode the notion of "the grease range" and treat it specially, rather than handling all unknown code points uniformly, the reserved values can become ossified in exactly the way greasing is meant to prevent. * *Limited effectiveness against a determined implementation.* An implementation that wishes to single out and ignore greasing can do so regardless of whether the values are drawn from a reserved range or the full unallocated space; the size of the reserved range does not materially change this. Reserving primarily aids diagnosis and avoids accidental collisions rather than defeating deliberate special-casing. * *Element-specific constraints.* Some DNS protocol elements have only a small range of values (see the table in Section 3) and cannot readily spare a subset for reservation; for these, random selection or forgoing greasing may be the only practical options. Others have internal structure, such as the data/meta/QTYPE classification of the RR Type space, where a single reserved range would not exercise each sub-range; reserving for these elements is still feasible but would require designating multiple ranges. The concern about random selection colliding with future real allocations can be mitigated without a reserved range by equipping greasing implementations with a pre-configured or configurable end- of-test date, after which a given greasing operation is retired so that it does not interfere with subsequent code point assignments. The amount of the space to reserve, if any, might also be informed empirically by the observed frequency of greasing traffic. Huque & Andrews Expires 7 January 2027 [Page 6] Internet-Draft DNS Greasing July 2026 [The working group has not yet reached consensus on whether to reserve ranges, and if so for which protocol elements. This section will be updated to record that decision.] 5. Reserved Code Point Values [Propose reserved ranges for some DNS protocol elements] 6. Sampled Selection of Traffic To avoid the overhead of needing to retry many queries in the event of large scale intolerance of unallocated code points, only a sampled fraction of DNS requests emitted by a resolver should advertise unallocated code points. Many DNS resolvers are very high transaction rate systems, so only a small sample size of such DNS requests is sufficient to get a rough picture of non-compliant servers, perhaps 1 in 1000 requests? Furthermore, a community effort of aggregating and analysing the results of failed queries from many DNS resolver operators can provide an even more comprehensive view of the ecosystem. 7. Telemetry and Results Evaluation DNS resolvers are expected to record the results of failures from the use of unallocated code points. This could be in a traditional log file, or a more complex centralized telemetry system. Additionally, the DNS Error Reporting [ERROR-RPT] mechanism could be employed to proactively notify operators that their authoritative DNS servers are deficient. 8. Detailed Behavior Work in-progress section .. Some topics to expand on: * Detailed expected behavior of DNS resolvers/clients. * Detailed expected behavior of DNS servers. * Detection of errors. * Fallback behavior (or not). * Settings: nameservers should be shipped with a default end-of-test date to prevent tests from interfering with future code point assignments. * Testing should be multi-factored. Huque & Andrews Expires 7 January 2027 [Page 7] Internet-Draft DNS Greasing July 2026 * Tests should be able to be individually disabled. * Sharing telemetry. 9. Greasing Initiated By DNS Responders This document largely focusses on greasing initiated by the DNS resolver or querier. Greasing operations could also be initiated by an authoritative server or DNS responder. This seems potentially a bit more fraught, since the responder cannot necessarily know what the result of the greasing action was, e.g., did the querier accept the answer with no problems, did it not accept it and retry other servers, did it not accept it and just fail, causing a denial of service to the downstream application, etc. However, greasing in this direction can be very helpful in targeted experiments. For example, some early measurements for DELEG proposals utilized server side greasing to insert unexpected record types in referral responses to test the behavior of DNS resolvers. Operators of DNS zones could perform targeted active measurements or rely on reports by users to determine if server side greasing works well. Some things a responder could do include: test setting the final DNS header flag (Z), send back unknown EDNS header flags, options, higher EDNS versions, etc. All of these should in theory be ignored on reception. Greasing by DNS responders should be disabled by default. 10. Security Considerations If an implementation does not select GREASE values at random, it may allow others to fingerprint specific resolvers or resolver implementations. Some DNS resolver implementations have traditionally resorted to falling back to retrying queries with various extension options disabled in the face of interoperability problems. Depending on the specific extension affected, this may allow an adversary to silently disable a security feature. Greasing of unallocated code points aims to identify such interoperability problems and help DNS resolver operators and implementations to decide when it is ok to disable fallback behavior for future extensions. Hence, this mechanism is expected to generally reduce the need for resolver fallback behavior, and improve security over time. Huque & Andrews Expires 7 January 2027 [Page 8] Internet-Draft DNS Greasing July 2026 11. IANA Considerations [If reserved code point ranges are decided, IANA will need to formally reserve them in the relevant protocol parameter registries. The annotation "Reserved for Greasing" should be employed to clearly distinguish such ranges from other ranges that might be reserved for private use or other purposes.] 12. References 12.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . 12.2. Informative References [EDNSCOMP] Consortium, I. S., "EDNS Compliance Tester", . [ERROR-RPT] Arends, R. and M. Larson, "DNS Error Reporting", . [FLAGDAY] Consortium, I. S., "DNS Flag Day 2019", . [GREASING] Pardue, L., "Maintaining Protocols Using Grease and Variability", . [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, DOI 10.17487/RFC2671, August 1999, . Huque & Andrews Expires 7 January 2027 [Page 9] Internet-Draft DNS Greasing July 2026 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016, . [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, . [RFC8701] Benjamin, D., "Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility", RFC 8701, DOI 10.17487/RFC8701, January 2020, . Authors' Addresses Shumon Huque Salesforce Email: shuque@gmail.com Mark Andrews Internet Systems Consortium Email: marka@isc.org Huque & Andrews Expires 7 January 2027 [Page 10]