idnits 2.17.1 draft-jabley-dnsop-refer-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 12, 2021) is 1169 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-ns-revalidation-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Abley 3 Internet-Draft Public Interest Registry 4 Intended status: Experimental February 12, 2021 5 Expires: August 16, 2021 7 REFER: A New Referral Mechanism for the DNS 8 draft-jabley-dnsop-refer-00 10 Abstract 12 The Domain Name System (DNS) incorporates a namespace that is 13 comprised, in practice, of multiple so-called zones. Each zone is, 14 in principal, a finite tree structure which can be administered 15 autonomously, and is connected to exactly one parent zone and zero or 16 more child zones. These connection points are known as zone cuts; a 17 parent zone contains information that allows the servers responsible 18 for the child zone to be found. 20 The current DNS specification encodes that information about child 21 zones using an "NS" resource record set in the parent zone, and a 22 corresponding "NS" resource record set in the child zone. These two 23 resource record sets have identical owner names, class, and resource 24 record type but can differ in other respects such as the time-to-live 25 (TTL) attribute, the resource record data associated with each set 26 and the availability of cryptographic signatures. This property of 27 being similar, related but potentially different has led to 28 operational complexity. 30 This document proposes a change to how zone cuts are encoded in the 31 parent zone, allowing the resource records in the parent and the 32 child zone to be more clearly distinguished and protected separately 33 using cryptographic signatures. 35 It is not at all clear that this is a good idea. To restate in 36 stronger terms, the goal of the experiment described in this document 37 is to determine just how bad an idea this is. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on August 16, 2021. 56 Copyright Notice 58 Copyright (c) 2021 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 3. An Assortment of Problem Statements . . . . . . . . . . . . . 4 76 3.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3.2. Ambiguity Across a Zone Cut . . . . . . . . . . . . . . . 4 78 3.3. Masking of Parental RRSets by Children . . . . . . . . . 5 79 4. The REFER Mechanism . . . . . . . . . . . . . . . . . . . . . 5 80 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 81 4.2. The REFER Resource Record Type . . . . . . . . . . . . . 6 82 4.3. The REFER OK EDNS(0) Option . . . . . . . . . . . . . . . 6 83 4.4. DNS Protocol Modifications . . . . . . . . . . . . . . . 7 84 4.4.1. Changes to Deployed Zone Data . . . . . . . . . . . . 7 85 4.4.2. Changes to DNS Server Behaviour . . . . . . . . . . . 8 86 4.4.2.1. Authoritative Servers . . . . . . . . . . . . . . 8 87 4.4.2.2. Recursive Servers . . . . . . . . . . . . . . . . 9 88 4.4.2.3. Other DNS Servers . . . . . . . . . . . . . . . . 9 89 4.5. Backwards Compatibility and Incremental Deployment . . . 9 90 4.6. Transport Considerations . . . . . . . . . . . . . . . . 9 91 5. Goals of Experiment . . . . . . . . . . . . . . . . . . . . . 10 92 5.1. Implementation . . . . . . . . . . . . . . . . . . . . . 10 93 5.2. Gauging the Desperation of the Camel . . . . . . . . . . 10 94 5.3. Incremental Deployment . . . . . . . . . . . . . . . . . 10 95 5.4. Effects on DNS Traffic . . . . . . . . . . . . . . . . . 10 96 5.5. Effects on DNS Zone Provisioning . . . . . . . . . . . . 11 97 5.6. Policy Hurdles At and Near the Root . . . . . . . . . . . 11 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 100 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 101 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 102 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 103 9.2. Informative References . . . . . . . . . . . . . . . . . 13 104 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 13 105 A.1. Venue for Discussion . . . . . . . . . . . . . . . . . . 13 106 A.2. Change History . . . . . . . . . . . . . . . . . . . . . 14 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 109 1. Introduction 111 The Domain Name System (DNS) base specification ([RFC1034], 112 [RFC1035]) has been extended many times since its original 113 publication. The use of two corresponding NS resource-record sets to 114 signal the existence of a zone cut, one in the parent zone and one in 115 the child zone, has resulted in some operational complexity. However 116 the cost of changing the nature of the referral mechanism given the 117 wide and varied assortment of dependent software deployed on the 118 Internet has always been assumed to be so high that it makes more 119 sense to work around that complexity than it does to review the 120 suitability of the incumbent mechanism. This document proposes to 121 challenge that assumption. 123 This document is organised as follows. A curated assortment of 124 problems associated with the incumbent referral mechanism can be 125 found in Section 3. Section 4 contains a proposed, experimental 126 replacement mechanism. Experiments intended to assess the proposed 127 new mechanism and compare it with the incumbent mechanism are 128 described in Section 5. IANA considerations, including code-point 129 assignments, are presented in Section 7 and the security implications 130 of the proposed new mechanism are discussed in Section 6. 132 2. Terminology 134 This document uses various terminology specific to the DNS. For 135 definitions and discussion of particular terms, see [RFC8499]. 137 The new referral mechanism described in this document is referred to 138 in this document "the REFER Mechanism" and referral responses that 139 follow it are referred to as "REFER Responses". The conventional, 140 current, standard mechanism described in [RFC1034] and [RFC1035] that 141 the REFER Mechanism seeks to replace (or augment, see Section 4.5) is 142 referred to as the "Standard Referral Mechanism" and corresponding 143 referrals using that mechanism are referred to as Standard Referrals. 145 This document uses capitalized keywords such as MUST and MAY to 146 describe the requirements for using the registered RR types. The 147 intended meaning of those keywords in this document are the same as 148 those described in [RFC2119]. Although these keywords are often used 149 to specify normative requirements in IETF Standards, their use in 150 this document does not imply that this document is a standard of any 151 kind. 153 3. An Assortment of Problem Statements 155 A handful of indicative problem statements that seem relevant to this 156 proposal are included below. This is not an exhaustive list. 158 3.1. Privacy 160 A Standard Referral response from an authoritative DNS server 161 includes an NS RRset. It is not possible for the response to include 162 a corresponding RRSIG RRset, since the administrator of a parent zone 163 is generally not in possession of the private keys needed to make 164 signatures in a child zone. The lack of signatures means that the 165 Standard Referral response is subject to on-path substitution 166 attacks, even if both parent and child zones are signed and the 167 originator of the request that triggered the referral response 168 requests DNSSEC data (with DO=1) and is capable of validating 169 responses. 171 While it is to be hoped that a validating resolver that falls victim 172 to such an attack would not cache subsequent responses from an 173 attacker's server, since sooner or later something would fail 174 validation, the metadata about the query and the query contents (e.g. 175 a non-minimised QNAME) will have leaked in the process of finding 176 out. 178 The REFER Mechanism does not suffer from this problem, since the 179 delegation information published in the parent and child zones does 180 not overload the same RRtype, and hence can be unambiguously signed 181 separately in both places, allowing validators to identify on-path 182 substitution attacks without leaking queries to rogue servers. Other 183 work has attempted to address this problem, e.g. 184 [I-D.fujiwara-dnsop-delegation-information-signer]. 186 3.2. Ambiguity Across a Zone Cut 188 When following a Standard Referral response from an authoritative 189 server to a child zone, DNS resolvers cannot always be relied upon to 190 retrieve an NS RRset from child nameservers. Instead they may simply 191 cache the NS RRset with the same owner name received in the Standard 192 Referral response from the parent. This can result in NS RRsets 193 being cached without signatures, since no signatures over the NS 194 RRset can normally be included in a referral response, or the 195 parent's choice of TTL being used in the cache instead of the 196 child's, or inaccurate data being cached in the case where the 197 child's authoritative data is not the same as the data published in 198 the parent zone. 200 The REFER Mechanism does not suffer from this problem, since the 201 RRset obtained from the parent has a different RRtype from any set 202 obtained from the child; any query that requires an NS RRset would 203 necessarily involve a response from the child and cannot be satisfied 204 by a referral response from the parent. Other work has attempted to 205 address this problem, e.g. [I-D.ietf-dnsop-ns-revalidation]. 207 3.3. Masking of Parental RRSets by Children 209 A nameserver serving both parent and child zones will normally not 210 provide a Standard Referral response from the parent if a response 211 can be formulated with data obtained from the child. This means that 212 the parent's NS RRset will normally be obscured from view, masked by 213 the corresponding NS RRset at the child's apex. This has the 214 potential to hide operational problems that might later become 215 apparent, e.g. if the child zone is moved to different nameservers. 217 The REFER Mechanism does not suffer from the same problem, since the 218 delegation information in the parent and child do not share the same, 219 overloaded RRtype; consequently both the parent zone data and the 220 child zone data can be queried independently, without ambiguity. 222 4. The REFER Mechanism 224 4.1. Overview 226 The REFER Mechanism can be summarised as follows: 228 o Introduce a new RRtype for publishing delegation information in 229 the parent zone, which has similar semantics to NS used for the 230 same purpose, except that the rules for signing the RRset are 231 specified to be the same as DS, i.e. signatures belong in the 232 parent; 234 o Specify a new EDNS(0) option which, when present in a query sent 235 to an authoritative server, signals to the server that REFER 236 referrals are supported and requested by the client; 238 o Introduce new, optional functionality in authoritative servers 239 such that queries requesting REFER responses will receive a REFER 240 Response, if available; 242 o Preserve the Standard Referral response for queries that do not 243 explicitly request the new behaviour, or for responses that are 244 generated from zones that do not include new-style delegation 245 RRtypes. 247 Complete deployment of the REFER Mechanism requires changes in all 248 DNS zones, all authoritative servers and all clients of authoritative 249 servers (e.g. recursive servers). This seems like an unrealistic 250 expectation. However, it seems intuitively true that certain modes 251 of incremental deployment may have useful characteristics; 252 determining whether this hypothesis holds in practice is one of the 253 objectives of this experiment, as described in Section 5. For more 254 discussion of incremental deployment, see Section 4.5. 256 The REFER Mechanism is described in more detail in the sections that 257 follow. 259 4.2. The REFER Resource Record Type 261 The REFER resource record (RR) is used to store a single nameserver 262 name in the DNS. It is intended to be used in a parent zone to 263 signal the presence of a zone cut and to specify the nameservers to 264 which a child zone is delegated. 266 The type value for the REFER RR is TBA1. 268 The REFER RR is class-independent. However, interpretation of the 269 REFER RR by DNS servers in processing DNS queries and responses is 270 only specified for class IN. 272 The REFER RR has no special time-to-live (TTL) requirements. 274 The RDATA for a REFER RR and its wire format is precisely the same as 275 for the NS RR, as described in [RFC1035] section 3.3.11. 277 The presentation format of the REFER RR is precisely the same as for 278 the NS RR, with the REFER keyword replacing the NS keyword. 280 4.3. The REFER OK EDNS(0) Option 282 The REFER Mechanism requires a means for the originator of a query to 283 signal to a server that if a referral response is generated, a REFER 284 Response is requested. The most consistent approach to achieve this 285 signalling seems to follow the approach used with the DO bit, as 286 specified in [RFC3225] and [RFC4035] section 3.2.1. However, since 287 EDNS(0) header bits are in short supply (there are only 15 of them 288 available for assignment, see [RFC6891]) this seems inappropriate for 289 an experimental proposal. Instead, this document specifies a 290 separate, optional EDNS(0) option. 292 The REFER OK EDNS(0) option is encoded as an OPTION-CODE of TBA2, an 293 OPTION-LENGTH of zero and no OPTION-DATA, as follows: 295 +0 (MSB) +1 (LSB) 296 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 297 0: | OPTION-CODE = TBA2 | 298 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 299 2: | OPTION-LENGTH = 0 | 300 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 302 The REFER OK EDNS(0) option MAY be included alongside other EDNS(0) 303 options in the same query. 305 A single DNS query SHOULD include zero or one REFER OK option; 306 including more than one does not change the intended signal and hence 307 serves no purpose. Systems which receive more than one REFER OK 308 option in a single query should behave precisely as if only a single 309 REFER OK option had been included. 311 A DNS response generated by a system that supports the REFER 312 Mechanism, in response to a query that included the REFER OK option, 313 should also include a single REFER OK option in the response, even if 314 the response is not a referral. 316 Any DNS system which receives a DNS message containing more than one 317 REFER OK option should behave precisely as if only a single REFER OK 318 option had been included. 320 4.4. DNS Protocol Modifications 322 4.4.1. Changes to Deployed Zone Data 324 In order for a referral response to be constructed using the REFER 325 Mechanism, the corresponding zone cut must be provisioned in the zone 326 data loaded in the server using a REFER RRset. An NS RRset with the 327 same owner name MAY also be present, but is not required. If both NS 328 and REFER RRsets exist at the same owner name, both RRsets SHOULD 329 point to the same set of servers, since operational confusion might 330 well result from them being different. However, zone administrators 331 MAY deliberately make the RDATA of each RRset different, e.g. for the 332 purposes of experimental measurement. 334 In a signed zone REFER RRsets MUST be signed, regardless of whether 335 the zone cut that they are being used to provision represents a 336 secure delegation or an insecure delegation. The keys used to 337 generate RRSIGs over a REFER RRset are those published in the parent 338 zone that contains the REFER RRset, similarly to the way in which DS 339 RRsets are signed. 341 4.4.2. Changes to DNS Server Behaviour 343 4.4.2.1. Authoritative Servers 345 An authoritative server that supports the REFER Mechanism MUST check 346 for the existence of the RO option in queries it receives. The 347 existence or non-existence of the RO option in the query MUST be 348 retained as part of the query attributes used to build a 349 corresponding response. 351 When generating a referral response, the intention is that an 352 authoritative server that supports the REFER Mechanism should send 353 referrals that are identical to the Standard Mechanism if the 354 corresponding query does not include the RO option, but should always 355 prefer to include REFER RRsets over NS RRsets at all other times. 357 1. If the query included the RO option and zone data above the zone 358 cut incudes a REFER RRset, that REFER RRset MUST be included in 359 the referral response precisely as an NS RRset would be included 360 under the Standard Mechanism. An RRSIG RRset over the REFER 361 RRset MUST also be included, if available. 363 2. If the query included the RO option and zone data above the zone 364 cut does not include a REFER RRset, the NS RRset MUST be included 365 precisely as it would under the Standard Mechanism. 367 3. If the query did not include the RO option and zone data above 368 the zone cut includes an NS RRset, that NS RRset MUST be included 369 precisely as it would be under the Standard Mechanism. 371 4. If the query did not include the RO option and zone data above 372 the zone cut does not include an NS RRset, an NS RRset MUST be 373 synthesised from the REFER RRset that is present. 375 No referral response should ever include both a REFER and an NS RRset 376 to communicate the target servers of a delegation. 378 An authoritative server that supports the REFER Mechanism MUST 379 include the RO option in every response to a query in which the RO 380 option was present, and MUST NOT include the RO option in any other 381 response, regardless of whether the response is a referral. 383 4.4.2.2. Recursive Servers 385 A recursive server that supports the REFER Mechanism: 387 1. MUST include the RO option in every query it sends; 389 2. MUST interpret and use REFER RRsets received in referral 390 responses in precisely the same way that NS RRsets received in 391 referral responses are interpreted when following the iterative 392 resolution process; 394 3. MUST use NS RRsets in preference to REFER RRsets with the same 395 owner name and QCLASS if both are present in the cache. 397 4.4.2.3. Other DNS Servers 399 No changes are required to DNS forwarders. 401 4.5. Backwards Compatibility and Incremental Deployment 403 The intent is that authoritative DNS servers supporting the REFER 404 Mechanism should generate identical responses to those following the 405 Standard Mechanism for all queries received without the RO option. 406 This allows a single server to support clients that do not support 407 the REFER Mechanism as well as those that do, and ensures a 408 consistent experience for clients that do not support the REFER 409 Mechanism regardless of whether it is deployed on any authoritative 410 server. 412 A recursive DNS server that supports the REFER Mechanism may complete 413 the iterative resolution process in the process of responding to a 414 query by means of inbound REFER responses. Such a server might not 415 be able to respond to a subsequent query received with QTYPE=NS from 416 the cache, but would need to initiate a new query in order to 417 retrieve the apex NS RRset from the servers that are authoritative 418 for the closest enclosing zone. This additional query has the 419 potential to increase response time, but has the advantage that the 420 ambiguity that might otherwise arise around whether a particular NS 421 RRset originates from above or below a zone cut is avoided. 422 Additionally, NS RRsets that are consistently retrieved from servers 423 below the zone cut have the opportunity to be cryptographically 424 signed, improving cache integrity through the validation process. 426 4.6. Transport Considerations 428 The REFER Mechanism imposes no special requirements on DNS transport 429 protocols. 431 5. Goals of Experiment 433 The overarching ambition of this experiment is to gauge whether a 434 change in a fundamental aspect of the deployed DNS protocol, the 435 referral mechanism, is plausible. This document does not specify any 436 experiments, but attempts to frame some indicative research 437 questions. 439 Since the two code points that are needed to carry out experiments 440 will be allocated from protocol registries that are not generally 441 managed with leases (i.e. assignments are essentially permanent) 442 there is no time period specified for this experiment. 444 The following are not intended to be an exhaustive list of research 445 questions, but rather examples intended to seed discussion. 447 5.1. Implementation 449 Is the REFER Mechanism specification proposed in this document 450 unambiguous and sufficient for it to be implemented? 452 5.2. Gauging the Desperation of the Camel 454 Can the REFER Mechanism be implemented in commonly-used DNS code 455 bases without causing unacceptable complexity? 457 This is a subjective question, but perhaps by gathering a diversity 458 of answers from different teams working on different code bases a 459 reasonable assessment can be made. 461 5.3. Incremental Deployment 463 Can the REFER Mechanism be deployed in an environment where support 464 is absent in other clients and servers? 466 A DNS implementation should interact with other clients and servers 467 that do not support the REFER Mechanism identically regardless of 468 whether it supports the REFER Mechanism itself. That is, the 469 mechanisms intended to provide backwards compatability to the 470 Standard Mechanism should work. 472 5.4. Effects on DNS Traffic 474 What effect would the REFER Mechanism have on traffic if it was 475 widely deployed? 477 5.5. Effects on DNS Zone Provisioning 479 What other systems, beyond those contemplated in this document, 480 depend upon delegations being provisioned in DNS zones using NS 481 RRsets? 483 This proposal allows deployment of both NS and REFER RRsets at a 484 single zone cut which might mitigate any negative effects of an NS- 485 to-REFER transition, but that mitigation comes at the cost of 486 increased zone size that might be significant in large, delegation- 487 centric zones such as those published by some TLD registries. 489 5.6. Policy Hurdles At and Near the Root 491 How practical might it be to deploy REFER RRsets in the root zone, or 492 TLD zones, and to support the REFER Mechanism in TLD and root 493 servers? 495 6. Security Considerations 497 The REFER Mechanism, if implemented by authoritative DNS servers and 498 their clients, has the potential to improve confidentiality of 499 communications since it allows a referral response from an 500 authoritative server to be signed. A signed referral response can be 501 validated and confirmed to be authentic before subsequent queries are 502 sent to the servers listed in the referral, avoiding the possibility 503 that the existence and contents of a query might be disclosed to an 504 unauthorised endpoint. 506 Since the signalling mechanism by which a client requests that the 507 REFER Mechanism be used in sending any referral response has no 508 cryptographic protection, this protocol is vulnerable to downgrade 509 attacks: that is, an on-path attacker could eliminate the RO option 510 from a query or replace a signed REFER RRset in a response with an 511 unsigned NS RRset. The impact of such an attack would be to 512 eliminate any benefits of the REFER Mechanism and revert to the 513 security characteristics of the Standard Mechanism. 515 No new concerns relating to Systems Security [RFC3552] associated 516 with the implementation or use of the REFER Mechanism have been 517 identified. 519 7. IANA Considerations 521 This section is a placeholder, intended to demonstrate that there is 522 an IANA action here without actually being very thorough about what 523 it should be. For example, both registries below support early 524 assignment by expert review, and if that path is chosen then the 525 requests this document makes of the IANA will be different. No 526 request for code points has been made at this time. 528 The IANA is requested to assign a value to the RRtype described in 529 this document as TBA1 and to add the value to the Resource Record 530 (RR) TYPEs registry as follows: 532 +-------+-------+-------------------------------------+-------------+ 533 | TYPE | Value | Meaning | Reference | 534 +-------+-------+-------------------------------------+-------------+ 535 | REFER | TBA1 | an authoritative name server viewed | (this | 536 | | | from a parent | document) | 537 +-------+-------+-------------------------------------+-------------+ 539 The IANA is requested to assign a value to the EDNS(0) option code 540 described in this document as TBA2 and to add the value to the DNS 541 EDNS0 Option Codes (OPT) registry as follows: 543 +-------+----------+----------+-----------------+ 544 | Value | Name | Status | Reference | 545 +-------+----------+----------+-----------------+ 546 | TBA2 | REFER OK | Optional | (this document) | 547 +-------+----------+----------+-----------------+ 549 8. Acknowledgements 551 Many people have daydreamed wistfully over the years about the 552 entrenched overloading of the NS RRset in the DNS. At least some of 553 them have done so out loud in bars, although it is entirely possible 554 that they did not realise anybody was listening. 556 9. References 558 9.1. Normative References 560 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 561 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 562 . 564 [RFC1035] Mockapetris, P., "Domain names - implementation and 565 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 566 November 1987, . 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, 570 DOI 10.17487/RFC2119, March 1997, 571 . 573 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 574 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 575 January 2019, . 577 9.2. Informative References 579 [I-D.fujiwara-dnsop-delegation-information-signer] 580 Fujiwara, K., "Delegation Information (Referrals) Signer 581 for DNSSEC", draft-fujiwara-dnsop-delegation-information- 582 signer-00 (work in progress), November 2020. 584 [I-D.ietf-dnsop-ns-revalidation] 585 Huque, S., Vixie, P., and R. Dolmans, "Delegation 586 Revalidation by DNS Resolvers", draft-ietf-dnsop-ns- 587 revalidation-00 (work in progress), September 2020. 589 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 590 RFC 3225, DOI 10.17487/RFC3225, December 2001, 591 . 593 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 594 Text on Security Considerations", BCP 72, RFC 3552, 595 DOI 10.17487/RFC3552, July 2003, 596 . 598 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 599 Rose, "Protocol Modifications for the DNS Security 600 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 601 . 603 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 604 for DNS (EDNS(0))", STD 75, RFC 6891, 605 DOI 10.17487/RFC6891, April 2013, 606 . 608 Appendix A. Editorial Notes 610 This section (and sub-sections) to be removed prior to publication. 612 A.1. Venue for Discussion 614 This is not an IETF working group document. However, at the risk of 615 upsetting the dnsop working group chairs and having to buy them all 616 drinks the next time we have a chance to actually travel to an actual 617 meeting with an actual beer, the dnsop working group mailing list 618 seems like a reasonable place to express fear and loathing at the 619 idea that someone even bothered to write this document. 621 There is no need to suggest that the previous paragraph seems 622 expressly designed to manufacture opportunities for mild, amateur 623 experiments in alcoholism. 625 A.2. Change History 627 00 Initial draft, circulated for the purposes of entertainment. 629 Author's Address 631 Joe Abley 632 Public Interest Registry 633 470 Moore Street 634 London, ON N6C 2C2 635 Canada 637 Email: jabley@pir.org