idnits 2.17.00 (12 Aug 2021) /tmp/idnits35559/draft-ihren-delegation-ttls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 151 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC1034' on line 129 looks like a reference -- Missing reference section? 'RFC1035' on line 132 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNS Operations Working Group Johan Ihren 2 draft-ihren-delegation-ttls-00.txt Autonomica 3 October 2003 Expires in six months 5 Importance Of Parent-side TTLs For Referrals Several Layers Deep 7 Status of this Memo 9 This document is an Internet-Draft and is subject to all 10 provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts 20 as reference material or to cite them other than as "work in 21 progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This memo documents a consequence of how the TTL re-writing 32 mechanism works (or rather does not work) for the case of a 33 resolver chasing a referral chain several layers deep. 35 The most common example of this is the case of a recursive resolver 36 trying to look up a third level domain name starting from the root. 38 A result of how this works is that it seems to be a good idea to 39 recommend an increase of the present standard TTL for delegations 40 from the root zone from the present 48 hours to something 41 significantly longer. But, more importantly, the choice of TTL for 42 the referral from the parent should be a decision made by the 43 child, not the parent. 45 1. Introduction. 47 When a resolver queries an authoritative server it has to be 48 prepared for several possible responses. The responses relevant 49 here are primarily 51 a) "The Answer", i.e. a response with the answer to the query in 52 the Answer section and the enclosing NS RRset in the Authority 53 section 55 b) "The Referral", i.e. a response with an empty Answer section and 56 the NS RRset of the child in the Authority section. 58 In the case of the referral the NS RRset is cached based upon the 59 TTL associated with the involved records. 61 In the probably most common case this referral will soon be 62 followed by an "Answer"-response from the child and then the TTL 63 for the NS RRset of the child will be re-written because the child 64 is authoritative for the contents of its own NS RRset and that data 65 is supplied in the Authority section of the response. 67 Since the NS RRset supplied by the parent will therefore only be 68 used once and then overwritten it does not matter much what TTL is 69 used by the parent for the referral. 71 However, in the case where the child will respond with another 72 referral (i.e. referring further down the hierarchy to a grandchild 73 of the parent) the response will contain an Authority section with 74 the referral data for the grandchild, rather than the childs 75 authoritative statement on its own NS RRset. 77 In this case the NS RRset for the child supplied by the parent will 78 not be overwritten and therefore it will stay in the cache of the 79 recursive resolver for as long as the parent-side TTL specifies. In 80 this case the parent-side TTL will matter very much. 82 2. Recommendation. 84 Following a referral several layers down into the DNS hiearchy is 85 especially common when looking up data starting from the root. 86 Therefore every TLD will be subject to this phenomena of the child 87 (i.e. the TLD) not updating the TTL information for the referral 88 from the parent. There are examples in other parts of the hierarchy 89 too. 91 Therefore it would be correct to let the child influence the choice 92 of parent-side TTL for a referral. In the particular case of TLD 93 referrals increasing the present 48 hour TTL significantly seems 94 appropriate. 96 Exactly how long a suitable TTL is will vary, but given that 97 typical turn-around time for changes to the root zone is on the 98 order of several weeks it does not seem excessive to use a one week 99 TTL as a base recommendation. 101 3. Security Considerations. 103 It is concievable that using a longer TTL than 48 hours in a TLD 104 delegation may cause problems in the case of an emergency rollover 105 from an old NS RRset to a new one. 107 On the other hand it is also concievable that a resolver may be cut 108 off from root name service for for a period of time during which 109 the cached referrals expire. By using a longer TTL the risk of this 110 scenario is decreased. 112 Which case is considered most likely or most important will not be 113 the same for all zones. It is therefore not a good idea to have the 114 TTL of the referral be decided by the parent since it should be a 115 decision for the child. 117 4. IANA Considerations. 119 Presently IANA uses the same 48 hour TTL on all delegation 120 information from the root, arpa and in-addr.arpa zones. Based upon 121 the argument above it is recommended that this practice is replaced 122 by instead honoring the wishes of the child for what TTL is 123 appropriate in each particular case. 125 5. References 127 5.1. Normative. 129 [RFC1034] Domain Names - Concepts and Facilities. P.V. Mockapetris, 130 November 1987. 132 [RFC1035] Domain Names - Implementation and Specification. 133 P.V. Mockapetris. November 1987. 135 6. Authors' Address 137 Johan Ihren 138 Autonomica AB 139 Bellmansgatan 30 140 SE-118 47 Stockholm, Sweden 141 johani@autonomica.se