Call me a contrarian, but I've never really signed onto the conventional wisdom that recursive and authoritative roles should never be mixed, even as I've transitioned into the InfoSec realm, where, generally speaking, we are quite wary of mixing roles within a single service (more software complexity leads to higher probability of defects, a bigger attack surface, and so on).
Other than the master server(s), where there is no choice but to be authoritative, at one end of the spectrum, and border resolvers, for which there is no choice but to be non-authoritative (since it's not practical to replicate data for the vast diversity of namespaces on the Internet in which to resolve queries), at the other end of the spectrum, there is a middle ground, where there is a real *choice* as to whether to be authoritative (i.e. a slave, possibly a "stealth slave") for internal zones or not. The decision of whether to be authoritative or not, is driven by a number of factors, such as worst-case-query-performance sensitivity, availability requirements, query-frequency-versus-refresh-overhead, available bandwidth, DNSSEC, etc. It is perfectly reasonable, architecturally, for a given DNS instance to be a stealth slave for some zones and to either delegate, stub and/or forward for other zones, or for the default to be one or the other (auth-server as default implies having an internal root). Different zones have different requirements, different use cases, query patterns, etc. so why wouldn't a choice of different configurations for different zones be appropriate? Now, as a matter of *implementation*, it might be useful, and arguably more secure, for these -- auth-server versus resolver -- to be separate software modules. But the modules should be able to co-exist on the same listener. Whether a given request gets dispatched to a different process or thread, depending on whether it is to be satisfied from authoritative data, or if iterative resolution (or forwarding) is required, is, again, a matter of implementation. But the choice to mix authoritative and non-authoritative on the same listener, should IMO remain available. Otherwise, you're forcing inappropriate choices on people -- e.g. slaving when it isn't really needed and could be considered overkill, or iterative/recursive resolution where slaving would be preferable from a performance, availability or other perspective. As for BIND 10, it looks pretty dead, to me. According to ISC's website, they concluded work on it, including an authoritative server module, and handed it off to the Open Source community, where it became "Bundy". But http://bundy-dns.de/ doesn't seem to have been updated since 2014. So, I wouldn't hold my breath on a full-featured BIND 10 or "Bundy" DNS implementation any time soon... - Kevin -----Original Message----- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mark Elkins Sent: Tuesday, February 20, 2018 2:58 AM To: bind-users@lists.isc.org Subject: Re: questions on allow-query Reading between the lines - it sounds like you may be mixing nameserver roles, recursion with authoritative. This is not a good idea and is why other Nameserver software (NSD, UNBOUND and others) either perform one role or the other. I understand that BIND-10 was also designed like this - separate software modules for the two separate roles. Then your "access list" is simple. Recursive: Starts with knowing next to nothing, can be asked for anything and serves a restrictive population acl "trusted" { 127.0.0.0/8; ::1/128; 192.X.X.0/24; 2001:hhhh:hhhh:hhhh::/48; }; allow-query { trusted; }; allow-recursion { trusted; }; Authoritative: Starts with knowing everything about just a few Domains, can only be asked about what it knows and serves the World. allow-query { any; }; allow-recursion { none; }; You'll otherwise find that things like DNSSEC don't work as expected. On 20/02/2018 00:51, @lbutlr wrote: > If I set > > allow-query { 127.0.0.1; [myipblock]; } > > Then my DNS doesn't respond to any other servers, right? This would be bad > for being authoritative. so, should I set that and then set allow-query { > any; }; in each zone? > > Is that better than simply setting the IPs that are allowed recursion? > > > > _______________________________________________ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark James ELKINS - Posix Systems - (South) Africa m...@posix.co.za Tel: +27.128070590 Cell: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
