RFC 3755

Legacy Resolver Compatibility for Delegation Signer (DS)

📅 published May 2004, from ietf

RFC 3755: Legacy Resolver Compatibility for Delegation Signer (DS) 💖

okay bestie, this is RFC 3755 and it's giving DNS security housekeeping 🧚✨ It's from the Network Working Group, written by S. Weiler at SPARTA, Inc., and it's a Standards Track doc dated May 2004. It updates RFC 3658 and RFC 2535. It doesn't obsolete anything, so nothing gets retired here 🫶

Status of This Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 📮

Copyright (C) The Internet Society (2004). All Rights Reserved. 🌸

Abstract

okay so the DNS Security (DNSSEC) specs have been evolving, and the syntax and semantics of the DNSSEC resource records (RRs) have changed along the way 🌈 Lots of deployed nameservers understand variants of these semantics. The danger is when a resolver that knows an earlier version queries an authoritative server that knows the new delegation signer semantics. That can get messy 💀, including at least one failure scenario that makes an unsecured zone unresolvable. This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to dodge those interactions 💅

1. Introduction ✨

The DNSSEC protocol has been through a lot of iterations, and the syntax and semantics aren't completely compatible from one to the next. That's just what happens when you propose a protocol, implement it, test it in the super complicated, super diverse Internet, and refine the definitions of the initial Proposed Standard 🧠 For DNSSEC it's extra tricky, because DNS is critical and widely deployed, and we still need to add security without making daily operations a nightmare.

A weak spot in previous DNS specs is that they didn't say much about resolver behavior, so implementors were pretty much on their own to figure out lots of details of resolver function 🙈 Combine that with all the DNSSEC iterations and you get fielded code with a wild variety of behaviors. That variety makes it hard to predict how a protocol change will be handled by every deployed resolver. The risk that a change causes unacceptable or even catastrophic failures makes it hard to design and deploy changes at all 😭 One strategy for managing that risk is to structure protocol changes so existing resolvers can completely ignore input that might confuse them or trigger undesirable failure modes. Smart, right? 👑

This document zooms in on one specific problem. Delegation Signer's (DS) [RFC3658] introduction of new semantics for the NXT RR is incompatible with the semantics in [RFC2535]. Answers from DS-aware servers can trigger an unacceptable failure mode in some resolvers that implement RFC 2535, and that's a huge disincentive to sign zones with DS 🙅‍♀️ The changes defined here allow DS to be deployed incrementally 🦋

1.1. Terminology

In this document, the term "unsecure delegation" means any delegation for which no DS record appears at the parent. An "unsecure referral" is an answer from the parent containing an NS RRset and a proof that no DS record exists for that name 🎀

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]. 📚

1.2. The Problem

Delegation Signer (DS) brings new semantics for the NXT RR that clash with the semantics in RFC 2535. In RFC 2535, NXT records were only required to be returned as part of a non-existence proof. With DS, an unsecure referral returns, in addition to the NS, a proof of non-existence of a DS RR in the form of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was to interpret a response with RCODE=0, AA=0, and both an NS and an NXT in the authority section. Some widely deployed 2535-aware resolvers interpret any answer with an NXT as proof of non-existence of the requested record 😱 This makes unsecure delegations invisible to 2535-aware resolvers, and it breaks the basic architectural principle that DNSSEC must do no harm. Signing a zone must not stop unsecured delegations from resolving 💔

2. Possible Solutions

This section walks through several solutions that were considered. Section 3 describes the one that got picked 🫶

2.1. Change SIG, KEY, and NXT type codes

To avoid the problem above, legacy (RFC2535-aware) resolvers need to be kept from seeing unsecure referrals that include NXT records in the authority section. The simplest way to do that is to change the type codes for SIG, KEY, and NXT 🔥

The obvious drawback is that new resolvers won't be able to validate zones signed with the old RRs. Honestly though, this problem already exists because of the DS changes, and resolvers that understand the old RRs (and have compatibility issues with DS) are way more prevalent than 2535-signed zones. So it's not really a new problem 🤷‍♀️

2.2. Change a subset of type codes

The observed problem with unsecure referrals could be fixed by changing only the NXT type code, or some other subset of the type codes that includes NXT. This looks simple on the surface, but it risks introducing new problems or not going far enough. It's quite possible that more incompatibilities exist between DS and earlier semantics 👀 Legacy resolvers may also get confused if they see records they recognize (SIG and KEY) but can't find any NXTs. It might seem unnecessary to fix something that isn't obviously broken, but it's far cleaner to change all of the type codes at once. That leaves legacy resolvers and tools completely blinded to DNSSEC, since they'll only see unknown RRs 🙈✨

2.3. Replace the DO bit

Another way to keep legacy resolvers from ever seeing DNSSEC records with DS semantics is to have authoritative servers send that data only to DS-aware resolvers. Someone proposed a new EDNS0 flag bit to signal DS-awareness (tentatively called "DA"), with authoritative servers sending DNSSEC data only in response to queries with the DA bit set. That would presumably supplant the DO bit described in [RFC3225] 💅

