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

[Mark Andrews <[e-mail]>]

> 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.

> 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]              INTERNET: [e-mail]