> On 14 May 2020, at 15:48, Puneet Sood <[email protected]> > wrote: > > Google Public DNS is planning to implement this draft in responses > from us (recursive resolver) to clients. > > *** Question: When can we expect to have an EDNS option code assigned > for the EDE option?
It’s already assigned. See the IANA registry. The value is 15. > *** Request for clarification on Section 3. Extended DNS Error Processing > The text in this section (and in the introduction) implies that a > response with a NOERROR RCODE may contain an EDE option. > "Receivers MUST be able to accept EDE codes and EXTRA-TEXT in > all messages, including those with a NOERROR RCODE, but need not act > on them" > > Scenario: Response has a NOERROR RCODE and contains some response RRs. > If the client sent an EDE option and the server supports EDE, is the > expectation that the server should always include the EDE option? No. While not explicitly specified a server would only include a EDE if it have something extended to report. There is also no requirement for there to be a EDE in the request before sending a EDE in a response. If EDE was expected to be in the request then there would have been a request format specified. All EDNS clients should handle unknown EDNS options in responses as that is a requirement of the base EDNS specification. > If the server includes an EDE option in the response, what is the > right EDE code to use? EDE code 0 [other] seems the closest but it > still implies an error. Also the description for it suggests including > EXTRA-TEXT which would not be useful. > > If the server does not include an EDE option in the response, the > response looks A-OK to the client. However if the client is attempting > to detect EDE option support on the server it might incorrectly assume > the server does not support EDE. There is no reliable way to determine if a server supports EDE. There is no requirement to return any given EDE. Which EDE return (if any) is up to the server developer. > To simplify the NOERROR scenario, can we have a no error EDE code > similar to the NOERROR RCODE? With this a server can include an EDE > option in all responses to queries containing an EDE option. > > Thanks, > Puneet > > > On Tue, May 5, 2020 at 4:52 PM <[email protected]> wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Domain Name System Operations WG of the >> IETF. >> >> Title : Extended DNS Errors >> Authors : Warren Kumari >> Evan Hunt >> Roy Arends >> Wes Hardaker >> David C Lawrence >> Filename : draft-ietf-dnsop-extended-error-16.txt >> Pages : 15 >> Date : 2020-05-05 >> >> Abstract: >> This document defines an extensible method to return additional >> information about the cause of DNS errors. Though created primarily >> to extend SERVFAIL to provide additional information about the cause >> of DNS and DNSSEC failures, the Extended DNS Errors option defined in >> this document allows all response types to contain extended error >> information. Extended DNS Error information does not change the >> processing of RCODEs. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-16 >> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-extended-error-16 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-extended-error-16 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> DNSOP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
