Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt
Wes Hardaker <wjhns1@hardakers.net> Mon, 11 March 2019 22:13 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 E4DFF128664 for <dnsop@ietfa.amsl.com>; Mon, 11 Mar 2019 15:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EBDF-Xchn9eN for <dnsop@ietfa.amsl.com>; Mon, 11 Mar 2019 15:13:38 -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 9933F1279B1 for <dnsop@ietf.org>; Mon, 11 Mar 2019 15:13:38 -0700 (PDT)
Received: from localhost (pc5.it-anacpk1-unet.ocn.ne.jp [153.150.27.29]) by mail.hardakers.net (Postfix) with ESMTPA id CB1CF232C1; Mon, 11 Mar 2019 15:13:29 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Cc: dnsop@ietf.org
References: <154689301066.32204.17312124670782800354@ietfa.amsl.com> <20190214195125.nwbazwpk3rgrgxkf@sources.org> <20190215090946.y4emnzo2mxa5dxe7@nic.fr>
Date: Mon, 11 Mar 2019 15:13:28 -0700
In-Reply-To: <20190215090946.y4emnzo2mxa5dxe7@nic.fr> (Stephane Bortzmeyer's message of "Fri, 15 Feb 2019 10:09:46 +0100")
Message-ID: <ybllg1l6ovr.fsf@wu.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GCv90tyTD6dTCKVqA6W2r8CrSvU>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.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: Mon, 11 Mar 2019 22:13:41 -0000
Hi Stephane, Thanks for your great review (and support of the draft). We've made a number of changes based on your suggestions, and I'm including a more detailed accounting below of steps taken based on your review. Sorry for the delay in getting a response back to you. 6 Stephane Bortzmeyer ===================== Now, the problems: 6.1 DONE It seems to me that this draft is mostly for resolvers, most planned ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ extended codes are useless for authoritative servers (except may be REFUSED/Lame?). I suggest to make that clear in the introduction: These extended error codes are specially useful for resolvers, to return to stub resolvers or to downstream resolvers. Authoritative servers MAY use them but most error codes would make no sense for them. + Warren agrees + Results: added, but modified to distinguish that you're really referring to receiving codes, not sending them (auth servers may need to send them, eg the block/prohibited one) 6.2 DONE ref issue ~~~~~~~~~~~~~~~~~~ > Unless a protective transport mechanism (like TSIG [RFC2845] or TLS > [RFC8094]) Why 8094, which does not have even one implementation, instead of 7858? + warren: oversight + results: added 7858 6.3 DONE sig expired ~~~~~~~~~~~~~~~~~~~~ > 4.2.3. SERVFAIL Extended DNS Error Code 3 - Signature Expired The >resolver attempted to perform DNSSEC validation, but the signature >was expired. I suggest to replace "the signature was expired" by "a signature in the validation chain was expired". Rationale: which signature? What if a DS at the parent is sign with an expired signature? + Warren: LTGM + Results: done 6.4 DONE dnskey missing text ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 4.2.5. SERVFAIL Extended DNS Error Code 5 - DNSKEY missing A DS >record existed at a parent, but no DNSKEY record could be found for >the child. I suggest to replace "no DNSKEY record could be found for the child" by "no DNSKEY record for this specific key could be found for the child". Rationale : the current text seems to imply this code is only when there is no DNSKEY at all. + Warren: LTGM + Brian disagrees + Michael Sheldon also disagrees and suggests "No supported matching DNSKEY record could be found for the child" + Result: took Michael's text 6.5 DONE blocked ~~~~~~~~~~~~~~~~ > 4.4.1. NXDOMAIN Extended DNS Error Code 1 - Blocked The resolver >attempted to perfom a DNS query but the domain is blacklisted due to >a security policy. The R flag should not be set. The last sentence is touchy. If a stub is configured with two resolvers, and one is fast but known for lying in some cases that you disagree with, you may ask a cookie from the other parent (no, resolver). + Warren agrees the bit should be flipped. + Result: flipped 6.6 DONE blocked 2 ~~~~~~~~~~~~~~~~~~ > 4.4.1. NXDOMAIN Extended DNS Error Code 1 - Blocked The resolver >attempted to perfom a DNS query but the domain is blacklisted due to >a security policy. I tend to think it would be a good idea to separate the case where the policy was decided by the resolver and the case where the policy came from outside, typically from the local law (see RFC 7725 for a similar case with HTTP). Rationale: in the first case (local policy of the resolver), the user may be interested in talking with the resolver admin if he or she disagrees with the blocking. In the second case, this would be useless. + Stephane adds: I really think it is important to make the difference between: * I blocked your request because that's _my_ policy * I blocked your request because I'm compelled to do so, don't complain, it would be useless. + Jim Reed: why? from the client's perspective no diff + Stephane: cause it indicates if you should call someone or you can't affect change + Result: Seems like rough concensus to add, so i did. 6.7 DONE forged answer ~~~~~~~~~~~~~~~~~~~~~~ Otherwise, I suggest to add an error code: NOERROR Extended DNS Error Code 3 - Forged answer For policy reasons (legal obligation, or malware filtering, for instance), an answer was forged. The R flag should not be set. Rationale: there is "NXDOMAIN Extended DNS Error Code 1 - Blocked" but policy-aware resolvers (lying resolvers, in plain english) do not always forge NXDOMAIN, they can also forge A or AAAA answers. See also the issue just before, about the need to differentiate resolver policy from "upper" policy, law, for instance. + Warren doesn't like forgged and wants a better word + Stephane: "substituded answer" maybe? + Result: took forged as I don't like any suggested replacement yet 6.8 DONE new code for no reachable authorities ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ooops, I forgot one: SERVFAIL Extended DNS Error Code 8 - No reachable authority The resolver could not reach any of the authoritative name servers (or they refused to reply). The R flag should be set. Rationale: in draft -04, all SERVFAIL extended error codes are for DNSSEC issues. In my experience, SERVFAIL happens also (and quite often) for routing issues (most zones have all their authoritative name servers in only one AS, sometimes even one prefix or, worse, one rack). We set the R flag because another resolver may not have the same routing issues, BGP not being consistent between all sites. True, an extended error code could be added after the RFC is published, through "Specification required" but 1) it is easier to do it now 2) it gives to the people who will implement the RFC a wider view of the possible uses. + Result: added -- Wes Hardaker USC/ISI
- [DNSOP] I-D Action: draft-ietf-dnsop-extended-err… internet-drafts
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended… Wes Hardaker
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended… Petr Špaček
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended… Stephane Bortzmeyer
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended… Stephane Bortzmeyer
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended… Michael J. Sheldon
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended… Warren Kumari
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended… Brian Dickson
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended… Stephane Bortzmeyer
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended… Stephane Bortzmeyer
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended… Jim Reid
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended… Stephane Bortzmeyer
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended… Petr Špaček
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended… Dick Franks
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended… Wes Hardaker
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended… Wes Hardaker
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended… Wes Hardaker