Subject: [DNSOP] draft-ietf-dnsop-7706bis-01 comments and Unbound example config

From: nusenu <[email-masked]>
Date: Wed, 14 Nov 2018 12:46:00 +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

---

From: nusenu <[email-masked]>
Date: Wed, 14 Nov 2018 13:01:00 +0000

> 	master: "k.root-servers.net

the above lost the closing quotes, correction:

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"