A DNS Resource Record for Additional Entropy

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC2119.

The core DNS protocol is defined in RFC1034, RFC1035 and clarified in RFC2181. It is a replicated hierarchical distributed database system that provides information fundamental to Internet operations, such as name to address mapping. One difficulty which affects most DNS implementations is a susceptibility to cache poisoning attacks as a result of forging DNS responses. There are only 16 bits of random data for expressing a query ID, making it a frequent target for forgery. [In fairness the query ID was never intended to provide resilience to forgery attacks. It was designed to allow a resolving name server to differentiate between responses to the outstanding queries it had sent to some other, presumably authoritative, name server.] Until recently most DNS server implementations used a small set of fixed port numbers for outgoing queries. This made the task of forging a response to a DNS query somewhat straightforward. Stub resolvers can be vulnerable to forgery attacks because they generally rely on the underlying operating system to select a port number for their DNS queries and may also use predictable query IDs. If these are insufficiently random, forging responses to queries from stub resolvers may not pose much of a challenge to attackers. Current defences against forgery of DNS responses include transaction authentication schemes such as TSIG RFC2845 and Secure DNS (DNSSEC) RFC4033 RFC4034 RFC4037. These can be difficult to deploy and operate, particularly for non-experts. TSIG is usually impractical outside environments where clients and servers are under the same administrative control. While DNSSEC provides integrity protection of DNS responses, it is not yet widely deployed. Considerable time and effort will be required before adoption of DNSSEC is ubiquitous. This document proposes an interim solution that could be used until widespread deployment of DNSSEC. It advocates the introduction of a new resource record type, AL, to add extra entropy to DNS queries, minimising ther potential exposure to DNS forgery attacks.

A new RR type whose mnemonic is AL (aleatoric) and type code FOO is proposed. All RDATA in the proposed AL record are sent in network byte order (see Section 2.3.2 of RFC1034). The AL record's RDATA consists of a fixed field of two octets containing a count of the number of octets in the following variable length field. This variable length field SHOULD contain random data.

ZS RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | COUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / ENTROPY / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: COUNT Number of octets in the ENTROPY field ENTROPY Random data

Use of this resource record for defending against forgery attacks is broadly comparable to the scheme used in RFC2845. AL resource records will generally be related to one DNS query/response transaction. Therefore there is no value in storing or retransmitting them. This means that AL resource records should be treated as meta-RRs and MUST NOT be cached.

A client generates an AL record on the fly by populating it with suitably random data and a count of the number of octets of that data. This is then inserted into the Additional Section of the query and the ARCOUNT incremented accordingly. If the AL record cannot be added to the query without causing it to be truncated, the client MUST either adjust the message to allow the AL record to be added or use TCP to make the query. Clients MUST NOT include more than one AL record in the Additional Section of each query. The client MUST retain a copy of the random data for each query until a response is received or the query times out. To maximise the opportunity for label compression, the name of the AL record SHOULD be identical to the QNAME in the query's Question Section.

Servers MUST NOT include more than one AL record in the Additional Section of a response. If a server receives a query with more than one AL record in the Additional Section, the query MUST be discarded and a FORMERR (RCODE = 1) returned to the client. When a server receives a query containing an AL record in the Additional Section, it MUST ensure this is copied to the Additional Section of the corresponding reply that it constructs. If the AL record cannot be added to the response without causing it to be truncated, the server MAY adjust the message by discarding other data from the Additional Section. A server MUST NOT discard any transaction signature from the Additional Section to make room for an AL record. In some circumstances, the amount of data in the reply may make it impossible to include an AL record in the Additional Section without causing truncation. In these cases the server MUST send a response consisting of empty Answer and Authority Sections, the original Question Section and the client's AL record in the Additional Section. This reply MUST set the TC bit to signal truncation and set the RCODE to 0 (NOERROR). The client SHOULD at this point retry the request using TCP in the manner described in Section 4.2.2 of RFC1035.

On receipt of a response containing an AL record in the Additional Section, the client SHOULD compare this to the random data it had generated for the original query. If these are not identical, the client MUST discard the reply and the corresponding state information for that query. When the original random data and the contents of the returned AL record's data are identical, the response is returned to the resolver that initiated the query in the conventional manner. A response containing more than one AL record in the Additional Section MUST be discarded.

The motivation of this document is the addition of extra randomness to DNS queries to make it harder to forge responses to them. However it is also envisaged that clients could make explicit lookups for this record type as a way of obtaining random data from a name server: for example if the server has access to a strong source of such data.

The generation and volume of random data for AR records need careful consideration. The random data SHOULD originate from a good entropy source. Large amounts of random data in an AR record is undesirable and may well be an unnecessary overhead because it increases the likelihood of truncated responses and an increased use of TCP based queries.

It MUST be recognised that this document only provides a limited defence from DNS forgery attacks. Although it introduces additional entropy to DNS queries that makes it harder to predict their contents, this scheme provides no protection whatsoever if an attacker has visibility of the outgoing query or its response and can intercept them. The only way to prevent these vulnerabilities is the use of transaction authentication and/or DNSSEC to detect spoofed or tampered responses. The suggested use of AL records is an ugly kludge to essentially increase the number of bits for a query ID without modifying the core protocol or breaking the installed base. It is not and MUST NOT be viewed as a mechanism to either provide DNS transaction security or authentication. The scheme proposed in this document is intended to minmise the exposure of routine UDP-based query/response transactions to forgery attacks that attempt to predict the query ID and port number. In particular, the introduction of this scheme and AR records MUST NOT be used to authenticate or validate any forms of zone transfer or dynamic update. These should be protected by some combination of transaction signature and secure data transport mechanisms such as a VPN or IPsec.

IANA is requested to issue a new type code and mnemonic for the proposed resource record. No other IANA services are required by this document.

The author would like to thank the authors of RFC 2845, Paul Vixie, Olafur Gudmundsson, Donald Eastlake and Brian Wellington for unintentionally inspiring this draft.