RFC 3833

RFC 3833: Threat Analysis of the Domain Name System (DNS) 🎀

Okay bestie, this is RFC 3833, and it's giving "we finally wrote down the threats" energy 💅. It's from the Network Working Group and it's labelled Informational (so it's info, not a standard, no cap). The authors are D. Atkins from IHTFP Consulting and R. Austein from ISC, and it's dated August 2004. The title block doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFC 🦋.

Status of this Memo 🌸

This memo is here to give info to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited ✨.

Copyright Notice 🌈

Copyright (C) The Internet Society (2004).

Abstract 💜

Okay so DNSSEC (the DNS Security Extensions) has been in development for most of the last decade, and the IETF never actually wrote down the specific threats it's supposed to protect against 😭. It's giving cart-before-the-horse. That made it super hard to tell whether DNSSEC even hits its design goals, since nobody really pinned those goals down. This note tries to document some of the known threats to the DNS, and, while it's at it, measures how useful (if at all) DNSSEC is for defending against them 🔥.

1. Introduction ✨

Okay, the earliest organized DNSSEC work in the IETF was an open design team meeting, set up by people from the DNS working group in November 1993 at the 28th IETF meeting in Houston 🧚. The big picture of DNSSEC as we know it today was already clear in Jim Galvin's summary of what came out of that meeting [Galvin93]:

• Some folks at the meeting cared about keeping DNS data away from unauthorized parties, but the design team made an explicit decision that "DNS data is `public'". They ruled every threat of data disclosure explicitly out of scope for DNSSEC 🙈.
• Some folks wanted authentication of DNS clients and servers as a basis for access control, but that work was also ruled out of scope for DNSSEC per se 💀.
• Backwards compatibility and co-existence with "insecure DNS" was listed as an explicit requirement 🫶.
• The resulting list of desired security services was:
  • 1) data integrity, and
  • 2) data origin authentication.
• The design team noted that a digital signature mechanism would support the desired services 🍓.

Okay so a bunch of detail decisions were still TBD (and in some cases got remade after people actually implemented stuff) over the next decade, but the basic model and design goals stayed locked in 🔒.

Here's the tea though: none of the DNSSEC work actually tries to spell out in any detail the kinds of attacks DNSSEC is meant to protect against, or why the list of desired security services came out of that Houston meeting the way it did 😤. For that, you have to go back to a paper Steve Bellovin originally wrote in 1990, which didn't get published until 1995, for reasons Bellovin explained in the paper's epilogue [Bellovin95] 📜.

It might seem a bit strange to publish a threat analysis a whole decade after starting work on the protocol that's supposed to defend against those threats, but that's exactly what this note is doing. Better late than never 🎀.

This note assumes you already know both DNS and DNSSEC, and it does not try to be a tutorial on either 💅. The DNS documents most relevant to this topic are: [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308], [RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535] 📚.

For the sake of discussion, this note uses "DNSSEC" to mean the core hierarchical public key and signature mechanism from the DNSSEC documents. It treats TKEY and TSIG as separate mechanisms 🔑. Honestly, channel security mechanisms like TKEY and TSIG are also part of the bigger problem of "securing DNS," so people often lump them into the overall set of "DNS security extensions." This split is kinda arbitrary 🤷‍♀️. It partly reflects how the protocol evolved, with a supposedly simpler channel security model added for certain operations like zone transfers and dynamic update requests. It maybe should change in a future revision of this note 🌸.

2. Known Threats 🔥

There are several distinct classes of threats to the DNS. Most of them are DNS-flavoured versions of more general problems, but a few are specific to quirks of the DNS protocol itself 💖.

2.1. Packet Interception 🕵️‍♀️

Some of the simplest DNS threats are different forms of packet interception: monkey-in-the-middle attacks, eavesdropping on requests combined with spoofed responses that beat the real response back to the resolver, and so on 😱. In any of these scenarios, the attacker can just tell either party (usually the resolver) whatever they want that party to believe. Packet interception attacks aren't unique to DNS, but DNS usually sends an entire query or response in a single unsigned, unencrypted UDP packet. That makes these attacks super easy for any bad guy who can intercept packets on a shared or transit network 💀.

It gets worse, bestie. The DNS query the attacker intercepts might just be a means to an end for them. The attacker could even return the correct result in the answer section of a reply, while using other parts of the message to set the stage for something more complicated, like a name chaining attack (see section 2.3) 🐍.

