[DNSOP] draft-ietf-dnsop-7706bis-01 comments and Unbound example config
nusenu <nusenu-lists@riseup.net> Wed, 14 November 2018 12:47 UTC
Return-Path: <nusenu-lists@riseup.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 59656130DED for <dnsop@ietfa.amsl.com>; Wed, 14 Nov 2018 04:47:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net
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 wCE1H5nDRFFT for <dnsop@ietfa.amsl.com>; Wed, 14 Nov 2018 04:47:00 -0800 (PST)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8B6130E07 for <dnsop@ietf.org>; Wed, 14 Nov 2018 04:46:59 -0800 (PST)
Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id A94E61A04D4 for <dnsop@ietf.org>; Wed, 14 Nov 2018 04:46:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1542199618; bh=VEl4xjzWgOiTvHaXLPqdJVYBubBeY3acgZtPSt/YKKc=; h=From:To:Subject:Date:From; b=W1AmAq3J1KX57JzgWQ9IUUqwppXOWimpnYv77omsJSd41nA72e8KAdqHEkldbyAan 5iFTus3PiQnl96HzZ8gVryHOIuHRMkAlOb74dMMkI09MZ74YNkiJFPNpki3nnqLqdU 6lLibBYzsLE/HlgurnrNbqXN0cVgx4eIxu57ZdAQ=
X-Riseup-User-ID: E8E1F80DBE8DF0D2C7B13E04E9A048F5C2A9C5C3E9A1F634A643D0E08C6ACDB1
Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id 0A685103497 for <dnsop@ietf.org>; Wed, 14 Nov 2018 04:46:56 -0800 (PST)
From: nusenu <nusenu-lists@riseup.net>
To: dnsop@ietf.org
Openpgp: preference=signencrypt
Autocrypt: addr=nusenu-lists@riseup.net; prefer-encrypt=mutual; keydata= xsFNBFj53gUBEADYKwT0pW1yiqt6UReZW8T2nXVCyeVT2G6z7AvW69afp82uthRH237pQ7Qs 5vq91DivN6fGN6cVksp0N9Yv+5HEQAwUxpLfcNDcGzmHMd0JMItEtozGv3a4FuiUoHAqeGXM 6Kzi3v5F2PZGF+U4QaGKEZq6u50gO/ZFy4GfC9z9tsO6Cm7s7KldVHMGx/a0MEGMwh6ZI9x2 hGXSSAKu58KRUkEpHzDiQTj+/j58ndNfZRQv6P5BLppHADRPqwEOm4RQcQYskyM0FdKXbJ8E 5GW268meflfv2BASsl3X/Xqxp+LNrstXIbFZ+38hVlQDDmdvaASpPTzIAxf8FxMYZqI+K1UE kP5nU45q84KiZoXwT6YYJDKToLSDnYkKlsrCSnLkE3Nb/IexgNoYO4nE6lT9BDV3athQCWw1 FwB5idRYWnIqbVgUFgYZDUdZBJmeTEeI+Wn5hFz6HvFVc/+haMVTcoEKSkG/tsSGsKOc2mp6 z+71io9JWrVQGmw7OeZeE4TvkF9GhwS8jrKO4E0crfcT/zT6368PZCO6Wpir8+po/ZfOWbbh 1hi3MxmXn4Fki55Zrvhy3sf28U+H/nByQV4CssYv/xVhIZsN/wNQLcDLgVs4JTBUik8eQR0Y Qrq9lG3ZVtbpEi7ZTJ6BOGIn2TKHsVIVGSQA0PdKpKYV45Lc4QARAQABzSBudXNlbnUgPG51 c2VudS1saXN0c0ByaXNldXAubmV0PsLBfQQTAQgAJwUCWPneBQIbAwUJBaOagAULCQgHAgYV CAkKCwIEFgIDAQIeAQIXgAAKCRCtYTjCRc1Cfq/kD/sHx+mnL6OLwJvBj1rVTyoHJYJARajz Go0yRlbrZSH6Z05OD3SDR9UVpWOZeY8JyFoTyCFQjAbIVjKifj0uSmi0j1iahrAgGGfik0cN XUkCxrW6jcJQ37EbvYWu4PryqLuC7IeQW1wCcB1ioyGYKkm2K6LZ9rzZPVYSmPohJ+gVI0Jt EdlNZl4JuZot9eA5w/22uvcStQHzXDsUxfqK8OAJpU8E3iBBdNpLPMDWpFz4g2yw5PD6jZ+K Q39PYMUFULaKe4YCw1O+0MFhZJI4KEcRYHuVy1b3cJjxzgVfEyFctLDsO1sh07vBhoVKUi8W e00pvGtv8QYxxMYIA3iACbsjGEr69GvvZ2pAnu9vT9OUCaES4riDCxbkMxK/Cbwk8F6mo0eq HDQ7sOZWQv81ncdG9ovlA7Pj96cEXgdtbbllF1aUZ8sAmT14YjGzhArGv7kyJ1imH5tX3OXk hBGA9JTk2mDNjEpFaTEajSvDiKyeEhWNTLm15siWkpg1124yjUkhQ3OCkw7aUDMiVn8+DQHo J2pP/84uUvngbhm1jV7nk8mxTUFgppUePkb5hhnRRzeK72QY00EwRdn7qnpNgijMJ3Fpjfy2 EeCEl3nNdcB7U0F+0ijA6P/+DROldxNr4eiP50RvV8XiW/yi2IkKBk50GNB87yYnDETxxx/c 2i00AM7BTQRY+d4FARAAwJZ6U7UT8uB1WCfLK3AOR1Wa9bzOAghlTR4WXbHB4ajQKG7/Fzud 99bnwD0V3/AOVz/SbGDyHe+7HMvd1A0Ll4NgyH6OpxY7wOwCXAYTAbcXLpM7eKTjjsb9A9XG 3FcIGvjcy76OkaewqhiABaShlStEYcPkRusHZuecXtCnfCjJKihU/kinWpBO9gY6SrF2KFCw aeS4r37brXQ9y8uy3gZ168QFuIa5AKfL0r5YN3k4StNSA2p5Z/pufWXMN3B03QC+3fireiz3 dinlHK6XjUW8oWSdNxJhexT/lUw+episNuWTQruy7PD+HeohYGXqjggmPUiWc171Sewb2f8H CHViHMee8QXqo/LSRkYVrtsx0HUSMKsVQOma/u2By03ucroIkQJQQfqX3YpK1i3EpUO2L0/m E8UpBvUm1vrst54EFym4tYNJTj9reVffFKh2cczmPVN5o8v3RrdTF96mGtcb9EJbGV4277ZE LqUspviEBXynqU3yZ48JhIWHj22/ha6TeBpapYZDOJ8lePed8E34J/GYE2YXl65LhpXAKvWz O3KiByGMysb9Li6zqZ9/BYQtg5CA6Q8Oo7pBxK4iiDH3GX2WvymmLoaOBpOaIYdvKr39fajE mzfbg7TdZKXxqp2KDrbw7vUJLDyrmPWpxHyhKHItzoi1Y59wzYSq3h0AEQEAAcLBZQQYAQgA DwUCWPneBQIbDAUJBaOagAAKCRCtYTjCRc1CfpfgEAC3tXZzhgKbF6fx5gMNDp/9MBpialvu k69UaGL3HUqM0/ytiT4FjYUmOK2mk37iop46GivsOC50PykG9gjbg9/QKUqgsZzJ8LJ+ldY4 /GKtiP5JoO59Obj8MJJ5Ta8yPfZiiNx/I8ydqd18E4PmQUCPlEKhett81t3+8R/mGwG72TaA hHwDjZAEjiXdnXh+z0AKpflCnYQafq0V73ofzuw4KovpJWMk/WPs5oSHhuV4TZ8nRkF6BR4y rEvs1kq8Y6DuNqQGwY3yilpnmqfMzzlWo7MlY657domU54bhGOsvNuZZsFDlcBczQo6h9OKq ckkVHUMAw38pX+EghzEfhYVWYmLNv5G9TA/M2s3frO3aN7ukNDq7CKIwfVz71/VfPaLQMY7/ jirzp9yIBZEi4E+PwP38FAGiD+nxzuUJv1rvxf6koqUGoHRvdppju2JLrC2nKW0La7RX7uZJ esCVkamT/XaXPROBTrZZqwbIXh2uSMzgXkC2mE1dsBf2rdsJ4y73+0DYq7YE52OV9MNoCYLH vpkapmD00svsP4sskRsrquPHkBBVCJa22lTaS8Oow9hGQe7BDjEhsVoPol889F0mbTRb3klv mGQ6/B/HA0pGWR9wISY8a7D40/qz6eE6+Yg22mtN1T8FFlNbyVmtBj0R/2HfJYhGBElLPefH jhF0TA==
Message-ID: <3d31dd2e-c744-261a-3a1e-edde55d6159a@riseup.net>
Date: Wed, 14 Nov 2018 12:46:00 +0000
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="guizbFHHtVl8Un3iUevUufOySCWaom4M3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2lp4TTS59RxkgEuN80VQrUPl9C8>
Subject: [DNSOP] draft-ietf-dnsop-7706bis-01 comments and Unbound example config
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: Wed, 14 Nov 2018 12:47:04 -0000
Hi Paul and DNSOP WG, thanks for working on this. comments inline: > It is important to note that the design described in this document is > controversial. Is it still considered "controversial" to mirror the root zone locally given that some big operators do this in practice or is this a rudiment from RFC7706? from this part in your presentation I hoped that RFC7706bis will have less of "please don't do this" compared to RFC7706: https://www.youtube.com/watch?v=g0Sz7gziUW0&feature=youtu.be&t=3972 > This design requires the addition of authoritative name server > software running on the same machine as the recursive resolver. In practice it is not "required" to run additional software anymore, right? (at least not for all software/versions) Since some resolvers included the functionality directly without the need to install and run additional software. > many people feel that it is an excessively risky > practice because it introduces a new operational piece to local DNS > operations where there was not one before. Is it still the case that many people feel it is "excessively risky" when all of it is implemented without additional software packages/daemons and an automatic fallback is implemented? > A different approach to solving the problems discussed in this > document is described in [RFC8198]. As you outlined in your answer to Tony Finch during the IETF103 DNSOP meeting [0] RFC8198 (Aggressive Use of DNSSEC-Validated Cache) doesn't solve the same thing (or at least not to the same extend), right? [0] https://www.youtube.com/watch?v=g0Sz7gziUW0&feature=youtu.be&t=4926 > [ Add examples of other resolvers such as Knot Resolver just putting this pointer here: [1] https://knot-resolver.readthedocs.io/en/stable/modules.html#root-on-loopback-rfc-7706 > [ Make the use cases explicit. Be clearer that a real use case is > folks who are worried that root server unavailabilty due to DDoS > against them is a reason some people would use the mechanisms here. > ] Latency and (un)observability also mentioned in RFC7706 and the current version are also real use cases. Reducing the load on root servers is another use-case, also mentioned by Wes during the meeting: https://www.youtube.com/watch?v=g0Sz7gziUW0&feature=youtu.be&t=4567 > Note that using this simplistic configuration will cause the > recursive resolver to fail if the local root zone server fails. A > more robust configuration would cause the resolver to start using the > normal remote root servers when the local root server fails (such as > if it does not respond or gives SERVFAIL responses). Will the RFC7706bis document still contain the 'simplistic' config/approach or only aim for the more robust one (requiring to have at least a fallback)? > Currently, the root can also be retrieved by AXFR over TCP from the > following root server operators: > > o b.root-servers.net > o c.root-servers.net > o f.root-servers.net > o g.root-servers.net > o k.root-servers.net d.root-servers.net can be added to this list (and to the config examples) as it specifically supports AXFR for RFC7706: > D-Root supports AXFR over TCP queries of the root zone in support of RFC7706. (from http://www.droot.maxgigapop.net/) > B.2. Example Configuration: Unbound 1.8 I was about to submit a github pull request with an Unbound config, but it is probably easier reviewed and challenged when send to this list directly: auth-zone: name: "." master: "b.root-servers.net master: "c.root-servers.net master: "d.root-servers.net master: "f.root-servers.net master: "g.root-servers.net master: "k.root-servers.net fallback-enabled: yes for-downstream: no for-upstream: yes zonefile: "root.zone" The above Unbound config is just one way to do it (originally found on the unbound-users list), another way would be to tell Unbound to fetch the root zone via http/https using: 'url' + 'tls-cert-bundle' similar to the config example in the above knot-resolver example [1]. you can also list master: and url: for the same zone for even more sources. https://www.internic.net/domain/root.zone https://nlnetlabs.nl/documentation/unbound/unbound.conf/ In practice it felt a bit as if not too many Unbound users are actually using such a RFC7706-style config (probably due to the missing documentation) since it seamed that I was the only one hitting (or reporting) Unbound bugs specific to such a config [2]. Looking forward to hear from more RFC7706 Unbound users. [2] https://nlnetlabs.nl/pipermail/unbound-users/2018-July/010736.html > B.3. Example Configuration: Unbound 1.4 and NSD 4 > > [ Do we still want this section? If so, maybe use Know without > cache-prefilling. ]] I believe it is fine to delete that section since Unbound 1.4 is from 2014. kind regards, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu