Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-16.txt

[Puneet Sood <[e-mail]>]

On Thu, May 14, 2020 at 2:09 AM Mark Andrews <[e-mail]> wrote:

>
>
> > On 14 May 2020, at 15:48, Puneet Sood <puneets=
> [e-mail]> 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.
>

Thanks for clarifying this. Makes the resolver response logic much simpler.
I had incorrectly remembered that the client had to specify this option in
the request.

-Puneet


> > 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 <[e-mail]> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dnsop
> >
> > _______________________________________________
> > DNSOP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dnsop
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone] <+61%202%209871%204742>              INTERNET:
> [e-mail]
>
>