RFC 3130

Notes from the State-Of-The-Technology: DNSSEC

📅 published June 2001, from ietf

RFC 3130: Notes from the State-Of-The-Technology: DNSSEC 💖

okay bestie, this one is a Category: Informational doc from June 2001, written by E. Lewis from NAI Labs 🎀. The Network Working Group published it as Request for Comments 3130. The title block doesn't list anything it obsoletes or updates, so it's a standalone snapshot of where DNSSEC was at that time 🦋.

Status of This Memo ✨

this one is giving "FYI, not a rulebook" 💅. It provides information for the Internet community and does not specify an Internet standard of any kind. Distribution is unlimited, so share it with everyone 🌸.

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

Abstract 🦋

this is just a memo from a DNSSEC (Domain Name System Security Extensions) status meeting 💜. That's the whole vibe ✨.

1.0 Introduction 💖

so there was a meeting of the groups building DNS Security Extensions (DNSSEC), held alongside the 49th IETF 🌸. They talked about how far the work had gotten, what people are actually asking DNSSEC to do, and what the IETF needs in order to move the definition up to Draft Standard level 🚀. literally a main character moment for DNS 👑.

DNSSEC [RFC 2535] has been cooking for years, and RFC 2535 is the core of its most recent definition 🍓. DNSSEC is part of the charter of two working groups, DNSEXT and DNSOP 🧚. ISC's BIND v8.2 implemented part of the spec, and BIND v9 is the first full implementation 💅. In 1999 and 2000, more than half a dozen workshops tested the concepts and the earliest implementations 🙈. But so far, DNSSEC is not in common use 💀, which is kind of sad ngl 😭.

The current collective wisdom is that DNSSEC is 1) important, 2) a buzzword, 3) hard, 4) immature 💀. To get the real state of the tech and find where work is needed, an informal gathering of groups known to be involved in DNSSEC happened alongside the 49th IETF ✨. The attendees represented NLnet Labs, The Foundation for Internet Infrastructure, RIPE NCC, ARIN, CAIRN (ISI and NAI Labs), NIST, DISA, RSSAC, Network Associates and Verisign (COM/NET/ORG TLDs) 🫶.

The agenda had three items 🎀. Each group reported its current research goals, then the room discussed the questions being asked of DNSSEC, and finally they looked at what it would take to reach Draft Standard status, which was the goal 🦋.

This report is not a transcript of the meeting. It's a summary 💜. Some of the info came from direct contact with participants after the meeting ✨.

1.1 What does the term "DNSSEC" mean? 🤔

one thing people kept saying is that DNSSEC isn't one monolithic technology 💅. The term refers to a "toolbox" of techniques and methodologies that, when used properly, can improve the integrity of the DNS 🧰. Because of that, some parts of DNSSEC are evolving way faster than others 🚀. TSIG [RFC 2845] has definitely reached a level of "being deployable" for zone transfers 🔥.

The following four components are considered part of DNSSEC 🌈:

The concept of digital signature protection of DNS traffic, as described in RFC 2535 and a few support documents (such as [RFC 3008]), is designed to protect the transfer of data at Internet scale 🌍. Then there's protecting queries and responses with the less-scalable but more efficient TSIG mechanism [RFC 2845], which applies to zone transfers, DHCP registrations, and other resolver to name server traffic 💜. Secure dynamic updates [RFC 3007] count as part of DNSSEC because they use TSIG 🎀. Last, the CERT resource record definition [RFC 2538] lets DNS act as a distribution mechanism for security data 🦋.

This breakdown is in no way definitive 💅. honestly it's a somewhat artificial grouping 🙈. DNSSEC doesn't cover all the security practiced in DNS today. For example, the redefinition of when and how data is cached [RFC 2181] plays a big role in hardening the DNS system 🔒. The four elements above are grouped together mostly because they interrelate, and also because they were developed at about the same time ✨.

2.0 Group Reports 🌸

the first part of the meeting was reports of goals 📋. From these, the group put together a taxonomy of efforts to see if there are gaps in the work 🔍.

2.1 NLnet Labs 🌷

