DNS Extensions Working Group G. Barwood Internet-Draft Intended status: Experimental 28 August 2009 Expires: March 2010 DNS Transport draft-barwood-dnsext-dns-transport-01 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 March 1, 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 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 DNS query is a single round trip, after a setup exchange that establishes a long term shared secret. The protocol may have other applications. Barwood Expires March 2010 [Page 1] Internet-Draft DNS Transport August 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Fragmentation. . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Server state . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4 Amplification attacks . . . . . . . . . . . . . . . . . . . 4 2.5 Packet retransmission . . . . . . . . . . . . . . . . . . . 4 2.6 Performance . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Setup request . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Setup response . . . . . . . . . . . . . . . . . . . . . . . 5 3.4 Initial request . . . . . . . . . . . . . . . . . . . . . . 6 3.5 Server response : single page . . . . . . . . . . . . . . . 6 3.6 Server response : multi page . . . . . . . . . . . . . . . . 7 3.7 Retry request . . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 A. Implementation of Cookies . . . . . . . . . . . . . . . . . . 9 Authors Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Barwood Expires March 2010 [Page 2] Internet-Draft DNS Transport August 2009 1. Introduction DNSSEC implies that DNS responses may be large, possibly larger than the de facto ~1500 byte internet MTU. The IP protocol specifies a means by which large IP packets are split into fragments and then re-assembled. Fragmented UDP responses are undesirable for several reasons: (1) Fragments can easily be spoofed. The DNS ID and port number are only present in the first fragment, and the IP ID is usually easy for an attacker to predict. (2) In practise fragmentation is not reliable, and large UDP packets may fail to be delivered. (3) If a single fragment is lost, the entire response must be re-sent. (4) Re-assembling fragments requires buffer resources, which opens up denial of service attacks. Instead, it is possible to use TCP for large responses, but this is undesirable, as TCP imposes significant overhead and state that may be vulnerable to denial of service attack. 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 protocol to allow large DNS responses to be sent using small UDP packets is proposed. Barwood Expires March 2010 [Page 3] Internet-Draft DNS Transport August 2009 2. Requirements 2.1 Fragmentation As described in the introduction, fragmentation is undesirable. However, fragmentation is unavoidable if the path MTU is too small. Therefore, we require only that fragmentation dos not occur provided the actual path MTU is at least the MTU sent by the client. 2.2 Spoofing Blind spoofing attacks must be prevented. 2.3 Server state No per-client server state is required between transactions. 2.4 Amplification attacks Amplification attacks against third parties must be prevented. 2.5 Packet re-transmission Only lost IP packets must be re-transmitted. This reduces problems due to network congestion. 2.6 Performance Each transaction must be performed in 1 RTT, after setup, provided that no IP packets are lost. Barwood Expires March 2010 [Page 4] Internet-Draft DNS Transport August 2009 3. Protocol 3.1 Overview Communication is in two stages. First a long-lived SERVERTOKEN is acquired by the client, using a standard DNS lookup. Subsequent queries are sent using a different port, and are protected by the SERVERTOKEN. Throughout, DNS Payload refers to a DNS Message [RFC1035], not including the 16-bit ID field. 3.2 Setup request The client acquires a SERVERTOKEN for a given Server IP address by sending a special question to the server, with QTYPE = TXT QCLASS = IN QNAME = TRANSPORT..LOCAL where is a secret label chosen to prevent spoofing of the response. 3.3 Setup response The server returns a TXT record as answer to the question, which contains a string with format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | SPORT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SERVERTOKEN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SPORT is a 16 bit UDP port number, to which requests are sent. SERVERTOKEN is a 32 bit value computed as a hash of the client IP Address and a permanent server secret. The TTL should be at least 1 day. The client associates the SERVERTOKEN and the client IP address ( for multi-homed clients ) with the Server IP address. If the TXT record is not returned, the server does not have support, and this fact should be cached, with a TTL of at least 1 day. If a copy of the Question is not returned, extra queries need to be sent to prevent spoofing. This should be very unusual - all known DNS servers return a copy of the question, except for format error responses, which should not occur. This format is intended to be extensible, so that multiple transport options can be obtained with a single query. Barwood Expires March 2010 [Page 5] Internet-Draft DNS Transport August 2009 3.4 Initial request To make a DNS request, a UDP packet is sent to SPORT, with format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | | MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SERVERTOKEN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QUERYID | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ DATA \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where : QUERYID identifies the request. MTU limits the size of the IP packets used to send the response. Must be at least 576 bytes. SERVERTOKEN is a copy of the SERVERTOKEN from the setup response. DATA is the DNS payload. 3.5 Server response : single page The server checks SERVERTOKEN (it does not respond to invalid tokens), and divides the DNS payload into equal size pages, so that the size of each IP packet is not greater than MTU. If there is only one page, the UDP response packet has format : +-+-+-+-+-+-+-+-+ | 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SERVERTOKEN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QUERYID | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ DATA \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where : SERVERTOKEN is a copy of the SERVERTOKEN from the initial request. QUERYID is a copy of QUERYID from the initial request. DATA is the DNS payload. The client checks SERVERTOKEN, and then uses DATA as the normal DNS response. Barwood Expires March 2010 [Page 6] Internet-Draft DNS Transport August 2009 3.6 Server response : multi page If there is more than one page, each UDP response packet has format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | | PAGE | PAGESIZE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SERVERTOKEN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | COOKIE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOTAL | QUERYID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DATA \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where : PAGE is the 0-based number of the page. PAGESIZE is the size into which the reponse has been divided. SERVERTOKEN is a copy of SERVERTOKEN from the request. COOKIE is used to re-try missing pages. TOTAL is the size of the complete response ( excluding tyhe ID ). QUERYID is a copy of QUERYID from the request. DATA is part of the DNS payload. The client checks SERVERTOKEN, allocates an assembly buffer of TOTAL bytes (if not already allocated), and copies DATA into it at offset PAGE x PAGESIZE. Once all the pages have been received, the assembly buffer contains the DNS payload. 3.7 Retry request If the client fails to receive a page, due to packet loss, it sends a retry request as follows : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | | PAGE | PAGESIZE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SERVERTOKEN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | COOKIE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QUERYID | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ DATA \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Barwood Expires March 2010 [Page 7] Internet-Draft DNS Transport August 2009 where : PAGE is the 0-based number of the page. QUERYID is a copy of QUERYID from the initial request. PAGESIZE is a copy of PAGESIZE from a server response. SERVERTOKEN is a copy of the SERVERTOKEN from the setup response. COOKIE is a copy of COOKIE from the server response. DATA is a copy of DATA from the initial request. Responses are the same as in section 3.6. If the response COOKIE changes, the existing pages are discarded, and retry requests are issued for the pages that have not been fetched, using a new QUERYID. If an initial request times out on 2 consecutive occasions (using a given SERVERTOKEN), the SERVERTOKEN is deleted, and a new SERVERTOKEN must be acquired. 3.8 Reserved areas Reserved areas and undefined bits must be set to zero length / zero by the sender and must be ignored by the receiver. Variable length areas after the end of the defined fields are always reserved. 4. Security Considerations Fragmented responses are vulnerable to blind spoofing, therefore fragmented responses should be avoided if possible. A check must be made that the MTU is at least 584, to prevent an attacker generating a large number of IP packets from a single request. 5. IANA Considerations None 6. Acknowledgments Mark Andrews, Alex Bligh, Robert Elz, Douglas Otis, Wouter Wijngaards and Nicholas Weaver were each instrumental in creating and refining this specification. 7. References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. Barwood Expires March 2010 [Page 8] Internet-Draft DNS Transport August 2009 Appendix A : Implementation of Cookies To show how server state is avoided or limited, two possible approaches to the implementation of cookies are shown. These are illustrative, and actual implementations are of course free to take a different approach. (1) The server maintains a DNS database version number, which is incremented when the database is updated. The DNS database is stuctured so that old queries may be replayed, with the database version number being supplied as a parameter. COOKIE is simply the DNS database version number. (2) The server maintains a list of recent multi-page responses: COOKIE DATA ACCESSTIME 1 .... 10:25:11 2 .... 10:25:16 ..... If a response is multi-page, the list is checked to see if there is an existing entry that can be used ( hashing techniques are used to make the search efficient ). Entries that have not been accessed for more than 5 seconds may be deleted. Some care should be taken to ensure that on server restart, old cookie values are not re-used. Periodically, a new range of cookies should be issued, and the new allocation value recorded in permanent storage. Alternatively, the server should wait 10 seconds after restarting before issuing any cookies. 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 March 2010 [Page 9]