Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt
Stephane Bortzmeyer <bortzmeyer@nic.fr> Thu, 14 February 2019 19:53 UTC
Return-Path: <stephane@sources.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 A030F131186 for <dnsop@ietfa.amsl.com>; Thu, 14 Feb 2019 11:53:11 -0800 (PST)
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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 CLqMzrHkGMJ6 for <dnsop@ietfa.amsl.com>; Thu, 14 Feb 2019 11:53:09 -0800 (PST)
Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fe27:3d3f]) (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 7E441131065 for <dnsop@ietf.org>; Thu, 14 Feb 2019 11:53:09 -0800 (PST)
Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id E53FFA07C9; Thu, 14 Feb 2019 20:53:06 +0100 (CET)
Received: by mail.sources.org (Postfix, from userid 1000) id C81FE190673; Thu, 14 Feb 2019 20:51:25 +0100 (CET)
Date: Thu, 14 Feb 2019 20:51:25 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: dnsop@ietf.org
Message-ID: <20190214195125.nwbazwpk3rgrgxkf@sources.org>
References: <154689301066.32204.17312124670782800354@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <154689301066.32204.17312124670782800354@ietfa.amsl.com>
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 9.6
X-Charlie: Je suis Charlie
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LWXQwhcelkYO8344QWZpjfjbVjY>
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: Thu, 14 Feb 2019 19:53:12 -0000
On Mon, Jan 07, 2019 at 12:30:10PM -0800, internet-drafts@ietf.org <internet-drafts@ietf.org> wrote a message of 44 lines which said: > Title : Extended DNS Errors > Authors : Warren Kumari > Evan Hunt > Roy Arends > Wes Hardaker > David C Lawrence > Filename : draft-ietf-dnsop-extended-error-04.txt Some remarks but before, note I think that it is very important that we have a way to report more detailed error causes. One of the biggest problems of DNSSEC is that there is no easy way for the resolver to report to the application about a DNSSEC problem. So, the work on this draft is essential. Now, the problems: 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. > Unless a protective transport mechanism (like TSIG [RFC2845] or TLS > [RFC8094]) Why 8094, which does not have even one implementation, instead of 7858? > 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? > 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. > 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). > 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. 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.
- [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