Internet DRAFT - draft-jabley-dnsop-refer

draft-jabley-dnsop-refer







Network Working Group                                           J. Abley
Internet-Draft                                  Public Interest Registry
Intended status: Experimental                          February 12, 2021
Expires: August 16, 2021


              REFER: A New Referral Mechanism for the DNS
                      draft-jabley-dnsop-refer-00

Abstract

   The Domain Name System (DNS) incorporates a namespace that is
   comprised, in practice, of multiple so-called zones.  Each zone is,
   in principal, a finite tree structure which can be administered
   autonomously, and is connected to exactly one parent zone and zero or
   more child zones.  These connection points are known as zone cuts; a
   parent zone contains information that allows the servers responsible
   for the child zone to be found.

   The current DNS specification encodes that information about child
   zones using an "NS" resource record set in the parent zone, and a
   corresponding "NS" resource record set in the child zone.  These two
   resource record sets have identical owner names, class, and resource
   record type but can differ in other respects such as the time-to-live
   (TTL) attribute, the resource record data associated with each set
   and the availability of cryptographic signatures.  This property of
   being similar, related but potentially different has led to
   operational complexity.

   This document proposes a change to how zone cuts are encoded in the
   parent zone, allowing the resource records in the parent and the
   child zone to be more clearly distinguished and protected separately
   using cryptographic signatures.

   It is not at all clear that this is a good idea.  To restate in
   stronger terms, the goal of the experiment described in this document
   is to determine just how bad an idea this is.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.




Abley                    Expires August 16, 2021                [Page 1]

Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021


   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."

   This Internet-Draft will expire on August 16, 2021.

