draft-ietf-dnsop-respsize-11.txt   draft-ietf-dnsop-respsize-12.txt 
Internet Engineering Task Force P. Vixie Internet Engineering Task Force P. Vixie
Internet-Draft Internet Systems Consortium Internet-Draft Internet Systems Consortium
Intended status: Informational A. Kato Intended status: Informational A. Kato
Expires: January 16, 2009 Keio University/WIDE Project Expires: September 15, 2011 Keio University/WIDE Project
July 15, 2008 March 14, 2011
DNS Referral Response Size Issues DNS Referral Response Size Issues
draft-ietf-dnsop-respsize-11 draft-ietf-dnsop-respsize-12
Abstract
With a mandated default minimum maximum UDP message size of 512
octets, the DNS protocol presents some special problems for zones
wishing to expose a moderate or high number of authority servers (NS
RRs). This document explains the operational issues caused by, or
related to this response size limit, and suggests ways to optimize
the use of this limited space. Guidance is offered to DNS server
implementors and to DNS zone operators.
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on September 15, 2011.
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 January 16, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Abstract This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
With a mandated default minimum maximum UDP message size of 512 This document may contain material from IETF Documents or IETF
octets, the DNS protocol presents some special problems for zones Contributions published or made publicly available before November
wishing to expose a moderate or high number of authority servers (NS 10, 2008. The person(s) controlling the copyright in some of this
RRs). This document explains the operational issues caused by, or material may not have granted the IETF Trust the right to allow
related to this response size limit, and suggests ways to optimize modifications of such material outside the IETF Standards Process.
the use of this limited space. Guidance is offered to DNS server Without obtaining an adequate license from the person(s) controlling
implementors and to DNS zone operators. the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
1. Introduction and Overview 1. Introduction and Overview
The DNS standard limits UDP message size to 512 octets (see [RFC1035] The original DNS standard limited UDP message size to 512 octets (see
4.2.1). Even though this limitation was due to the required minimum [RFC1035] 4.2.1). Even though this limitation was due to the
IP reassembly limit for IPv4, it became a hard DNS protocol limit and required minimum IP reassembly limit for IPv4, it became a hard DNS
is not implicitly relaxed by changes in a network layer protocol, for protocol limit and is not implicitly relaxed by changes in a network
example to IPv6. layer protocol, for example to IPv6.
The EDNS (Extension Mechanisms for DNS) protocol extension starting The EDNS (Extension Mechanisms for DNS) protocol extension starting
with version 0 permits larger responses by mutual agreement of the with version 0 permits larger responses by mutual agreement of the
requester and responder (see [RFC2671] 2.3, 4.5), and it is requester and responder (see [RFC2671] 2.3, 4.5), and it is
recommended to support EDNS. The 512 octets UDP message size limit recommended to support EDNS. The 512 octets UDP message size limit
will remain in practical effect until virtually all DNS servers and will remain in practical effect until virtually all DNS servers and
resolvers support EDNS. resolvers support EDNS.
Since DNS responses include a copy of the request, the space Since DNS responses include a copy of the request, the space
available for response data is somewhat less than the full 512 available for response data is somewhat less than the full 512
octets. Negative responses are quite small, but for positive and octets. Negative responses are quite small, but for positive and
referral responses, every octet must be carefully and sparingly referral responses, every octet must be carefully and sparingly
allocated. While the response size of positive responses is also a allocated. While the response size of positive responses is also a
concern in [RFC3226], this document specifically addresses referral concern in [RFC3226], this document specifically addresses referral
response size. response size.
EDNS deployment eleven years after the publication of [RFC2671] has
reached approximately 65% of the client population as measured at one
root name server and this fraction has not changed in recent years.
The long tail of EDNS deployment may eventually be measured in
decades.
Even if EDNS deployment reached 100% of all DNS initiators and
responders there will still be cases when path MTU limitations or IP
fragmentation/reassembly problems in firewalls and other middleboxes
will cause EDNS failures which leads to non-extended DNS retries. A
smaller referral response will always be better than a larger one if
the same end result can be achieved either way.
2. Delegation Details 2. Delegation Details
2.1. Relevant Protocol Elements 2.1. Relevant Protocol Elements
A positive delegation response will include the following elements: A positive delegation response will include the following elements:
Header Section: fixed length (12 octets) Header Section: fixed length (12 octets)
Question Section: original query (name, class, type) Question Section: original query (name, class, type)
Answer Section: empty, or a CNAME/DNAME chain Answer Section: empty, or a CNAME/DNAME chain
Authority Section: NS RRset (nameserver names) Authority Section: NS RRset (nameserver names)
skipping to change at page 6, line 11 skipping to change at page 7, line 11
shown in Figure 1. Note that 13 servers are named, and 13 addresses shown in Figure 1. Note that 13 servers are named, and 13 addresses
are given. This query was artificially designed to exactly reach the are given. This query was artificially designed to exactly reach the
512 octets limit. 512 octets limit.
;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13 ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
;; QUERY SECTION: ;; QUERY SECTION:
;; [23456789.123456789.123456789.\ ;; [23456789.123456789.123456789.\
123456789.123456789.123456789.com A IN] ;; @80 123456789.123456789.123456789.com A IN] ;; @80
;; AUTHORITY SECTION: ;; AUTHORITY SECTION:
com. 86400 NS E.GTLD-SERVERS.NET. ;; @112 com. 172800 NS E.GTLD-SERVERS.NET. ;; @112
com. 86400 NS F.GTLD-SERVERS.NET. ;; @128 com. 172800 NS F.GTLD-SERVERS.NET. ;; @128
com. 86400 NS G.GTLD-SERVERS.NET. ;; @144 com. 172800 NS G.GTLD-SERVERS.NET. ;; @144
com. 86400 NS H.GTLD-SERVERS.NET. ;; @160 com. 172800 NS H.GTLD-SERVERS.NET. ;; @160
com. 86400 NS I.GTLD-SERVERS.NET. ;; @176 com. 172800 NS I.GTLD-SERVERS.NET. ;; @176
com. 86400 NS J.GTLD-SERVERS.NET. ;; @192 com. 172800 NS J.GTLD-SERVERS.NET. ;; @192
com. 86400 NS K.GTLD-SERVERS.NET. ;; @208 com. 172800 NS K.GTLD-SERVERS.NET. ;; @208
com. 86400 NS L.GTLD-SERVERS.NET. ;; @224 com. 172800 NS L.GTLD-SERVERS.NET. ;; @224
com. 86400 NS M.GTLD-SERVERS.NET. ;; @240 com. 172800 NS M.GTLD-SERVERS.NET. ;; @240
com. 86400 NS A.GTLD-SERVERS.NET. ;; @256 com. 172800 NS A.GTLD-SERVERS.NET. ;; @256
com. 86400 NS B.GTLD-SERVERS.NET. ;; @272 com. 172800 NS B.GTLD-SERVERS.NET. ;; @272
com. 86400 NS C.GTLD-SERVERS.NET. ;; @288 com. 172800 NS C.GTLD-SERVERS.NET. ;; @288
com. 86400 NS D.GTLD-SERVERS.NET. ;; @304 com. 172800 NS D.GTLD-SERVERS.NET. ;; @304
;; ADDITIONAL SECTION: ;; ADDITIONAL SECTION:
A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320 A.GTLD-SERVERS.NET. 172800 A 192.5.6.30 ;; @320
B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336 B.GTLD-SERVERS.NET. 172800 A 192.33.14.30 ;; @336
C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352 C.GTLD-SERVERS.NET. 172800 A 192.26.92.30 ;; @352
D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368 D.GTLD-SERVERS.NET. 172800 A 192.31.80.30 ;; @368
E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384 E.GTLD-SERVERS.NET. 172800 A 192.12.94.30 ;; @384
F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400 F.GTLD-SERVERS.NET. 172800 A 192.35.51.30 ;; @400
G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416 G.GTLD-SERVERS.NET. 172800 A 192.42.93.30 ;; @416
H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432 H.GTLD-SERVERS.NET. 172800 A 192.54.112.30 ;; @432
I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448 I.GTLD-SERVERS.NET. 172800 A 192.43.172.30 ;; @448
J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464 J.GTLD-SERVERS.NET. 172800 A 192.48.79.30 ;; @464
K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480 K.GTLD-SERVERS.NET. 172800 A 192.52.178.30 ;; @480
L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496 L.GTLD-SERVERS.NET. 172800 A 192.41.162.30 ;; @496
M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512 M.GTLD-SERVERS.NET. 172800 A 192.55.83.30 ;; @512
;; MSG SIZE sent: 80 rcvd: 512 ;; MSG SIZE sent: 80 rcvd: 512
Figure 1 Figure 1
For longer query names, the number of address records supplied will For longer query names, the number of address records supplied will
be lower. Furthermore, it is only by using a common parent name be lower. Furthermore, it is only by using a common parent name
(which is "GTLD-SERVERS.NET." in this example) that all 13 addresses (which is "GTLD-SERVERS.NET." in this example) that all 13 addresses
are able to fit, due to the use of DNS compression pointers in the are able to fit, due to the use of DNS compression pointers in the
last 12 occurrences of the parent domain name. The outputs from the last 12 occurrences of the parent domain name. The outputs from the
skipping to change at page 12, line 39 skipping to change at page 13, line 39
Phone: +1 650 423 1300 Phone: +1 650 423 1300
Email: paul@vix.com Email: paul@vix.com
Akira Kato Akira Kato
Keio University/WIDE Project Keio University/WIDE Project
Graduate School of Media Design, 4-1-1 Hiyoshi Graduate School of Media Design, 4-1-1 Hiyoshi
Kohoku, Yokohama 223-8526 Kohoku, Yokohama 223-8526
JP JP
Phone: +81 3 5418 6419 Phone: +81 45 564 2490
Email: kato@wide.ad.jp Email: kato@wide.ad.jp
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 14 change blocks. 
58 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/