DNS Response Pre-processing Security Guidelines: Awaiting Valid Responses

The Domain Name System (DNS) , is a fundamental component of the Internet's infrastructure. DNS resolvers, including recursive resolvers, forwarders, and stub resolvers, interact with upstream DNS servers and process their responses in the course of resolving domain names to IP addresses. Response pre-processing is a critical phase in this interaction, involving initial checks and validations of incoming packets before the formal processing of DNS record content. Additional clarifications on DNS behavior can be found in and .

While the basic DNS protocol is defined in and , these specifications do not provide sufficient detail on how resolvers should handle various forms of invalid, malformed, or unexpected response packets. For instance, Section 4.1.2 of describes header fields but offers limited guidance on how a receiver should validate and react to non-compliant header fields. This lack of specificity has led to diversity in DNS software implementations. Research has shown that these implementation differences and improper handling of edge cases can create exploitable logical vulnerabilities. Attackers can trigger these vulnerabilities by sending specially crafted malformed DNS responses, leading to consequences such as DNS cache poisoning (see also , , and ), Denial of Service (DoS), or resolver resource exhaustion. These attacks leverage unexpected resolver behaviors during the response pre-processing phase, such as premature termination of resolution, erroneous acceptance of invalid data, or bypassing internal control mechanisms.

The primary goal of this document is to provide clear guidance and best practices for the response pre-processing logic of DNS resolvers (including recursive resolvers, forwarders, and stub resolvers). Central to this is the introduction and formalization of the "Awaiting Valid Responses" mechanism. This document aims to:

Clarify the sequence of validation steps and behaviors that resolvers should perform upon receiving packets from upstream servers.
Emphasize the principle of not prematurely terminating a resolution attempt upon receipt of an invalid or malformed packet.
Provide recommendations for handling various common scenarios involving malformed and unexpected packets.
Reduce the occurrence of logical vulnerabilities by standardizing pre-processing behavior, thereby enhancing the overall security and robustness of the DNS infrastructure.

This document does not attempt to modify the core data formats of the DNS protocol or the fundamental flow of query/response exchanges. Instead, it focuses on clarifying and supplementing existing specifications with respect to response reception and initial validation. This document acknowledges that the diversity of DNS implementations is a strength and not a weakness. The exact mitigations detailed herein are provided as operational guidance and Best Current Practices, rather than rigid Internet Standards. Implementers are encouraged to adapt these mechanisms to suit their specific architectures.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Resolver:: An entity that performs DNS query resolution. This can be a recursive resolver, a DNS forwarder, or a stub resolver.
Upstream Server:: A server to which a resolver sends DNS queries, e.g., an authoritative name server or another recursive resolver.
Response Pre-processing:: The set of checks and validation steps performed by a resolver upon receiving a packet from an upstream server, prior to the formal processing of DNS data content (e.g., caching records, returning to a client).
Malformed Packet:: A packet that does not conform to the format requirements of the DNS protocol specification or relevant network protocols (IP, UDP, TCP).
Unexpected Packet:: A packet that, while potentially well-formed, does not match the resolver's current resolution context in terms of its content (e.g., mismatched TXID, incorrect QR bit) or timing.
Valid Response:: A well-formed response packet whose content (especially the TXID) matches an active query and which adheres to DNS protocol logic.
Awaiting Valid Response Window:: The period during which a resolver, after sending a query, waits to receive a valid response, typically limited by a query timeout mechanism.
Four-tuple:: The combination of IP layer and transport layer identifiers, typically including source IP address, destination IP address, source port number, and destination port number.
Transaction ID (TXID):: A 16-bit identifier in the DNS header used to match queries and responses.
TUDOOR Attack:: A class of attacks described in the paper that exploit logical vulnerabilities in DNS response pre-processing.

A DNS resolver, after sending a query to an upstream server, MUST initiate an internal "Awaiting Valid Responses" cycle. During this cycle, the resolver's primary objective is to receive and validate a valid response corresponding to the query sent. The following principles MUST be adhered to:

