RFC 5452

Measures for Making DNS More Resilient against Forged Answers

📅 published January 2009, from ietf

RFC 5452: Measures for Making DNS More Resilient against Forged Answers 🎀

Okay bestie, let's dig into RFC 5452 💖 It's called Measures for Making DNS More Resilient against Forged Answers, and it's a Standards Track document from January 2009. The authors are A. Hubert from Netherlabs Computer Consulting BV. and R. van Mook from Equinix, and it's part of the Network Working Group. It updates RFC 2181 ✨, and the header doesn't list anything it obsoletes.

Status of This Memo 🦋

This one is an Internet standards track protocol document for the whole Internet community, and it's asking everyone for discussion and suggestions for improvements 💬. If you want to know where this protocol stands on the standardization ladder, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution is totally unlimited, so share away 🌈

Copyright (c) 2009 IETF Trust and the people listed as the document authors. All rights reserved 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info, as they're in effect on the publication date. Please actually read those, bestie, because they explain your rights and restrictions for this document 🙈

Abstract ✨

Okay so the internet climate right now is honestly scary for the Domain Name System 😭 Until DNS can be fully secured, we can already harden it so that "spoofing" a recursing nameserver becomes many orders of magnitude harder 🔥

Even a DNS that's cryptographically secured gets a big win from being able to toss out bogus responses fast, because that can save a huge amount of computation 🧠

So this document describes some behavior that hasn't been standardized before, and it lays out how to make DNS more resilient against accepting incorrect responses 💅 It updates RFC 2181, just so you know 🎀

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  2.  Requirements and Definitions . . . . . . . . . . . . . . . . .  4
    2.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  4
    2.2.  Key Words  . . . . . . . . . . . . . . . . . . . . . . . .  5
  3.  Description of DNS Spoofing  . . . . . . . . . . . . . . . . .  5
  4.  Detailed Description of Spoofing Scenarios . . . . . . . . . .  6
    4.1.  Forcing a Query  . . . . . . . . . . . . . . . . . . . . .  6
    4.2.  Matching the Question Section  . . . . . . . . . . . . . .  7
    4.3.  Matching the ID Field  . . . . . . . . . . . . . . . . . .  7
    4.4.  Matching the Source Address of the Authentic Response  . .  7
    4.5.  Matching the Destination Address and Port of the
          Authentic Response . . . . . . . . . . . . . . . . . . . .  8
    4.6.  Have the Response Arrive before the Authentic Response . .  8
  5.  Birthday Attacks . . . . . . . . . . . . . . . . . . . . . . .  9
  6.  Accepting Only In-Domain Records . . . . . . . . . . . . . . .  9
  7.  Combined Difficulty  . . . . . . . . . . . . . . . . . . . . . 10
    7.1.  Symbols Used in Calculation  . . . . . . . . . . . . . . . 10
    7.2.  Calculation  . . . . . . . . . . . . . . . . . . . . . . . 11
  8.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
    8.1.  Repetitive Spoofing Attempts for a Single Domain Name  . . 13
  9.  Forgery Countermeasures  . . . . . . . . . . . . . . . . . . . 13
    9.1.  Query Matching Rules . . . . . . . . . . . . . . . . . . . 13
    9.2.  Extending the Q-ID Space by Using Ports and Addresses  . . 14
      9.2.1.  Justification and Discussion . . . . . . . . . . . . . 14
    9.3.  Spoof Detection and Countermeasure . . . . . . . . . . . . 15
  10. Security Considerations  . . . . . . . . . . . . . . . . . . . 15
  11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
  12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
    12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
    12.2. Informative References . . . . . . . . . . . . . . . . . . 17

1. Introduction 🌸

Okay so this doc describes a bunch of common DNS implementation problems 🙈 People have known about them for a while, but they're still mostly unsolved. Besides recapping them, it also has rules that make compliant resolvers way more resistant to these attacks if you implement them 💪 The big goal is to make today's DNS as secure as possible within the current protocol boundaries ✨

The words in here are mainly for resolver authors. Operators get to decide which nameserver implementation to run and which options to turn on 🧚 Operational constraints can override the security concerns below, but implementations are still expected to let an operator enable the functionality described in this document 🫶

Literally almost every transaction on the Internet involves DNS, which is covered in [RFC1034], [RFC1035], and beyond 🌐

Also, it has recently become possible to get SSL/TLS certificates with no other proof of identity than being able to reply to a verification email sent over SMTP ([RFC5321]). And that email routing generally uses DNS 💀