Sure, it would be possible to sign DNS messages with a channel security mechanism like TSIG or IPsec, or even encrypt them with IPsec. But that wouldn't be a very good solution for interception attacks 🙅‍♀️. First, it would add a fairly high processing cost per DNS message, plus a very high cost for setting up and maintaining bilateral trust relationships between every party that might be involved in resolving any given query. For heavily used name servers (like the servers for the root zone), that cost would almost certainly be prohibitively high 😩. Even more important, the trust model in that design would be wrong. At best it would only give a hop-by-hop integrity check on DNS messages, and it would not give any kind of end-to-end integrity check between the producer of DNS data (the zone administrator) and the consumer of DNS data (the application that triggered the query) 🙃.

By contrast, DNSSEC (when used properly) does provide an end-to-end data integrity check, so it's a much better solution for this class of problems during basic DNS lookup operations 💖.

TSIG does have its place, though 🎀. It fits in corners of the DNS protocol where there's a specific trust relationship between a particular client and a particular server. Examples are zone transfer, dynamic update, or a resolver (stub or otherwise) that isn't going to check all the DNSSEC signatures itself 🫶.

Note that DNSSEC does not protect against modification of the DNS message header, so any properly paranoid resolver must:

• Perform all of the DNSSEC signature checking on its own,
• Use TSIG (or some equivalent mechanism) to ensure the integrity of its communication with whatever name servers it chooses to trust, or
• Resign itself to the possibility of being attacked via packet interception (and via other techniques discussed below) 😭.

2.2. ID Guessing and Query Prediction 🎯

Since DNS is mostly used over UDP/IP, it's pretty easy for an attacker to generate packets that match the transport protocol parameters 👀. The ID field in the DNS header is only a 16-bit field, and the server UDP port for DNS is a well-known value. That means there are only 2**32 possible combinations of ID and client UDP port for a given client and server. That's not a particularly big range, and it isn't enough to stop a brute force search. Plus, in practice, both the client UDP port and the ID can often be predicted from previous traffic. It's also not uncommon for the client port to be a known fixed value (thanks, firewalls and other restrictions), which often shrinks the search space to something smaller than 2**16 😬.

By itself, ID guessing isn't enough for an attacker to inject bogus data. But when you combine it with knowledge (or guesses) about the QNAMEs and QTYPEs a resolver might be querying, the resolver is only weakly defended against injection of bogus responses 🙈.

This attack relies on predicting a resolver's behaviour, so it's most likely to work when the victim is in a known state. That could be because the victim rebooted recently, or because the attacker influenced the victim's behaviour with some other action, or because the victim is responding (in a predictable way) to some third party action the attacker knows about 🧚.

This attack is both harder and easier for the attacker than the simple interception attack described above. It's harder because the attack only works if the attacker guesses correctly. It's easier because the attacker doesn't need to be on a transit or shared network 🦋.

In most other respects, this attack looks a lot like a packet interception attack. A resolver that checks DNSSEC signatures will be able to detect the forged response. Resolvers that don't do DNSSEC signature checking themselves should use TSIG or some equivalent mechanism to make sure their communication with a recursive name server that does do DNSSEC signature checking has integrity 🫶💅

2.3. Name Chaining

okay bestie, the most iconic class of DNS-specific threats is the name chaining attacks 💅🔥 These are a subset of a bigger group of name-based attacks, sometimes called "cache poisoning" attacks 🧪 Most name-based attacks can be partly mitigated by the classic move of checking RRs in response messages for relevance to the original query, but those checks do not catch name chaining attacks 😭 There are a few versions of the basic attack, but they all share one thing: they involve DNS RRs whose RDATA portion (right hand side) includes a DNS name (or, in a few cases, something that is not a DNS name but directly maps to one) 🎀 Any RR like that is, at least in principle, a hook that lets an attacker feed bad data into a victim's cache, which can potentially mess up later decisions based on DNS names 🙈

The worst examples are CNAME, NS, and DNAME RRs, because they can redirect a victim's query to a location of the attacker's choosing 💀 MX and SRV are somewhat less dangerous, but in principle they can also trigger further lookups at a location of the attacker's choosing 🦋 Address RR types such as A or AAAA don't have DNS names in their RDATA, but since the IN-ADDR.ARPA and IP6.ARPA trees are indexed using a DNS encoding of IPv4 and IPv6 addresses, these record types can also be used in a name chaining attack 🌸

