One document matched: draft-barwood-dnsext-edns-page-option-03.txt
Differences from draft-barwood-dnsext-edns-page-option-02.txt
DNS Extensions Working Group G. Barwood
Internet-Draft
Intended status: Standards track 23 August 2009
Expires: February 2010
EDNS Page Option
draft-barwood-dnsext-edns-page-option-03
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 23, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Initial request . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Server response . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Follow-up request . . . . . . . . . . . . . . . . . . . . . 5
3. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
7. Informative References . . . . . . . . . . . . . . . . . . . . 7
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 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 response, 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.
A particular problem occurs with 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.
Barwood Expires February 2010 [Page 3]
Internet-Draft EDNS Page Option August 2009
2. Protocol
Reserved areas and undefined bits must be set to zero length / zero by
the sender and must be ignored by the receiver.
2.1 Initial request
The client signals support in it's initial request by including
an EDNS Page option with option data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|A| | UDPMAX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXTID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ RESERVED /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where :
A is a 1 bit field set to request that the server send all
pages immediately. It must not be used with proxy servers
that do not support it, except for discovery. The server
may decline the request.
UDPMAX is a 12 bit field that limits the UDP payload of response
packets. Commonly set to 512, as proxies often limit
responses to the RFC 1035 UDP limit. The minimum value
is 512.
EXTID is a 32 bit field used to validate the response, preventing
blind spoofing.
2.2 Server response
The server responds with an EDNS Page option with option data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|N| | PAGESIZE | TOTAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXTID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| COOKIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAGE | /
+-+-+-+-+-+-+-+-+ /
/ DATA /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where :
Barwood Expires February 2010 [Page 4]
Internet-Draft EDNS Page Option August 2009
A is a 1 bit field set to indicate that all pages have
been sent.
N indicates that the cookie is omitted, and follow-up
requests are not possible.
PAGESIZE is a 14 bit field, the size of the pages into which the full
response is divided, chosen so that the UDP payload does not
exceed UDPMAX from the initial request. Servers may also
limit the UDP payload for other reasons, for example to
mitigate an amplification attack, or to avoid IP
fragmentation.
TOTAL is the total size, in bytes, of the whole response.
EXTID is a copy of the EXTID from the request. The client must
check that the value is as expected.
COOKIE is a 32 bit field, used in follow-up requests.
PAGE is an 8 bit field.
DATA is a variable length field containg the page data.
The client allocates an assembly buffer of TOTAL bytes, and copies DATA
into it, at offset PAGE x PAGESIZE.
2.3 Follow-up request
If the A bit of the response is zero, the client sends a follow-up
request for each page it has not yet received. The client should also
send follow-up requests if an expected response is not received after
a timeout period due to packet loss.
A follow-up request is identical to the initial request, except
that the EDNS page option data is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| | PAGESIZE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXTID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| COOKIE |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAGE | /
+-+-+-+-+-+-+-+-+ /
/ RESERVED /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where :
PAGESIZE is a copy of PAGESIZE in the response.
Barwood Expires February 2010 [Page 5]
Internet-Draft EDNS Page Option August 2009
EXTID is a copy of EXTID in the initial request.
COOKIE is a copy of COOKIE from the response.
PAGE identifies the required page.
COOKIE identifies a read-only representation of the full response
on the server, possibly in conjunction with the Question.
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.
Follow-up requests may be sent in parallel.
3. Compatibility
Servers are not required to support the EDNS Page option, however
support is encouraged.
Authoritative servers that do not support the EDNS page option can
expect a higher level of TCP traffic.
Authoritative servers need not support cookies. Initial requests to
authoritative servers should normally set the A flag. However, cookie
support is encouraged, as it allows dropped packets to be retried
without re-sending the whole response.
DNSSEC aware recursive servers need to support cookies if they may
be accessed via proxy servers that truncate responses at 512 bytes.
DNSSEC validating stub resolvers need to use the EDNS Page option if
they may be deployed behind proxy servers that truncate responses at
512 bytes.
Firewalls may not allow multiple responses through, and servers
should detect this possibility, and disable multiple responses,
if the firewall cannot be re-configured.
4. 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.
Barwood Expires February 2010 [Page 6]
Internet-Draft EDNS Page Option August 2009
To limit the effectiveness of amplification attacks on third parties,
servers should make every effort to limit the maximum number of
packets that are sent in response to a single query.
Suggested techniques include:
- Declining requests to send all pages when QTYPE=ANY.
- Not sending the NS RRset when QTYPE=DNSKEY.
- Limiting additional section processing so that it does not
contribute to the maximum response.
- Checking that UDPMAX in the initial request at least 512.
5. IANA Considerations
The EDNS TYPE code for Page Option.
6. Acknowledgments
Mark Andrews, Alex Bligh, Robert Elz, DOuglas Otis,
Wouter Wijngaards, Nicholas Weaver were each instrumental in
creating and refining this specification.
7. 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 7]
| PAFTECH AB 2003-2026 | 2026-04-24 05:20:44 |