So basically, any party that (even temporarily) controls DNS can reroute most kinds of Internet traffic, including the verification steps for getting an SSL/TLS certificate. That means even traffic protected by SSL/TLS could get diverted 😭

It's totally conceivable that rerouted traffic could be used against Internet users 🚨

These developments (and others) have made DNS security and trustworthiness super important again 👑 The DNS community is working hard on a cryptographically enhanced DNS protocol, but in the meantime, steps should be taken so that existing DNS use is as secure as possible within the bounds of the relevant standards 💜

It should also be noted that the most commonly used resolvers currently don't perform as well as they could on this, which makes this document urgently important ⭐

A thorough analysis of DNS risks is in [RFC3833] 📚

This document expands on some of the risks in RFC 3833, especially the ones in the sections on "ID Guessing and Query Prediction" and "Name Chaining" 🔍 It also emphasizes a bunch of existing rules and guidelines already in the relevant DNS protocol specs. The new requirements here are meant to keep DNS reliable until a more secure protocol is standardized and deployed 🦋

Even when every measure below is implemented, protocol users are still NOT protected against third parties who can observe, modify, or inject packets into a resolver's traffic. Not fully safe, bestie!

For protocol extensions that protect against these scenarios, see [RFC4033] and beyond 🎀

2. Requirements and Definitions 📝

2.1. Definitions 🧩

This document uses the following definitions:

  • Client: typically a 'stub-resolver' on an end-user's computer.
  • Resolver: a nameserver performing recursive service for clients, also known as a caching server, or a full service resolver ([RFC1123], Section 6.1.3.1).
  • Stub resolver: a very limited resolver on a client computer, that leaves the recursing work to a full resolver.
  • Query: a question sent out by a resolver, typically in a UDP packet.
  • Response: the answer sent back by an authoritative nameserver, typically in a UDP packet.
  • Third party: any entity other than the resolver or the intended recipient of a question. The third party may have access to an arbitrary authoritative nameserver, but has no access to packets transmitted by the resolver or authoritative server.
  • Attacker: malicious third party.
  • Spoof: the activity of attempting to subvert the DNS process by getting a chosen answer accepted.
  • Authentic response: the correct answer that comes from the right authoritative server.
  • Target domain name: domain for which the attacker wishes to spoof in an answer.
  • Fake data: response chosen by the attacker.

2.2. Key Words 🔑

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]. Yes, these are the official key words, so pay attention to them 👀

3. Description of DNS Spoofing 🕵️‍♀️

Once certain steps are taken, it's feasible to "spoof" the current majority of deployed resolvers with carefully crafted and timed DNS packets 😱 After being spoofed, a caching server keeps repeating the data it wrongly accepted, and it makes its clients contact the wrong servers, which might be malicious 💀

To understand how this works, it's important to know what makes a resolver accept a response 🧐

Section 5.3.3 of [RFC1034] kinda predicted this exact problem:

The resolver should be highly paranoid in its parsing of responses. It should also check that the response matches the query it sent using the ID field in the response.

So DNS data gets accepted by a resolver if and only if all of these are true:

  1. The question section of the reply packet is equivalent to the question section of a question packet that's still waiting for a response. 🎯
  2. The ID field of the reply packet matches the ID field of the question packet. 🆔
  3. The response comes from the same network address the question was sent to. 📍
  4. The response comes in on the same network address, port number included, that the question was sent from. 🔌

In general, the first response that matches all four conditions is the one that gets accepted ⚡

Now, if a third party meets all four conditions before the authentic nameserver's response does, it can feed a resolver fabricated data 😈 When it does that, we call it an "attacker" trying to spoof in fake data 🦹‍♀️

Every condition above can theoretically be met by a third party. How hard that is depends on the resolver implementation and the zone configuration 🎭

4. Detailed Description of Spoofing Scenarios 🎬

The previous paragraph covered the requirements an attacker must match in order to spoof in manipulated (or fake) data. This section talks about how hard each one is, and how implementation-defined choices change how much work an attacker has to do to meet those difficulties 💅

Some more details are in Section 2.2 of [RFC3833] 📖

4.1. Forcing a Query ✨

okay so, formally a nameserver doesn't have to do any work except for its operator, its customers, or more generally its users 💅 But open recursing nameservers have recently been abused to amplify denial-of-service attacks 💀

