Internet DRAFT - draft-andrews-dnsext-soa-discovery
draft-andrews-dnsext-soa-discovery
Network Working Group M. Andrews
Internet-Draft ISC
Expires: December 16, 2006 June 14, 2006
DNS Start of Authority Discovery
draft-andrews-dnsext-soa-discovery-01
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 December 16, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Sometimes it is necessary to discover the Start of Authority points
in the DNS, otherwise known as zone cuts, without causing negative
entries to be recorded in caches. This document describes how to
achieve this.
Andrews Expires December 16, 2006 [Page 1]
Internet-Draft DNS Start of Authority Discovery June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
2. Why Choose SOA over NS Queries . . . . . . . . . . . . . . . . 3
3. Authoritative Server Behaviour . . . . . . . . . . . . . . . . 4
4. Caching Server Behaviour . . . . . . . . . . . . . . . . . . . 4
5. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 7
Andrews Expires December 16, 2006 [Page 2]
Internet-Draft DNS Start of Authority Discovery June 2006
1. Introduction
When performing a DNS UPDATE RFC 2136 [RFC2136] it is necessary to
send the request to the nameservers for the zone. Often, however,
all you have is the name of the record to be updated. From this you
need to discover the zone and the authoritative nameservers to which
the DNS UPDATE request should be addressed to.
One method would be to query for the root nameservers then have the
client follow the delegation path talking to each set of nameservers
in turn. In practice this does not work due to firewalls and because
not all names in the DNS actually have a delegation path from the
root. The later is especially true with split DNS configurations and
with sites using private addressing RFC 1918 [RFC1918].
The next method is just to query for the SOA or NS records (both
being present only at zone cuts) at the query name, removing labels
until a answer is returned. This works well if the initial query
happens to be at a zone cut and reasonably well if the query name
exists in the DNS. It does not work well if name does not exist in
the DNS as the negative cache entry obscures the changes that are
about to be made.
This document describes changes to nameserver behaviour which remove
the undesired side effects of making a SOA query.
1.1. Reserved Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Why Choose SOA over NS Queries
As the primary motivation for this was to support UPDATE requests and
these are supposed to be preferentially directed at the SOA MNAME,
the SOA query was required. SOA queries will also usually return the
corresponding NS RRset in the additional section where as the NS
query will not return the SOA RRset at zone cuts.
SOA queries are not part of the normal query mix. Not negatively
caching the SOA response is unlikely to have a detrimental impact.
SOA queries do not interfere with any benefits of caching the NODATA
response to NS queries made by nameservers performing DNSSEC
validations RFC 4035, Section 4.2 [RFC4035].
Andrews Expires December 16, 2006 [Page 3]
Internet-Draft DNS Start of Authority Discovery June 2006
3. Authoritative Server Behaviour
When returning a negative answer to a SOA query, the nameserver sets
the TTL of the SOA record in the authority section of the response to
zero rather than the SOA MINIMUM as described in RFC 2308 [RFC2308].
An implementation SHOULD do this by default but MUST allow it to be
overriden on a per zone basis. Some zones which are not updateable,
TLDs in particular, have "unregistered" children which attempt to
update them. Returning a negative response with a non-zero TTL can
reduce the load on the authoritative servers.
4. Caching Server Behaviour
When a resolver receives a negative answer to a SOA query it MAY set
the negative cache TTL to zero. It MAY also set the TTL of the SOA
record in the authority section to zero.
The is useful when the authoritative servers do not follow this
documents and there are update clients using the cache.
5. Client Behaviour
Clients start by issuing a recursive query for a SOA resource record
at <QNAME,QCLASS>. If we get one as an answer that matches the
<SOA,QNAME,QCLASS> tuple we have found the containing zone name.
If a referral is returned then fail.
If a CNAME or DNAME is returned in the answer section the QNAME does
not correspond to a zone name and any SOA record present may not be
for the desired zone. The client SHOULD re-query removing the
leftmost (least significant) label from QNAME.
If we get a SOA record in the authority section this record should
refer to the enclosing zone, RFC 2308 [RFC2308].
If the answer section is empty and there is not SOA record in the
authority section the client needs to re-query with the leftmost
label removed.
If a client performs an UPDATE it should not immediately perform a
action that depends on the updated data being returned to the
resolver. UPDATEs, even when NOTIFY RFC 1996 [RFC1996] is in use,
take some time to propagate to the authoritative servers.
Immediately querying for the updated data using a caching server will
Andrews Expires December 16, 2006 [Page 4]
Internet-Draft DNS Start of Authority Discovery June 2006
often defeat the steps taken here.
Polling each of the nameservers for the zone to see if it has the new
data and waiting if it doesn't should prevent this occurring. If you
do this use exponential back-off when polling.
6. IANA Considerations
This document has no actions for IANA.
7. Security Considerations
As with all answers from the DNS, clients need to be aware that
answers may be spoofed. It is advised that that clients use DNSSEC,
TSIG, SIG(0) or some other cryptographic mechanism to detect such
spoofed responses.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
8.2. Informative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
RFC 1918, February 1996.
[RFC1996] Vixie, P., "Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, February 1996.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
Andrews Expires December 16, 2006 [Page 5]
Internet-Draft DNS Start of Authority Discovery June 2006
Author's Address
Mark P. Andrews
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
US
Email: Mark_Andrews@isc.org
Andrews Expires December 16, 2006 [Page 6]
Internet-Draft DNS Start of Authority Discovery June 2006
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 (2006). 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.
Andrews Expires December 16, 2006 [Page 7]
