<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 04/11/2019 22:07, Steve Shipway
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1572905224.3514.24.camel@smxemail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div><br>
</div>
<div><span>The problems with having two IP addresses are that then
I need two IPs going through all the various firewalls (more
trouble for setup and migration)</span></div>
</blockquote>
You need access to the resolver IP from your clients (end-users,
servers etc), and access to the authoritative IP from your
recursors.<br>
<blockquote type="cite"
cite="mid:1572905224.3514.24.camel@smxemail.com">
<div><span>plus, which do you use for the zone NS records?</span></div>
</blockquote>
<p>The authoritative server only.<br>
</p>
<blockquote type="cite"
cite="mid:1572905224.3514.24.camel@smxemail.com">
<div><span> You have to have something like ns0, ns1 pointing to
the recursor (for clients to use) and ns0a ns1a in the NS
records pointing to the resolver... </span></div>
</blockquote>
<p>Clients always configure their resolver using IP addresses, not
domain names - otherwise you have the chicken-and-egg situation
(how do you resolve the name to an IP, when you can't yet reach
your recursor?)</p>
<p>The NS records are used by the recursor, to find the
authoritative server.<br>
</p>
<blockquote type="cite"
cite="mid:1572905224.3514.24.camel@smxemail.com">
<div><span> You end up with a different IP for the clients to use
from the one the NS records use, and queries could be coming
in to either.</span></div>
</blockquote>
Clients always talk to the resolver. Resolvers talk to the
authoritative nameservers. There's no ambiguity.<br>
<blockquote type="cite"
cite="mid:1572905224.3514.24.camel@smxemail.com">
<div><span><br>
</span></div>
<div>This also doesn't address the problem of the recursor not
being able to automatically know which zones to pass on to the
resolver - if you add a zone to the resolver, you need to
reconfigure the recursor to find it, else it might end up using
the external nameserver by accident.</div>
</blockquote>
<p>You want split or hidden DNS - that is, names which can only be
resolved by your internal clients, but not resolved by the outside
world?</p>
<p>In that case, yes, your recursor needs to be told for those
domains where the authoritative servers are, since it can't follow
the public NS records. With pdns recursor you can store the list
of domains to forward in a file.<br>
</p>
<blockquote type="cite"
cite="mid:1572905224.3514.24.camel@smxemail.com">
<div> Then dnsdist, seems to be necessary to forward notify
packets on to the resolver as the recursor just drops them.</div>
<div><span><br>
</span></div>
</blockquote>
<p>Were you thinking dnsdist in front of recursor, or dnsdist in
front of authoritative?</p>
<p>I wouldn't use either. dnsdist would still need to know which
domains are hidden/internal (hence need to go to the internal auth
servers) with everything else going to the public DNS.<br>
</p>
<br>
<blockquote type="cite"
cite="mid:1572905224.3514.24.camel@smxemail.com">
<div><span>
<div class="-x-evo-signature-wrapper"><span
class="-x-evo-signature">I can see why an ISP, handling
many queries and needing huge scale</span></div>
</span></div>
</blockquote>
<p>There are a whole bunch of reasons, and there's a link to an
article by djb by this. Partly it's because of different resource
requirements: recursors need lots of RAM, authoratitive servers
need some sort of database.</p>
<p>But I'll briefly explain another important issue.<br>
</p>
<p>Let's say your customer registers a domain foo.com, and you
install it on your nameservers. On the public Internet, foo.com
is delegated to them; and your customers also use these
nameservers as a cache.</p>
<p>Some time later, your customer moves to a different ISP. Without
telling you - since they're not your customer any more - they move
foo.com to another ISP's nameservers. That is, the NS records now
point to different nameservers.</p>
<p>However, you still have foo.com on your nameservers. If those
nameservers are also being used by your own customers as
recursors, then they will see the *old and stale* data for that
zone. The owner of foo.com may change the zone, e.g. to move a
webserver to a different IP, but your own customers see the old
data.<br>
</p>
<p>This ends up with a bug which is really hard to debug. Your
customers contact the owners of foo.com and say "I'm having
trouble getting to your website". They check, and everything is
fine. Your customer contacts you, and says they're having
problems accessing the Internet. You check, and everything looks
fine. Eventually your customer, who realises that every other ISP
can resolve foo.com properly except you, leaves.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:1572905224.3514.24.camel@smxemail.com">
<div><span>
<div class="-x-evo-signature-wrapper"><span
class="-x-evo-signature">, would want to do this; but it
is a horrible amount of complexity for small organisations
that just want the benefit of the API and are otherwise
fine with bind running on a small linux VM. It would have
been better to have had the option to run in split mode
(for large ISPs) or combined mode (for small
organisations) rather than just supporting large setups
only.</span></div>
</span></div>
</blockquote>
<p>That would add unnecessary complexity to the powerdns code,
reduce performance, and make maintenance harder.<br>
</p>
<p>If you want to continue to use bind, you are of course free to do
so. Bind is the kitchen sink of nameservers, and doesn't have a
great track record when it comes to security, but it does have a
lot of functionality.<br>
</p>
<p>Regards,</p>
<p>Brian.<br>
</p>
</body>
</html>