Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CA+9_gVtG9bxoj3czW7wgcHoRq7e8B3VyoKd+5-Ba4wbZ_LDFuA@mail.gmail.com>
Date: Thu, 14 May 2020 16:09:34 +1000
Cc: IETF DNSOP WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <98FA896F-5034-40CE-8B25-15DA230FBBB8@isc.org>
References: <158871188730.7528.4018207019268407373@ietfa.amsl.com>
 <CA+9_gVtG9bxoj3czW7wgcHoRq7e8B3VyoKd+5-Ba4wbZ_LDFuA@mail.gmail.com>
To: Puneet Sood <puneets=40google.com@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/SJUIdHMAPMbMcl2J1A7DdTzpMNQ>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-16.txt
Precedence: list



> On 14 May 2020, at 15:48, Puneet Sood =
<puneets=3D40google.com@dmarc.ietf.org> wrote:
>=20
> Google Public DNS is planning to implement this draft in responses
> from us (recursive resolver) to clients.
>=20
> *** Question: When can we expect to have an EDNS option code assigned
> for the EDE option?

It=E2=80=99s 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"
>=20
> 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.
>=20
> 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.
>=20
> Thanks,
> Puneet
>=20
>=20
> On Tue, May 5, 2020 at 4:52 PM <internet-drafts@ietf.org> wrote:
>>=20
>>=20
>> 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.
>>=20
>>        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
>>=20
>> 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.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/
>>=20
>> 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
>>=20
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-extended-error-16
>>=20
>>=20
>> 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.
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>>=20
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>=20
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

--=20
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org