[DNSOP] changes to extended errors based on your comments
Wes Hardaker <wjhns1@hardakers.net> Sat, 10 August 2019 05:30 UTC
Return-Path: <wjhns1@hardakers.net>
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 80CB11200CD for <dnsop@ietfa.amsl.com>; Fri, 9 Aug 2019 22:30:17 -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_HELO_NONE=0.001, SPF_PASS=-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 RpESZJpoFIgu for <dnsop@ietfa.amsl.com>; Fri, 9 Aug 2019 22:30:15 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF031200E5 for <dnsop@ietf.org>; Fri, 9 Aug 2019 22:30:15 -0700 (PDT)
Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id BDA532AFC5; Fri, 9 Aug 2019 22:30:14 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: dnsop@ietf.org, Ralph Dolmans <ralph@nlnetlabs.nl>
Date: Fri, 09 Aug 2019 22:30:14 -0700
Message-ID: <ybl7e7lio49.fsf@w7.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EpB6VnL7RbP15_7e-bHX7Ohg0uM>
Subject: [DNSOP] changes to extended errors based on your comments
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: Sat, 10 Aug 2019 05:30:17 -0000
Thanks for your feedback about the extended errors draft. Below are responses to some of your previously raised points in email to dnsop: 8.4 Ralph Dolmans ~~~~~~~~~~~~~~~~~ I made an Extended DNS Errors implementation in Unbound during the IETF104 hackathon. Implementing the code that handles the errors was rather straightforward, the difficult part is (as Stéphane already pointed out) finding the right locations in the code for the individual errors. Some remarks regarding the draft: 8.4.1 NOCHANGE Since it is possible to have multiple extended error options, is it ---------------------------------------------------------------------------------- expected to return all errors that match the result, or only the most specific one? For example: if a DNSSEC signatures is expired should both the "DNSSEC bogus" (SERVFAIL/Extended error 1) and the "Signature expired" (SERVFAIL/Extended error 2) be returned? + Response: I'd return what seems to be the most appropriate set, given the situation. I think both of the above seem to apply so the question is, would it be confusing to ever return "too much". I'm not sure we want to over-specify and implementations should be free to pick what debugging/info-codes they think is best to return. IMHO, personally, I think sig expired is sufficient because it implies the BOGUS code already. 8.4.2 DONE I am not sure whether linking the info code to the rcode is a good idea. ----------------------------------------------------------------------------------- Some info codes can happen for different rcodes. It is in Unbound for example possible to block a domain by sending a REFUSED rcode, while the document list blocking only for the NXDOMAIN rcode. If the rcode/info-code coupling will remain then I would like to have the same info code for a specific error under different rcodes, for example always use info-code 1 for blocking. + Response: Per discussion at IETF105, the linking is now dropped. 8.4.3 NOCHANGE Since EDNS is hop-by-hop, only error information from the resolver you ------------------------------------------------------------------------------------- are talking to is returned. There are cases when the interesting information is not in the first resolver. For example: if a resolver forwards queries to another one and the last one does DNSSEC validation then the resolver you are talking to does not generate the interesting information. Is it maybe an idea to add some text stating that extended error-aware resolvers should forward the received EDNS option? + We sort of discussed this at one point in various venues (both physical and electronic). I think the resolution was "lets leave that for an update once we get more experience". I think picking when to forward and when it's meant "just for you" becomes complex and harder to specify. 8.4.4 DONE I think having the extra information provided by this document is useful ----------------------------------------------------------------------------------- for debugging, and only for that. This extra information should not be used to make any DNS resolving decision, which makes the retry flag a bad idea. At the moment I don't have to trust all my secondaries as long as my zone is DNSSEC signed. The worst thing they can do is not return my data or tamper with it, in which case the validating resolver will ignore it and try another nameserver. Giving a nameserver the power to instruct a resolver to not try at another nameserver gives them the power to make my zone unavailable. This completely changes the current trust model. Please remove the retry flag from the document. + The R bit has been removed in the latest flag, due to your and other people's requests :-) -- Wes Hardaker USC/ISI
- [DNSOP] changes to extended errors based on your … Wes Hardaker