RFC 3225

Indicating Resolver Support of DNSSEC

📅 published December 2001, from ietf

RFC 3225: Indicating Resolver Support of DNSSEC 🎀

okay bestie, this is the one about how a resolver tells a server "hey, I can handle DNSSEC records" 🫶 so the server doesn't just dump them on everyone. here's the title block 👇

  • Network Working Group 🌸
  • RFC 3225, Indicating Resolver Support of DNSSEC
  • Author: D. Conrad (David Conrad), Nominum, Inc. 💅
  • Category: Standards Track ✨
  • Date: December 2001 📅
  • Obsoletes / Updates: the header doesn't list either one 🦋

Status of This Memo ✨

okay so this doc is an Internet standards track protocol for the Internet community 💖 it's also asking for discussion and suggestions for improvements 🙏 for the official standardization state of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚 and yes, distribution is unlimited 🌈

Copyright (C) The Internet Society (2001). All Rights Reserved. 💜

Abstract 🔮

okay the big idea: to deploy DNSSEC (Domain Name System Security Extensions) for real 🔥 DNSSEC aware servers should only do automatic inclusion of DNSSEC RRs when there's an explicit indication that the resolver can understand those RRs 🧚 this doc proposes using a bit in the EDNS0 header to send that explicit indication, and it describes the protocol changes needed to make that notification happen ✨

1. Introduction 🦋

so DNSSEC [RFC2535] is designed to give data integrity and authentication to security aware resolvers and applications, using cryptographic digital signatures 🔐 but here's the tea: as DNSSEC gets deployed, non-DNSSEC-aware clients are gonna query DNSSEC-aware servers 😭 and in that situation, the DNSSEC-aware server (answering a request for data in a signed zone) responds with SIG, KEY, and/or NXT records 💀 for reasons we'll get into later, those responses can cause big operational problems for the DNS infrastructure 🙈

this doc is about avoiding those problems. the plan is that DNSSEC-aware servers only respond with SIG, KEY, and/or NXT RRs when the resolver explicitly says it can understand them 💅

for this document, "DNSSEC security RRs" means RRs of type SIG, KEY, or NXT 🍓

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🌸

2. Rationale 💜

at the start of DNSSEC deployment, most queries are gonna come from resolvers that aren't DNSSEC aware 🥺 so they don't understand or support DNSSEC security RRs at all 😩 when one of those resolvers sends a query for a DNSSEC signed zone, the DNSSEC spec says the nameserver has to respond with the appropriate DNSSEC security RRs 💀 but DNS UDP datagrams are capped at 512 bytes [RFC1035] 📦 so responses with DNSSEC security RRs very likely get truncated, and then the resolver retries the query over TCP 😵‍💫

and TCP DNS queries are a whole mood 🙃 they come with a ton of overhead from connection setup and teardown ⏳ operationally, the extra TCP queries are gonna be rough: more network traffic (usually five packets for one query/response instead of two) 📈, more latency from the extra round trip times ⏱️, more queries failing from timeouts ❌, and way more load on nameservers 🔥

also, in the early experimental deployments of DNSSEC, people reported that non-DNSSEC aware resolvers couldn't handle responses containing DNSSEC security RRs 💔 in the worst case the resolver fails, and in the slightly better case the whole response gets ignored 😭

given all of that, it'd be prudent to explicitly tell the nameserver that the client is prepared to receive (if not understand) DNSSEC security RRs 🫶

client-side DNSSEC support is treated as binary 🔘 the client is either willing to receive all DNSSEC security RRs or willing to accept none of them 💅 so one bit is enough to signal client-side DNSSEC support ✨ effective DNSSEC use needs EDNS0 [RFC2671] anyway 🦋 and bits in the "classic" (non-EDNS enhanced DNS header) are scarce 🥀 plus, some non-compliant caching or forwarding servers might inappropriately copy data from classic headers as queries get passed on to authoritative servers 🙈 so the proposal uses a bit from the EDNS0 header instead 🎀

there was an alternative: treat the existence of an EDNS0 header as an implicit sign that the client supports DNSSEC 🤔 but that wasn't chosen, because some applications may support EDNS0 while using DNSSEC would be inappropriate for them 🚫

3. Protocol Changes 🧚

the way the client explicitly tells the server it can accept (if not understand) DNSSEC security RRs is by using the most significant bit of the Z field on the EDNS0 OPT header in the query ✨ this bit is called the "DNSSEC OK" (DO) bit 💖 in the EDNS0 OPT meta-RR, the DO bit is the first bit of the third and fourth bytes of the "extended RCODE and flags" portion 😍 it's laid out like this:

                +0 (MSB)                +1 (LSB)
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      0: |   EXTENDED-RCODE      |       VERSION         |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      2: |DO|                    Z                       |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

setting the DO bit to one in a query tells the server the resolver is able to accept DNSSEC security RRs 🌈 with the DO bit cleared (set to zero), the resolver is unprepared to handle them, and those RRs MUST NOT be returned in the response (unless DNSSEC security RRs are explicitly queried for) 🚫 and the DO bit of the query MUST be copied in the response 🫶

more specifically, DNSSEC-aware nameservers MUST NOT insert SIG, KEY, or NXT RRs to authenticate a response as specified in [RFC2535] unless the DO bit was set on the request 💅 security records that match an explicit SIG, KEY, NXT, or ANY query, or that are part of the zone data for an AXFR or IXFR query, are included whether or not the DO bit was set ✨

a recursive DNSSEC-aware server MUST set the DO bit on recursive requests, no matter what the DO bit was on the initiating resolver request 🔁 if the initiating request didn't have the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC security RRs before returning the data to the client 🧹 but cached data MUST NOT be modified 🔒

if a server replies to a query that has the DO bit set with NOTIMP, FORMERR or SERVFAIL, the resolver SHOULD NOT expect DNSSEC security RRs 🙅‍♀️ and it SHOULD retry the query without EDNS0, following section 5.3 of [RFC2671] 🔄

Security Considerations 🔐

⚠️ this part is seriously important, bestie 😤

the absence of DNSSEC data in a response to a query with the DO bit set MUST NOT be taken to mean there's no security information available for that zone 🚨 the response could be forged, or it could be a non-forged response to an altered query (one where the DO bit was cleared) 😱

IANA Considerations 🦋

EDNS0 [RFC2671] defines 16 bits as extended flags in the OPT record, and those bits get encoded into the TTL field of the OPT record (RFC2671 section 4.6) 🎀

this document reserves one of those bits as the OK bit 💖 it's requested that the left most bit be allocated 🙏 so the USE of the OPT record TTL field would look like this:

                +0 (MSB)                +1 (LSB)
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      0: |   EXTENDED-RCODE      |       VERSION         |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      2: |DO|                    Z                       |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Acknowledgements 🌸

this doc is based on a rough draft by Bob Halley 💜 with input from Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush, Rob Austein, Steve Bellovin, and Erik Nordmark 🫶

References 📚

[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. 🦋

[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987. 🌷

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑

[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. 🔐

[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. 🧩

Author's Address 💌

David Conrad
Nominum Inc.
950 Charter Street
Redwood City, CA 94063
USA

Phone: +1 650 381 6003
EMail: david.conrad@nominum.com

the legal text is kept word for word here so nothing gets changed 🫶

Copyright (C) The Internet Society (2001).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society. ✨

📦 where this page comes from