Clarifications to the DNS Specification
updated by
- rfc-2535 — Domain Name System Security Extensions
- rfc-4033 — DNS Security Introduction and Requirements
- rfc-4034 — Resource Records for the DNS Security Extensions
- rfc-4035 — Protocol Modifications for the DNS Security Extensions
- rfc-4343 — Domain Name System (DNS) Case Insensitivity Clarification
- rfc-5452 — Measures for Making DNS More Resilient against Forged Answers
- rfc-8767 — Serving Stale Data to Improve DNS Resiliency
updates
Extracted elements (25)
Differing TTLs within an RRSet are deprecated because no use for this has been found that cannot be better accomplished otherwise, and it causes partial replies from caching servers where some but not all TTLs in an RRSet have expired, leading to incomplete non-truncated responses.
The TC bit must not be set when additional information is omitted due to space constraints; the omitted records should simply be dropped and the reply sent as-is. This avoids forcing clients into TCP for data that was only supplementary.
At a zone cut, both the parent and child zone may have NXT records for the same name; these two NXT records do not form an RRSet even when both zones are hosted on the same server. NXT RRSets always contain exactly one RR.
SIG records (DNSSEC) are permitted to appear in the authority section containing only those SIG RRs whose 'type covered' field equals the type of an answer being returned, rather than the full SIG RRSet. Servers must not cache such partial SIG records in a way that would allow them to be returned in response to a SIG query.
A query for a specific label, class, and type must return all records in the associated RRSet. If the entire RRSet will not fit in the response, the response must be marked as truncated (TC bit set).
A server for a zone should not return authoritative answers for queries related to names in another zone, including NS and A records at a zone cut, unless it is also a server for the other zone. Servers should ignore data other than NS records (and necessary A records) configured at a zone cut.
All RRs within an RRSet must have the same TTL value. The use of differing TTLs in an RRSet is deprecated. In no case may a server send an RRSet with TTLs not all equal.
An alias name (the label of a CNAME record) may have SIG, NXT, and KEY RRs if DNSSEC is in use, but must have no other data records. For any DNS label, exactly one of these holds: it has one CNAME record (optionally with DNSSEC records), one or more non-CNAME records, no RRs, or does not exist.
An RRSet should only be included once in any DNS reply, regardless of which section (Answer, Authority, or Additional) it appears in. It should not be repeated in the same or any other section except where explicitly required by specification (e.g., SOA in AXFR).
DNS implementations must not place any restrictions on the labels that can be used beyond the length limits: individual labels are limited to 1–63 octets, and a full domain name is limited to 255 octets including separators. Any binary string is a valid DNS label.
If a client receives an RRSet with differing TTLs from a non-authoritative source, it should ignore the RRSet. If from an authoritative source, it should treat all TTLs as if set to the lowest TTL in the RRSet.
Implementations must treat TTL values received with the most significant bit set as if the entire value received was zero. Implementations may place an upper bound on any received TTL value and treat larger values as that upper bound.
Implementations should not assume that SOA records will have a TTL of zero, nor are they required to send SOA records with a TTL of zero. The RFC1035 suggestion that SOA TTL should always be zero to prevent caching is not to be followed.
Replies to all DNS queries must be directed to the port from which they were sent. For UDP queries, the server must record the source port and use it as the destination port in the response.
Servers must never merge RRs from a response with RRs already in their cache to form an RRSet. If a response contains data that would form an RRSet with cached data, the server must either ignore the response RRs or discard the entire cached RRSet.
SOA records, if added to an authoritative answer, are to be placed in the authority section, not the additional section. RFC1034 section 4.3.4's mention of the additional section for SOA in negative caching is incorrect.
The domain name used as the value of an NS resource record, or part of the value of an MX resource record, must not be an alias. These names must have address records (currently A records) and must never have a CNAME RR.
The MNAME field of the SOA record must contain the name of the primary (master) server for the zone, not the name of the zone itself.
The TC (truncated) bit must be set only when an RRSet required as part of the response cannot be included in its entirety. It must not be set merely because optional additional information was omitted; such additional records should be dropped entirely and the reply sent with TC clear.
The value of a PTR record must not be an alias (CNAME label). There is no restriction that a PTR RRSet contain only one record; multiple PTR records for a name are permitted.
When responding to UDP queries, a server must set the IP source address in the reply to the destination address from the query packet's IP header. If that address is not permitted, the server may use any legal address allocated to it, chosen to maximize client reachability.
A Resource Record Set (RRSet) is defined as the group of DNS Resource Records sharing the same label, class, and type but potentially differing in data. Servers should suppress exact duplicates (same label, class, type, and data). An RRSet is the atomic unit for DNS responses.
Data trustworthiness is ranked from most to least: primary zone file data, zone transfer data, authoritative answer section data, authority section of authoritative answer, glue from primary or transfer, non-authoritative answer section data, and additional information from any answer. Additional data and non-authoritative authority section data must not be returned as answers to queries.
This document does not address DNS security. Correct implementation of the clarifications herein may limit the spread of non-malicious bad data in the DNS, but only DNSSEC (RFC2065) can protect against deliberate attempts to subvert DNS data. The data ranking rules in section 5.4.1 are not security mechanisms.
The TTL field is an unsigned integer with a minimum of 0 and a maximum of 2147483647 (2^31 - 1). It is encoded in the least-significant 31 bits of the 32-bit TTL field, with the most significant bit set to zero.