DNS Response Pre-processing Security Guidelines: Awaiting Valid Responses

1.1. Background

The Domain Name System (DNS) [RFC1034], [RFC1035] 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.¶

1.2. Problem Statement

While the basic DNS protocol is defined in [RFC1034] and [RFC1035], 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 [RFC1035] 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 [TUDOOR] 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, 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.¶

1.3. Document Goals and Scope

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.¶

4.1. Core Principles

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 Section 4.2) 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.¶

4.2. Recommended State Model for Response Pre-processing

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

4.3. General Guidelines for Handling Malformed and Unexpected Packets

• 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.¶

5.1. Regarding Cache Poisoning (V_CP)

By mandating in State 4.2.5 (Section 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 (Section 4.2.7) is fundamental to preventing cache poisoning.¶

5.2. Regarding Denial of Service (V_DS)

By emphasizing that the resolver MUST continue to await a valid response (return to State 0 (Section 4.2.1)) 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 (Section 4.2.3), 4.2.4 (Section 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.¶

5.3. Regarding Resource Exhaustion (V_RC)

By explicitly requiring in State 4.2.10 (Section 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.¶