Persistent Waiting: After issuing a query, a resolver MUST continuously listen for and process incoming packets until either a response confirmed as valid is received, or the timeout mechanism for that query is triggered.
Strict Validation: All received packets MUST undergo a series of predefined validation steps (detailed in ) before being accepted as a valid response.
Preferential Discarding of Invalid Packets: Any packet identified during validation as malformed, unexpected, or unrelated to an active query MUST be discarded. After discarding, the resolver MUST continue to await subsequent, potentially valid responses and SHOULD NOT terminate the resolution attempt for the original query solely due to the receipt of an invalid packet. An exception is if a packet (e.g., a trusted ICMP message) definitively indicates a permanent failure for that query.
Avoidance of Premature Termination: A resolver MUST NOT prematurely terminate the resolution process for an original query or close the associated network socket due to the receipt of most types of malformed or unexpected packets.
Timeout Handling: If a valid response is not received within the pre-set Awaiting Valid Response Window, the resolver MUST follow its established timeout and retransmission logic.

The following state model describes the recommended response pre-processing flow. A resolver maintains an independent state for each active outbound query.

Description: The resolver has sent a query upstream and is awaiting a response. A timeout timer is active. Entry Condition: After sending a query. Action: Listen on the network socket.

Description: An IP packet is received from the network interface. Actions:

Validate the packet's network layer header (e.g., IP header checksum). If invalid, the packet MUST be discarded.
Check if the packet's four-tuple matches the expected response source for any active query. If no match, the packet MUST be discarded.
If passed, proceed to the next state based on protocol type (e.g., ICMP, UDP, TCP). For UDP/TCP, proceed to State 3 (). For ICMP, proceed to State 2 ().

Description: The received packet is an ICMP message. Actions:

The resolver SHOULD inspect the ICMP message type, code, and the quoted original datagram information in its payload to determine if it is relevant and trustworthy for an active query.
For ICMP messages indicating Port Unreachable (Type 3, Code 3) that match an active query's authoritative server and port, the resolver MAY consider this a failure signal for that specific upstream server/port combination and act accordingly (e.g., try an alternate server, or mark this query attempt as failed after multiple tries).
For other types of ICMP errors, especially those of unknown origin or ambiguous meaning, the resolver SHOULD NOT terminate the entire resolution process solely based on this ICMP message. It is RECOMMENDED to log the message and return to State 0 () to continue waiting.
The resolver MUST NOT prematurely terminate resolution due to specific ICMP message combinations that can be exploited for DoS, as described in and .

Description: The received packet is a UDP or TCP segment. Actions:

Validate the transport layer header (e.g., UDP/TCP checksum, if applicable and checked). If invalid, the packet MUST be discarded.
Check the UDP/TCP payload length. If the payload is empty or its length is insufficient to contain a minimal DNS header (12 bytes), the packet MUST be discarded. The resolver returns to State 0 ().
If the payload length is sufficient, proceed to State 4 ().

Description: Validation of the DNS message header fields. Actions:

Parse the DNS header.
QR Bit: MUST be 1 (response). If the QR bit is 0 (query), this packet MUST be discarded. The resolver returns to State 0 (). This is intended to prevent V_CP vulnerabilities like the one affecting Microsoft DNS in .
OpCode: Should typically be 0 (standard query). Responses to other OpCodes should be handled according to their definitions and local policy. If the OpCode is invalid or unsupported, the packet SHOULD be discarded.
QDCOUNT: For a response, this field should generally match the QDCOUNT in the corresponding query. In many cases, it should be 1. If QDCOUNT does not meet expectations (e.g., is much larger than 1, or inconsistent with the query), the packet SHOULD be treated as suspicious and potentially discarded, depending on local policy and strict interpretation of . Refer to .
Other header fields (e.g., AA, TC, RD, RA, Z, RCODE) MUST be checked for validity within a response context. Headers with overtly contradictory or illegal values MUST cause the packet to be discarded. The resolver returns to State 0 ().
If header fields are preliminarily valid, proceed to State 5 ().

Description: Parsing and validation of the Question, Answer, Authority, and Additional sections of the DNS message body. Actions:

Parse the sections according to the counts in the header.
Validate domain name representations (including the validity of compression pointers), RR types, and RDATA formats.
Any critical error that prevents unambiguous parsing of record content or violates specified formats (e.g., invalid compression pointer loops, RDLENGTH mismatch with actual data) MUST cause the packet to be discarded. The resolver returns to State 0 ().
If all sections are parsed successfully, proceed to State 6 ().

Description: Validation that the TXID in the response matches that of an active query. Actions:

