[DNSOP] Extended DNS Errors (implementation) feedback

Ralph Dolmans <ralph@nlnetlabs.nl> Tue, 26 March 2019 09:46 UTC

Return-Path: <ralph@nlnetlabs.nl>
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 4E09812029B for <dnsop@ietfa.amsl.com>; Tue, 26 Mar 2019 02:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
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 FKDfeG2XU5nT for <dnsop@ietfa.amsl.com>; Tue, 26 Mar 2019 02:46:35 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 454CB1202A2 for <dnsop@ietf.org>; Tue, 26 Mar 2019 02:46:35 -0700 (PDT)
Received: from [192.168.43.148] (unknown [188.206.65.238]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id C7D7F15F79 for <dnsop@ietf.org>; Tue, 26 Mar 2019 10:46:32 +0100 (CET)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=ralph@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1553593592; bh=7Y5HOMCIIlggPnXRRjlYA+Tpywv6xJgYHSwvFN206oQ=; h=From:Subject:To:Date; b=AIYFE+iYk3ikb6oqm17soG/rRhkEnwsm9aPAuqUxwv645lFqvt+p0XEt05YCi07oT dWobFPGPIZprS637c14+MNYlOQHJtS05RkziygMvKYfY4/LYzrzMuiTGTa5o/3Nc4b NVlC7SH5T68qLjMuLYRjrBF+UxCSyakei8TjLmcs=
From: Ralph Dolmans <ralph@nlnetlabs.nl>
Openpgp: preference=signencrypt
Autocrypt: addr=ralph@nlnetlabs.nl; prefer-encrypt=mutual; keydata= mQENBFLLw3QBCADwSt/VWovpRdtSFdwCW+/4ZaFEtIPAKgID42dzNOU+57LP3xuHiEeXZ0Ln hJRNmW4g5+01Fq4+bTeRyfL7MauIpumSqpnCpq5RZYDI8QqZftYnmm8XdjOjNLJXX3nfD0Tc 1YD2psNHLR9YOT0WfiPGPuN8uTzE/EcFHuMgrWx4kdWQGO2EBOu1Ss1ejvK6xs5AIn209mWY CPZ1FA24AgvnOPPYH2i9Fx+MMoj3Aun/nJbnp7B/4kKQvCDBJNyDYxFdgfjT0lkM5bSa7PJq AkXB/HYCJnfw9+MLbkoozdMs9ddg9YaqwSDWe60pBgkRnvd4+69OgZJvSYxky4XYMNdJABEB AAG0IlJhbHBoIERvbG1hbnMgPHJhbHBoQG5sbmV0bGFicy5ubD6JAVUEEwECAD8CGyMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAFiEEIWFafyR46own3Sa4MJGNgnVyQiIFAlwOkIUFCRKo zpEACgkQMJGNgnVyQiK1lQgArOpDYzWsCX9YpBNZMkr5KNZOFhPXULRlaw++XiBA1leYij2y BpU22bL3gpDiu2LuF5fFYeLm1Xf0g/K7GmfQ6gVffJf/a2QQmv11i9LODfzX00IFjppYekcv mU9HYa5r5n8fC1Sq/rsFcSHGSUyv2Kpz5LEUdwDYgRntBSG2pUlxIsHpPr8WcEyRAOgZ7GjE 0H84Q860OzS3trq9+9mChWovfOyeE/pCiEC5oqWKL++cnMh9tdKJcDaRNuuC4Eal+fZxr0/G o6AeSRk4lYype5fydZrpgvWSMhuNzzrByc7fz7qd6OyM4NqpzRPnzKD976nwrm8fv+F783GN vQeik7kBDQRSy8N0AQgA4VaLFk/Cee30CqVKEGcCOuRWVjFwSVX4rfmv7v7IXIj+KQqXhv8y wOLYNdFTN/wEp6B4jysl84MxnYiUpOErJN/AjyFvoJV9CGTFZNWy6D4sSbppcqIRlHAt+G+p qnIQPFA1BmYq8DFo/C0dvKgGe0wyNh2zxBIJpav64lXC7byittD4NGe8Bd4HcSIZyUBnxoL0 KSPOHTFvAiBe/qJJEExfxKYUQO2KXbgA+1Z/wpEb1Vqyy7VETTu4QKBBPnVWuvLA+cKYkbUm U2v1n/w9WSoVE0NXR9aDIesRe6xLkmdp8415chddP3WPh9J34N5C8W+AslIXbMo1E/tPnxzK MQARAQABiQE8BBgBAgAmAhsMFiEEIWFafyR46own3Sa4MJGNgnVyQiIFAlwOkIkFCRKozpUA CgkQMJGNgnVyQiLEfAf+NVeSoJe+0Kdz0oBHFv7BA0llQeTbE7Po92yn7WXi6imTanvR6Nug wr8+Lj21SVE20wFvtoFnfnSLRT8ZV2Vtw3s6EufHi8Ho8BM66IIBcLX18ZgPGF44FXISCnGA 7N9WGIjCwymA4FDBhtH2qcPBAgzbCXy2icyuTFCycJfPDbdxiBZPP31fNTYDqhVRKzMhFK4z 2fmyzRRhLklVOQ/MwUVqdLqbXphQsLq0CwOhDmVyXqneupYXKju20YCIie8DvA+MW87QZAcy Obp3zKBn162XKEg+LRVRsM406Sj1e9ClV0Gqqzqxt4ynJ2Rs88rfcJFvhBWMB/MuRLWwBTPY xA==
To: dnsop@ietf.org
Message-ID: <288f0bd5-1306-3e09-435f-74d4172ab4b1@nlnetlabs.nl>
Date: Tue, 26 Mar 2019 10:46:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/AWTfCaeIxNwsqFvqQpZqT6b7UZQ>
Subject: [DNSOP] Extended DNS Errors (implementation) feedback
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: Tue, 26 Mar 2019 09:46:37 -0000

Hi all,

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:

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?

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.

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?

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.

-- Ralph