draft-ietf-dnsop-respsize-05.txt   draft-ietf-dnsop-respsize-06.txt 
DNSOP Working Group Paul Vixie, ISC DNSOP Working Group Paul Vixie, ISC
INTERNET-DRAFT Akira Kato, WIDE INTERNET-DRAFT Akira Kato, WIDE
<draft-ietf-dnsop-respsize-05.txt> August 2006 <draft-ietf-dnsop-respsize-06.txt> August 2006
DNS Referral Response Size Issues DNS Referral Response Size Issues
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. 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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
document specifically addresses delegation response sizes. document specifically addresses delegation response sizes.
2 - Delegation Details 2 - Delegation Details
2.1. RELEVANT PROTOCOL ELEMENTS 2.1. RELEVANT PROTOCOL ELEMENTS
2.1.1. A delegation response will include the following elements: 2.1.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, or a CNAME/DNAME chain
Authority Section: NS RRset (nameserver names) Authority Section: NS RRset (nameserver names)
Additional Section: A and AAAA RRsets (nameserver addresses) Additional Section: A and AAAA RRsets (nameserver addresses)
2.1.2. If the total response size exceeds 512 octets, and if the data 2.1.2. If the total response size exceeds 512 octets, and if the data
that does not fit was "required", then the TC bit will be set that does not fit was "required", then the TC bit will be set
(indicating truncation). This will usually cause the requester to retry (indicating truncation). This will usually cause the requester to retry
using TCP, depending on what information was desired and what using TCP, depending on what information was desired and what
information was omitted. For example, truncation in the authority information was omitted. For example, truncation in the authority
section is of no interest to a stub resolver who only plans to consume section is of no interest to a stub resolver who only plans to consume
the answer section. If a retry using TCP is needed, the total cost of the answer section. If a retry using TCP is needed, the total cost of
skipping to change at page 3, line 11 skipping to change at page 3, line 11
truncation. When TC bit is set, the final apparent RRset in the final truncation. When TC bit is set, the final apparent RRset in the final
non-empty section must be considered "possibly damaged" (see [RFC1035 non-empty section must be considered "possibly damaged" (see [RFC1035
6.2], [RFC2181 9]). 6.2], [RFC2181 9]).
INTERNET-DRAFT August 2006 RESPSIZE INTERNET-DRAFT August 2006 RESPSIZE
2.1.4. With or without truncation, the glue present in the additional 2.1.4. With or without truncation, the glue present in the additional
data section should be considered "possibly incomplete", and requesters data section should be considered "possibly incomplete", and requesters
should be prepared to re-query for any damaged or missing RRsets. Note should be prepared to re-query for any damaged or missing RRsets. Note
that truncation of the additional data section might not be signalled that truncation of the additional data section might not be signalled
via the TC bit since additional data is often optional. via the TC bit since additional data is often optional (see discussion
in [RFC4472 B]).
2.1.5. DNS label compression allows a domain name to be instantiated 2.1.5. DNS label compression allows a domain name to be instantiated
only once per DNS message, and then referenced with a two-octet only once per DNS message, and then referenced with a two-octet
"pointer" from other locations in that same DNS message (see [RFC1035 "pointer" from other locations in that same DNS message (see [RFC1035
4.1.4]). If all nameserver names in a message share a common parent 4.1.4]). If all nameserver names in a message share a common parent
(for example, all ending in ".ROOT-SERVERS.NET"), then more space will (for example, all ending in ".ROOT-SERVERS.NET"), then more space will
be available for incompressable data (such as nameserver addresses). be available for incompressable data (such as nameserver addresses).
2.1.6. The query name can be as long as 255 characters of presentation 2.1.6. The query name can be as long as 255 octets of network data. In
data, which can be up to 256 octets of network data. In this worst case this worst case scenario, the question section will be 259 octets in
scenario, the question section will be 260 octets in size, which would size, which would leave only 240 octets for the authority and additional
leave only 240 octets for the authority and additional sections (after sections (after deducting 12 octets for the fixed length header.)
deducting 12 octets for the fixed length header.)
2.2. ADVICE TO ZONE OWNERS 2.2. ADVICE TO ZONE OWNERS
2.2.1. Average and maximum question section sizes can be predicted by 2.2.1. Average and maximum question section sizes can be predicted by
the zone owner, since they will know what names actually exist, and can the zone owner, since they will know what names actually exist, and can
measure which ones are queried for most often. Note that if the zone measure which ones are queried for most often. Note that if the zone
contains any wildcards, it is possible for maximum length queries to contains any wildcards, it is possible for maximum length queries to
require positive responses, but that it is reasonable to expect require positive responses, but that it is reasonable to expect
truncation and TCP retry in that case. For cost and performance truncation and TCP retry in that case. For cost and performance
reasons, the majority of requests should be satisfied without truncation reasons, the majority of requests should be satisfied without truncation
skipping to change at page 3, line 47 skipping to change at page 3, line 47
2.2.2. Some queries to non-existing names can be large, but this is not 2.2.2. Some queries to non-existing names can be large, but this is not
a problem because negative responses need not contain any answer, a problem because negative responses need not contain any answer,
authority or additional records. See [RFC2308 2.1] for more information authority or additional records. See [RFC2308 2.1] for more information
about the format of negative responses. about the format of negative responses.
2.2.3. The minimum useful number of name servers is two, for redundancy 2.2.3. The minimum useful number of name servers is two, for redundancy
(see [RFC1034 4.1]). A zone's name servers should be reachable by all (see [RFC1034 4.1]). A zone's name servers should be reachable by all
IP transport protocols (e.g., IPv4 and IPv6) in common use. IP transport protocols (e.g., IPv4 and IPv6) in common use.
2.2.4. The best case is no truncation at all. This is because many 2.2.4. The best case is no truncation at all. This is because many
requesters will retry using TCP by reflex, or will automatically re- requesters will retry using TCP immediately, or will automatically re-
query for RRsets that are possibly truncated, without considering query for RRsets that are possibly truncated, without considering
whether the omitted data was actually necessary. whether the omitted data was actually necessary.
INTERNET-DRAFT August 2006 RESPSIZE INTERNET-DRAFT August 2006 RESPSIZE
2.3. ADVICE TO SERVER IMPLEMENTORS 2.3. ADVICE TO SERVER IMPLEMENTORS
2.3.1. In case of multi-homed name servers, it is advantageous to 2.3.1. In case of multi-homed name servers, it is advantageous to
include an address record from each of several name servers before include an address record from each of several name servers before
including several address records for any one name server. If address including several address records for any one name server. If address
records for more than one transport (for example, A and AAAA) are records for more than one transport (for example, A and AAAA) are
available, then it is advantageous to include records of both types available, then it is advantageous to include records of both types
early on, before the message is full. early on, before the message is full.
2.3.2. Each added NS RR for a zone will add between 16 and 44 octets to 2.3.2. Each added NS RR for a zone will add 12 fixed octets (name, type,
every non-truncated referral or negative response from the zone's class, ttl, and rdlen) plus 2 to 255 variable octets (for the NSDNAME).
authority servers (16 octets for an NS RR, 16 octets for an A RR, and 28 Each A RR will require 16 octets, and each AAAA RR will require 28
octets for an AAAA RR), in addition to whatever space is taken by the octets.
nameserver name (NS NSDNAME as well as A or AAAA owner name).
2.3.3. While DNS distinguishes between necessary and optional resource 2.3.3. While DNS distinguishes between necessary and optional resource
records, this distinction is according to protocol elements necessary to records, this distinction is according to protocol elements necessary to
signify facts, and takes no official notice of protocol content signify facts, and takes no official notice of protocol content
necessary to ensure correct operation. For example, a nameserver name necessary to ensure correct operation. For example, a nameserver name
that is in or below the zone cut being described by a delegation is that is in or below the zone cut being described by a delegation is
"necessary content," since there is no way to reach that zone unless the "necessary content," since there is no way to reach that zone unless the
parent zone's delegation includes "glue records" describing that name parent zone's delegation includes "glue records" describing that name
server's addresses. server's addresses.
skipping to change at page 10, line 48 skipping to change at page 10, line 48
The recommendations contained in this document have no known security The recommendations contained in this document have no known security
implications. implications.
7 - IANA Considerations 7 - IANA Considerations
This document does not call for changes or additions to any IANA This document does not call for changes or additions to any IANA
registry. registry.
8 - Acknowledgement 8 - Acknowledgement
The authors thank Peter Koch, Rob Austein, and Joe Abley for their The authors thank Peter Koch, Rob Austein, Joe Abley, and Mark Andrews
valuable comments and suggestions. for their valuable comments and suggestions.
INTERNET-DRAFT August 2006 RESPSIZE INTERNET-DRAFT August 2006 RESPSIZE
This work was supported by the US National Science Foundation (research This work was supported by the US National Science Foundation (research
grant SCI-0427144) and DNS-OARC. grant SCI-0427144) and DNS-OARC.
9 - References 9 - References
[RFC1034] Mockapetris, P.V., "Domain names - Concepts and Facilities", [RFC1034] Mockapetris, P.V., "Domain names - Concepts and Facilities",
RFC1034, November 1987. RFC1034, November 1987.
[RFC1035] Mockapetris, P.V., "Domain names - Implementation and [RFC1035] Mockapetris, P.V., "Domain names - Implementation and
Specification", RFC1035, November 1987. Specification", RFC1035, November 1987.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", RFC1123, October 1989. Application and Support", RFC1123, October 1989.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC1996, August 1996. Changes (DNS NOTIFY)", RFC1996, August 1996.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
RFC2308, March 1998.
[RFC2181] Elz, R., Bush, R., "Clarifications to the DNS Specification", [RFC2181] Elz, R., Bush, R., "Clarifications to the DNS Specification",
RFC2181, July 1997. RFC2181, July 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
RFC2308, March 1998.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC2671, [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC2671,
August 1999. August 1999.
[RFC4472] Durand, A., Ihren, J., Savola, P., "Operational Consideration
and Issues with IPV6 DNS", April 2006.
10 - Authors' Addresses 10 - Authors' Addresses
Paul Vixie Paul Vixie
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
+1 650 423 1301 +1 650 423 1301
vixie@isc.org vixie@isc.org
Akira Kato Akira Kato
 End of changes. 10 change blocks. 
19 lines changed or deleted 21 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/