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]
