DNS/RFC/8906/3

Contents

3. Common Kinds of Queries That Result in No or Bad Responses

If a zone is delegated to a server, that server should respond to a SOA query for that zone with an SOA record.

Failing to respond at all is always incorrect, regardless of the configuration of the server.

Responding with anything other than an SOA record in the answer section indicates a bad delegation.

Some servers fail to respond to unknown or unsupported types. If a server receives a query for a type that it doesn't recognise, or doesn't implement, it is expected to return the appropriate response as if it did recognise the type but does not have any data for that type, i.e., either NOERROR or NXDOMAIN. The exceptions to this are queries for Meta-RR types, which may return NOTIMP.

Some servers fail to respond to DNS queries with various DNS flags set, regardless of whether they are defined or still reserved. At the time of writing, there are servers that fail to respond to queries with the AD flag set to 1 and servers that fail to respond to queries with the last reserved flag set. Servers should respond to such queries. If the server does not know the meaning of a flag, it must not copy it to the response (Section 4.1.1 of [RFC1035]). If the server does not understand the meaning of a request, it should reply with a FORMERR response with unknown flags set to zero.

3.1.3.1. Recursive Queries

A non-recursive server is supposed to respond to recursive queries as if the Recursion Desired (RD) bit is not set [RFC1034].

The use of previously undefined opcodes is to be expected. Since the DNS was first defined, two new opcodes have been added, UPDATE and NOTIFY. NOTIMP is the expected rcode to an unknown or unimplemented opcode.
- | NOTE: while new opcodes will most probably use the current | layout structure for the rest of the message, there is no | requirement that anything other than the DNS header match.

All DNS servers are supposed to respond to queries over TCP [RFC7766]. While firewalls should not block TCP connection attempts, those that do should cleanly terminate the connection by sending TCP RESET or sending ICMP/ICMPv6 Administratively Prohibited messages. Dropping TCP connections introduces excessive delays to the resolution process.

Identifying servers that fail to respond to EDNS queries can be done by first confirming that the server responds to regular DNS queries, followed by a series of otherwise identical queries using EDNS, then making the original query again. A series of EDNS queries is needed, as at least one DNS implementation responds to the first EDNS query with FORMERR but fails to respond to subsequent queries from the same address for a period until a regular DNS query is made. The EDNS query should specify a UDP buffer size of 512 bytes to avoid false classification of not supporting EDNS due to response packet size. If the server responds to the first and last queries but fails to respond to most or all of the EDNS queries, it is probably faulty. The test should be repeated a number of times to eliminate the likelihood of a false positive due to packet loss. Firewalls may also block larger EDNS responses, but there is no easy way to check authoritative servers to see if the firewall is misconfigured.

Some servers respond correctly to EDNS version 0 queries but fail to respond to EDNS queries with version numbers that are higher than zero. Servers should respond with BADVERS to EDNS queries with version numbers that they do not support. Some servers respond correctly to EDNS version 0 queries but fail to set QR=1 when responding to EDNS versions they do not support. Such responses may be discarded as invalid (as QR is not 1) or treated as requests (when the source port of the original request was port 53).

Some servers fail to respond to EDNS queries with EDNS options set. The original EDNS specification left this behaviour undefined [RFC2671], but the correct behaviour was clarified in [RFC6891]. Unknown EDNS options are supposed to be ignored by the server.

Some servers fail to respond to EDNS queries with EDNS flags set. Servers should ignore EDNS flags they do not understand and must not add them to the response [RFC6891].

=== 3.2.5. Truncated EDNS Responses ===

Some EDNS-aware servers fail to include an OPT record when a truncated response is sent. An OPT record is supposed to be included in a truncated response [RFC6891]. Some EDNS-aware servers fail to honour the advertised EDNS UDP buffer size and send oversized responses [RFC6891]. Servers must send UDP responses no larger than the advertised EDNS UDP buffer size.

Some nameservers incorrectly only return an EDNS response when the DNSSEC OK (DO) bit [RFC3225] is 1 in the query. Servers that support EDNS should always respond to EDNS requests with EDNS responses. Some nameservers fail to copy the DO bit to the response despite clearly supporting DNSSEC by returning an RRSIG records to EDNS queries with DO=1. Nameservers that support DNSSEC are expected to copy the DO bit from the request to the response.

Some EDNS-aware servers incorrectly limit the TCP response sizes to the advertised UDP response size. This breaks DNS resolution to clients where the response sizes exceed the advertised UDP response size despite the server and the client being capable of sending and receiving larger TCP responses, respectively. It effectively defeats setting TC=1 in UDP responses.