Full service lets the third party send the target resolver a query for the domain name they want to spoof 🎯 When the resolver gets that query and doesn't have the answer cached, it sends queries to the relevant authoritative nameservers. That opens a window of opportunity where fake answer data can get accepted 🙈

Queries can also be forced indirectly, for example by getting a mail server to do DNS lookups 📬

Some operators restrict access by not recursing for unauthorized IP addresses, and only answer from the cache 🔒 This makes spoofing harder, because the third party can't force the exact moment a question gets asked. It's still possible to work out a time range though 🕰️ Nameservers helpfully publish the decreasing time to live (TTL) of cached entries, and that tells you from which absolute time onwards a new query could be sent to refresh the expired entry. so helpful, and so dangerous 😭

The time to live of the target domain name's RRSets decides how often a window of opportunity shows up, which means a short TTL makes spoofing way more viable 🔥

Also, the attacker might totally have authorized access to the target resolver, like if they're a customer or employee of its operator 👀 Access can also be enabled through the use of reflectors, as outlined in [RFC5358]. main character energy for the attacker, ngl 🦋

4.2. Matching the Question Section 💖

DNS packets, both queries and responses, contain a question section. Incoming responses should be verified to have a question section that is equivalent to that of the outgoing query. checking the question section is literally the bare minimum, bestie 🫶

4.3. Matching the ID Field 🎀

The DNS ID field is 16 bits wide. If all of those bits get used and their contents are truly random, it takes on average 32768 attempts to guess it 🧮 Anecdotal evidence suggests some implementations only use 14 bits, which means an average of 8192 attempts will do the trick 😬

Then there's the "Birthday Attack" 🎂 If the target nameserver can be forced into having multiple identical queries outstanding, any fake data the attacker sends gets matched against all of those outstanding queries. That seriously raises the chance of success. More details are in Section 5 🧁

4.4. Matching the Source Address of the Authentic Response 🌸

ok so meeting this condition means being able to send packets on behalf of the address of the authoritative nameserver 🫣 Two Best Current Practice documents ([RFC2827] and [RFC3013] specifically) tell Internet access providers to stop their customers from pretending to use IP addresses that aren't assigned to them. but these recommendations aren't universally implemented, or even widely implemented, sadly 😤

Lots of zones have two or three authoritative nameservers. That makes matching the source address of the authentic response really likely, even with a naive choice that has a double digit success rate 📈

Most recursing nameservers store relative performance indications of authoritative nameservers. That can make it easier to predict which nameserver was originally queried, which is the one most likely to respond the quickest ⚡

Generally, this condition takes at most two or three attempts before it's matched 🏃‍♀️

4.5. Matching the Destination Address and Port of the Authentic Response 🦋

Note that the destination address of the authentic response is the source address of the original query 💅

The actual address of a recursing nameserver is usually known. The port used for asking questions is harder to pin down 🧐 Most current resolvers pick an arbitrary port at startup (possibly at random) and use it for all outgoing queries. In quite a number of cases, the source port of outgoing questions is fixed at the traditional DNS assigned server port number of 53 🙃

If the source port of the original query is random but static, any authoritative nameserver under observation by the attacker can be used to figure out this port. so matching this condition often needs zero guesswork 🤭

If multiple ports are used for sending queries, the effective ID space gets bigger by a factor equal to the number of ports used 📈

Less common resolving servers pick a random port per outgoing query 🎲 If that strategy is followed, the port number counts as an additional ID field, again containing up to 16 bits.

If the maximum ports range is used, around 32256 source ports would have to be tried, on average, before matching the source port of the original query. That's because ports below 1024 may be unavailable for use, which leaves 64512 options 🫠

It's generally safe for DNS to use ports in the range 1024-49152, even though some of these ports are allocated to other protocols 🌈 DNS resolvers can't use any ports that are already in use. When a DNS resolver uses a port, it releases that port after a short time and moves to a different one. Only with a high-volume resolver could an application that wants a particular UDP port end up stuck with a long term block-out 🚫

It's worth knowing that a firewall won't stop the matching of this address, because it accepts answers that (appear to) come from the correct address, so it adds no extra security 🧱

4.6. Have the Response Arrive before the Authentic Response ⏱️

Once any packet has matched the previous four conditions (plus possible additional conditions), no further responses are generally accepted 🚪

That means the third party only has a limited time to inject its spoofed response. For calculations, we'll assume a window of at most 100 ms (depending on the network distance to the authentic authoritative nameserver) 🏎️

This time period can be way longer if the authentic authoritative nameservers are (briefly) overloaded by queries, maybe by the attacker themselves 😈

