DNS Extensions Working Group G. Barwood Internet-Draft Intended status: Standards track 18 August 2009 Expires: February 2010 EDNS Page Option draft-barwood-dnsext-edns-page-option-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 February 16, 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 EDNS option to allow large DNS responses to be sent using small UDP packets. Barwood Expires February 2010 [Page 1] Internet-Draft EDNS Page Option August 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Initial request . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Server response . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Follow-up request . . . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 6. Informative References . . . . . . . . . . . . . . . . . . . . 5 Barwood Expires February 2010 [Page 2] Internet-Draft EDNS Page Option August 2009 1. Introduction DNSSEC implies that DNS responses may be large, possibly larger than the de factor ~1500 byte internet MTU. Large UDP packets are undesirable for 3 reasons: (1) Although the IP protocol specifies a means by which large IP packets are split into fragments and then re-assembled, in practice this mechanism cannot be relied on, and large UDP packets may fail to be delivered (2) If a single fragment is lost, the the entire response must be re-sent. (3) The large ratio between the request size and the response size allows malicious programs to mount "amplification" attacks. (4) Re-assembling fragments requires buffer resources, which opens up denial of service attacks. Instead, it is possible to use TCP, but this is undesirable, as TCP imposes significant overhead and state that is 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. A particular problem occurs with home router proxies, which often truncate DNS responses at 512 bytes. In this case, TCP does not help, and it is impossible to retrieve responses through the proxy. Therefore an EDNS option to allow large DNS responses to be sent using small UDP packets is proposed. The option includes an authentication mechanism that prevents blind spoofing of the response, provided IP fragmentation does not occur. 2. Protocol 2.1 Initial request The client signals support in it's initial request by including an EDNS Page option containing the following data: - Secret Key ( 4 bytes ) The secret key is used to validate the response, preventing blind spoofing. Barwood Expires February 2010 [Page 3] Internet-Draft EDNS Page Option August 2009 2.2 Server response The server responds with an EDNS Page option containing the following option data: - Secret key ( 4 bytes ) - Page size ( 2 bytes ) - Page number ( 1 byte ) - Cookie ( 4 bytes ) - Total response size ( 2 bytes ) - Page data The original Question is not sent. The secret key is a copy of the secret key sent in the request. The page size is chosen so that the complete response packet size does not exceed the EDNS UDP payload size as defined in [RFC2181]. Servers may also limit the response size for other reasons, for example to mitigate an amplification attack, or to avoid IP fragmentation. The client allocates an assembly buffer, and copies the Page data into it, at offset (Page number) x (Page Size). 2.3 Follow-up request The client then sends a follow-up request for each page it has not yet received. Each follow-up request has the Question and an EDNS page option with option data as follows: - Secret Key ( 4 bytes ) - Page size ( 2 bytes ) - Page number ( 1 byte ) - Cookie ( 4 bytes ) The cookie (possibly in conjunction with the Question) identifies a read-only representation of the full response on the server. The cookie has a lifetime of 5 seconds. After this time has elapsed, a SERVERFAIL error response may be generated. When the client has received all of the pages, the complete assembled response is then processed normally. The follow-up requests may be sent in parallel. The client should retry a request if no response is received after a timeout period. Barwood Expires February 2010 [Page 4] Internet-Draft EDNS Page Option August 2009 3. Security Considerations The secret key may expose internal state to an attacker who controls a name server. It is essential that a cryptographically strong source of random numbers be used to generate the secret key. This must be seeded from data that cannot be guessed by an attacker, such as thermal noise or other random physical fluctuations. Clients must verify the secret key in each response. Fragmented responses are vulnerable to blind spoofing, therefore fragmented responses should be avoided if possible. 4. IANA Considerations The EDNS TYPE code for Page Option. 5. Acknowledgments 6. Informative References [RFC2181] P. Vixie, "Extension Mechanisms for DNS (EDNS0)", RFC 2181, August 1999. 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 February 2010 [Page 5]