This only works if all 2535-aware resolvers zero out EDNS0 flags they don't understand. If one passed the DA bit through unchanged, it would still see the new semantics and would probably fail to see unsecure delegations 😬 Since it's impractical to know how every DNS implementation handles unknown EDNS0 flags, this isn't a universal solution. It could still be considered in addition to changing the RR type codes.

2.4. Increment the EDNS version

Another possible solution is to increment the EDNS version number defined in [RFC2671]. The assumption is that all existing implementations will reject higher versions than they support, and the DO bit stays as the signal for DNSSEC awareness. This approach has not been tested 🧪

2.5. Do nothing

There's a large deployed base of DNS resolvers that understand DNSSEC as defined by the standards track RFC 2535 and [RFC2065]. Because of under-specification in those documents, they interpret any answer with an NXT as a non-existence proof. As long as that's true, zone owners have a strong incentive not to sign any zones that contain unsecure delegations, or those delegations would be invisible to that huge installed base 😭 This would dramatically slow DNSSEC adoption.

Unfortunately, without signed zones there's no clear incentive for resolver operators to upgrade their software to support the new version of DNSSEC defined in RFC 3658. Historical data suggests resolvers are rarely upgraded, and old nameserver code never dies 💀

Rather than wait years for resolvers to be upgraded through natural processes before signing zones with unsecure delegations, this document fixes the problem with a protocol change. That immediately removes the disincentive to sign zones and allows widespread deployment of DNSSEC 🌈💖

4.2. DNS Security Algorithm Numbers ✨

okay bestie, so zone signing (DNSSEC) and transaction security (SIG(0) and TKEY) are gonna use different sets of algorithms 💅 That's why the "DNS Security Algorithm Numbers" registry is getting an upgrade. Two new columns get added to show whether each algorithm can be used for zone signing, transaction security mechanisms, or both 🦋 Only algorithms usable for zone signing may be used in DNSKEY, RRSIG, and DS RRs. Only algorithms usable for SIG(0) and/or TSIG may be used in SIG and KEY RRs.

All currently defined algorithms except for Indirect (algorithm 252) stay usable for transaction security mechanisms 🌸 Only RSA/SHA-1 [RFC3110], DSA/SHA-1 [RFC2536], and private algorithms (types 253 and 254) may be used for zone signing 👑 Also, the registry doesn't list each algorithm's requirement level, only whether it may be used for each purpose. So for example, RSA/MD5 is allowed for transaction security mechanisms but is NOT RECOMMENDED, per [RFC3110]. 🙈

Next, the presentation format algorithm mnemonics from [RFC2535] Section 7 get added to the registry 🧚 This document assigns RSA/SHA-1 the mnemonic RSASHA1.

Assigning new algorithms in this registry still requires IETF Standards Action ✨ Changing algorithm mnemonics or applicability also requires IETF Standards Action. Documents defining a new algorithm must address the algorithm's applicability and should assign it a presentation mnemonic 💖

4.3. DNSKEY Flags 🎀

Like the KEY resource record, DNSKEY has a 16-bit flags field 💅 This document creates a brand new registry just for the DNSKEY flags field.

At first, this registry only has one assignment, bit 7 (the ZONE bit) 🌈 Bits 0-6 and 8-15 are open for assignment by IETF Standards Action.

4.4. DNSKEY Protocol Octet 🍓

Like the KEY resource record, DNSKEY has an eight-bit protocol field 🫶 The only defined value is 3 (DNSSEC), and no other values are allowed. That means this field doesn't need an IANA registry 💀

5. Security Considerations 🔥

The changes introduced here don't materially affect security 😭 The implications of trying to use both new and legacy types together aren't well understood, and trying it would probably lead to unintended and dangerous results. Not me doing that 🙈

Changing type codes leaves code paths in legacy resolvers that never get exercised 💀 Unexercised code paths are a frequent source of security holes, mostly because nobody scrutinizes them often enough. Scary stuff, bestie 👑

Doing nothing, as described in section 2.5, will slow DNSSEC deployment ✨ That doesn't decrease security, but it also doesn't increase it 🥲

6. References 📚

6.1. Normative References

  • [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. 🦋
  • [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999. 💜
  • [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. 🧚
  • [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s)", RFC 2931, September 2000. 🎀
  • [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001. 🍓
  • [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", RFC 3658, December 2003. ✨

6.2. Informative References

  • [RFC2065] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997. 🌈
  • [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. 💅
  • [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001. 🫶
  • [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002. 🙈
  • [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. ⭐

7. Acknowledgments 🫶

The changes here and the analysis of alternatives had lots of contributors 💖 With apologies to anyone I've missed, they include: Michael Graff, Johan Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis, Bill Manning, Paul Vixie, and Suzanne Woolf. 👑

Big thanks to Jakob Schlyter and Mark Andrews for spotting the incompatibility described in section 1.2 🔥

The author also wants to thank Scott Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive comments ✨

8. Author's Address 🦋

Samuel Weiler
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
USA

EMail: weiler@tislabs.com

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property 🌸

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for implementers or users to use such proprietary rights can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Please send that information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💜

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

📦 where this page comes from