Copyright Notice

   Copyright (c) 2021 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
   (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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  An Assortment of Problem Statements . . . . . . . . . . . . .   4
     3.1.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Ambiguity Across a Zone Cut . . . . . . . . . . . . . . .   4
     3.3.  Masking of Parental RRSets by Children  . . . . . . . . .   5
   4.  The REFER Mechanism . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  The REFER Resource Record Type  . . . . . . . . . . . . .   6
     4.3.  The REFER OK EDNS(0) Option . . . . . . . . . . . . . . .   6
     4.4.  DNS Protocol Modifications  . . . . . . . . . . . . . . .   7
       4.4.1.  Changes to Deployed Zone Data . . . . . . . . . . . .   7
       4.4.2.  Changes to DNS Server Behaviour . . . . . . . . . . .   8
         4.4.2.1.  Authoritative Servers . . . . . . . . . . . . . .   8
         4.4.2.2.  Recursive Servers . . . . . . . . . . . . . . . .   9
         4.4.2.3.  Other DNS Servers . . . . . . . . . . . . . . . .   9
     4.5.  Backwards Compatibility and Incremental Deployment  . . .   9
     4.6.  Transport Considerations  . . . . . . . . . . . . . . . .   9
   5.  Goals of Experiment . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Implementation  . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Gauging the Desperation of the Camel  . . . . . . . . . .  10
     5.3.  Incremental Deployment  . . . . . . . . . . . . . . . . .  10
     5.4.  Effects on DNS Traffic  . . . . . . . . . . . . . . . . .  10
     5.5.  Effects on DNS Zone Provisioning  . . . . . . . . . . . .  11



Abley                    Expires August 16, 2021                [Page 2]

Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021


     5.6.  Policy Hurdles At and Near the Root . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Appendix A.  Editorial Notes  . . . . . . . . . . . . . . . . . .  13
     A.1.  Venue for Discussion  . . . . . . . . . . . . . . . . . .  13
     A.2.  Change History  . . . . . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   The Domain Name System (DNS) base specification ([RFC1034],
   [RFC1035]) has been extended many times since its original
   publication.  The use of two corresponding NS resource-record sets to
   signal the existence of a zone cut, one in the parent zone and one in
   the child zone, has resulted in some operational complexity.  However
   the cost of changing the nature of the referral mechanism given the
   wide and varied assortment of dependent software deployed on the
   Internet has always been assumed to be so high that it makes more
   sense to work around that complexity than it does to review the
   suitability of the incumbent mechanism.  This document proposes to
   challenge that assumption.

   This document is organised as follows.  A curated assortment of
   problems associated with the incumbent referral mechanism can be
   found in Section 3.  Section 4 contains a proposed, experimental
   replacement mechanism.  Experiments intended to assess the proposed
   new mechanism and compare it with the incumbent mechanism are
   described in Section 5.  IANA considerations, including code-point
   assignments, are presented in Section 7 and the security implications
   of the proposed new mechanism are discussed in Section 6.

2.  Terminology

   This document uses various terminology specific to the DNS.  For
   definitions and discussion of particular terms, see [RFC8499].

   The new referral mechanism described in this document is referred to
   in this document "the REFER Mechanism" and referral responses that
   follow it are referred to as "REFER Responses".  The conventional,
   current, standard mechanism described in [RFC1034] and [RFC1035] that
   the REFER Mechanism seeks to replace (or augment, see Section 4.5) is
   referred to as the "Standard Referral Mechanism" and corresponding
   referrals using that mechanism are referred to as Standard Referrals.




Abley                    Expires August 16, 2021                [Page 3]

Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021


   This document uses capitalized keywords such as MUST and MAY to
   describe the requirements for using the registered RR types.  The
   intended meaning of those keywords in this document are the same as
   those described in [RFC2119].  Although these keywords are often used
   to specify normative requirements in IETF Standards, their use in
   this document does not imply that this document is a standard of any
   kind.

3.  An Assortment of Problem Statements

   A handful of indicative problem statements that seem relevant to this
   proposal are included below.  This is not an exhaustive list.

3.1.  Privacy

   A Standard Referral response from an authoritative DNS server
   includes an NS RRset.  It is not possible for the response to include
   a corresponding RRSIG RRset, since the administrator of a parent zone
   is generally not in possession of the private keys needed to make
   signatures in a child zone.  The lack of signatures means that the
   Standard Referral response is subject to on-path substitution
   attacks, even if both parent and child zones are signed and the
   originator of the request that triggered the referral response
   requests DNSSEC data (with DO=1) and is capable of validating
   responses.

   While it is to be hoped that a validating resolver that falls victim
   to such an attack would not cache subsequent responses from an
   attacker's server, since sooner or later something would fail
   validation, the metadata about the query and the query contents (e.g.
   a non-minimised QNAME) will have leaked in the process of finding
   out.

   The REFER Mechanism does not suffer from this problem, since the
   delegation information published in the parent and child zones does
   not overload the same RRtype, and hence can be unambiguously signed
   separately in both places, allowing validators to identify on-path
   substitution attacks without leaking queries to rogue servers.  Other
   work has attempted to address this problem, e.g.
   [I-D.fujiwara-dnsop-delegation-information-signer].

3.2.  Ambiguity Across a Zone Cut

   When following a Standard Referral response from an authoritative
   server to a child zone, DNS resolvers cannot always be relied upon to
   retrieve an NS RRset from child nameservers.  Instead they may simply
   cache the NS RRset with the same owner name received in the Standard
   Referral response from the parent.  This can result in NS RRsets



Abley                    Expires August 16, 2021                [Page 4]

Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021


   being cached without signatures, since no signatures over the NS
   RRset can normally be included in a referral response, or the
   parent's choice of TTL being used in the cache instead of the
   child's, or inaccurate data being cached in the case where the
   child's authoritative data is not the same as the data published in
   the parent zone.

   The REFER Mechanism does not suffer from this problem, since the
   RRset obtained from the parent has a different RRtype from any set
   obtained from the child; any query that requires an NS RRset would
   necessarily involve a response from the child and cannot be satisfied
   by a referral response from the parent.  Other work has attempted to
   address this problem, e.g.  [I-D.ietf-dnsop-ns-revalidation].

3.3.  Masking of Parental RRSets by Children

   A nameserver serving both parent and child zones will normally not
   provide a Standard Referral response from the parent if a response
   can be formulated with data obtained from the child.  This means that
   the parent's NS RRset will normally be obscured from view, masked by
   the corresponding NS RRset at the child's apex.  This has the
   potential to hide operational problems that might later become
   apparent, e.g. if the child zone is moved to different nameservers.

   The REFER Mechanism does not suffer from the same problem, since the
   delegation information in the parent and child do not share the same,
   overloaded RRtype; consequently both the parent zone data and the
   child zone data can be queried independently, without ambiguity.

4.  The REFER Mechanism

4.1.  Overview

   The REFER Mechanism can be summarised as follows:

   o  Introduce a new RRtype for publishing delegation information in
      the parent zone, which has similar semantics to NS used for the
      same purpose, except that the rules for signing the RRset are
      specified to be the same as DS, i.e. signatures belong in the
      parent;

   o  Specify a new EDNS(0) option which, when present in a query sent
      to an authoritative server, signals to the server that REFER
      referrals are supported and requested by the client;

   o  Introduce new, optional functionality in authoritative servers
      such that queries requesting REFER responses will receive a REFER
      Response, if available;



Abley                    Expires August 16, 2021                [Page 5]

Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021


   o  Preserve the Standard Referral response for queries that do not
      explicitly request the new behaviour, or for responses that are
      generated from zones that do not include new-style delegation
      RRtypes.

   Complete deployment of the REFER Mechanism requires changes in all
   DNS zones, all authoritative servers and all clients of authoritative
   servers (e.g. recursive servers).  This seems like an unrealistic
   expectation.  However, it seems intuitively true that certain modes
   of incremental deployment may have useful characteristics;
   determining whether this hypothesis holds in practice is one of the
   objectives of this experiment, as described in Section 5.  For more
   discussion of incremental deployment, see Section 4.5.

   The REFER Mechanism is described in more detail in the sections that
   follow.

4.2.  The REFER Resource Record Type

   The REFER resource record (RR) is used to store a single nameserver
   name in the DNS.  It is intended to be used in a parent zone to
   signal the presence of a zone cut and to specify the nameservers to
   which a child zone is delegated.

   The type value for the REFER RR is TBA1.

   The REFER RR is class-independent.  However, interpretation of the
   REFER RR by DNS servers in processing DNS queries and responses is
   only specified for class IN.

   The REFER RR has no special time-to-live (TTL) requirements.

   The RDATA for a REFER RR and its wire format is precisely the same as
   for the NS RR, as described in [RFC1035] section 3.3.11.

   The presentation format of the REFER RR is precisely the same as for
   the NS RR, with the REFER keyword replacing the NS keyword.

4.3.  The REFER OK EDNS(0) Option

   The REFER Mechanism requires a means for the originator of a query to
   signal to a server that if a referral response is generated, a REFER
   Response is requested.  The most consistent approach to achieve this
   signalling seems to follow the approach used with the DO bit, as
   specified in [RFC3225] and [RFC4035] section 3.2.1.  However, since
   EDNS(0) header bits are in short supply (there are only 15 of them
   available for assignment, see [RFC6891]) this seems inappropriate for




Abley                    Expires August 16, 2021                [Page 6]

Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021


   an experimental proposal.  Instead, this document specifies a
   separate, optional EDNS(0) option.

   The REFER OK EDNS(0) option is encoded as an OPTION-CODE of TBA2, an
   OPTION-LENGTH of zero and no OPTION-DATA, as follows:

                  +0 (MSB)                            +1 (LSB)
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    0: |                   OPTION-CODE = TBA2                          |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    2: |                   OPTION-LENGTH = 0                           |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   The REFER OK EDNS(0) option MAY be included alongside other EDNS(0)
   options in the same query.

   A single DNS query SHOULD include zero or one REFER OK option;
   including more than one does not change the intended signal and hence
   serves no purpose.  Systems which receive more than one REFER OK
   option in a single query should behave precisely as if only a single
   REFER OK option had been included.

   A DNS response generated by a system that supports the REFER
   Mechanism, in response to a query that included the REFER OK option,
   should also include a single REFER OK option in the response, even if
   the response is not a referral.

   Any DNS system which receives a DNS message containing more than one
   REFER OK option should behave precisely as if only a single REFER OK
   option had been included.

4.4.  DNS Protocol Modifications

4.4.1.  Changes to Deployed Zone Data

   In order for a referral response to be constructed using the REFER
   Mechanism, the corresponding zone cut must be provisioned in the zone
   data loaded in the server using a REFER RRset.  An NS RRset with the
   same owner name MAY also be present, but is not required.  If both NS
   and REFER RRsets exist at the same owner name, both RRsets SHOULD
   point to the same set of servers, since operational confusion might
   well result from them being different.  However, zone administrators
   MAY deliberately make the RDATA of each RRset different, e.g. for the
   purposes of experimental measurement.

   In a signed zone REFER RRsets MUST be signed, regardless of whether
   the zone cut that they are being used to provision represents a
   secure delegation or an insecure delegation.  The keys used to



Abley                    Expires August 16, 2021                [Page 7]

Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021


   generate RRSIGs over a REFER RRset are those published in the parent
   zone that contains the REFER RRset, similarly to the way in which DS
   RRsets are signed.

4.4.2.  Changes to DNS Server Behaviour

4.4.2.1.  Authoritative Servers

   An authoritative server that supports the REFER Mechanism MUST check
   for the existence of the RO option in queries it receives.  The
   existence or non-existence of the RO option in the query MUST be
   retained as part of the query attributes used to build a
   corresponding response.

   When generating a referral response, the intention is that an
   authoritative server that supports the REFER Mechanism should send
   referrals that are identical to the Standard Mechanism if the
   corresponding query does not include the RO option, but should always
   prefer to include REFER RRsets over NS RRsets at all other times.

   1.  If the query included the RO option and zone data above the zone
       cut incudes a REFER RRset, that REFER RRset MUST be included in
       the referral response precisely as an NS RRset would be included
       under the Standard Mechanism.  An RRSIG RRset over the REFER
       RRset MUST also be included, if available.

   2.  If the query included the RO option and zone data above the zone
       cut does not include a REFER RRset, the NS RRset MUST be included
       precisely as it would under the Standard Mechanism.

   3.  If the query did not include the RO option and zone data above
       the zone cut includes an NS RRset, that NS RRset MUST be included
       precisely as it would be under the Standard Mechanism.

   4.  If the query did not include the RO option and zone data above
       the zone cut does not include an NS RRset, an NS RRset MUST be
       synthesised from the REFER RRset that is present.

   No referral response should ever include both a REFER and an NS RRset
   to communicate the target servers of a delegation.

   An authoritative server that supports the REFER Mechanism MUST
   include the RO option in every response to a query in which the RO
   option was present, and MUST NOT include the RO option in any other
   response, regardless of whether the response is a referral.






Abley                    Expires August 16, 2021                [Page 8]

Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021


4.4.2.2.  Recursive Servers

   A recursive server that supports the REFER Mechanism:

   1.  MUST include the RO option in every query it sends;

   2.  MUST interpret and use REFER RRsets received in referral
       responses in precisely the same way that NS RRsets received in
       referral responses are interpreted when following the iterative
       resolution process;

   3.  MUST use NS RRsets in preference to REFER RRsets with the same
       owner name and QCLASS if both are present in the cache.

4.4.2.3.  Other DNS Servers

   No changes are required to DNS forwarders.

4.5.  Backwards Compatibility and Incremental Deployment

   The intent is that authoritative DNS servers supporting the REFER
   Mechanism should generate identical responses to those following the
   Standard Mechanism for all queries received without the RO option.
   This allows a single server to support clients that do not support
   the REFER Mechanism as well as those that do, and ensures a
   consistent experience for clients that do not support the REFER
   Mechanism regardless of whether it is deployed on any authoritative
   server.

   A recursive DNS server that supports the REFER Mechanism may complete
   the iterative resolution process in the process of responding to a
   query by means of inbound REFER responses.  Such a server might not
   be able to respond to a subsequent query received with QTYPE=NS from
   the cache, but would need to initiate a new query in order to
   retrieve the apex NS RRset from the servers that are authoritative
   for the closest enclosing zone.  This additional query has the
   potential to increase response time, but has the advantage that the
   ambiguity that might otherwise arise around whether a particular NS
   RRset originates from above or below a zone cut is avoided.
   Additionally, NS RRsets that are consistently retrieved from servers
   below the zone cut have the opportunity to be cryptographically
   signed, improving cache integrity through the validation process.

4.6.  Transport Considerations

   The REFER Mechanism imposes no special requirements on DNS transport
   protocols.




Abley                    Expires August 16, 2021                [Page 9]

Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021


5.  Goals of Experiment

   The overarching ambition of this experiment is to gauge whether a
   change in a fundamental aspect of the deployed DNS protocol, the
   referral mechanism, is plausible.  This document does not specify any
   experiments, but attempts to frame some indicative research
   questions.

   Since the two code points that are needed to carry out experiments
   will be allocated from protocol registries that are not generally
   managed with leases (i.e. assignments are essentially permanent)
   there is no time period specified for this experiment.

   The following are not intended to be an exhaustive list of research
   questions, but rather examples intended to seed discussion.

5.1.  Implementation

   Is the REFER Mechanism specification proposed in this document
   unambiguous and sufficient for it to be implemented?

5.2.  Gauging the Desperation of the Camel

   Can the REFER Mechanism be implemented in commonly-used DNS code
   bases without causing unacceptable complexity?

   This is a subjective question, but perhaps by gathering a diversity
   of answers from different teams working on different code bases a
   reasonable assessment can be made.

5.3.  Incremental Deployment

   Can the REFER Mechanism be deployed in an environment where support
   is absent in other clients and servers?

   A DNS implementation should interact with other clients and servers
   that do not support the REFER Mechanism identically regardless of
   whether it supports the REFER Mechanism itself.  That is, the
   mechanisms intended to provide backwards compatability to the
   Standard Mechanism should work.

5.4.  Effects on DNS Traffic

   What effect would the REFER Mechanism have on traffic if it was
   widely deployed?






Abley                    Expires August 16, 2021               [Page 10]

Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021


5.5.  Effects on DNS Zone Provisioning

   What other systems, beyond those contemplated in this document,
   depend upon delegations being provisioned in DNS zones using NS
   RRsets?

   This proposal allows deployment of both NS and REFER RRsets at a
   single zone cut which might mitigate any negative effects of an NS-
   to-REFER transition, but that mitigation comes at the cost of
   increased zone size that might be significant in large, delegation-
   centric zones such as those published by some TLD registries.

5.6.  Policy Hurdles At and Near the Root

   How practical might it be to deploy REFER RRsets in the root zone, or
   TLD zones, and to support the REFER Mechanism in TLD and root
   servers?

6.  Security Considerations

   The REFER Mechanism, if implemented by authoritative DNS servers and
   their clients, has the potential to improve confidentiality of
   communications since it allows a referral response from an
   authoritative server to be signed.  A signed referral response can be
   validated and confirmed to be authentic before subsequent queries are
   sent to the servers listed in the referral, avoiding the possibility
   that the existence and contents of a query might be disclosed to an
   unauthorised endpoint.

   Since the signalling mechanism by which a client requests that the
   REFER Mechanism be used in sending any referral response has no
   cryptographic protection, this protocol is vulnerable to downgrade
   attacks: that is, an on-path attacker could eliminate the RO option
   from a query or replace a signed REFER RRset in a response with an
   unsigned NS RRset.  The impact of such an attack would be to
   eliminate any benefits of the REFER Mechanism and revert to the
   security characteristics of the Standard Mechanism.

   No new concerns relating to Systems Security [RFC3552] associated
   with the implementation or use of the REFER Mechanism have been
   identified.

7.  IANA Considerations

   This section is a placeholder, intended to demonstrate that there is
   an IANA action here without actually being very thorough about what
   it should be.  For example, both registries below support early
   assignment by expert review, and if that path is chosen then the



Abley                    Expires August 16, 2021               [Page 11]

Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021


   requests this document makes of the IANA will be different.  No
   request for code points has been made at this time.

   The IANA is requested to assign a value to the RRtype described in
   this document as TBA1 and to add the value to the Resource Record
   (RR) TYPEs registry as follows:

   +-------+-------+-------------------------------------+-------------+
   | TYPE  | Value | Meaning                             | Reference   |
   +-------+-------+-------------------------------------+-------------+
   | REFER | TBA1  | an authoritative name server viewed | (this       |
   |       |       | from a parent                       | document)   |
   +-------+-------+-------------------------------------+-------------+

   The IANA is requested to assign a value to the EDNS(0) option code
   described in this document as TBA2 and to add the value to the DNS
   EDNS0 Option Codes (OPT) registry as follows:

             +-------+----------+----------+-----------------+
             | Value | Name     | Status   | Reference       |
             +-------+----------+----------+-----------------+
             | TBA2  | REFER OK | Optional | (this document) |
             +-------+----------+----------+-----------------+

8.  Acknowledgements

   Many people have daydreamed wistfully over the years about the
   entrenched overloading of the NS RRset in the DNS.  At least some of
   them have done so out loud in bars, although it is entirely possible
   that they did not realise anybody was listening.

9.  References

9.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.




Abley                    Expires August 16, 2021               [Page 12]

Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021


   [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
              January 2019, <https://www.rfc-editor.org/info/rfc8499>.

9.2.  Informative References

   [I-D.fujiwara-dnsop-delegation-information-signer]
              Fujiwara, K., "Delegation Information (Referrals) Signer
              for DNSSEC", draft-fujiwara-dnsop-delegation-information-
              signer-00 (work in progress), November 2020.

   [I-D.ietf-dnsop-ns-revalidation]
              Huque, S., Vixie, P., and R. Dolmans, "Delegation
              Revalidation by DNS Resolvers", draft-ietf-dnsop-ns-
              revalidation-00 (work in progress), September 2020.

   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC",
              RFC 3225, DOI 10.17487/RFC3225, December 2001,
              <https://www.rfc-editor.org/info/rfc3225>.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/info/rfc3552>.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <https://www.rfc-editor.org/info/rfc4035>.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891,
              DOI 10.17487/RFC6891, April 2013,
              <https://www.rfc-editor.org/info/rfc6891>.

Appendix A.  Editorial Notes

   This section (and sub-sections) to be removed prior to publication.

A.1.  Venue for Discussion

   This is not an IETF working group document.  However, at the risk of
   upsetting the dnsop working group chairs and having to buy them all
   drinks the next time we have a chance to actually travel to an actual
   meeting with an actual beer, the dnsop working group mailing list
   seems like a reasonable place to express fear and loathing at the
   idea that someone even bothered to write this document.




Abley                    Expires August 16, 2021               [Page 13]

Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021


   There is no need to suggest that the previous paragraph seems
   expressly designed to manufacture opportunities for mild, amateur
   experiments in alcoholism.

A.2.  Change History

   00 Initial draft, circulated for the purposes of entertainment.

Author's Address

   Joe Abley
   Public Interest Registry
   470 Moore Street
   London, ON  N6C 2C2
   Canada

   Email: jabley@pir.org


































Abley                    Expires August 16, 2021               [Page 14]