draft-ietf-dnsop-respsize-00.txt   draft-ietf-dnsop-respsize-01.txt 
DNSOP Working Group Paul Vixie, ISC (Ed.) DNSOP Working Group Paul Vixie, ISC (Ed.)
INTERNET-DRAFT Akira Kato, WIDE INTERNET-DRAFT Akira Kato, WIDE
<draft-ietf-dnsop-respsize-00.txt> June, 2003 <draft-ietf-dnsop-respsize-01.txt> July, 2004
DNS Response Size Issues DNS Response Size Issues
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions
This document is an Internet-Draft and is in full conformance with of section 3 of RFC 3667. By submitting this Internet-Draft, each
all provisions of Section 10 of RFC2026. author represents that any applicable patent or other IPR claims of
which we are aware have been or will be disclosed, and any of which
we become aware will be disclosed, in accordance with RFC 3668.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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 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.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003-2004). All Rights Reserved.
Abstract Abstract
With a mandated default minimum maximum message size of 512 octets, With a mandated default minimum maximum message size of 512 octets,
the DNS protocol presents some special problems for zones wishing to the DNS protocol presents some special problems for zones wishing to
expose a moderate or high number of authority servers (NS RRs). This expose a moderate or high number of authority servers (NS RRs). This
document explains the operational issues caused by, or related to document explains the operational issues caused by, or related to
this response size limit. this response size limit.
INTERNET-DRAFT June 2003 RESPSIZE
1 - Introduction and Overview 1 - Introduction and Overview
1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512 1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
octets. Even though this limitation was due to the required minimum UDP octets. Even though this limitation was due to the required minimum UDP
reassembly limit for IPv4, it is a hard DNS protocol limit and is not reassembly limit for IPv4, it is a hard DNS protocol limit and is not
implicitly relaxed by changes in transport, for example to IPv6. implicitly relaxed by changes in transport, for example to IPv6.
INTERNET-DRAFT June 2003 RESPSIZE
1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger 1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger
responses by mutual agreement of the requestor and responder. However, responses by mutual agreement of the requestor and responder. However,
deployment of EDNS0 cannot be expected to reach every Internet resolver deployment of EDNS0 cannot be expected to reach every Internet resolver
in the short or medium term. The 512 octet message size limit remains in the short or medium term. The 512 octet message size limit remains
in practical effect at this time. in practical effect at this time.
1.3. Since DNS responses include a copy of the request, the space 1.3. Since DNS responses include a copy of the request, the space
available for response data is somewhat less than the full 512 octets. available for response data is somewhat less than the full 512 octets.
For negative or positive responses, there is rarely a space constraint. For negative responses, there is rarely a space constraint. For
For positive and delegation responses, though, every octet must be positive and delegation responses, though, every octet must be carefully
carefully and sparingly allocated. This document specifically addresses and sparingly allocated. This document specifically addresses
delegation response sizes. delegation response sizes.
2 - Delegation Details 2 - Delegation Details
2.1. A delegation response will include the following elements: 2.1. A 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) Answer Section: (empty)
Authority Section: NS RRset (nameserver names) Authority Section: NS RRset (nameserver names)
skipping to change at page 2, line 42 skipping to change at page 3, line 5
then the TC bit will be set (indicating truncation) which may cause the then the TC bit will be set (indicating truncation) which may cause the
requestor to retry using TCP, depending on what information was present requestor to retry using TCP, depending on what information was present
and what was omitted. If a retry using TCP is needed, the total cost of and what was omitted. If a retry using TCP is needed, the total cost of
the transaction is much higher. the transaction is much higher.
2.3. RRsets are never sent partially, so if truncation occurs, entire 2.3. RRsets are never sent partially, so if truncation occurs, entire
RRsets are omitted. Note that the authority section consists of a RRsets are omitted. Note that the authority section consists of a
single RRset. It is absolutely essential that truncation not occur in single RRset. It is absolutely essential that truncation not occur in
the authority section. the authority section.
INTERNET-DRAFT June 2003 RESPSIZE
2.4. DNS label compression allows a domain name to be instantiated only 2.4. DNS label compression allows a domain name to be instantiated only
once per DNS message, and then referenced with a two-octet "pointer" once per DNS message, and then referenced with a two-octet "pointer"
from other locations in that same DNS message. If all nameserver names from other locations in that same DNS message. If all nameserver names
in a message are similar (for example, all ending in ".ROOT- in a message are similar (for example, all ending in ".ROOT-
SERVERS.NET"), then more space will be available for uncompressable data SERVERS.NET"), then more space will be available for uncompressable data
(such as nameserver addresses). (such as nameserver addresses).
2.5. The query name can be as long as 255 characters of presentation 2.5. The query name can be as long as 255 characters of presentation
data, which can be up to 256 octets of network data. In this worst case data, which can be up to 256 octets of network data. In this worst case
scenario, the question section will be 260 octets in size, which would scenario, the question section will be 260 octets in size, which would
INTERNET-DRAFT June 2003 RESPSIZE
leave only 240 octets for the authority and additional sections (after leave only 240 octets for the authority and additional sections (after
deducting 12 octets for the fixed length header.) deducting 12 octets for the fixed length header.)
2.6. Average and maximum question section sizes can be predicted by the 2.6. Average and maximum question section sizes can be predicted by the
zone owner, since they will know what names actually exist, and can zone owner, since they will know what names actually exist, and can
measure which ones are queried for most often. For cost and performance measure which ones are queried for most often. For cost and performance
reasons, the majority of requests should be satisfied without truncation reasons, the majority of requests should be satisfied without truncation
or TCP retry. or TCP retry.
2.7. Requestors who deliberately send large queries to force truncation 2.7. Requestors who deliberately send large queries to force truncation
are only increasing their own costs, and cannot effectively attack the are only increasing their own costs, and cannot effectively attack the
resources of an authority server since the requestor would have to retry resources of an authority server since the requestor would have to retry
using TCP to complete the attack. An attack that always used TCP would using TCP to complete the attack. An attack that always used TCP would
have a lower cost. have a lower cost.
2.8. The minimum useful glue is two address records. (With only one 2.8. The minimum useful number of address records is two, since with
address, the probability that it would refer to an unreachable server is only one address, the probability that it would refer to an unreachable
too high.) Truncation which occurs after two address records have been server is too high. Truncation which occurs after two address records
added to the additional data section is therefore less operationally have been added to the additional data section is therefore less
significant than truncation which occurs earlier. operationally significant than truncation which occurs earlier.
2.9. The best case is no truncation. (This is because many requestors 2.9. The best case is no truncation. (This is because many requestors
will retry using TCP by reflex, without considering whether the omitted will retry using TCP by reflex, without considering whether the omitted
data was actually necessary.) data was actually necessary.)
INTERNET-DRAFT June 2003 RESPSIZE INTERNET-DRAFT June 2003 RESPSIZE
3 - Analysis 3 - Analysis
3.1. An instrumented protocol trace of a best case delegation response 3.1. An instrumented protocol trace of a best case delegation response
follows. Note that 13 servers are named, and 13 addresses are given. follows. Note that 13 servers are named, and 13 addresses are given.
This query was artificially designed to exactly reach the 512 octet This query was artificially designed to exactly reach the 512 octet
limit. limit.
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 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. 86400 NS E.GTLD-SERVERS.NET. ;; @112
com. 86400 NS F.GTLD-SERVERS.NET. ;; @128 com. 86400 NS F.GTLD-SERVERS.NET. ;; @128
com. 86400 NS G.GTLD-SERVERS.NET. ;; @144 com. 86400 NS G.GTLD-SERVERS.NET. ;; @144
com. 86400 NS H.GTLD-SERVERS.NET. ;; @160 com. 86400 NS H.GTLD-SERVERS.NET. ;; @160
com. 86400 NS I.GTLD-SERVERS.NET. ;; @176 com. 86400 NS I.GTLD-SERVERS.NET. ;; @176
skipping to change at page 5, line 4 skipping to change at page 5, line 4
F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400 F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400
G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416 G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416
H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432 H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432
I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448 I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448
J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464 J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464
K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480 K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480
L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496 L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496
M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512 M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512
;; MSG SIZE sent: 80 rcvd: 512 ;; MSG SIZE sent: 80 rcvd: 512
INTERNET-DRAFT June 2003 RESPSIZE INTERNET-DRAFT June 2003 RESPSIZE
3.2. For longer query names, the number of address records supplied will 3.2. For longer query names, the number of address records supplied will
be lower. Furthermore, it is only by using a common parent name (which be lower. Furthermore, it is only by using a common parent name (which
is GTLD-SERVERS.NET in this example) that all 13 addresses are able to is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
fit. The following output from a response simulator demonstrates these fit. The following output from a response simulator demonstrates these
properties: properties:
% perl respsize.pl 13 13 0 % perl respsize.pl 13 13 0
common name, average case: msg:303 glue#13 (green) common name, average case: msg:303 nsaddr#13 (green)
common name, worst case: msg:495 glue# 1 (red) common name, worst case: msg:495 nsaddr# 1 (red)
uncommon name, average case: msg:457 glue# 3 (orange) uncommon name, average case: msg:457 nsaddr# 3 (orange)
uncommon name, worst case: msg:649(*) glue# 0 (red) uncommon name, worst case: msg:649(*) nsaddr# 0 (red)
% perl respsize.pl 13 13 2 % perl respsize.pl 13 13 2
common name, average case: msg:303 glue#11 (orange) common name, average case: msg:303 nsaddr#11 (orange)
common name, worst case: msg:495 glue# 1 (red) common name, worst case: msg:495 nsaddr# 1 (red)
uncommon name, average case: msg:457 glue# 2 (orange) uncommon name, average case: msg:457 nsaddr# 2 (orange)
uncommon name, worst case: msg:649(*) glue# 0 (red) uncommon name, worst case: msg:649(*) nsaddr# 0 (red)
(Note: The response simulator's source code is contained in the (Note: The response simulator program is shown in Section 5.)
appendix.)
Here we use the term "green" if all address records could fit, or Here we use the term "green" if all address records could fit, or
"orange" if two or more could fit, or "red" if fewer than two could fit. "orange" if two or more could fit, or "red" if fewer than two could fit.
It's clear that without a common parent for nameserver names, much space It's clear that without a common parent for nameserver names, much space
would be lost. would be lost.
4 - Further Work We're assuming an average query name size of 64 since that is the
typical average maximum size seen in trace data at the time of this
4.1. Traces from one or more root name servers and at least a dozen writing. If Internationalized Domain Name (IDN) or any other technology
diverse TLD name servers should be analyzed to measure the actual which results in larger query names be deployed significantly in advance
minimum, maximum, average, and standard deviation in query name sizes. of EDNS, then more new measurements and new estimates will have to be
made.
4.2. Current delegation response sizes from the root server system for 4 - Conclusions
all TLDs should be measured in light of the known query name sizes found
to be in use.
4.3. A policy should be created for the addition of AAAA RR's for 4.1. The current practice of giving all nameserver names a common parent
existing name servers, in both TLD delegations under the root zone, and (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
SLD delegations under interested TLDs. responses and allows for more nameservers to be enumerated than would
otherwise be possible. (Note that in this case it is wise to serve the
common parent domain's zone from the same servers that are named within
it, in order to limit external dependencies when all your eggs are in a
single basket.)
4.4. Participants in the Internationalized Domain Names (IDN) effort 4.2. Thirteen (13) seems to be the effective maximum number of
should take careful note of the performance effects of larger query nameserver names usable traditional (non-extended) DNS, assuming a
names on root name server system delegation sizes. common parent domain name, and assuming that additional-data truncation
is undesirable in the average case.
INTERNET-DRAFT June 2003 RESPSIZE INTERNET-DRAFT June 2003 RESPSIZE
4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a
prototypical delegation that currently contains thirteen (13) IPv4
nameserver addresses (A RRs) for thirteen (13) nameserver names under a
common parent, would not have a significant negative operational impact
on the domain name system.
5 - Source Code 5 - Source Code
#!/usr/bin/perl -w #!/usr/bin/perl -w
$asize = 2+2+2+4+2+4; $asize = 2+2+2+4+2+4;
$aaaasize = 2+2+2+4+2+16; $aaaasize = 2+2+2+4+2+16;
($nns, $na, $naaaa) = @ARGV; ($nns, $na, $naaaa) = @ARGV;
test("common", "average", common_name_average($nns), $na, $naaaa); test("common", "average", common_name_average($nns),
test("common", "worst", common_name_worst($nns), $na, $naaaa); $na, $naaaa);
test("uncommon", "average", uncommon_name_average($nns), $na, $naaaa); test("common", "worst", common_name_worst($nns),
test("uncommon", "worst", uncommon_name_worst($nns), $na, $naaaa); $na, $naaaa);
test("uncommon", "average", uncommon_name_average($nns),
$na, $naaaa);
test("uncommon", "worst", uncommon_name_worst($nns),
$na, $naaaa);
exit 0; exit 0;
sub test { my ($namekind, $casekind, $msg, $na, $naaaa) = @_; sub test { my ($namekind, $casekind, $msg, $na, $naaaa) = @_;
my $nglue = numglue($msg, $na, $naaaa); my $nglue = numglue($msg, $na, $naaaa);
printf "%8s name, %7s case: msg:%3d%s glue#%2d (%s)\n", printf "%8s name, %7s case: msg:%3d%s nsaddr#%2d (%s)\n",
$namekind, $casekind, $namekind, $casekind,
$msg, ($msg > 512) ? "(*)" : " ", $msg, ($msg > 512) ? "(*)" : " ",
$nglue, ($nglue == $na + $naaaa) ? "green" $nglue, ($nglue == $na + $naaaa) ? "green"
: ($nglue >= 2) ? "orange" : ($nglue >= 2) ? "orange"
: "red"; : "red";
} }
sub pnum { my ($num, $tot) = @_; sub pnum { my ($num, $tot) = @_;
return sprintf "%3d%s", return sprintf "%3d%s",
} }
sub numglue { my ($msg, $na, $naaaa) = @_; sub numglue { my ($msg, $na, $naaaa) = @_;
my $space = ($msg > 512) ? 0 : (512 - $msg); my $space = ($msg > 512) ? 0 : (512 - $msg);
my $num = 0; my $num = 0;
while ($space && ($na || $naaaa )) { while ($space && ($na || $naaaa )) {
if ($na) { if ($na) {
if ($space >= $asize) { if ($space >= $asize) {
$space -= $asize; $space -= $asize;
INTERNET-DRAFT June 2003 RESPSIZE
$num++; $num++;
} }
$na--; $na--;
} }
if ($naaaa) { if ($naaaa) {
if ($space >= $aaaasize) { if ($space >= $aaaasize) {
$space -= $aaaasize; $space -= $aaaasize;
$num++; $num++;
} }
$naaaa--; $naaaa--;
INTERNET-DRAFT June 2003 RESPSIZE
} }
} }
return $num; return $num;
} }
sub msgsize { my ($qname, $nns, $nsns) = @_; sub msgsize { my ($qname, $nns, $nsns) = @_;
return 12 + # header return 12 + # header
$qname+2+2 + # query $qname+2+2 + # query
0 + # answer 0 + # answer
$nns * (4+2+2+4+2+$nsns); # authority $nns * (4+2+2+4+2+$nsns); # authority
skipping to change at page 8, line 4 skipping to change at page 8, line 4
return 15 + worst_case($nns, 2); return 15 + worst_case($nns, 2);
} }
sub uncommon_name_average { my ($nns) = @_; sub uncommon_name_average { my ($nns) = @_;
return average_case($nns, 15); return average_case($nns, 15);
} }
sub uncommon_name_worst { my ($nns) = @_; sub uncommon_name_worst { my ($nns) = @_;
return worst_case($nns, 15); return worst_case($nns, 15);
} }
INTERNET-DRAFT June 2003 RESPSIZE INTERNET-DRAFT June 2003 RESPSIZE
5 - Author's Address Security Considerations
The recommendations contained in this document have no known security
implications.
IANA Considerations
This document does not call for changes or additions to any IANA
registry.
IPR Statement
Copyright (C) The Internet Society (2003-2004). 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 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.
Authors' Addresses
Paul Vixie Paul Vixie
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
+1 650 779 7000 +1 650 423 1301
paul@vix.com vixie@isc.org
Akira Kato Akira Kato
University of Tokyo, Information Technology Center University of Tokyo, Information Technology Center
2-11-16 Yayoi Bunkyo 2-11-16 Yayoi Bunkyo
Tokyo 113-8658, JAPAN Tokyo 113-8658, JAPAN
+81 3 5841 2750 +81 3 5841 2750
kato@wide.ad.jp kato@wide.ad.jp
 End of changes. 

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