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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
