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:::::/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
