idnits 2.17.00 (12 Aug 2021) /tmp/idnits6915/draft-ietf-dnsind-clarify-00.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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (February 1996) is 9591 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) == Unused Reference: 'RFC1034' is defined on line 136, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 139, but no explicit reference was found in the text Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Robert Elz 2 Internet Draft University of Melbourne 3 Expiration Date: August 1996 4 Randy Bush 5 RGnet, Inc. 7 February 1996 9 Clarifications to the DNS Specification 11 draft-ietf-dnsind-clarify-00.txt 13 1. Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 2. Abstract 33 This draft considers some areas that have been identified as problems 34 with the specification of the Domain Name System, and proposes 35 remedies for the defects identified. Two separate issues are 36 considered, IP packet header address usage from multi-homed servers, 37 and TTLs in sets of records with the same name, class, and type. 39 3. Introduction 41 Several problem areas in the Domain Name System specification have 42 been noted through the years. This draft addresses two of them. The 43 two issues here are independent. Those issues are the question of 44 which source address a multi-homed DNS server should use when 45 replying to a query, and the issue of differing TTLs for DNS records 46 with the same label, class and type. 48 Suggestions for clarifications to the DNS specification to avoid the 49 problems caused are made in this draft. The solutions proposed 50 herein are intended to stimulate discussion. It is entirely possible 51 that the sense of either may be reversed before the next iteration of 52 this draft. 54 4. Server reply source address selection 56 Many DNS clients, in fact, most DNS clients, if not all, whether a 57 server acting as a client for the purposes of recursive query 58 resolution, or a resolver, expect that the address from which a reply 59 is received via UDP will be the same address as that to which the 60 query eliciting the reply was sent. This, along with the identifier 61 (ID) in the reply is used for disambiguating replies, and filtering 62 spurious responses. This may, or may not, have been intended when 63 the DNS was designed, but is now a fact of life. 65 Some multi-homed hosts running DNS servers fail to anticipate this 66 usage, and consequently send replies from the "wrong" source address, 67 causing the reply to be discarded by the client. 69 To avoid these problems, servers when responding to queries using UDP 70 must cause the reply to be sent with the source address field in the 71 IP header set to the address that was in the destination address 72 field of the IP header of the packet containing the query causing the 73 response. If this would cause the response to be sent from an 74 illegal IP address for sources, then the response must not be sent. 76 [Aside: An alternative would be to finish the previous sentence 77 with "... may be sent from any legal IP address allocated to the 78 server."] 80 5. Multiple TTLs in a Resource Record Set 82 DNS Resource Records (RRs) each have a label, class, type, and data. 83 While it is meaningless for two records to ever have label, class, 84 type and data all equal (servers should suppress such duplicates if 85 encountered), it is possible for many record types to exist with the 86 same label class and type, but with different data. Such a group of 87 records is hereby defined to be a Resource Record Set (RRSet). 89 In all cases, a query for a specific (or non-specific) label, class, 90 and type, will always return all records in the associated RRSet - 91 whether that be one or more RRs, or the response shall be marked as 92 "truncated" if the entire RRSet will not fit in the response. 94 Resource Records also each have a time to live (TTL). It is possible 95 for the RRs in a RRSet to have different TTLs, however this has no 96 known useful purpose, and can cause partial replies (not marked 97 "truncated") from a caching server, where the TTLs for some of the 98 RRs in the RRSet have expired, but not all have. 100 Consequently the use of differing TTLs in a RRSet is hereby 101 deprecated, all TTLs in a RRSet should be the same. 103 Should a client receive a response containing RRs from an RRSet with 104 TTLs not all equal, it should treat the RRs for all purposes as if 105 all TTLs in the RRSet had been set to the value of the lowest TTL in 106 the RRSet. 108 Servers never merge RRs from a response with RRs in their cache to 109 form a RRSet, they must either ignore the RRs in the response, or use 110 those to replace existing RRs from the cache, as appropriate. 111 Consequently the issue of TTLs varying between the cache and a 112 response does not cause concern, one will be ignored. 114 A Resource Record Set should only be included once in any DNS reply. 115 It may occur in any of the Answer, Authority, or Additional 116 Information sections, as required, however should not be repeated in 117 the same, or any other, section, except where explicitly required by 118 a specification. Eg: an AXFR response requires the SOA record 119 (always an RRSet containing a single RR) be both the first and last 120 record of the reply. Where duplicates are required this way, the TTL 121 transmitted in each case must be the same. 123 6. Security Considerations 125 This document does not consider security. 127 In particular, nothing in section 4 is any way related to, or useful 128 for, any security related purposes. 130 It is not believed that anything in this document adds to any 131 security issues that may exist with the DNS, nor does it do anything 132 to lessen them. 134 7. References 136 [RFC1034] Domain Names - Concepts and Facilities, 137 P. Mockapetris, ISI, November 1987. 139 [RFC1035] Domain Names - Implementation and Specification 140 P. Mockapetris, ISI, November 1987 142 8. Acknowledgements 144 To be supplied.