NLnet Labs is working to understand what DNSSEC does to ccTLDs, specifically .de (Germany), .nl (The Netherlands), and .se (Sweden) 🇩🇪🇳🇱🇸🇪. So far they've studied applying digital signatures and NXT records to a zone 🧁. The conclusion: there are no real problems with memory or CPU speed when signing large zones, not even for ".com." 💪. NLnet Labs offered to work with Verisign to dig deeper 🤝.

NLnet Labs is also trying to define and document procedures for TLD registries, registrars and registrants to properly handle things like zone-resigning and key-rollover at the root, TLD, and lower levels 📝. The outcome so far: the DNSOP Roll Over proposal seems impractical, or maybe even impossible, to implement at large TLDs 😬. NLnet Labs will produce a draft on an alternative KEY+SIG handling scheme where SIGs are only kept in the zone where the corresponding zone-KEY lives 🔑. This scheme cuts the actions needed for resigning zones from 2 levels (current zone and all children) down to 1 level (current zone) ✂️. For key-rollover, it cuts the work from 3 levels (parent, current zone and all children) to 2 levels (parent and current zone) 🎉.

2.2 Verisign 🏢

Verisign's registry operations and corporate components have been looking at what DNSSEC means for very large zones, not just from a hardware point of view but from an institutional one 🏛️. Since providing delegations is already a commercial service for them, they're trying to figure out what it would take to offer a DNSSEC service 💼. A big open question is parent validation of each delegated zone's keys 🔐.

2.3 The Foundation for Internet Infrastructure 🇸🇪

The Foundation for Internet Infrastructure is an organization in Sweden running a project with two parts 🌲. One part looks at the "topology" of the DNSSEC participants, and the other is about general development of tools 🛠️.

The study is looking at the administrative issues of running DNSSEC 📊. One issue is a possible 4-party interaction in using DNSSEC: the registry, the registrar, the registrant, and the DNS operator 👯. Any combination of these four may live inside one entity, like a registrant that runs its own DNS as part of its IT department 🏠.

The other part of the study looks at what happens in the resolver 🔍. Goals include DNSSEC-enabling tools like ISAKMPd (an IPSEC key negotiation software), secure NTP4, and e-mail 📧. Part of this effort is implemented in the sigz.net experiment, and info on it lives at www.sigz.net 🧪.

2.4 RSSAC 👑

The RSSAC (Root Server System Advisory Committee) has concluded that TSIG is worthwhile and should be deployed ✅. There's no schedule for deployment yet, though 🗓️.

As for the rest of DNSSEC, the RSSAC says we need a better understanding of the impact of the new features before they go into production 🧐. Right now, potential testbeds are being documented 📚. Two fundamental assumptions: a DNSSEC testbed involving the root servers is desirable, and such a testbed would allow for long-term testing ⏳. The second assumption comes from needing to understand how repeated zone key validations can happen at multiple independent levels of the DNS hierarchy 🌳.

2.5 CAIRN 🛰️

CAIRN (Collaborative Advanced Interagency Research Network) is a DARPA-sponsored network for collaborative research 🤓. One funded activity involving DNSSEC is FMESHD, shorthand for Fault-Tolerant Mesh of Trust in DNSSEC 🕸️. The goal is to figure out how to build a resolver's chain of trust when parts of the DNS tree are unavailable or unsecured 🔗. An early deliverable is an extension of secure shell to retrieve keys from DNSSEC 🐚. As part of this activity, DNSSEC is being implemented and studied in a non-major provider zone 🧑‍🔬.

2.6 NIST 📈

NIST is collecting performance info on DNSSEC 📉. One of the big fears about adopting DNSSEC is the workload it adds to existing DNS machine workload 😰. The hope is to quantify that fear and see whether it's real or imagined 🔬.

If time permits, there may be an effort to implement a zone integrity checking program (written in Java) that looks for missteps in the use of DNSSEC ☕. Base code exists, but it needs work beyond the current baseline 🛠️.

2.7 DISA 🎖️

The U.S. Defense Information Systems Agency is providing funds to have DNSSEC implemented in BIND 💰. Of particular interest: making sure the DNSSEC specifications are correct, that BIND adheres to those specifications, and that BIND is available on the operating systems used by the US Department of Defense 🇺🇸. DISA expects that every line of code developed through this effort will be made publicly available as part of stock BIND releases 🌍✨.

2.8 RIPE NCC 🇪🇺

