Measures for Making DNS More Resilient against Forged Answers
updates
- rfc-2181 — Clarifications to the DNS Specification
Extracted elements (22)
A crypto-strength (pseudo-)random number generator is required rather than a simple increment or weak PRNG because weak generators expose internal state: an attacker observing several sequential 'random' values can predict future ones, effectively reducing the ID space to near zero.
A full DNS resolver with only one or a small number of upstream-facing endpoints effectively uses constants for IP source address and UDP port, which are highly predictable; since attackers can force the resolver to query attacker-controlled nameservers, any constant or sequential state can be measured and used to predict future state.
Source port randomization was chosen as the primary countermeasure because it extends the effective transaction ID space from 16 bits to up to 32 bits (16-bit ID plus ~16-bit port), expanding the problem space by a factor of ~64000 and making the bandwidth required for a 50% spoofing success exceed 285 Gb/s—infeasible in practice.
Birthday attacks are possible when an attacker forces a resolver to have multiple identical outstanding queries (same QNAME, QTYPE, QCLASS) to the same authoritative server simultaneously; each forged packet then has a proportionally higher chance of matching, rising linearly with the number of outstanding identical queries.
It is generally safe for DNS to use ports in the range 1024–49152 even though some are allocated to other protocols; a DNS resolver using such a port will release it after a short time and migrate to a different port, with only high-volume resolvers posing a risk of long-term port block-out for other applications.
Some firewalls may need reconfiguring if they are currently set up to only allow outgoing DNS queries from a single source port (53); enabling port randomization requires that outgoing queries from a broad port range be permitted.
A resolver implementation MUST match responses to all of the following query attributes before applying DNS trustworthiness rules: source address against query destination address, destination address against query source address, destination port against query source port, query ID, query name, and query class and type. A mismatch means the response MUST be considered invalid.
If a cryptographic verification of response validity is available (TSIG, SIG(0)), resolver implementations MAY waive the port and ID randomization rules and rely on the cryptographic guarantee instead.
If a resolver detects that an attempt is being made to spoof it—for example, by discovering that many packets fail the matching criteria—it MAY abandon the UDP query and re-issue it over TCP, which is far more resilient against forgery due to its use of sequence numbers.
Resolver implementations MUST use an unpredictable source port for outgoing queries from the largest practicable range of available ports (53, or 1024 and above), MUST use multiple different source ports simultaneously when multiple queries are outstanding, and MUST use an unpredictable query ID utilizing the full 0-65535 range.
Resolver implementations SHOULD provide means to avoid usage of certain ports, allowing operators to exclude ports that may cause conflicts with other applications or policy constraints.
Resolvers SHOULD favor authoritative nameservers with which a trust relation has been established; stub-resolvers SHOULD be able to use TSIG (RFC 2845) or IPsec (RFC 4301) when communicating with their recursive resolver.
Resolvers that have multiple IP addresses SHOULD use them in an unpredictable manner for outgoing queries to further enlarge the effective ID space available to an attacker.
DNS data is to be accepted by a resolver if and only if: (1) the question section of the reply is equivalent to that of an outstanding query, (2) the ID field matches, (3) the response comes from the same network address to which the question was sent, and (4) the response arrives on the same address and port from which the question was sent. The first response matching all four conditions is accepted.
Responses from authoritative nameservers must be checked for in-domain validity: data should only be accepted if the originating server is authoritative for the QNAME or a parent of the QNAME. One approach is to only accept data that is part of the domain for which the query was intended.
Source port randomization effectively extends the DNS transaction ID space. With ports in the range 1024–49152 available (approximately 64512 options), an attacker must on average try around 32256 source ports before matching the original query's source port, multiplying the effective problem space by up to 64000.
The combined spoofing difficulty formula is P_s = (D * R * W) / (N * P * I), where D is identical outstanding queries, R is attacker packet rate, W is the window of opportunity in seconds, N is the number of authoritative nameservers, P is the number of source ports used, and I is the number of distinct IDs available.
The DNS ID field is 16 bits wide, providing at most 65536 distinct values. If full random use is made of all bits, an attacker requires on average 32768 attempts to guess; implementations using only 14 bits reduce this to around 8192 attempts on average.
DNS recursive servers behind NAT or a stateful firewall may exhaust all available NAT translation entries/ports under high query load when using port randomization, since randomization causes translation entries to be consumed faster than with a fixed query port.
Even with all measures implemented, resolvers are not protected against third parties with the ability to observe, modify, or inject packets in the resolver's traffic; cryptographic DNS extensions (DNSSEC, RFC 4033) are needed to address that class of attack.
The effects of source port randomization may be dramatically reduced by NAT devices that serialize or limit the UDP source ports used by the querying resolver. NAT boxes and stateful firewalls should purge outgoing DNS query translation entries 10–17 seconds after the last outgoing query on that mapping, and RFC 4787-compliant devices must treat UDP messages to port 53 differently than most other UDP.
To minimize port/state exhaustion attacks staged from outside, services that generate many DNS queries per connection (particularly email servers) should be rate-limited.