--- /dev/null
+ DNSOP Working Group Paul Vixie, ISC (Ed.)
+ INTERNET-DRAFT Akira Kato, WIDE
+ <draft-ietf-dnsop-respsize-01.txt> July, 2004
+
+
+ DNS Response Size Issues
+
+
+ Status of this Memo
+ This document is an Internet-Draft and is subject to all provisions
+ of section 3 of RFC 3667. By submitting this Internet-Draft, each
+ 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
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+
+ The list of current Internet-Drafts can be accessed at
+ 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.
+
+
+ Copyright Notice
+
+
+ Copyright (C) The Internet Society (2003-2004). All Rights Reserved.
+
+
+
+
+
+ Abstract
+
+
+ With a mandated default minimum maximum 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.
+
+
+
+
+
+
+ Expires December 2004 [Page 1]
+ INTERNET-DRAFT June 2003 RESPSIZE
+
+
+
+ 1 - Introduction and Overview
+
+
+ 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
+ reassembly limit for IPv4, it is a hard DNS protocol limit and is not
+ implicitly relaxed by changes in transport, for example to IPv6.
+
+
+ 1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger
+ responses by mutual agreement of the requestor and responder. However,
+ 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 practical effect at this time.
+
+
+ 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.
+ For negative responses, there is rarely a space constraint. For
+ positive and delegation responses, though, every octet must be carefully
+ and sparingly allocated. This document specifically addresses
+ delegation response sizes.
+
+
+ 2 - Delegation Details
+
+
+ 2.1. A delegation response will include the following elements:
+
+
+ Header Section: fixed length (12 octets)
+ Question Section: original query (name, class, type)
+ Answer Section: (empty)
+ Authority Section: NS RRset (nameserver names)
+ Additional Section: A and AAAA RRsets (nameserver addresses)
+
+
+ 2.2. If the total response size would exceed 512 octets, and if the data
+ that would not fit was in the question, answer, or authority section,
+ then the TC bit will be set (indicating truncation) which may cause the
+ 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
+ the transaction is much higher.
+
+
+ 2.3. RRsets are never sent partially, so if truncation occurs, entire
+ RRsets are omitted. Note that the authority section consists of a
+ single RRset. It is absolutely essential that truncation not occur in
+ the authority section.
+
+
+
+
+
+
+
+
+ Expires December 2004 [Page 2]
+ INTERNET-DRAFT June 2003 RESPSIZE
+
+
+
+ 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"
+ from other locations in that same DNS message. If all nameserver names
+ in a message are similar (for example, all ending in ".ROOT-
+ SERVERS.NET"), then more space will be available for uncompressable data
+ (such as nameserver addresses).
+
+
+ 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
+ scenario, the question section will be 260 octets in size, which would
+ leave only 240 octets for the authority and additional sections (after
+ deducting 12 octets for the fixed length header.)
+
+
+ 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
+ measure which ones are queried for most often. For cost and performance
+ reasons, the majority of requests should be satisfied without truncation
+ or TCP retry.
+
+
+ 2.7. Requestors who deliberately send large queries to force truncation
+ are only increasing their own costs, and cannot effectively attack the
+ 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
+ have a lower cost.
+
+
+ 2.8. The minimum useful number of address records is two, since with
+ only one address, the probability that it would refer to an unreachable
+ server is too high. Truncation which occurs after two address records
+ have been added to the additional data section is therefore less
+ operationally significant than truncation which occurs earlier.
+
+
+ 2.9. The best case is no truncation. (This is because many requestors
+ will retry using TCP by reflex, without considering whether the omitted
+ data was actually necessary.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Expires December 2004 [Page 3]
+ INTERNET-DRAFT June 2003 RESPSIZE
+
+
+
+ 3 - Analysis
+
+
+ 3.1. An instrumented protocol trace of a best case delegation response
+ follows. Note that 13 servers are named, and 13 addresses are given.
+ This query was artificially designed to exactly reach the 512 octet
+ limit.
+
+
+ ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
+ ;; QUERY SECTION:
+ ;; [23456789.123456789.123456789.\
+ 123456789.123456789.123456789.com A IN] ;; @80
+
+
+ ;; AUTHORITY SECTION:
+ com. 86400 NS E.GTLD-SERVERS.NET. ;; @112
+ com. 86400 NS F.GTLD-SERVERS.NET. ;; @128
+ com. 86400 NS G.GTLD-SERVERS.NET. ;; @144
+ com. 86400 NS H.GTLD-SERVERS.NET. ;; @160
+ com. 86400 NS I.GTLD-SERVERS.NET. ;; @176
+ com. 86400 NS J.GTLD-SERVERS.NET. ;; @192
+ com. 86400 NS K.GTLD-SERVERS.NET. ;; @208
+ com. 86400 NS L.GTLD-SERVERS.NET. ;; @224
+ com. 86400 NS M.GTLD-SERVERS.NET. ;; @240
+ com. 86400 NS A.GTLD-SERVERS.NET. ;; @256
+ com. 86400 NS B.GTLD-SERVERS.NET. ;; @272
+ com. 86400 NS C.GTLD-SERVERS.NET. ;; @288
+ com. 86400 NS D.GTLD-SERVERS.NET. ;; @304
+
+
+ ;; ADDITIONAL SECTION:
+ A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320
+ B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336
+ C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352
+ D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368
+ E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384
+ F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400
+ G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416
+ H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432
+ I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448
+ J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464
+ K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480
+ L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496
+ M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512
+
+
+ ;; MSG SIZE sent: 80 rcvd: 512
+
+
+
+
+
+
+ Expires December 2004 [Page 4]
+ INTERNET-DRAFT June 2003 RESPSIZE
+
+
+
+ 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
+ is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
+ fit. The following output from a response simulator demonstrates these
+ properties:
+
+
+ % perl respsize.pl 13 13 0
+ common name, average case: msg:303 nsaddr#13 (green)
+ common name, worst case: msg:495 nsaddr# 1 (red)
+ uncommon name, average case: msg:457 nsaddr# 3 (orange)
+ uncommon name, worst case: msg:649(*) nsaddr# 0 (red)
+ % perl respsize.pl 13 13 2
+ common name, average case: msg:303 nsaddr#11 (orange)
+ common name, worst case: msg:495 nsaddr# 1 (red)
+ uncommon name, average case: msg:457 nsaddr# 2 (orange)
+ uncommon name, worst case: msg:649(*) nsaddr# 0 (red)
+
+
+ (Note: The response simulator program is shown in Section 5.)
+
+
+ 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.
+ It's clear that without a common parent for nameserver names, much space
+ would be lost.
+
+
+ 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
+ writing. If Internationalized Domain Name (IDN) or any other technology
+ which results in larger query names be deployed significantly in advance
+ of EDNS, then more new measurements and new estimates will have to be
+ made.
+
+
+ 4 - Conclusions
+
+
+ 4.1. The current practice of giving all nameserver names a common parent
+ (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
+ 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.2. Thirteen (13) seems to be the effective maximum number of
+ nameserver names usable traditional (non-extended) DNS, assuming a
+ common parent domain name, and assuming that additional-data truncation
+ is undesirable in the average case.
+
+
+
+
+ Expires December 2004 [Page 5]
+ 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
+
+
+ #!/usr/bin/perl -w
+
+
+ $asize = 2+2+2+4+2+4;
+ $aaaasize = 2+2+2+4+2+16;
+ ($nns, $na, $naaaa) = @ARGV;
+ test("common", "average", common_name_average($nns),
+ $na, $naaaa);
+ test("common", "worst", common_name_worst($nns),
+ $na, $naaaa);
+ test("uncommon", "average", uncommon_name_average($nns),
+ $na, $naaaa);
+ test("uncommon", "worst", uncommon_name_worst($nns),
+ $na, $naaaa);
+ exit 0;
+
+
+ sub test { my ($namekind, $casekind, $msg, $na, $naaaa) = @_;
+ my $nglue = numglue($msg, $na, $naaaa);
+ printf "%8s name, %7s case: msg:%3d%s nsaddr#%2d (%s)\n",
+ $namekind, $casekind,
+ $msg, ($msg > 512) ? "(*)" : " ",
+ $nglue, ($nglue == $na + $naaaa) ? "green"
+ : ($nglue >= 2) ? "orange"
+ : "red";
+ }
+
+
+ sub pnum { my ($num, $tot) = @_;
+ return sprintf "%3d%s",
+ }
+
+
+ sub numglue { my ($msg, $na, $naaaa) = @_;
+ my $space = ($msg > 512) ? 0 : (512 - $msg);
+ my $num = 0;
+
+
+ while ($space && ($na || $naaaa )) {
+ if ($na) {
+ if ($space >= $asize) {
+ $space -= $asize;
+
+
+
+
+ Expires December 2004 [Page 6]
+ INTERNET-DRAFT June 2003 RESPSIZE
+
+
+
+ $num++;
+ }
+ $na--;
+ }
+ if ($naaaa) {
+ if ($space >= $aaaasize) {
+ $space -= $aaaasize;
+ $num++;
+ }
+ $naaaa--;
+ }
+ }
+ return $num;
+ }
+
+
+ sub msgsize { my ($qname, $nns, $nsns) = @_;
+ return 12 + # header
+ $qname+2+2 + # query
+ 0 + # answer
+ $nns * (4+2+2+4+2+$nsns); # authority
+ }
+
+
+ sub average_case { my ($nns, $nsns) = @_;
+ return msgsize(64, $nns, $nsns);
+ }
+
+
+ sub worst_case { my ($nns, $nsns) = @_;
+ return msgsize(256, $nns, $nsns);
+ }
+
+
+ sub common_name_average { my ($nns) = @_;
+ return 15 + average_case($nns, 2);
+ }
+
+
+ sub common_name_worst { my ($nns) = @_;
+ return 15 + worst_case($nns, 2);
+ }
+
+
+ sub uncommon_name_average { my ($nns) = @_;
+ return average_case($nns, 15);
+ }
+
+
+ sub uncommon_name_worst { my ($nns) = @_;
+ return worst_case($nns, 15);
+ }
+
+
+
+
+ Expires December 2004 [Page 7]
+ INTERNET-DRAFT June 2003 RESPSIZE
+
+
+
+ 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
+ 950 Charter Street
+ Redwood City, CA 94063
+ +1 650 423 1301
+ vixie@isc.org
+
+
+ Akira Kato
+ University of Tokyo, Information Technology Center
+ 2-11-16 Yayoi Bunkyo
+ Tokyo 113-8658, JAPAN
+ +81 3 5841 2750
+ kato@wide.ad.jp
+
+
+
+
+
+
+
+
+
+
+ Expires December 2004 [Page 8]
\ No newline at end of file
--- /dev/null
+
+
+Network Working Group S. Woolf
+Internet-Draft Internet Systems Consortium, Inc.
+Expires: January 16, 2005 D. Conrad
+ Nominum, Inc.
+ July 18, 2004
+
+
+ Identifying an Authoritative Name `Server
+ draft-ietf-dnsop-serverid-02
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of section 3 of RFC 3667. By submitting this Internet-Draft, each
+ author represents that any 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 become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at 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, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ With the increased use of DNS anycast, load balancing, and other
+ mechanisms allowing more than one DNS name server to share a single
+ IP address, it is sometimes difficult to tell which of a pool of name
+ servers has answered a particular query. A standardized mechanism to
+ determine the identity of a name server responding to a particular
+ query would be useful, particularly as a diagnostic aid. Existing ad
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 1]
+\f
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+ hoc mechanisms for addressing this concern are not adequate. This
+ document attempts to describe the common ad hoc solution to this
+ problem, including its advantages and disadvantasges, and to
+ characterize an improved mechanism.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 2]
+\f
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+1. Introduction
+
+ With the increased use of DNS anycast, load balancing, and other
+ mechanisms allowing more than one DNS name server to share a single
+ IP address, it is sometimes difficult to tell which of a pool of name
+ servers has answered a particular query. A standardized mechanism to
+ determine the identity of a name server responding to a particular
+ query would be useful, particularly as a diagnostic aid.
+
+ Unfortunately, existing ad-hoc mechanisms for providing such
+ identification have some shortcomings, not the least of which is the
+ lack of prior analysis of exactly how such a mechanism should be
+ designed and deployed. This document describes the existing
+ convention used in one widely deployed implementation of the DNS
+ protocol and discusses requirements for an improved solution to the
+ problem.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 3]
+\f
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+2. Rationale
+
+ Identifying which name server is responding to queries is often
+ useful, particularly in attempting to diagnose name server
+ difficulties. However, relying on the IP address of the name server
+ has become more problematic due the deployment of various load
+ balancing solutions, including the use of shared unicast addresses as
+ documented in [RFC3258].
+
+ An unfortunate side effect of these load balancing solutions is that
+ traditional methods of determining which server is responding can be
+ unreliable. Specifically, non-DNS methods such as ICMP ping, TCP
+ connections, or non-DNS UDP packets (e.g., as generated by tools such
+ as "traceroute"), etc., can end up going to a different server than
+ that which receives the DNS queries.
+
+ The widespread use of the existing convention suggests a need for a
+ documented, interoperable means of querying the identity of a
+ nameserver that may be part of an anycast or load-balancing cluster.
+ At the same time, however, it also has some drawbacks that argue
+ against standardizing it as it's been practiced so far.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 4]
+\f
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+3. Existing Conventions
+
+ Recent versions of the commonly deployed Berkeley Internet Name
+ Domain implementation of the DNS protocol suite from the Internet
+ Software Consortium [BIND] support a way of identifying a particular
+ server via the use of a standard, if somewhat unusual, DNS query.
+ Specifically, a query to a late model BIND server for a TXT resource
+ record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will
+ return a string that can be configured by the name server
+ administrator to provide a unique identifier for the responding
+ server (defaulting to the value of a gethostname() call). This
+ mechanism, which is an extension of the BIND convention of using
+ CHAOS class TXT RR queries to sub-domains of the "BIND." domain for
+ version information, has been copied by several name server vendors.
+
+ For reference, the other well-known name used by recent versions of
+ BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A
+ query for a TXT RR for this name will return an administratively re-
+ definable string which defaults to the version of the server
+ responding.
+
+3.1 Advantages
+
+ There are several valuable attributes to this mechanism, which
+ account for its usefulness.
+ 1. This mechanism is within the DNS protocol itself. An
+ identification mechanism that relies on the DNS protocol is more
+ likely to be successful (although not guaranteed) in going to the
+ same machine as a "normal" DNS query.
+ 2. It is simple to configure. An administrator can easily turn on
+ this feature and control the results of the relevant query.
+ 3. It allows the administrator complete control of what information
+ is given out in the response, minimizing passive leakage of
+ implementation or configuration details. Such details are often
+ considered sensitive by infrastructure operators.
+
+3.2 Disadvantages
+
+ At the same time, there are some forbidding drawbacks to the
+ VERSION.BIND mechanism that argue against standardizing it as it
+ currently operates.
+ 1. It requires an additional query to correlate between the answer
+ to a DNS query under normal conditions and the supposed identity
+ of the server receiving the query. There are a number of
+ situations in which this simply isn't reliable.
+ 2. It reserves an entire class in the DNS (CHAOS) for what amounts
+ to one zone. While CHAOS class is defined in [RFC1034] and
+ [RFC1035], it's not clear that supporting it solely for this
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 5]
+\f
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+ purpose is a good use of the namespace or of implementation
+ effort.
+ 3. It is implementation specific. BIND is one DNS implementation.
+ At the time of this writing, it is probably the most prevalent,
+ for authoritative servers anyway. This does not justify
+ standardizing on its ad hoc solution to a problem shared across
+ many operators and implementors.
+
+ The first of the listed disadvantages is technically the most
+ serious. It argues for an attempt to design a good answer to the
+ problem that "I need to know what nameserver is answering my
+ queries", not simply a convenient one.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 6]
+\f
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+4. Characteristics of an Implementation Neutral Convention
+
+ The discussion above of advantages and disadvantages to the
+ HOSTNAME.BIND mechanism suggest some requirements for a better
+ solution to the server identification problem. These are summarized
+ here as guidelines for any effort to provide appropriate protocol
+ extensions:
+ 1. The mechanism adopted MUST be in-band for the DNS protocol. That
+ is, it needs to allow the query for the server's identifying
+ information to be part of a normal, operational query. It SHOULD
+ also permit a separate, dedicated query for the server's
+ identifying information.
+ 2. The new mechanism should not require dedicated namespaces or
+ other reserved values outside of the existing protocol mechanisms
+ for these, i.e. the OPT pseudo-RR.
+ 3. Support for the identification functionality SHOULD be easy to
+ implement and easy to enable. It MUST be easy to disable and
+ SHOULD lend itself to access controls on who can query for it.
+ 4. It should be possible to return a unique identifier for a server
+ without requiring the exposure of information that may be
+ non-public and considered sensitive by the operator, such as a
+ hostname or unicast IP address maintained for administrative
+ purposes.
+ 5. The identification mechanism SHOULD NOT be
+ implementation-specific.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 7]
+\f
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+5. IANA Considerations
+
+ This document proposes no specific IANA action. Protocol extensions,
+ if any, to meet the requirements described are out of scope for this
+ document. Should such extensions be specified and adopted by normal
+ IETF process, the specification will include appropriate guidance to
+ IANA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 8]
+\f
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+6. Security Considerations
+
+ Providing identifying information as to which server is responding
+ can be seen as information leakage and thus a security risk. This
+ motivates the suggestion above that a new mechanism for server
+ identification allow the administrator to disable the functionality
+ altogether or partially restrict availability of the data. It also
+ suggests that the serverid data should not be readily correlated with
+ a hostname or unicast IP address that may be considered private to
+ the nameserver operator's management infrastructure.
+
+ Propagation of protocol or service meta-data can sometimes expose the
+ application to denial of service or other attack. As DNS is a
+ critically important infrastructure service for the production
+ Internet, extra care needs to be taken against this risk for
+ designers, implementors, and operators of a new mechanism for server
+ identification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 9]
+\f
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+7. Acknowledgements
+
+ The technique for host identification documented here was initially
+ implemented by Paul Vixie of the Internet Software Consortium in the
+ Berkeley Internet Name Daemon package. Comments and questions on
+ earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
+ Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
+ ICANN Root Server System Advisory Committee. The newest draft takes
+ a significantly different direction from previous versions, owing to
+ discussion among contributors to the DNSOP working group and others,
+ particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam Weiler,
+ and Rob Austein.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 10]
+\f
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+Intellectual Property Statement
+
+ 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.
+
+
+Disclaimer of Validity
+
+ 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.
+
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (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.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 11]
+\f
+
projects / thirdparty / bind9.git / commitdiff
