Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-extended-error
Shane Kerr <shane@time-travellers.org> Thu, 25 October 2018 20:11 UTC
Return-Path: <shane@time-travellers.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 26A82130EC0 for <dnsop@ietfa.amsl.com>; Thu, 25 Oct 2018 13:11:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 bs3X76qmq5i8 for <dnsop@ietfa.amsl.com>; Thu, 25 Oct 2018 13:11:07 -0700 (PDT)
Received: from time-travellers.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D13C130EE0 for <dnsop@ietf.org>; Thu, 25 Oct 2018 13:11:05 -0700 (PDT)
Received: from [2001:470:78c8:2:511f:b040:e564:d9d1] by time-travellers.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <shane@time-travellers.org>) id 1gFlyK-000393-Rb for dnsop@ietf.org; Thu, 25 Oct 2018 20:11:12 +0000
To: dnsop@ietf.org
References: <CADyWQ+EuNCPLQrG7YWb1-MOhQvqXvtq5i1FsRAW+hmLBHs06-A@mail.gmail.com> <CAKr6gn3RCR__ChfB9A4cckaWPfX9nb6=v1iEr9-4q0JpYhFCiw@mail.gmail.com>
From: Shane Kerr <shane@time-travellers.org>
Message-ID: <5ed325d8-ffd2-961c-abca-86b993cef352@time-travellers.org>
Date: Thu, 25 Oct 2018 22:11:02 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <CAKr6gn3RCR__ChfB9A4cckaWPfX9nb6=v1iEr9-4q0JpYhFCiw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DTkY9-xsl5l14I_F7OSrnY8UffQ>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-extended-error
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, 25 Oct 2018 20:11:09 -0000
Dear DNS colleagues, I definitely agree with George that last call seems a bit premature. As he points out, section 6 is a large open question. We need to either change EDNS behavior to allow an unsolicited EDNS option in a response or change this draft to include an appropriate EDNS option when it queries. Personally I think the draft should specify that the query should include an empty version of this EDNS option to indicate support (this is actually helpful, as it doesn't make too much sense sending back extra information that clients will ignore, decades of BIND adding useless ADDITIONAL section data notwithstanding). Plus there's also this odd bit of stray text laying around: Here is a reference to an "external" (non-RFC / draft) thing: ([IANA.AS_Numbers]). And this is a link to an ID:[I-D.ietf-sidr-iana-objects]. Also is this correct: o OPTION-LENGTH, 2 octets ((defined in [RFC6891]) contains the length of the payload (everything after OPTION-LENGTH) in octets and should be 4. If I am correct there are at least 6 octets after the OPTION-LENGTH and possibly more if EXTRA-TEXT is present. Also, this text seems a bit unclear: R - Retry The R (or Retry) flag provides a hint to the receiver that it should retry the query, probably by querying another server. If the R bit is set (1), the sender believes that retrying the query may provide a successful answer next time; if the R bit is clear (0), the sender believes that it should not ask another server. The "probably by querying another server" is odd. In my mind it should explicitly apply to querying another server ONLY. The draft refers to EXTRA-TEXT twice, and EXTRA-INFO once which is presumably meant to be the same thing. In any case, I think the encoding of this field should be specified as either ASCII or UTF-8. I prefer UTF-8, because otherwise I won't be able to send back 🤯 emoji in error messages (and the authors won't be able to use the 🍄 emoji that they clearly want). I am not sure I agree with these recommendations: 4.1.5. Extended DNS Error Code 5 - Unsupported DNSKEY Algorithm The resolver attempted to perform DNSSEC validation, but a DNSKEY RRSET contained only unknown algorithms. The R flag should not be set. 4.1.6. Extended DNS Error Code 6 - Unsupported DS Algorithm The resolver attempted to perform DNSSEC validation, but a DS RRSET contained only unknown algorithms. The R flag should not be set. This seems like a case where a stub resolver may want to try another full-service resolver that may support more algorithms, so perhaps the text "The R flag should not be set" should be removed. While the draft suggests that it is possible to add multiple EDE to a message: o RESPONSE-CODE, 2 octets: this SHOULD be a copy of the RCODE from the primary DNS packet. When including multiple extended error EDNS0 records in a response in order to provide additional error information, the RESPONSE-CODE MAY be a different RCODE. It is not explicit about how this is done. If the intention is for a resolver to forward this back to a stub resolver, then it needs to be mentioned, probably in section 3, something like this. However, then we also need some text describing how a client behaves when presented with multiple EDE. Finally, do we have any implementations of this draft? It seems pretty straightforward, but I don't actually think that it's possible to develop interoperable code with the draft as it stands today. I vaguely recall that we wanted running code going forward to try to starve the DNS camel... Cheers, -- Shane On 25/10/2018 00.30, George Michaelson wrote: > How can it go WGLC with section 6 an open question? > > in every other respect I like the document. Bad Hair and all. > > I would like to understand if we could work out a way to do traceroute > in the codes, with some defined code to ask the DNS resolver to > perform a TTL drop on a counter and mark itself into the chain, which > would help uncover resolver chains. > > With IANA registry requests, I may be wrong here, but I thought we had > some (boilerplate?) language about how IANA is asked to operate the > registry: what criteria judge acceptance. Is it like the OID and > basically open (hair oil) slather, or is it only at WG RFC documented > request? > > -G > > On Wed, Oct 24, 2018 at 4:42 PM Tim Wicinski <tjw.ietf@gmail.com> wrote: >> >> >> Hi >> >> We've been talking with the authors of Extended Error and now that >> they've gotten around to updating the document, and the chairs >> feel it is ready for Working Group Last Call. >> >> We're going to kick this WGLC off this week and run it through IETF103. >> This will give folks time during the meeting to bring up any issues >> they may have there. >> >> >> This starts a Working Group Last Call for draft-ietf-dnsop-extended-error >> >> Current versions of the draft is available here: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ >> >> >> The Current Intended Status of this document is: Standards Track >> >> Please review the draft and offer relevant comments. >> If this does not seem appropriate please speak out. >> If someone feels the document is *not* ready for publication, >> please speak out with your reasons. >> >> This starts a two+ week Working Group Last Call process, >> and ends on at the end of IETF 103: 9 November 2018 >> >> thanks >> tim >> >> _______________________________________________ >> 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 >
- [DNSOP] Working Group Last Call for draft-ietf-dn… Tim Wicinski
- Re: [DNSOP] Working Group Last Call for draft-iet… George Michaelson
- Re: [DNSOP] Working Group Last Call for draft-iet… Shane Kerr
- Re: [DNSOP] Working Group Last Call for draft-iet… Wes Hardaker
- Re: [DNSOP] Working Group Last Call for draft-iet… Joe Abley
- Re: [DNSOP] Working Group Last Call for draft-iet… Ray Bellis
- Re: [DNSOP] Working Group Last Call for draft-iet… Paul Vixie
- Re: [DNSOP] Working Group Last Call for draft-iet… Petr Špaček
- Re: [DNSOP] Working Group Last Call for draft-iet… Donald Eastlake