The IESG has approved the following document: - 'Extension Mechanisms for DNS (EDNS(0))' (draft-ietf-dnsext-rfc2671bis-edns0-10.txt) as Internet Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2671bis-edns0/ 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.
