Algorithms for Domain Name System (DNS) Cookies constructionInternet Systems ConsortiumCZondrej@isc.orgNLnet LabsScience Park 400Amsterdam1098 XHNetherlandswillem@nlnetlabs.nl
Internet
DNSOP Working Group left the construction of Server Cookies to the discretion
of the DNS Server (implementer) which has resulted in a gallimaufry of
different implementations. As a result, DNS Cookies are impractical
to deploy on multi-vendor anycast networks, because the Server Cookie
constructed by one implementation cannot be validated by another.
This document provides precise directions for creating Server Cookies to
address this issue. Furthermore, is obsoleted as a suitable Hash
function for calculating DNS Cookies. is introduced as a new
REQUIRED Hash function for calculating DNS Cookies.
This document updates In in Section 6 it is "RECOMMENDED for simplicity that
the Same Server Secret be used by each DNS server in a set of anycast
servers." However, how precisely a Server Cookie is calculated from
this Server Secret, is left to the implementation.
This guidance has let to DNS Cookie implementations, calculating the
Server Cookie in different ways. This causes problems with anycast
deployments with DNS Software from multiple vendors, because even when
all DNS Software would share the same secret, as RECOMMENDED in Section
6. of , they all produce different Server Cookies based on
that secret and (at least) the Client Cookie and Client IP Address.
In Section instructions for constructing a Client
Cookie are given
In Section instructions for constructing a Server
Cookie are given
In Section the different hash functions usable
for DNS Cookie construction are listed. and HMAC-SHA-256-64
are obsoleted and AES and are
introduced as a REQUIRED hash function for DNS Cookie
implementations.
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.
The Client Cookie is a nonce and should be treated as such. For simplicity,
it can be calculated from Client IP Address, Server IP Address and a secret
known only to the Client. The Client Cookie SHOULD have at least 64-bits
of entropy. If a secure pseudorandom function (like SipHash24) is used there's
no need to change Client secret periodically and change the Client secret only
if it has been compromised.
It's recommended but not required that a pseudorandom function is used to
construct the Client Cookie:
where "|" indicates concatenation.
The Server Cookie is effectively message authentication code (MAC) and should be
treated as such.
The Server Cookie is not required to be changed periodically if a secure
pseudorandom function is used.
The 128-bit Server Cookie consists of Sub-Fields: a 1 octet Version
Sub-Field, a 1 octet Cookie Algorithm Sub-Field, a 2 octet Reserved
Sub-Field, a 4 octet Timestamp Sub-Field and a 8 octet Hash Sub-Field.
The Version Sub-Field prescribes the structure and Hash calculation
formula. This document defines Version 1 to be the structure and way to
calculate the Hash Sub-Field as defined in this Section.
The Cookie Algo value defines what algorithm function to use for
calculating the Hash Sub-Field as described in . The values
are described in .
The value of the Reserved Sub-Field is reserved for future versions of Server
Side Cookie construction. Even though the value has no specific meaning
in this Version, note that it is used in determining the Hash value
as described in .
The Timestamp value prevents Replay Attacks and MUST be checked by the server to
be within a defined period of time. The DNS Server SHOULD allow Cookies within
1 hour period in the past and 5 minutes into the future to allow operation of
low volume clients and certain time skew between the DNS servers in the anycast.
The DNS Server SHOULD generate new Server Cookie at least if the received Server
Cookie from the Client is older than half an hour.
It's important that all the DNS servers use the same algorithm for computing the
Server Cookie. This document defines the Version 1 of the Server Side algorithm
to be:
Implementation recommendations for Cookie Algorithms [DNSCOOKIE-IANA]:
NumberMnemonicsClient CookieServer Cookie1FNVMUST NOTMUST NOT2HMAC-SHA-256-64MUST NOTMUST NOT3AESMAYMAY4SIPHASH24MUSTMUST is a Non-Cryptographic Hash Algorithm and this document obsoletes
the usage of FNV in DNS Cookies.
HMAC-SHA-256-64 is an HMAC-SHA-256 algorithm reduced to 64-bit. This particular
algorithm was implemented in BIND, but it was never the default algorithm and the
computational costs makes it unsuitable to be used in DNS Cookies. Therefore
this document obsoletes the usage of HMAC-SHA-256 algorithm in the DNS Cookies.
The AES algorithm has been the default DNS Cookies algorithm in BIND until
version x.y.z, and other implementations MAY implement AES algorithm as
implemented in BIND for backwards compatibility. However it's recommended that
new implementations implement only a pseudorandom functions for DNS Cookies, in
this document that would be SipHash24.
is a pseudorandom function suitable as message authentication
code, and this document REQUIRES compliant DNS Server to use SipHash24 as a
mandatory and default algorithm for DNS Cookies to ensure interoperability
between the DNS Implementations.
IANA is requested to create and maintain a sub-registry (the "DNS Cookie
Algorithm" registry) of the "Domain Name System (DNS) Parameters"
registry. The initial values for this registry are described in .
The FNV Non-Cryptographic Hash AlgorithmSipHash: a fast short-input PRF