Technical Summary
The Domain Name System's wire protocol includes a number of fixed
fields whose range has been or soon will be exhausted and does not
allow requestors to advertise their capabilities to responders.
This document describes backward compatible mechanisms for allowing
the protocol to grow.
This document updates the EDNS0 specification (RFC 2671) based on
feedback from deployment experience in several implementations. It
also closes the IANA registry for extended labels created as part
of RFC 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain
Name System") which depends on the existence of extended labels.
The main contribution of RFC2671 was to allow larger DNS messages
over UDP, beween cooperating parties, this is crucial for DNSSEC
and other modern DNS uses.
Working Group Summary
Working group is solidly behind this document.
Document Quality
There are many implemenations of this specification, the working
group wish is that this be published as Internet Standard. This
document is the cummulation of fair ammount of work and
experience. During the WG process most of the changes in the
document were stylistic and presentation ones rather than
technical.
These are the responses to the questions from RFC 6410 regarding
publication as an Internet Standard.
(1) There are at least two independent interoperating implementations
with widespread deployment and successful operational experience.
There are MANY implementations, as a matter of fact almost all
DNS implementations support ENDS0, there is great
interoperability. The only issues that we have discovered are
that some implementations have strange ideas (non-RFC1035
compliant) as what to return when seeing ENDS0 option in
message. This is covered in this document.
(2) There are no errata against the specification that would cause a
new implementation to fail to interoperate with deployed ones.
There are no errata filed against RFC2671 and RFC2671bis takes
into account most of the issues that RFC2671 underspecified.
(3) There are no unused features in the specification that greatly
increase implementation complexity.
Correct.
(4) If the technology required to implement the specification
requires patented or otherwise controlled technology, then the
set of implementations must demonstrate at least two independent,
separate and successful uses of the licensing process.
The technology required to implement the specification requires
no patented or otherwise controlled technology.
Personnel
Olafur Gudmundsson (ogud at ogud.com) is the document
shepherd. Ralph Droms <rdroms.ietf@gmail.com> is the
Responsible AD.