The general form of a name chaining attack goes something like this:

• Victim issues a query, perhaps at the instigation of the attacker or some third party; in some cases the query itself may be unrelated to the name under attack (that is, the attacker is just using this query as a means to inject false information about some other name) ✨
• Attacker injects response, whether via packet interception, query guessing, or by being a legitimate name server that's involved at some point in the process of answering the query that the victim issued 👀
• Attacker's response includes one or more RRs with DNS names in their RDATA; depending on which particular form this attack takes, the object may be to inject false data associated with those names into the victim's cache via the Additional section of this response, or may be to redirect the next stage of the query to a server of the attacker's choosing (in order to inject more complex lies into the victim's cache than will fit easily into a single response, or in order to place the lies in the Authority or Answer section of a response where they will have a better chance of sneaking past a resolver's defenses) 😈

Any attacker who can insert resource records into a victim's cache can almost certainly do some kind of damage, so there are cache poisoning attacks which are not name chaining attacks in the sense discussed here 🫠 However, in the case of name chaining attacks, the cause and effect relationship between the initial attack and the eventual result may be significantly more complex than in the other forms of cache poisoning, so name chaining attacks merit special attention 🔮

The common thread in all of the name chaining attacks is that response messages allow the attacker to introduce arbitrary DNS names of the attacker's choosing and provide further information that the attacker claims is associated with those names; unless the victim has better knowledge of the data associated with those names, the victim is going to have a hard time defending against this class of attacks 🥺

This class of attack is particularly insidious given that it's quite easy for an attacker to provoke a victim into querying for a particular name of the attacker's choosing, for example, by embedding a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail to the victim 📧 If the victim's mail reading program attempts to follow such a link, the result will be a DNS query for a name chosen by the attacker 🫣

DNSSEC should provide a good defense against most (all?) variations on this class of attack 🛡️ By checking signatures, a resolver can determine whether the data associated with a name really was inserted by the delegated authority for that portion of the DNS name space. More precisely, a resolver can determine whether the entity that injected the data had access to an allegedly secret key whose corresponding public key appears at an expected location in the DNS name space with an expected chain of parental signatures that start with a public key of which the resolver has prior knowledge 🔐

DNSSEC signatures do not cover glue records, so there's still a possibility of a name chaining attack involving glue, but with DNSSEC it is possible to detect the attack by temporarily accepting the glue in order to fetch the signed authoritative version of the same data, then checking the signatures on the authoritative version 🕵️‍♀️✨

---

2.4. Betrayal By Trusted Server

Another variation on the packet interception attack is the trusted server that turns out not to be so trustworthy, whether by accident or by intent 🥀 Many client machines are only configured with stub resolvers, and use trusted servers to perform all of their DNS queries on their behalf. In many cases the trusted server is furnished by the user's ISP and advertised to the client via DHCP or PPP options 📡 Besides accidental betrayal of this trust relationship (via server bugs, successful server break-ins, etc), the server itself may be configured to give back answers that are not what the user would expect, whether in an honest attempt to help the user or to promote some other goal such as furthering a business partnership between the ISP and some third party 🙃

This problem is particularly acute for frequent travelers who carry their own equipment and expect it to work in much the same way wherever they go 🧳✈️ Such travelers need trustworthy DNS service without regard to who operates the network into which their equipment is currently plugged or what brand of middle boxes the local infrastructure might use 💼

While the obvious solution to this problem would be for the client to choose a more trustworthy server, in practice this may not be an option for the client 🤷‍♀️ In many network environments a client machine has only a limited set of recursive name servers from which to choose, and none of them may be particularly trustworthy. In extreme cases, port filtering or other forms of packet interception may prevent the client host from being able to run an iterative resolver even if the owner of the client machine is willing and able to do so 🚫 Thus, while the initial source of this problem is not a DNS protocol attack per se, this sort of betrayal is a threat to DNS clients, and simply switching to a different recursive name server is not an adequate defense 💔

Viewed strictly from the DNS protocol standpoint, the only difference between this sort of betrayal and a packet interception attack is that in this case the client has voluntarily sent its request to the attacker 😬 The defense against this is the same as with a packet interception attack: the resolver must either check DNSSEC signatures itself or use TSIG (or equivalent) to authenticate the server that it has chosen to trust 🔑 Note that use of TSIG does not by itself guarantee that a name server is at all trustworthy: all TSIG can do is help a resolver protect its communication with a name server that it has already decided to trust for other reasons. Protecting a resolver's communication with a server that's giving out bogus answers is not particularly useful 🗑️