5. Birthday Attacks 🎂

The so-called "birthday paradox" says a group of 23 people is enough to have a more than even chance of two or more members sharing a birthday 🥳

An attacker can use this exact phenomenon if they can force the target resolver to have multiple equivalent outstanding queries (identical QNAME, QTYPE, and QCLASS) at any one time to the same authoritative server 🧠

Any packet the attacker sends then has a much higher chance of getting accepted, because it only has to match any of the outstanding queries for that single domain 💘 Compared to the birthday analogy above, the chance of any queries and responses in the group sharing an ID rises quickly 📈

As long as small numbers of queries are sent out, the chance of successfully spoofing a response rises linearly with the number of outstanding queries for the exact domain and nameserver 📏

For larger numbers, this effect is less pronounced 🫥

More details are available in US-CERT [vu-457875] 📚

6. Accepting Only In-Domain Records 🧚

Responses from authoritative nameservers often include information that isn't part of the zone they're authoritative for 🙃 For example, a query for the MX record of a domain might get a mail exchanger in another domain as a response, plus the IP address of that mail exchanger 📬

If accepted uncritically, the resolver could end up accepting data from an untrusted source 😬 Care must be taken to only accept data if it's known that the originator is authoritative for the QNAME or a parent of the QNAME 🔍

One very simple way to do this is to only accept data that's part of the domain the query was meant for 🍓

7. Combined Difficulty 🧮

Given a known or static destination port and a matching ID field, matching the source and destination address takes on average in the order of 2 * 2^15 = 65000 packets, assuming a zone has 2 authoritative nameservers 💅

If the window of opportunity is around 100 ms, as assumed above, an attacker would need to briefly transmit 650000 packets/s to have a 50% chance of getting spoofed data accepted on the first attempt 🥵

A realistic minimal DNS response is around 80 bytes, including IP headers. That makes the packet rate above a respectable burst of 416 Mbit/s 💨

As of mid-2006, this kind of bandwidth wasn't common, but it wasn't scarce either, especially for those in a position to control lots of servers 🖥️

These numbers change when a window of a full second is assumed. That could happen because the arrival of the authentic response gets prevented by overloading the bona fide authoritative hosts with decoy queries 🫠 This drops the needed bandwidth to 42 Mbit/s 📉

If, on top of that, the attacker gets more than a single chance and is allowed up to 60 minutes of work on a domain with a time to live of 300 seconds, a meager 4 Mbit/s is enough for a 50% chance of getting fake data accepted 🤏 With that longer time, matching condition 1 mentioned above is straightforward. any popular domain will have been queried a number of times within that hour, and given the short TTL, that leads to queries to authoritative nameservers, which opens windows of opportunity 🪟

7.1. Symbols Used in Calculation 🧾

Assume the following symbols are used:

  • I: Number distinct IDs available (maximum 65536)
  • P: Number of ports used (maximum around 64000 as ports under 1024 are not always available, but often 1)
  • N: Number of authoritative nameservers for a domain (averages around 2.5)
  • F: Number of "fake" packets sent by the attacker
  • R: Number of packets sent per second by the attacker
  • W: Window of opportunity, in seconds. Bounded by the response time of the authoritative servers (often 0.1s)
  • D: Average number of identical outstanding queries of a resolver (typically 1, see Section 5)
  • A: Number of attempts, one for each window of opportunity

7.2. Calculation ✨

okay so the spoofing odds are basically: how many fake packets land inside the window, divided by the size of the problem space 🎯 💅

if the resolver has 'D' identical outstanding queries, each fake packet gets a proportionally higher chance of matching any of them. this only holds up for small values of 'D' 🫶

in symbols, if the probability of being spoofed is P_s:

              D * F
   P_s =    ---------
            N * P * I

ngl it's way more useful to think in packet rate instead of aggregate packets, since you can easily convert that to bandwidth if you need it 🦋

if the window of opportunity length is 'W' and the attacker can send 'R' packets per second, the number of fake packets 'F' that are candidates to be accepted is:

                          D * R * W
   F = R * W  ->   P_s  = ---------
                          N * P * I

now for the combined chance 'P_cs' of spoofing over a chosen time period 'T'. the attacker gets a brand new window of opportunity every time the TTL 'TTL' of the target domain expires, so the number of attempts 'A' is equal to 'T / TTL'. main character energy for the attacker 💀

