[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