Also note that if the stub resolver does not trust the name server that is doing work on its behalf and wants to check the DNSSEC signatures itself, the resolver really does need to have independent knowledge of the DNSSEC public key(s) it needs in order to perform the check. Usually the public key for the root zone is enough, but in some cases knowledge of additional keys may also be appropriate 🗝️

It is difficult to escape the conclusion that a properly paranoid resolver must always perform its own signature checking, and that this rule even applies to stub resolvers 🫡👑

---

2.5. Denial of Service

As with any network service (or, indeed, almost any service of any kind in any domain of discourse), DNS is vulnerable to denial of service attacks 😩 DNSSEC does not help this, and may in fact make the problem worse for resolvers that check signatures, since checking signatures both increases the processing cost per DNS message and in some cases can also increase the number of messages needed to answer a query 🐌 TSIG (and similar mechanisms) have equivalent problems.

DNS servers are also at risk of being used as denial of service amplifiers, since DNS response packets tend to be significantly longer than DNS query packets 📦📈 Unsurprisingly, DNSSEC doesn't help here either 🙄

---

2.6. Authenticated Denial of Domain Names

Much discussion has taken place over the question of authenticated denial of domain names 🗣️ The particular question is whether there is a requirement for authenticating the non-existence of a name. The issue is whether the resolver should be able to detect when an attacker removes RRs from a response 🕳️

General paranoia aside, the existence of RR types whose absence causes an action other than immediate failure (such as missing MX and SRV RRs, which fail over to A RRs) constitutes a real threat 😳 Arguably, in some cases, even the absence of an RR might be considered a problem. The question remains: how serious is this threat? Clearly the threat does exist; general paranoia says that some day it'll be on the front page of some major newspaper, even if we cannot conceive of a plausible scenario involving this attack today 📰 This implies that some mitigation of this risk is required 🚨

Note that it's necessary to prove the non-existence of applicable wildcard RRs as part of the authenticated denial mechanism, and that, in a zone that is more than one label deep, such a proof may require proving the non-existence of multiple discrete sets of wildcard RRs 🃏

DNSSEC does include mechanisms which make it possible to determine which authoritative names exist in a zone, and which authoritative resource record types exist at those names 🔍 The DNSSEC protections do not cover non-authoritative data such as glue records 🧩

2.7. Wildcards ✨

okay so wildcards are a whole saga 🙈 people have argued for ages about whether and how to give data integrity and data origin authentication to "wildcard" DNS names. Conceptually, RRs with wildcard names are patterns for synthesizing RRs on the fly, following the matching rules in section 4.3.2 of RFC 1034. The rules have some quirks that can totally trap an unwary zone admin 💀 but a lot of sites lean on wildcard RRs really hard, especially wildcard MX RRs. 🍓

To provide the services people want for wildcard RRs, we need to do two things:

• We need a way to attest to the existence of the wildcard RR itself (basically, we need to prove the synthesis rule exists), and
• We need a way to attest to the non-existence of any RRs which, if they existed, would make the wildcard RR irrelevant under the synthesis rules that govern how wildcard RRs get used (basically, we need to prove the synthesis rule is applicable).

This makes the wildcard mechanisms depend on the authenticated denial mechanism from the previous section, so they're kind of a package deal 🎀

DNSSEC has mechanisms along these lines 🦋 which let a resolver verify that a name server applied the wildcard expansion rules correctly when it generated an answer. Iconic behavior, honestly. 👑

3. Weaknesses of DNSSEC 💀

Okay, but DNSSEC has its own problems too, bestie, and we have to be real about them 🫶

