About query response on a view

[Mark Andrews]

In message <1449745839.4651.50.camel at posix.co.za>, Mark Elkins writes:
>
> On Thu, 2015-12-10 at 08:53 +0000, Okan Bostan wrote:
> > Hi,
> > Firstly thanks for all the responses, giving more details about our
> > config:
> >
> > Internal view: Internal DNS service for the internal clients. Accepts
> > requests from internal IP, Recursion is on, forwarding the out of zone
> > queries to our cache-only DNS servers. Also serves some zone
> > information.
> > External view: Authoritative DNS service for our domain.  Accepts
> > requests from external IP, No recursion,
> >
> > Also we will consider to separate the recursive and authoritative
> > servers, but separating them with views isn’t a good solution?
> >
> > @Eray Aslan, additional-from-cache and additional-from-auth settings
> > did the trick, now server gives “query refused”
> >
> > @Barry Finkel, yes I typed dig ww. At that point, every recursive
> > query gives the same output. But thanks for the info.
> >
> > @Mark Elkins,In our setup, we have one machine with 2 IP addresses.
> > (option 3) We are planning to use DNNSEC, Could you give more
> > information about the possible DNSSEC problem?
>
> Resolver Problem:
> DNSSEC requires an appropriately configured recursive resolver that can
> chase answers and signatures down from the root. It should not also be
> authoritative (ie have Zones). To the best of my knowledge, answers from
> Zones that the Software instance is authoritative for will never be
> DNSSEC validated (AD bit set). This might not initially seem like a
> problem (you trust your own setup) but things like DANE will not work,
> ie DANE in an SMTP environment.

Only if the DANE client is broken.  In general client can't trust
AD (think coffee shop) so the DANE client needs to do validation
for itself.  Once a client is validating itself AD is irrelevent.

> Resolver Solution:
> Move the Internal Views of Authoritaive Data (Internal Zones) to a Third
> IP address.
> Run the Recursive Server on the "Resolver Only" IP address, perhaps use
> UNBOUND (I like BIND - but multiple instances of BIND is going to become
> administratively painful). 

Absolute hogwash.  It's easy enough to configure a single instance
of named to provide authoritative services on on address and recursive
services on a second address.

As for running multiple instances we do that all the time when
testing and it really isn't that hard.

controls { inet address ...; };
option {
	listen-on { address; };
	query-source address;
	notify-source address;
	transfer-source address;
	pid-file "/var/run/named-address/named.pid";
		 or
	pid-file "/var/run/named/named-address.pid";
};

> It MUST be the only Port 53 application on
> that 3rd IP address. Basically, copy the root KSK into a file owned by
> unbound and tell unbound to use that file.
> # cd /etc/unbound  (whatever)
> # dig . dnskey | grep 257 > root-anchors.txt
> # chown unbound: root.anchors.txt
> ...then add "auto-trust-anchor-file: root.anchors.txt" to unbound.conf
> (Confirm the authenticity of the root dnskey/KSK from
> https://dnssec.co.za and other sources)
> 
> DNSSEC Signing your Zones is easy enough but I've never tried to sign an
> Internal and External version of the same Zone. Why complicate life.
> You'll have to hand-roll a solution.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org