If the response TXID matches an active query's TXID, proceed to State 7 ().
If the TXID does not match, this packet MUST be discarded. The resolver returns to State 0 ().

Description: A valid response, having passed all pre-processing validations, has been received. Actions:

Stop the timeout timer associated with this query.
Pass the validated response data to subsequent DNS processing modules (e.g., caching, responding to the client).
The pre-processing flow for this query concludes.

Description: The timeout timer for awaiting a valid response has expired. Actions:

If retransmission is permitted and the maximum retransmission count has not been reached, proceed to State 9 ().
Otherwise, proceed to State 10 ().

Description: Deciding whether to retransmit the query. Actions:

The resolver MUST check if the configured retransmission limit for this query has been reached. This check MUST occur before an actual retransmission is performed, to prevent V_RC vulnerabilities as described in .
If the limit has not been reached, the resolver MAY retransmit the query (potentially with a new TXID and/or source port). After retransmission, return to State 0 ().
If the limit has been reached, proceed to State 10 ().

Description: The resolution attempt for this query has terminated. Actions:

Return an appropriate error response (e.g., SERVFAIL) to the original requestor.
Clean up state associated with this query.

Silent discard: For most packets determined to be invalid during pre-processing, the resolver SHOULD discard them silently, i.e., without sending any form of response to the source. This avoids leaking information about the resolver's internal state or behavior.
Persistent Listening: After discarding an invalid packet, the resolver MUST continue to listen on the socket for other potential responses related to the original query, until the query times out.
Logging: A resolver MAY log diagnostic information about discarded malformed or unexpected packets. However, the level and frequency of logging should be configurable to prevent the logging system itself from becoming an attack vector or performance bottleneck.
No State Contamination: The processing of invalid packets MUST NOT negatively affect the state of the resolver's other active queries or its shared cache.

The specifications in this document are intended to mitigate security vulnerabilities arising from flaws in response pre-processing logic, particularly those highlighted in the research.

By mandating in State 4.2.5 () that the QR bit in a response MUST be 1 and that packets with QR=0 are discarded, attacks that exploit response sockets to probe source ports or inject queries are prevented. Concurrently, strict TXID matching in State 4.2.7 () is fundamental to preventing cache poisoning.

By emphasizing that the resolver MUST continue to await a valid response (return to State 0 ()) after receiving most types of malformed packets (including specific ICMP messages, empty-payload UDP packets, etc.), rather than prematurely terminating resolution (as specified in States 4.2.3 (), 4.2.4 ()), the effectiveness of such DoS attacks is significantly reduced. Failure should only be determined after a genuine query timeout or exhaustion of retransmission limits.

By explicitly requiring in State 4.2.10 () that the retransmission count limit MUST be checked before any retransmission decision, attacks that induce a resolver to send an excessive number of queries to exhaust its resources are prevented.

The guidelines in this document aim to enhance the resilience of DNS resolvers against specific types of attacks. However, implementers should be aware of the following:

Implementation Correctness: The effectiveness of these guidelines depends on their correct and complete implementation. Any deviation from the state machine logic could reintroduce vulnerabilities.
Resource Limits: While handling high volumes of incoming traffic (including malicious traffic), resolvers still require appropriate internal resource management mechanisms (e.g., rate limiting requests from a single source) to prevent self-overload.
Logging Security: Logging is vital for monitoring and troubleshooting but can also leak information or be used in attacks. Control over log content, verbosity, and rate is necessary.
Randomness Requirements: Strong source port and TXID randomization remain crucial for defending against DNS cache poisoning (see ) and are complementary to the specifications herein.
DNSSEC: DNS Security Extensions (DNSSEC) provide cryptographic validation of DNS data origin and integrity. The pre-processing steps defined in this document should occur before or in parallel with DNSSEC validation, as even packets claiming to be DNSSEC-signed can be malformed at lower layers.
Evolving Threats: Attack techniques evolve. DNS implementers and operators need to remain vigilant and stay informed about new security threats and mitigation strategies.

This document is intended to clarify and supplement existing DNS specifications, not to replace them.

It builds upon the DNS protocol foundations defined in and , providing more specific guidance on the response handling aspects.
It aligns with the robustness requirements for host application layers in and .
It supports the measures for making DNS more resilient against forged answers proposed in .
For QDCOUNT handling, it refers to the spirit of .

This document does not require any IANA actions.