DNS Extensions Working Group G. Barwood Internet-Draft Intended status: Experimental 21 October 2009 Expires: April 2010 DNS Transport draft-barwood-dnsext-dns-transport-14 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 22, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This documnent describes an experimental transport protocol for DNS. IP fragmentation is avoided, blind spoofing, amplification attacks and other denial of service attacks are prevented. Latency for a typical DNS query is a single round trip, after a setup hadnshake. No per-client server state is required between transactions. The protocol may have other applications. Barwood Expires April 2010 [Page 1] Internet-Draft DNS Transport October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions and Objectives . . . . . . . . . . . . . . . . . . 3 2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Security Objectives . . . . . . . . . . . . . . . . . . . . 4 2.3 Performance Objectives . . . . . . . . . . . . . . . . . . 4 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Setup request . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Setup response . . . . . . . . . . . . . . . . . . . . . . 5 3.4 Initial request . . . . . . . . . . . . . . . . . . . . . . 5 3.5 Server response : single page . . . . . . . . . . . . . . . 6 3.6 Server response : multi page . . . . . . . . . . . . . . . 6 3.7 Follow-up request . . . . . . . . . . . . . . . . . . . . . 7 3.8 Encryption and Authentication . . . . . . . . . . . . . . . 7 3.9 Congestion control . . . . . . . . . . . . . . . . . . . . 8 3.10 Status codes . . . . . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 7.2 Informative References . . . . . . . . . . . . . . . . . . . 11 Appendix A. Implementation of Cookies . . . . . . . . . . . . . . 12 Appendix B. Anycast considerations . . . . . . . . . . . . . . . 12 Authors Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Barwood Expires April 2010 [Page 2] Internet-Draft DNS Transport October 2009 1. Introduction DNSSEC implies that DNS responses may be large, possibly larger than the de facto ~1500 byte internet MTU. Large responses are a challenge for DNS transport. EDNS [RFC2671] was introduced in 1999 to allow larger responses to be sent over UDP, previously DNS/UDP was limited to a 512 bytes. EDNS is problematic for several reasons: (1) It allows amplification attacks against 3rd parties. DNS/UDP has always been susceptible to these attacks, but EDNS has increased the amplification factor by an order of magnitude. (2) The IP protocol specifies a means by which large IP packets are split into fragments and then re-assembled. However fragmented UDP responses are undesirable for several reasons: o Fragments may be spoofed. The DNS ID and port number are only present in the first fragment, and the IP ID may be easy for an attacker to predict. o In practice fragmentation is not reliable, and large UDP packets may fail to be delivered. o If a single fragment is lost, the entire response must be re-sent. o Re-assembling fragments requires buffer resources, which opens up denial of service attacks [GONT]. Instead, it is possible to use TCP, but this is undesirable, as TCP imposes increased latency and significant server state that may be vulnerable to denial of service attack. In addition, support for TCP is not universal. Nearly all current DNS traffic is carried by UDP with a maximum size of 512 bytes, and relying on TCP is a risk for the deployment of DNSSEC. Therefore a new protocol is proposed, with mnenomic QRP, to stand for "Quick Response Protocol". 2. Definitions and Objectives 2.1 Definitions 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 [RFC2119]. DNS Payload A DNS Message [RFC1035], not including the 16-bit ID field. For AXFR, the response messages are concatenated without ID fields, to form a single DNS payload. Barwood Expires April 2010 [Page 3] Internet-Draft DNS Transport October 2009 Transaction A transaction is initiated by a client request packet and the server responds with one or more response packets. All the packets in a transaction have the same REQUESTID. Transfer The requested transfer of a DNS Payload, using one or more transactions as described in sections 3.6 and 3.7. 2.2 Security Objectives Fragmentation must not occur provided the actual path MTU is at least the MTU sent by the client or 600 bytes, whichever is larger. Blind spoofing attacks must be prevented. Amplification attacks against third parties must be prevented. 2.3 Performance Objectives No per-client server state must be needed between transactions. Each Transfer ( for moderate response sizes ) is performed in a single round trip, after setup. Only lost IP packets are re-transmitted. 3. Protocol 3.1 Overview Communication is over UDP [RFC768] in two stages. First a long-lived SERVERTOKEN is acquired by the client. Subsequent queries are protected against amplification attacks by the SERVERTOKEN. DNS server support for the protocol is signaled by a general purpose method [TPORT]. Each UDP packet starts with a 16-bit OPCODE, followed ( except as described in section 3.8 ) by a 64-bit REQUESTID that identifies the transaction. These fields are not shown in the packet diagrams. Fixed length field sizes are as shown in the packet diagrams. All numbers are unsigned integers, with the first bit being the most significant. Variable length reserved areas MUST be omitted by the sender. Fixed length reserved areas MUST be set to zero by the sender. All reserved areas MUST be ignored by the receiver. Barwood Expires April 2010 [Page 4] Internet-Draft DNS Transport October 2009 3.2 Setup request The client acquires a SERVERTOKEN for a given Server IP address by sending a packet with OPCODE 1, format : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ RESERVED \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3 Setup response The server response has OPCODE 1, format : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SERVERTOKEN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | STATUS | RESERVED \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where : SERVERTOKEN is a 32 bit value computed as a secure hash of the client IP Address and a long term server secret. Servers MUST change the long term secret at least once every 4 weeks. STATUS is an 8 bit status code, see section 3.10. The client associates SERVERTOKEN, and the client IP address ( for multi-homed clients ) with the Server IP address. 3.4 Initial request To make a DNS request, a packet is sent with OPCODE 2, format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SERVERTOKEN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | COUNT | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ DATA \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where : SERVERTOKEN is a copy of SERVERTOKEN from the setup response. MTU limits the size in bytes of the IP packets used to send the response. MUST be at least 600. COUNT limits the number of pages the server will send. DATA is the DNS payload. Barwood Expires April 2010 [Page 5] Internet-Draft DNS Transport October 2009 3.5 Server response : single page The server checks SERVERTOKEN, and obtains the DNS response payload. If the requested MTU is less than 600 bytes, the server SHOULD set MTU to 600 bytes. If the path MTU is known to be less than the value supplied by the client, MTU is reduced to that value ( but not to less than 600 bytes ). If the DNS payload size plus IP/UDP/QRP overhead is not greater than MTU, the server sends a single page response, OPCODE 2, format : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ DATA \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where DATA is the DNS payload. The client uses DATA as the normal DNS response. 3.6 Server response : multi page Otherwise, the server divides the DNS payload into equal size pages, so that each IP response packet does not exceed MTU, and sends multiple packets, each with OPCODE 3 and format : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ DATA \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOTAL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | COOKIE | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | COUNT | PAGE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAGESIZE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where : DATA is part of the DNS payload. TOTAL is the size of the complete DNS payload. COOKIE is a 64-bit value used to request further pages. COUNT is the number of pages sent. PAGE is the 24-bit zero-based number of this page. PAGESIZE is the size into which the DNS payload has been divided. The client allocates an assembly buffer of TOTAL bytes (if not already allocated), and copies DATA into it at offset PAGE x PAGESIZE. Barwood Expires April 2010 [Page 6] Internet-Draft DNS Transport October 2009 Clients SHOULD impose limits on the maximum size response (TOTAL) they will accept, to prevent attacks by malicious servers. Servers MAY send a smaller number of pages than requested, for policy reasons, or if there is local congestion. The pages sent have numbers 0 .. COUNT-1. 3.7 Follow-up request If the client does not receive a page, due to not all pages being sent, or packet loss (with the former having priority), it sends a packet with OPCODE 3, format : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SERVERTOKEN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | COOKIE | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | COUNT | PAGE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAGESIZE | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ DATA \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where : SERVERTOKEN is a copy of the SERVERTOKEN from the setup response. COOKIE is a copy of COOKIE from the server response. COUNT is the number of pages requested. PAGE is the number of the first page to be sent. PAGESIZE is a copy of PAGESIZE from the server response. DATA is a copy of DATA from the initial request. The server response is the same as in section 3.6. Once a client has received all pages, it processes the complete assembled response as normal. If the server encounters an error condition, such as an invalid SERVERTOKEN or COOKIE, it sends a setup response (section 3.3), and the client retries with a new initial request (section 3.4). If a server has more than one IP address, a client MAY attempt to use a SERVERTOKEN it has previously acquired from another IP address. A client MAY also attempt to re-use a COOKIE to continue a failed transfer on an alternate server IP address or an alternatve server. Barwood Expires April 2010 [Page 7] Internet-Draft DNS Transport October 2009 3.8 Encryption and Authentication. OPCODE 4 is used to optionally encrypt and authenticate packets. The encryption and authentication algorithms are described in [NACL]. Public keys are 255 bits. The wire format is 32 bytes, with the unused first bit set to zero. Public key tags are the first 4 bytes of the wire format public key. For client requests, the OPCODE is followed by o A 12 byte client nonce. o A 32 byte client public key. o A 4 byte server public key tag. o A cryptographic box containing a 16 byte MAC and the encrypted packet. For server responses, the OPCODE is followed by o A 12 byte client nonce ( copied from the request ). o A 12 byte server nonce. o A cryptographic box containing a 16 byte MAC and the encrypted packet. In both cases the 64-bit REQUESTID is omitted from the unencrypted packet, which starts with the underlying OPCODE. The 12 byte client nonce is used instead to identify the transaction. Public keys are stored in QRPK resource records, which are included in the Authority section of the response whenever an A or AAAA record for the same domain is sent. The wire format is as above, the presentation format is the 50 character base32 encoded string of the 255-bit public key, using "0123456789BCDFGHJKLMNPQRSTUVWXYZ" as the alphabet for the encoding, which is case insensitive. To avoid inter-operability problems with old non-conformant resolvers, when the DNS transport protocol is UDP (without EDNS) and QTYPE=MX, or according to similar criteria determined by operational experience, QRPK records MAY be omitted. Where the parent zone does not have QRPK support, or the domain owner is unable to upload a QRPK record to the parent zone, public keys MAY be encoded in a label of a name server, using the prefix "QK-" followed by the presentation format encoding of the public key. 3.9 Congestion control The number of pages requested but not received or lost (INFLIGHT) MUST be limited to a value (INFLIGHTMAX) so that undue network congestion is avoided. Packets are deemed lost if they do not arrive within TIMEOUT milli-seconds of being requested. A simple method suitable for current DNS purposes (excluding AXFR) is to set INFLIGHTMAX = 4 and TIMEOUT = 1500 milli-seconds. Barwood Expires April 2010 [Page 8] Internet-Draft DNS Transport October 2009 Alternatively, the following control algorithm MAY be used to allow higher performance. Set INFLIGHTMAX = 4 + 3 * ( RTT / PT ) * ( RTT / RTT_RECENT ) TIMEOUT = INFLIGHTHIGH * PT + 2 * RTT_MAX where RTT is the observed minimum round trip time based on a long sampling period. PT is the smoothed observed time to transmit a full size packet based on a long sampling period. RTT_RECENT is the smoothed observed round trip time, based on a short sampling period. INFLIGHTHIGH is the highest value of INFLIGHT for the current transfer. RTT_MAX is the maximum round trip time observed over an long sampling period. The intention is that the the number of in-flight packets is quickly reduced in response to an increase in latency. Sampling periods and smoothing filters need to be determined and tuned based on operational experience. "A long sampling period" might be the last 8 transfers. RTT_RECENT might be updated when a packet arrives by setting RTT_RECENT = ALPHA * TRIP + (1-ALPHA) * RTT_RECENT where TRIP is the round trip time for the packet. ALPHA is 0.1 if PACKETS > 10, otherwise 1.0 / PACKETS. PACKETS is the number of packets received. Other control algorithms MAY be employed, provided they do not cause a significant increase in latency ( round trip time ). Algorithms that increase INFLIGHT until packets are lost MUST NOT be used. Explicit Congestion Notification [RFC3168] MAY be used. Barwood Expires April 2010 [Page 9] Internet-Draft DNS Transport October 2009 3.10 Status Codes The following values are defined: 0 No error 1 Invalid SERVERTOKEN 2 Invalid COOKIE 11 Invalid OPCODE 12 End of packet error 13 Other format error 31 Invalid PAGESIZE 32 Invalid PAGE 41 Invalid Public Key Tag 42 Authentication error Only codes 0-2 will occur if the protocol is correctly implemented, in the absence of network errors or attacks. Servers MAY optionally generate status codes greater than 10. Such responses MAY be logged or used for debugging purposes, but MUST otherwise be ignored. 4. Security Considerations Fragmented responses are vulnerable to blind spoofing. If the path MTU is less than the value supplied by the client, denial of service attacks are possible, and data can be altered unless authenticated by other means. Amplification attacks from previous users of the client IP address on the current user are not prevented by the protocol until the long term server secret is changed, as described in section 3.3. In-path (man-in-the-middle) amplification attacks are not prevented, however such attacks are relatively difficult to carry out, requiring the attacker to have network access close to the victim. Transactions not protected as described in section 3.8 are vulnerable to data alteration. Such attacks may be prevented by the use of DNSSEC. Secret values need to be generated so that an attacker cannot easily guess them, by using cryptographic random number generators seeded from data that cannot be guessed by an attacker, such as thermal noise or other random physical fluctuations. Barwood Expires April 2010 [Page 10] Internet-Draft DNS Transport October 2009 5. IANA Considerations The following values may be used for private testing only : 53000 for the UDP Port to which requests are sent. 252 for the DNS transport protocol identifier ( mnemomic QRP ). 65356 for the TPORT resource record type identifier. 65357 for the QRPK recorce record type identifier. IANA is requested to make official reservations, to allow public operation. 6. Acknowledgments Mark Andrews, Alex Bligh, Robert Elz, Alfred Hoenes, Douglas Otis, Nicholas Weaver and Wouter Wijngaards were each instrumental in creating and refining this specification. 7. References 7.1 Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC768] J. Postel, "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, August 1980. [TPORT] Barwood, G., "DNS Transport Signal", IETF dnsext draft, October 2009. [NACL] Bernstein, D., "Cryptography in NaCl", March 2009. [RFC3168] Ramakrishnan, K., "The Addition of Explicit Congestion Notification (ECN) to IP", September 2001. 7.2 Informative References [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [GONT] Gont, F., "Security Assessment of the Internet Protocol version 4", August 2009. Barwood Expires April 2010 [Page 11] Internet-Draft DNS Transport October 2009 Appendix A. Implementation of Cookies The suggested implementation of cookies is by version numbers. Each RRset has a version number assigned from a 64-bit clock that is increased whenever the DNS database is updated. The version of a response is the largest version number of the associated RRsets. The cookie is the version number. If the database is updated while a transfer is progress, a COOKIE error occurs, and the client restarts the transfer. Alternatively, if old queries may be replayed, COOKIE errors may be avoided( however such errors should be rare ). Appendix B. Anycast considerations Anycast DNS servers need to operate consistently. There are (at least ) two possibilities: (a) Each server within the Anycast system issues distinct SERVERTOKENS. If the Anycast routing changes, a SERVERTOKEN error occurs, and the client restarts the query. (b) Each server within the Anycast system has the same long term secret, and thus issues the same SERVERTOKEN to a given client. A global clock is used for issuing updates. If the Anycast routing changes and an update is in progress, a COOKIE error may occur, and the client has to restart the query. Such errors can be avoided by not serving updates until all the Anycast servers have received a copy. Author's Address George Barwood 33 Sandpiper Close Gloucester GL2 4LZ United Kingdom Phone: +44 452 722670 EMail: george.barwood@blueyonder.co.uk Barwood Expires April 2010 [Page 12]