The RIPE NCC is looking at the impact of DNSSEC on IP-registries 🗂️. It's planning to coordinate and assist in the deployment of DNSSEC 🤝. Because the RIPE NCC is the Regional Internet Registry for Europe, the focus will be on deploying DNSSEC on the reverse map tree (in-addr.arpa for IPv4) 🔄.

2.9 ARIN 🇺🇸

ARIN is investigating DNSSEC for signing its delegated zones under in-addr.arpa 🔏. It took part in a dnssec workshop following NANOG 20, held in Washington, DC in October, 2000 🏙️. It also took part in an ipv6-dnssec workshop that followed IETF 49 in San Diego, California ☀️. On top of that, ARIN has set up a server dedicated to testing various DNS experiments, including DNSSEC, and carrying out limited testing 🧪.

2.10 Network Associates 💻

NAI is pushing to get the tislabs.com zone running in accordance with DNSSEC 🚀. This is an example of a non-Internet service provider (neither an IP transit, IP address allocation, nor domain name managing entity) using DNSSEC within the normal operations of its Information Technology department 🏢. It's giving "real-world use case" 💅.

2.11 ip6.int. domain 🌐

The name servers authoritative for the ip6.int. domain are mostly upgraded to support CERT records and TSIG 🆙. Once that's fully done and the proposals are approved, TSIG and CERT records will be used ✅. Further DNSSEC work for this domain is unknown for now 🤷‍♀️.

Topology Based Domain Search (TBDS) is a DARPA-funded activity investigating how DNS may keep running in disconnected parts of the Internet 🔌. Topics of interest, either covered by this project or associated with it, include the use of split keys, self-signed zone (keys), and multiple signing algorithms 🔑. A goal is establishing signed infrastructure zones, which would make it easier to create a distributed CA for activities like IPSEC and FreeSwan 🔐🌈.

3.0 Taxonomy of efforts and What is missing ✨

okay so the efforts being undertaken cover a huge range of work areas 🌈, from big domain registries all the way down to domain name consumers 💅. Work on producing zones (signing, key management) is already going, and the use side (resolvers using DNSSEC secured data) is just starting 🫶.

From the discussion, there were no apparent areas lacking attention 💖. ngl though, more input is needed in some areas, especially around making use of DNSSEC (applications and IT departments) 🙈.

4.0 Questions facing DNSSEC 🔥

By the 49th IETF meeting, the most pressing question was "is it deployable?" 😭 Just from how much emphasis everyone put on it, the meeting made a list of questions and made sure every single one either had a known answer or had work underway to address it 💅.

4.1 Is it deployable? When? 🦋

The usual answer has been "not now." 💀 And "when" is always off in the future, like "about a year." Since the spring of 1999, a series of workshops has been held to try to reach a deployable point 🧚.

It's getting clearer that longer term workshops are needed 👑. When you go through the motions of any workshop, the number of issues raised that impact the protocol's specification is shrinking, and so are the implementation issues. So one or two day workshops have been helping less and less with reaching deployment 😩.

What's needed is longer term test configurations, maybe workshops held alongside other events that assume continuity 🌸. That way we can better assess the issues that involve the passage of time, like expirations on key validations, etc. ⏰

As noted in section 1.1 and touched on in section 2, TSIG is the more advanced piece of DNSSEC 👑. Using TSIG to protect zone transfers has already matured to the "really good idea to do" stage, even though the other elements of DNSSEC haven't. Using TSIG to protect traffic between a local resolver and its "default" recursive name server still needs more work though 🥺.

4.2 Does DNSSEC work? Is it the right approach? 🤔

There's a lot of effort going into making the specification work as proposed 💪. There's also some effort into assessing the spec at this point, especially the value of the NXT records and possible replacements for them 🔍.

There seems to be little question about the value of the KEY and SIG records ✨. Some research is still needed on KEY validation across zone boundaries, but at least that work is scheduled 📅.

4.3 How will client software make use of DNSSEC? 📱

There are a bunch of efforts to take existing applications and have them make direct use of DNSSEC to carry out their functions 🧩. One example is secure shell.

Whether or when DNSSEC will be understood by the (POSIX-like) operating system routines gethostbyname and similar ones hasn't been addressed yet 🤷‍♀️.

4.4 What are the remaining issues? 🧐

