INTERNET-DRAFT Declan Ma, Ed. Intended Status: Proposed Standard zDNS Ltd. Expires: 2015-10-15 2015-05-22 Issues Concerning DNS SOA Resource Records draft-bill-dnsop-soa-records-00 Abstract RFC 2181 collected eight independent considerations and created a single docuement to address each of them in turn. Over the following two decades it has become clear that each of these items should be considered and evovolve in its own right, as suggested in RFC 2181. This document extracts the exact text from RFC 2181 and places it into its own track. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Declan Ma, Ed. Expires 2015-10-15 [Page 1] INTERNET DRAFT Issues Concerning DNS SOA Resource Records 2015-05-22 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Placement of SOA RRs in authoritative answers . . . . . . . . . 3 4 TTLs on SOA RRs . . . . . . . . . . . . . . . . . . . . . . . . 3 5 The SOA.MNAME field . . . . . . . . . . . . . . . . . . . . . . 3 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 3 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 4 Declan Ma, Ed. Expires 2015-10-15 [Page 2] INTERNET DRAFT Issues Concerning DNS SOA Resource Records 2015-05-22 1 Introduction This document is intended to state three minor issues concerning DNS SOA resource records and their use. 2 Terminology 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]. 3 Placement of SOA RRs in authoritative answers RFC1034, in section 3.7, indicates that the authority section of an authoritative answer may contain the SOA record for the zone from which the answer was obtained. When discussing negative caching, RFC1034 section 4.3.4 refers to this technique but mentions the additional section of the response. The former is correct, as is implied by the example shown in section 6.2.5 of RFC1034. SOA records, if added, are to be placed in the authority section. 4 TTLs on SOA RRs the format of a Resource Record, that the definition of the TTL field contains a throw away line which states that the TTL of an SOA record should always be sent as zero to prevent caching. This is mentioned nowhere else, and has not generally been implemented. Implementations should not assume that SOA records will have a TTL of zero, nor are they required to send SOA records with a TTL of zero. 5 The SOA.MNAME field It is quite clear in the specifications, yet seems to have been widely ignored, that the MNAME field of the SOA record should contain the name of the primary (master) server for the zone identified by the SOA. It should not contain the name of the zone itself. That information would be useless, as to discover it, one needs to start with the domain name of the SOA record - that is the name of the zone. 6 Security Considerations It may be observed that in section 3.2.1 of RFC1035, which defines Declan Ma, Ed. Expires 2015-10-15 [Page 3] INTERNET DRAFT Issues Concerning DNS SOA Resource Records 2015-05-22 the format of a Resource Record, that the definition of the TTL field contains a throw away line which states that the TTL of an SOA record should always be sent as zero to prevent caching. This is mentioned nowhere else, and has not generally been implemented. Implementations should not assume that SOA records will have a TTL of zero, nor are they required to send SOA records with a TTL of zero. 7 References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2199] Ramos, A., "Request for Comments Summary RFC Numbers 2100- 2199", RFC 2199, January 1998. 8 Authors' Addresses Declan Ma, Ed. ZDNS Ltd. 4, South 4th Street, Zhongguancun, Haidian, Beijing 100190, China Declan Ma, Ed. Expires 2015-10-15 [Page 4]