draft-ietf-dnsext-message-size-03.txt   draft-ietf-dnsext-message-size-04.txt 
DNSEXT Working Group Olafur Gudmundsson (NAI Labs) DNSEXT Working Group Olafur Gudmundsson
<draft-ietf-dnsext-message-size-03.txt> <draft-ietf-dnsext-message-size-04.txt>
Updates: RFC 2535, RFC 2874 Updates: RFC 2535, RFC 2874
DNSSEC and IPv6 A6 aware server/resolver message size requirements DNSSEC and IPv6 A6 aware server/resolver message size requirements
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Comments should be sent to the authors or the DNSEXT WG mailing list Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org namedroppers@ops.ietf.org
This draft expires on July 20, 2001. This draft expires on August 22, 2001.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All rights reserved. Copyright (C) The Internet Society (2001). All rights reserved.
Abstract Abstract
This document mandates support for EDNS0 in DNS entities claiming to This document mandates support for EDNS0 in DNS entities claiming to
support either DNS Security Extensions or A6 records. This support either DNS Security Extensions or A6 records. This
requirement is necessary because these new features increase the size requirement is necessary because these new features increase the size
of DNS messages. If EDNS0 is not supported fall back to TCP will of DNS messages. If EDNS0 is not supported fall back to TCP will
happen, having a detrimental impact on query latency and DNS server happen, having a detrimental impact on query latency and DNS server
load. load. This document updates [RFC2535] and [RFC2874], by adding new
requirements.
1 - Introduction 1 - Introduction
Familiarity with the DNS[RFC1034, RFC1035], DNS Security Familiarity with the DNS[RFC1034, RFC1035], DNS Security
Extensions[RFC2535], EDNS0[RFC2671] and A6[RFC2874] is helpful. Extensions[RFC2535], EDNS0[RFC2671] and A6[RFC2874] is helpful.
RFC 1035[RFC1035] Section 2.3.4 requires that DNS messages over UDP RFC 1035[RFC1035] Section 2.3.4 requires that DNS messages over UDP
have a data payload of 512 octets or less. Most DNS software today have a data payload of 512 octets or less. Most DNS software today
will not accept larger UDP datagrams. Any answer that requires more will not accept larger UDP datagrams. Any answer that requires more
than 512 octets, results in a partial and sometimes useless reply than 512 octets, results in a partial and sometimes useless reply
skipping to change at page 4, line 11 skipping to change at page 4, line 13
large numbers of servers are often exactly those zones that are large numbers of servers are often exactly those zones that are
critical to network operation and that already sustain fairly high critical to network operation and that already sustain fairly high
loads. loads.
2.4 UDP vs TCP for DNS messages 2.4 UDP vs TCP for DNS messages
Given all these factors, it is essential that any implementation that Given all these factors, it is essential that any implementation that
supports DNSSEC and or A6 be able to use larger DNS messages than 512 supports DNSSEC and or A6 be able to use larger DNS messages than 512
octets. octets.
The original 512 restriction was put in place to avoid fragmentation The original 512 restriction was put in place to reduce the
of DNS responses. A fragmented UDP message that suffers a loss of probability of fragmentation of DNS responses. A fragmented UDP
one of the fragments renders the answer useless and the query must be message that suffers a loss of one of the fragments renders the
retried. A TCP connection requires a larger number of round trips answer useless and the query must be retried. A TCP connection
for establishment, data transfer and tear down, but only the lost requires a larger number of round trips for establishment, data
data segments are retransmitted. transfer and tear down, but only the lost data segments are
retransmitted.
In the early days a number of IP implementations did not handle In the early days a number of IP implementations did not handle
fragmentation well, but all modern operating systems have overcome fragmentation well, but all modern operating systems have overcome
that issue thus sending fragmented messages is fine from that that issue thus sending fragmented messages is fine from that
standpoint. The open issue is the effect of losses on fragmented standpoint. The open issue is the effect of losses on fragmented
messages. If connection has high loss ratio only TCP will allow messages. If connection has high loss ratio only TCP will allow
reliable transfer of DNS data, most links have low loss ratios thus reliable transfer of DNS data, most links have low loss ratios thus
sending fragmented UDP packet in one round trip is better than sending fragmented UDP packet in one round trip is better than
establishing a TCP connection to transfer a few thousand octets. establishing a TCP connection to transfer a few thousand octets.
skipping to change at page 4, line 51 skipping to change at page 5, line 8
message size of 4000. This value might be too low to get full message size of 4000. This value might be too low to get full
answers for high level servers and successor of this document may answers for high level servers and successor of this document may
require a larger value. require a larger value.
All RFC2874-compliant servers and resolver MUST support EDNS0 and All RFC2874-compliant servers and resolver MUST support EDNS0 and
advertise message size of at least 1024 octets, but SHOULD advertise advertise message size of at least 1024 octets, but SHOULD advertise
message size of 2048. The IPv6 datagrams should be 1024 octets, message size of 2048. The IPv6 datagrams should be 1024 octets,
unless the MTU of the path is known. unless the MTU of the path is known.
All RFC2535 and RFC2874 compliant entities MUST be able to handle All RFC2535 and RFC2874 compliant entities MUST be able to handle
fragmented IP and IPv6 UDP packets. fragmented IPv4 and IPv6 UDP packets.
All hosts supporting both RFC2535 and RFC2874 MUST use the larger All hosts supporting both RFC2535 and RFC2874 MUST use the larger
required value in EDNS0 advertisements. required value in EDNS0 advertisements.
4 Acknowledgments 4 Acknowledgments
Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas
Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward Lewis Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward Lewis
Michael Patton and Kazu Yamamoto were instrumental in motivating and Michael Patton and Kazu Yamamoto were instrumental in motivating and
shaping this document. shaping this document.
skipping to change at page 6, line 12 skipping to change at page 6, line 15
[RFC2874] M. Crawford, C. Huitema, ``DNS Extensions to Support IPv6 [RFC2874] M. Crawford, C. Huitema, ``DNS Extensions to Support IPv6
Address Aggregation and Renumbering'', RFC2874, July 2000. Address Aggregation and Renumbering'', RFC2874, July 2000.
[OK] D. Conrad, ``Indicating Resolver Support of DNSSEC'', Work in [OK] D. Conrad, ``Indicating Resolver Support of DNSSEC'', Work in
progress, draft-ietf-dnsext-dnssec-okbit-xx.txt, November progress, draft-ietf-dnsext-dnssec-okbit-xx.txt, November
2000. 2000.
Author Address Author Address
Olafur Gudmundsson Olafur Gudmundsson
NAI Labs/Network Associates 3826 Legation Street, NW
3060 Washington Road (Rt. 97) Washington, DC 20015
Glenwood, MD 21738
USA USA
<ogud@tislabs.com> <ogud@ogud.com>
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/