to calculate the combined chance of at least one success, the following formula holds:

                                                        (T / TTL)
                         A          (       D * R * W )
   P_cs = 1 - ( 1 - P_s )    =  1 - ( 1  -  --------- )
                                    (       N * P * I )

when the common numbers (as listed above) for D, W, N, P, and I get plugged in, this formula reduces to:

                               (T / TTL)
              (         R    )
   P_cs = 1 - ( 1 -  ------- )
              (      1638400 )

the big takeaway 👑: if the nameserver implementation is unchanged, only raising the TTL offers protection. raising N, the number of authoritative nameservers, isn't feasible beyond a small number, so it's not the fix 🙈

for the degenerate case of a zero-second TTL, a window of opportunity opens for each query sent. that makes the effective TTL equal to 'W' above, which is the response time of the authoritative server ⏱️

this last case also holds for spoofing techniques that don't rely on TTL expiry at all, but use repeated and changing queries instead 🔥

8. Discussion 🌸

okay this section is where the numbers get real 😭 the calculations above show how relatively easy it is to spoof DNS data. for example, using the formula derived earlier on an RRSet with a 3600 second TTL, an attacker sending 7000 fake response packets/s (a rate of 4.5 Mbit/s) has a 10% chance of spoofing a record in the first 24 hours, which climbs to 50% after a week. yikes 🙈

for an RRSet with a TTL of 60 seconds, the 10% level is hit after 24 minutes, 50% after less than 3 hours, and 90% after around 9 hours 💜

for some classes of attacks, the effective TTL is near zero, as noted above 🍓

note that the attacks mentioned above can be detected by watchful server operators. an unexpected incoming stream of 4.5 Mbit/s of packets might get noticed 👀

an important assumption in these calculations, however, is a known or static destination port of the authentic response 🎀

if that port number is unknown and also needs to be guessed, the problem space expands by a factor of 64000. that leads the attacker to need in excess of 285Gb/s to achieve similar success rates. bestie that is a LOT of bandwidth 😭

such bandwidth isn't generally available, and it isn't expected to be in the foreseeable future 🫶

also, some firewalls may need reconfiguring if they're currently set up to only allow outgoing queries from a single DNS source port ✨

8.1. Repetitive Spoofing Attempts for a Single Domain Name 🧚

techniques are available that use an effectively infinite number of queries to achieve a desired spoofing goal. in the math above, this reduces the effective TTL to 0 💀

if such techniques are used, with the same 7000 packets/s rate mentioned above and using 1 source port, the spoofing chance rises to 50% within 7 seconds. seven seconds!! 😱

if 64000 ports are used, as recommended in this document, at the same query rate, the 50% level is reached after around 116 hours. so port randomization really is the move 🦋

9. Forgery Countermeasures 🛡️💖

9.1. Query Matching Rules 🎯

a resolver implementation MUST match responses to all of the following attributes of the query:

  • Source address against query destination address
  • Destination address against query source address
  • Destination port against query source port
  • Query ID
  • Query name
  • Query class and type

this happens before applying DNS trustworthiness rules (see Section 5.4.1 of [RFC2181]), so the matching comes first, babe ✨

a mismatch means the response MUST be considered invalid. no vibes, just rejection 💅

9.2. Extending the Q-ID Space by Using Ports and Addresses 🌈

resolver implementations MUST:

  • Use an unpredictable source port for outgoing queries from the range of available ports (53, or 1024 and above) that is as large as possible and practicable;
  • Use multiple different source ports simultaneously in case of multiple outstanding queries;
  • Use an unpredictable query ID for outgoing queries, utilizing the full range available (0-65535).

resolvers that have multiple IP addresses SHOULD use them in an unpredictable manner for outgoing queries 🌸

resolver implementations SHOULD provide means to avoid usage of certain ports 🎀

resolvers SHOULD favor authoritative nameservers with which a trust relation has been established. stub-resolvers SHOULD be able to use Transaction Signature (TSIG) ([RFC2845]) or IPsec ([RFC4301]) when communicating with their recursive resolver 🔐

in case a cryptographic verification of response validity is available (TSIG, SIG(0)), resolver implementations MAY waive the above rules and rely on that guarantee instead. the cryptography is doing the heavy lifting here 🫶

proper unpredictability can be achieved by employing a high quality (pseudo-)random generator, as described in [RFC4086] 🎲✨

9.2.1. Justification and Discussion 🧠