• DNSSEC is complex to implement and has some nasty edge cases at the zone cuts that need very careful coding. Testbed experience so far suggests that trivial zone configuration errors or expired keys can cause serious problems for a DNSSEC-aware resolver, and that the current protocol's error reporting may leave something to be desired.
• DNSSEC significantly increases the size of DNS response packets. Among other issues, this makes DNSSEC-aware DNS servers even more effective as denial of service amplifiers. 😭
• DNSSEC answer validation increases the resolver's workload, since a DNSSEC-aware resolver has to perform signature validation and, in some cases, also issue further queries. That extra work also increases the time it takes to get an answer back to the original DNS client, which is likely to trigger timeouts and re-queries in some cases. Arguably, many current DNS clients are already too impatient even before the further delays DNSSEC will add are taken into account, but that topic is beyond the scope of this note. 🙄
• Like DNS itself, DNSSEC's trust model is almost totally hierarchical. DNSSEC does let resolvers have special additional knowledge of public keys beyond those for the root, but in the general case the root key is the one that matters. So any compromise in any of the zones between the root and a particular target name can damage DNSSEC's ability to protect the integrity of data owned by that target name. This isn't a change, since insecure DNS has the same model. 🌸
• Key rollover at the root is really hard. Work to date has not even come close to adequately specifying how the root key rolls over, or even how it's configured in the first place. 😩
• DNSSEC creates a requirement for loose time synchronization between the validating resolver and the entity creating the DNSSEC signatures. Before DNSSEC, all time-related actions in DNS could be performed by a machine that only knew about "elapsed" or "relative" time. Because the validity period of a DNSSEC signature is based on "absolute" time, a validating resolver must have the same concept of absolute time as the zone signer in order to determine whether the signature is within its validity period or has expired. An attacker that can change a resolver's opinion of the current absolute time can fool the resolver using expired signatures. An attacker that can change the zone signer's opinion of the current absolute time can fool the zone signer into generating signatures whose validity period does not match what the signer intended. ⏰💀
• The possible existence of wildcard RRs in a zone complicates the authenticated denial mechanism considerably. For most of the decade DNSSEC has been under development, these issues were poorly understood. At various times there have been questions about whether the authenticated denial mechanism is completely airtight, and whether it would be worthwhile to optimize it for the common case where wildcards are not present in a zone. However, the main problem is just the inherent complexity of the wildcard mechanism itself. This complexity probably makes the code for generating and checking authenticated denial attestations somewhat fragile. Still, giving up wildcards entirely isn't practical given how widely they're used, so we are going to have to live with wildcards. The real question is whether the proposed optimizations would make DNSSEC's mechanisms more or less fragile. 🧐
• Even with DNSSEC, the class of attacks discussed in section 2.4 is not easy to defeat. For DNSSEC to be effective in this case, it must be possible to configure the resolver to expect certain categories of DNS records to be signed. This may require manual configuration of the resolver, especially during the initial DNSSEC rollout period, when the resolver cannot reasonably expect the root and TLD zones to be signed. 🔧

4. Topics for Future Work 🔮

This section lists a few subjects not covered above that probably need additional study, additional mechanisms, or both. Future-us problems, basically. 🧚

4.1. Interactions With Other Protocols 🌈

The discussion above has concentrated exclusively on attacks within the boundaries of the DNS protocol itself, since those are (some of) the problems DNSSEC was intended to protect against. There are, however, other potential problems at the boundaries where DNS interacts with other protocols. 👀

4.2. Securing DNS Dynamic Update 🔐

DNS dynamic update opens a number of potential problems when combined with DNSSEC. Dynamic update of a non-secure zone can use TSIG to authenticate the updating client to the server. TSIG doesn't scale very well, since it requires manual configuration of shared keys between the DNS name server and each TSIG client. But it works well in a limited or closed environment, like a DHCP server updating a local DNS name server. 🏠

Major issues show up when you try to use dynamic update on a secure zone. TSIG can similarly be used in a limited fashion to authenticate the client to the server, but TSIG only protects DNS transactions, not the actual data. The TSIG is also not inserted into the DNS zone, so resolvers cannot use the TSIG to verify the changes to the zone. This means that either:

a) The updating client must have access to a zone-signing key in order to sign the update before sending it to the server, or

b) The DNS name server must have access to an online zone-signing key in order to sign the update.

In either case, a zone-signing key must be available to create signed RRsets to place in the updated zone. The fact that this key must be online (or at least available) is a potential security risk. 😬

Dynamic update also requires an update to the SERIAL field of the zone's SOA RR. In theory, this could also be handled by either of the above options, but in practice (a) would almost certainly be extremely fragile, so (b) is the only workable mechanism. 🙃

There are other threats when it comes to describing the policy of who can make what changes to which RRsets in the zone. The current access control scheme in Secure Dynamic Update is fairly limited. There's no way to give fine-grained access to updating DNS zone information to multiple entities, each of whom may need different kinds of access. For example, Alice may need to be able to add new nodes to the zone or change existing nodes, but not remove them. Bob may need to be able to remove zones but not add them. Carol may need to be able to add, remove, or modify nodes, but only A records. 🎭

