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 . If we get one as an answer that matches the 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]