There are still a few protocol issues. The NXT resource record is designed to provide a way to authentically deny that data exists 🙅. The problem is that the proposed solution may be worse than the problem, in the eyes of some 💀. There's an alternative, the NO resource record, being considered in the DNSEXT working group 🎀. Right now DNSEXT is considering this question: Is there a need to authentically deny existence of data, and if so, which is better, NXT (the incumbent) or NO?

Another less defined issue is the mechanism for parent validation of children's signatures. The protocol elements are settling, but the operational considerations aren't, as the work mentioned in section 2 shows 🫠. DNSSEC interactions have also come up in discussions about a standard registry-registrar protocol 🌈.

5.0 Progressing to Draft Standard 🚀

The IETF goal for DNSSEC is to move the documents through the standards track [RFC 2026] 🛤️. RFC 2535 is currently the second iteration at the Proposed Standard level 🥈. It needs to cycle through Proposed once more, and after that the next goal is Draft.

To pass to the Draft Standard level, two main requirements must be met. There must be two or more interoperable implementations. There must also be sufficient successful operational experience ✅.

5.1 Revision of RFC 2535 via DNSEXT ✍️

DNSEXT will soon begin rewriting the RFC 2535 specification (and its support documents), rolling in updates and clarifications based on implementation and testing experience 📝.

5.2 Operations document(s) via DNSOP 🛠️

DNSOP will keep being the forum for operations documents based on DNSSEC activity. The community needs to bring more documents to this group 📚.

5.3 Interoperability 🤝

Demonstrating DNSSEC interoperability (two different implementations interacting while doing DNSSEC work) is tricky, because so far only BIND is seriously being fitted with DNSSEC 😬. There are other partial implementations of DNSSEC functionality, so partial interoperability demos might be possible 🧩.

During the meeting, folks realized that, given the goals stated, a second DNSSEC implementation is needed in 18 months ⏳. Various people in the room said they'd start looking into what could be done about it 👀.

6.0 Acknowledgements 🫶

The following people attended the meeting and/or provided text for this report (in no particular order): Mark Kosters (Network Solutions), Patrik Faltstrom (Cisco), Ted Lindgreen and Miek Gieben (NLnet Labs), Jaap Akerhuis (SIDN), Olaf Kolkmann (RIPE NCC), Bill Manning and Dan Massey (ISI), Martin Fredriksson, Hakan Olsson and Jakob Schlyter (Carlstedt Research & Technology), Doug Montgomery and Scott Rose (NIST), Johan Ihren and Lars-Johan Liman (Autonomica), Brian Wellington (Nominum), Kevin Meynell (CENTR), Ed Lewis and Olafur Gudmundsson (NAI Labs). Huge thank you, besties 💖

7.0 IANA Considerations 🎟️

This document doesn't involve assigned numbers in any way 🙌.

8.0 Security Considerations 🔐

This document is a discussion of security enhancements to the DNS, but it does not itself impact security 🙈 Phew, but still, don't get comfy. Where security issues arise, they will be discussed in the Security Considerations of the appropriate document, so keep your eyes peeled 👀💀

9.0 References 📚

The text of any RFC can be retrieved by a web browser by requesting the URL ftp://ftp.isi.edu/in-notes/rfc<wxyz>.txt, where "wxyz" is the number of the RFC.

[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision
           3", BCP 9, RFC 2026, October 1996.

[RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS
           Specification", July 1997.

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

[RFC 2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in
           the Domain Name System", March 1999.

[RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
           Wellington, "Secret Key Transaction Authentication for DNS
           (TSIG)", May 2000.

[RFC 3007] Wellington, B., "Secure Domain Name System Dynamic
           Update", November 2000.

[RFC 3008] Wellington, B., "Domain Name System Security Signing
           Authority", November 2000.

10.0 Editor's Address 📬

Edward Lewis
3060 Washington Rd (Rte 97)
Glenwood, MD 21738

Phone: +1(443)259-2352
EMail: lewis@tislabs.com

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

Anyone can copy and give this document, and translations of it, to others 💜. You can also make derivative works that comment on or explain it, or help with implementing it, and publish and distribute those in whole or in part without restriction of any kind, as long as the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when translating 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 🌈✨ the end, bestie ✨🌈

📦 where this page comes from