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

Mark Andrews <marka@isc.org> Thu, 14 May 2020 06:09 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4763A0BAB for <dnsop@ietfa.amsl.com>; Wed, 13 May 2020 23:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tK4rLHMKaOMm for <dnsop@ietfa.amsl.com>; Wed, 13 May 2020 23:09:41 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E393A0BA5 for <dnsop@ietf.org>; Wed, 13 May 2020 23:09:41 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 49FF93AB005; Thu, 14 May 2020 06:09:41 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3DA6E160042; Thu, 14 May 2020 06:09:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 29503160066; Thu, 14 May 2020 06:09:41 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id S20H4NW6PX2J; Thu, 14 May 2020 06:09:41 +0000 (UTC)
Received: from [172.30.42.99] (unknown [49.2.101.160]) by zmx1.isc.org (Postfix) with ESMTPSA id 59700160042; Thu, 14 May 2020 06:09:40 +0000 (UTC)
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>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/SJUIdHMAPMbMcl2J1A7DdTzpMNQ>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-16.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2020 06:09:44 -0000


> On 14 May 2020, at 15:48, Puneet Sood <puneets=40google.com@dmarc.ietf.org> 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 <internet-drafts@ietf.org> 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
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org