since an attacker can force a full DNS resolver to send queries to the attacker's own nameservers, any constant or sequential state held by such a resolver can be measured. it must not be trivially easy to reverse engineer the resolver's internal state in a way that allows low-cost, high-accuracy prediction of future state. the attacker shouldn't be able to read the room 👀

a full DNS resolver with only one or a small number of upstream-facing endpoints is effectively using constants for its IP source address and UDP port number. these are very predictable by potential attackers, so they must therefore be avoided 🙅‍♀️

a full DNS resolver that uses a simple increment to get its next DNS query ID is likewise very predictable, and so very spoofable 💀

finally, weak random number generators have been shown to expose their internal state, so an attacker who witnesses several sequential "random" values can easily predict the next ones. a crypto-strength random number generator is one whose output cannot be predicted no matter how many successive values are witnessed. that's the gold standard, periodt 💅👑

9.3. Spoof Detection and Countermeasure 🚨

if a resolver detects that an attempt is being made to spoof it, perhaps by discovering that many packets fail the criteria outlined above, it MAY abandon the UDP query and re-issue it over TCP. TCP, by the nature of its use of sequence numbers, is far more resilient against forgery by third parties. it's giving fortress energy 🏰🫶

10. Security Considerations 🔥

this document clarifies the DNS specification to decrease the probability that DNS responses can be successfully forged. the recommendations found above should be considered complementary to possible cryptographical enhancements of the domain name system, which protect against a larger class of attacks 🔐

this document recommends the use of UDP source port number randomization to extend the effective DNS transaction ID beyond the available 16 bits. so important, so dramatic 😭

a resolver that does not implement the recommendations outlined above can easily be forced to accept spoofed responses. those responses are then passed on to client computers, which misdirects (user) traffic toward possibly malicious entities. yikes 💀

this document directly impacts the security of the Domain Name System, so implementers are urged to follow its recommendations 🚨

most security considerations can be found in Sections 4 and 5, while proposed countermeasures are described in Section 9 🗺️

for brevity's sake, instead of repeating the security considerations references, the reader is referred to those sections 📚

nothing in this document specifies particular algorithms for operators to use. it does specify algorithms that implementations SHOULD or MUST support 🎀

it should be noted that the effects of source port randomization may be dramatically reduced by NAT devices that either serialize or limit in volume the UDP source ports used by the querying resolver 🙈

DNS recursive servers sitting behind a NAT or a stateful firewall may consume all available NAT translation entries/ports when operating under high query load. port randomization causes translation entries to be consumed faster than a fixed query port does 🍓

to avoid this, NAT boxes and stateful firewalls can/should purge outgoing DNS query translation entries 10-17 seconds after the last outgoing query on that mapping was sent. [RFC4787]-compliant devices need to treat UDP messages with port 53 differently than most other UDP protocols 🧚

to minimize the potential that port/state exhaustion attacks can be staged from the outside, it is recommended that services generating a number of DNS queries for each connection be rate limited. this applies in particular to email servers 📧💜

11. Acknowledgments 🫶

source port randomization in DNS was first implemented and possibly invented by Dan J. Bernstein. legend 👑

although any mistakes remain our own, the authors gratefully acknowledge the help and contributions of:

  • Stephane Bortzmeyer
  • Alfred Hoenes
  • Peter Koch
  • Sean Leach
  • Norbert Sendetzky
  • Paul Vixie
  • Florian Weimer
  • Wouter Wijngaards
  • Dan Wing

thank you all, you're literally the reason this works 🌈✨

12. References 📚

12.1. Normative References 💅

  • [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.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
  • [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
  • [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
  • [RFC3013] Killalea, T., "Recommended Internet Service Provider Security Services and Procedures", BCP 46, RFC 3013, November 2000.
  • [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
  • [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
  • [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

12.2. Informative References 📚✨

okay so these are the "nice to know" reads, bestie. you don't need them to build the thing, but they give you so much background 🤓

[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.

[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.

[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, October 2008.

[vu-457875] United States CERT, "Various DNS service implementations generate multiple simultaneous queries for the same resource record", VU 457875, November 2002.

Authors' Addresses 🎀

meet the authors, the brains behind all of this 🧠💜

Bert Hubert
Netherlabs Computer Consulting BV.
Braillelaan 10
Rijswijk (ZH)  2289 CM
The Netherlands

EMail: bert.hubert@netherlabs.nl


Remco van Mook
Equinix
Auke Vleerstraat 1
Enschede  7521 PE
The Netherlands

EMail: remco@eu.equinix.com
📦 where this page comes from