idnits 2.17.00 (12 Aug 2021) /tmp/idnits8670/draft-ietf-dnsind-clarify-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1996) is 9501 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. 'DNSSEC' Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Robert Elz 3 Internet Draft University of Melbourne 4 Expiration Date: November 1996 5 Randy Bush 6 RGnet, Inc. 8 May 1996 10 Clarifications to the DNS Specification 12 draft-ietf-dnsind-clarify-01.txt 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 1. Abstract 34 This draft considers some areas that have been identified as problems 35 with the specification of the Domain Name System, and proposes 36 remedies for the defects identified. Two separate issues are 37 considered, IP packet header address usage from multi-homed servers, 38 and TTLs in sets of records with the same name, class, and type. 40 2. Introduction 42 Several problem areas in the Domain Name System specification 43 [RFC1034, RFC1035] have been noted through the years [RFC1123]. This 44 draft addresses two additional problem areas. The two issues here 45 are independent. Those issues are the question of which source 46 address a multi-homed DNS server should use when replying to a query, 47 and the issue of differing TTLs for DNS records with the same label, 48 class and type. 50 Suggestions for clarifications to the DNS specification to avoid 51 these problems are made in this memo. The solutions proposed herein 52 are intended to stimulate discussion. It is possible that the sense 53 of either may be reversed before the next iteration of this draft, 54 but less likely now than it was before the previous version. 56 3. Server Reply Source Address Selection 58 Most, if not all, DNS clients, whether servers acting as clients for 59 the purposes of recursive query resolution, or resolvers, expect the 60 address from which a reply is received to be the same address as that 61 to which the query eliciting the reply was sent. This, along with 62 the identifier (ID) in the reply is used for disambiguating replies, 63 and filtering spurious responses. This may, or may not, have been 64 intended when the DNS was designed, but is now a fact of life. 66 Some multi-homed hosts running DNS servers fail to anticipate this 67 usage, and consequently send replies from the "wrong" source address, 68 causing the reply to be discarded by the client. 70 3.1. UDP Source Address Selection 72 To avoid these problems, servers when responding to queries using UDP 73 must cause the reply to be sent with the source address field in the 74 IP header set to the address that was in the destination address 75 field of the IP header of the packet containing the query causing the 76 response. If this would cause the response to be sent from an IP 77 address which is not permitted for this purpose, then the response 78 may be sent from any legal IP address allocated to the server. That 79 address should be chosen to maximise the possibility that the client 80 will be able to use it for further queries. Servers configured in 81 such a way that not all their addresses are equally reachable from 82 all potential clients need take particular care when responding to 83 queries sent to anycast, multicast, or similar, addresses. 85 3.2. Port Number Selection 87 Replies to all queries must be directed to the port from which they 88 were sent. With queries received via TCP this is an inherent part of 89 the transport protocol, for queries received by UDP the server must 90 take note of the source port and use that as the destination port in 91 the response. Replies should always be sent from the port to which 92 they were directed. Except in extraordinary circumstances, this will 93 be the well known port assigned for DNS queries [RFC1700]. 95 4. Resource Record Sets 97 Each DNS Resource Record (RR) each has a label, class, type, and 98 data. While it is meaningless for two records to ever have label, 99 class, type and data all equal (servers should suppress such 100 duplicates if encountered), it is possible for many record types to 101 exist with the same label class and type, but with different data. 102 Such a group of records is hereby defined to be a Resource Record Set 103 (RRSet). 105 4.1. Sending RRs from an RRSet 107 A query for a specific (or non-specific) label, class, and type, will 108 always return all records in the associated RRSet - whether that be 109 one or more RRs, or the response shall be marked as "truncated" if 110 the entire RRSet will not fit in the response. 112 4.2. TTLs of RRs in an RRSet 114 Resource Records also have a time to live (TTL). It is possible for 115 the RRs in an RRSet to have different TTLs, however no uses for this 116 have been found which cannot be better accomplished in other ways. 117 This can, however, cause partial replies (not marked "truncated") 118 from a caching server, where the TTLs for some but not all of the RRs 119 in the RRSet have expired. 121 Consequently the use of differing TTLs in an RRSet is hereby 122 deprecated, the TTLs of all RRs in an RRSet must be the same. 124 Should a client receive a response containing RRs from an RRSet with 125 differing TTLs, it should treat the RRs for all purposes as if all 126 TTLs in the RRSet had been set to the value of the lowest TTL in the 127 RRSet. 129 4.3. Receiving RRSets 131 Servers never merge RRs from a response with RRs in their cache to 132 form an RRSet. If a response contains data which would form an RRSet 133 with data in a server's cache the server must either ignore the RRs 134 in the response, or use those to replace the existing RRSet in the 135 cache, as appropriate. Consequently the issue of TTLs varying 136 between the cache and a response does not cause concern, one will be 137 ignored. 139 4.3.1. Ranking data 141 When considering whether to accept an RRSet in a reply, or retain an 142 RRSet already in its cache instead, a server should consider the 143 relative likely trustworthiness of the various data. That is, an 144 authoritative answer from a reply should replace cached data that had 145 been obtained from additional information in an earlier reply, but 146 additional information from a reply will be ignored if the cache 147 contains data from an authoritative answer or a zone file. 149 The accuracy of data available is assumed from its source. 150 Trustworthiness shall be, in order from most to least: 152 + Data from a primary zone file, other than glue data, 153 + Data from a zone transfer, other than glue, 154 + That from the answer section of an authoritative reply, 155 + Glue from a primary zone, or glue from a zone transfer, 156 + Data from the authority section of an authoritative answer, 157 + Data from the answer section of a non-authoritative answer, 158 + Additional information from an authoritative answer, 159 + Data from the authority section of a non-authoritative answer, 160 + Additional information from non-authoritative answers. 162 Where authenticated data has been received it shall be considered 163 more trustworthy than unauthenticated data of the same type. 165 "Glue" above includes any record in a zone file that is not properly 166 part of that zone, including nameserver records of delegated sub- 167 zones (NS records), address records that accompany those NS records 168 (A, AAAA, etc), and any other stray data that might appear. 170 4.4. Sending RRSets (reprise) 172 A Resource Record Set should only be included once in any DNS reply. 173 It may occur in any of the Answer, Authority, or Additional 174 Information sections, as required, however should not be repeated in 175 the same, or any other, section, except where explicitly required by 176 a specification. For example, an AXFR response requires the SOA 177 record (always an RRSet containing a single RR) be both the first and 178 last record of the reply. Where duplicates are required this way, 179 the TTL transmitted in each case must be the same. 181 5. Security Considerations 183 This document does not consider security. 185 In particular, nothing in section 3 is any way related to, or useful 186 for, any security related purposes. 188 Section 4.3.1 is also not related to security. Security of DNS data 189 will be obtained by the Secure DNS [DNSSEC], which is orthogonal to 190 this memo. 192 It is not believed that anything in this document adds to any 193 security issues that may exist with the DNS, nor does it do anything 194 to lessen them. 196 6. References 198 [RFC1034] Domain Names - Concepts and Facilities, (STD 13) 199 P. Mockapetris, ISI, November 1987. 201 [RFC1035] Domain Names - Implementation and Specification (STD 13) 202 P. Mockapetris, ISI, November 1987 204 [RFC1123] Requirements for Internet hosts - application and support, 205 (STD 3) R. Braden, January 1989 207 [RFC1700] Assigned Numbers (STD 2) 208 J. Reynolds, J. Postel, October 1994. 210 [DNSSEC] Domain Name System Security Extensions, 211 D. E. Eastlake, 3rd, C. W. Kaufman, 212 Work in Progress (Internet Draft), January 1996. 214 7. Acknowledgements 216 This memo arose from discussions in the DNSIND working group of the 217 IETF in 1995 and 1996, the members of that working group are largely 218 responsible for the ideas captured herein. 220 8. Authors' addresses 222 Robert Elz 223 Computer Science 224 University of Melbourne 225 Parkville, Victoria, 3052 226 Australia. 228 EMail: kre@munnari.OZ.AU 230 Randy Bush 231 RGnet, Inc. 232 9501 SW Westhaven 233 Portland, Oregon, 97225 234 United States. 236 EMail: randy@psg.com