As per Relevance of the word requirement, we have this rfc below:
Network Working Group O.
Request for Comments: 3226 December 2001
Updates: 2874, 2535
Category: Standards
DNSSEC and IPv6 A6 aware server/resolver message size
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document mandates support for EDNS0 (Extension Mechanisms
DNS) in DNS entities claiming to support either DNS
Extensions or A6 records. This requirement is necessary
these new features increase the size of DNS messages. If EDNS0
not supported fall back to TCP will happen, having a
impact on query latency and DNS server load. This document
RFC 2535 and RFC 2874, by adding new requirements
1.
Familiarity with the DNS [RFC1034, RFC1035], DNS Security
[RFC2535], EDNS0 [RFC2671] and A6 [RFC2874] is helpful
STD 13, RFC 1035 Section 2.3.4 requires that DNS messages over
have a data payload of 512 octets or less. Most DNS software
will not accept larger UDP datagrams. Any answer that requires
than 512 octets, results in a partial and sometimes useless
with the Truncation Bit set; in most cases the requester will
retry using TCP. Furthermore, server delivery of truncated
varies widely and resolver handling of these responses also varies
leading to additional inefficiencies in handling truncation
Compared to UDP, TCP is an expensive protocol to use for a
transaction like DNS: a TCP connection requires 5 packets for
and tear down, excluding data packets, thus requiring at least 3
round trips on top of the one for the original UDP query. The
Gudmundsson Standards Track [Page 1]
RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
server also needs to keep a state of the connection during
transaction. Many DNS servers answer thousands of queries
second, requiring them to use TCP will cause significant overhead
delays
1.1.
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY
in this document are to be interpreted as described in RFC 2119.
2. Motivating
2.1. DNSSEC
DNSSEC [RFC2535] secures DNS by adding a Public Key signature on
RR set. These signatures range in size from about 80 octets to 800
octets, most are going to be in the range of 80 to 200 octets.
addition of signatures on each or most RR sets in an
significantly increases the size of DNS answers from secure zones
For performance reasons and to reduce load on DNS servers, it
important that security aware servers and resolvers get all the
in Answer and Authority section in one query without truncation
Sending Additional Data in the same query is helpful when the
is authoritative for the data, and this reduces round trips
DNSSEC OK[OK] specifies how a client can, using EDNS0, indicate
it is interested in receiving DNSSEC records. The OK bit does
eliminate the need for large answers for DNSSEC capable clients
2.1.1. Message authentication or TSIG
TSIG [RFC2845] allows for the light weight authentication of
messages, but increases the size of the messages by at least 70
octets. DNSSEC specifies for computationally expensive
authentication SIG(0) using a standard public key signature. As
one TSIG or SIG(0) can be attached to each DNS answer the
increase of message authentication is not significant, but may
lead to a truncation
2.2. IPv6
IPv6 addresses [RFC2874] are 128 bits and can be represented in
DNS by multiple A6 records, each consisting of a domain name and
bit field. The domain name refers to an address prefix that
require additional A6 RRs to be included in the answer.
where the queried name has multiple A6 addresses may overflow a 512-
octet UDP packet size
Gudmundsson Standards Track [Page 2]
RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
2.3. Root server and TLD server
The current number of root servers is limited to 13 as that is
maximum number of name servers and their address records that fit
one 512-octet answer for a SOA record. If root servers
advertising A6 or KEY records then the answer for the root NS
will not fit in a single 512-octet DNS message, resulting in a
number of TCP query connections to the root servers. Even if
client resolver query their local name server for information,
are millions of these servers. Each name server must
update its information about the high level servers
For redundancy, latency and load balancing reasons, large numbers
DNS servers are required for some zones. Since the root zone is
by the entire net, it is important to have as many servers
possible. Large TLDs (and many high-visibility SLDs) often
enough servers that either A6 or KEY records would cause the
response to overflow the 512 byte limit. Note that these zones
large numbers of servers are often exactly those zones that
critical to network operation and that already sustain fairly
loads
2.4. UDP vs TCP for DNS
Given all these factors, it is essential that any implementation
supports DNSSEC and or A6 be able to use larger DNS messages than 512
octets
The original 512 restriction was put in place to reduce
probability of fragmentation of DNS responses. A fragmented
message that suffers a loss of one of the fragments renders
answer useless and the query must be retried. A TCP
requires a larger number of round trips for establishment,
transfer and tear down, but only the lost data segments
retransmitted
In the early days a number of IP implementations did not
fragmentation well, but all modern operating systems have
that issue thus sending fragmented messages is fine from
standpoint. The open issue is the effect of losses on
messages. If connection has high loss ratio only TCP will
reliable transfer of DNS data, most links have low loss ratios
sending fragmented UDP packet in one round trip is better
establishing a TCP connection to transfer a few thousand octets
Gudmundsson Standards Track [Page 3]
RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
2.5. EDNS0 and large UDP
EDNS0 [RFC2671] allows clients to declare the maximum size of
message they are willing to handle. Thus, if the expected answer
between 512 octets and the maximum size that the client can accept
the additional overhead of a TCP connection can be avoided
3. Protocol changes
This document updates RFC 2535 and RFC 2874, by adding
requirements
All RFC 2535 compliant servers and resolvers MUST support EDNS0
advertise message size of at least 1220 octets, but SHOULD
message size of 4000. This value might be too low to get
answers for high level servers and successor of this document
require a larger value
All RFC 2874 compliant servers and resolver MUST support EDNS0
advertise message size of at least 1024 octets, but SHOULD
message size of 2048. The IPv6 datagrams should be 1024 octets
unless the MTU of the path is known. (Note that this is smaller
the minimum IPv6 MTU to allow for some extension headers and/
encapsulation without exceeding the minimum MTU.)
All RFC 2535 and RFC 2874 compliant entities MUST be able to
fragmented IPv4 and IPv6 UDP packets
All hosts supporting both RFC 2535 and RFC 2874 MUST use the
required value in EDNS0 advertisements
4.
Harald Alvestrand, Rob Austein, Randy Bush, David Conrad,
Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward
Michael Patton and Kazu Yamamoto were instrumental in motivating
shaping this document
5. Security Considerations
There are no additional security considerations other than those
RFC 2671.
6. IANA Considerations
Gudmundsson Standards Track [Page 4]
RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
7.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation
Specification", STD 13, RFC 1035, November 1987.
[RFC2535] Eastlake, D. "Domain Name System Security Extensions",
2535, March 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
2671, August 1999.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B
Wellington, "Secret Key Transaction Authentication for
(TSIG)", RFC 2845, May 2000.
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to
IPv6 Address Aggregation and Renumbering", RFC 2874,
2000.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
3225, December 2001.
8. Author
Olafur
3826 Legation Street,
Washington, DC 20015
EMail: ogud@ogud.
Gudmundsson Standards Track [Page 5]
RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
9. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Gudmundsson Standards Track [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
