In
https://kb.isc.org/article/AA-00874/0/Best-Practices-for-those-running-Recursive-Servers.html
one of the recommendations is to separate the two roles:

"Do not combine authoritative and recursive nameserver functions -- have
each function performed by separate server sets"

On Wed, Jan 14, 2015 at 4:10 AM, Nick Holland <n...@holland-consulting.net>
wrote:

> On 01/13/15 16:26, sven falempin wrote:
> > Dear OpenBSD users,
> >
> > Recently unbound made his way in base, pushing the complex bind/named
> > out for our own good.
> >
> > I would like to internally and externally solve some domain names
> > differently (so some service are accessible from inside and outside
> > without some fancy NAT or worse), I found out 'some' call this setup a
> > 'split-dns', often use for internal mail server.
> >
> > I also found out BIND got a feature for this and internet gossip
> >
> > <<
> > Unbound doesn't support split-horizon DNS. It's primarily meant as a
> > recursive and caching nameserver, and has only limited support for
> > serving authoritative answers.
> >>>
> >
> > Of course i imagine ran two unbound with two different IP address
> binding ....
> >
> > I feel like I am missing something.
>
> yes.  you are stuck thinking like BIND.
>
> > If I want to manage my domain , shall I use bind on the 'main' server ?
>
> no. :)
>
> You are designing around a BIND "feature", then declaring other products
> unsuitable because they don't match the spec you designed around.
>
> Start with the basic rule: BIND's design is bad.  Almost everything
> about it is wrong -- file formats, zone transfers, etc.  Once you
> realize that, things get much easier.  If you find an alternative
> "lacks" a "feature" of BIND, it's probably best you don't use that
> feature.  Really.
>
> Read Dan Bernstein's writeups on DNS, in addition to the BIND fanboy
> stuff.  Having managed a lot of DNS for a lot of domains for a few
> employers, I'm quite satisfied that Bernstein's much more right than
> wrong on DNS.
>
> There are two roles for DNS servers -- finding answers about a random
> domain, and providing answers about SPECIFIC domains.  The first is
> sometimes called "Resolvers", the second is sometimes called an
> authoritative server.  BIND mushed those two roles together stupidly,
> and people have been stuck thinking like that for decades now.  Separate
> them in your head.
>
> unbound is the resolver, nsd is the authoritative server.
>
> Want to find answers for your user's DNS queries?  That's unbound, the
> resolver.  That's the only thing users talk to.  Resolution is pretty
> complicated, not the kind of code you want to trust too blindly.
>
> Want to answer authoritatively about a domain?  That's the authoritative
> server...but you should never ask an authoritative server about anything
> other than what they are authoritative for.  Authoritative servers are
> relatively simple -- you ask a question, they either have the answer
> right there ready to give you, or they don't, but it all boils down to
> question, a single lookup, respond.  No need to talk elsewhere for info.
>
> Keep in mind, one computer can have LOTS of separate IP addresses to
> connect server processes to (don't forget you got all of 127.0.0.0/8!).
>  You also have lots of ports you can connect services to, and on an
> OpenBSD box, you have PF which can direct traffic from exposed ports and
> IP addresses to internal ones.  You seem to be uncomfortable with the
> idea of running multiple servers...why?  Your box is quite capable of
> multi-tasking!
>
> You can also have one BIG cache on a resolving server, and a bunch of
> minimal resolvers that act as message routers to either the big caching
> resolver or authoritative servers.
>
> So...assuming you really want to put internal and external DNS on the
> same box (not a really good idea), you can put NSD with your internal
> info on 127.0.0.2, NSD with external info on 127.0.0.1, and unbound on
> your internal facing NIC, configured to refer your internally hosted
> domains to 127.0.0.2.  External queries for your authoritative server
> get redirected to 127.0.0.1...and the outside world never touches your
> resolver.
>
> Why would you want the outside world touching your internal DNS servers
> anyway?  Talk about an unneeded hole in the firewall.  If you are doing
> enough with DNS that you need to host your own external authoritative
> server, you can justify a couple old computers for that.  Otherwise, I'd
> suggest letting your registrar handle your dns for you.
>
> Design your network properly, it gets really easy -- all my internal
> systems are in the zone "in.nickh.org", my local DNS resolver knows to
> pass *.in.nickh.org to my local authoritative server, the rest is
> resolved as "normal".
>
> Nick.

Reply via email to