Scaling properties of the key management problem here are a particular concern that needs more study. 🗝️

4.3. Securing DNS Zone Replication 📦

As discussed in previous sections, DNSSEC per se attempts to provide data integrity and data origin authentication services on top of the normal DNS query protocol. Using the terminology from [RFC3552], DNSSEC provides "object security" for the normal DNS query protocol. For purposes of replicating entire DNS zones, however, DNSSEC does not provide object security, because zones include unsigned NS RRs and glue at delegation points. Using TSIG to protect zone transfer (AXFR or IXFR) operations provides "channel security", but still doesn't provide object security for complete zones. The trust relationships involved in zone transfer are still very much a hop-by-hop matter, with name server operators trusting other name server operators, rather than an end-to-end matter of name server operators trusting zone administrators. 🤝

Zone object security was not an explicit design goal of DNSSEC, so failing to provide it shouldn't be a surprise. Still, there are some zone replication scenarios where it would be a very useful extra service, so this seems like a good area for future work. In theory, it shouldn't be difficult to add zone object security as a backwards compatible enhancement to the existing DNSSEC model. But the DNSEXT WG has not yet discussed either the desirability of, or the requirements for, such an enhancement. 📝

5. Conclusion 🎀

Based on the analysis above, the DNSSEC extensions do appear to solve a set of problems that really need solving, and they're worth deploying. ✨👑

Security Considerations 🚨

This entire document is about security considerations of the DNS. The authors believe that deploying DNSSEC will help to address some, but not all, of the known threats to the DNS. Not every threat gets fixed by DNSSEC, so keep your guard up, bestie. 🛡️💜

Acknowledgments 🫶

This note is based both on previous published works by others and on a number of discussions, both public and private, over a period of many years. But particular thanks go to

Jaap Akkerhuis, Steve Bellovin, Dan Bernstein, Randy Bush, Steve Crocker, Olafur Gudmundsson, Russ Housley, Rip Loomis, Allison Mankin, Paul Mockapetris, Thomas Narten Mans Nilsson, Pekka Savola, Paul Vixie, Xunhua Wang, and any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working groups whose names and contributions the authors have forgotten, none of whom are responsible for what the authors did with their ideas. 💖

As with any work of this nature, the authors of this note acknowledge that we are standing on the toes of those who have gone before us. Readers interested in this subject may also wish to read [Bellovin95], [Schuba93], and [Vixie95]. 📚🦋

Normative References ✨

okay bestie, these are the docs the spec literally can't function without 📚💖

• [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. 🌸
• [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. 🌸
• [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. 🎀
• [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. 💅
• [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. ✨
• [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. 🦋
• [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. 🔐
• [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. 🔑
• [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. 🧚
• [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999. 👑

Informative References

these ones are the extra reading that's giving "go deeper if you're curious" 🤓🫶

• [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. 💜
• [Bellovin95] Bellovin, S., "Using the Domain Name System for System Break-Ins", Proceedings of the Fifth Usenix Unix Security Symposium, June 1995. 🙈
• [Galvin93] Design team meeting summary message posted to dns-security@tis.com mailing list by Jim Galvin on 19 November 1993. 💀
• [Schuba93] Schuba, C., "Addressing Weaknesses in the Domain Name System Protocol", Master's thesis, Purdue University Department of Computer Sciences, August 1993. 🎓
• [Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of the Fifth Usenix Unix Security Symposium, June 1995. 🌈

Authors' Addresses

these are the two legends who wrote it, so you know who to thank 🫶✨

Derek Atkins
IHTFP Consulting, Inc.
6 Farragut Ave
Somerville, MA  02144
USA

EMail: derek@ihtfp.com


Rob Austein
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA

EMail: sra@isc.org

Full Copyright Statement

the legal bit, but make it cute 💅📜

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.

okay now the serious disclaimer, and yes it's in caps on purpose 🙈 this document and the info in it 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. no promises, just vibes 🫠

Intellectual Property

the lawyer-y part, but I'll keep it real 🧾🦋

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 claim it has made any independent effort to identify any such rights. Info on how rights work for RFC documents lives 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 get a general license or permission for implementers or users to use these proprietary rights can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr. 🔍

and the IETF literally invites anyone to tell them about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. send that info to ietf-ipr@ietf.org 📬✨

Acknowledgement

last but not least, the funding tea ☕💖

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