Dual-NSD setup management

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Dual-NSD setup management

Felipe Scarel
Hello all,

after reading some documentation on the NSD manpage and online, it
seems there's no support for views as offered with BIND. I've gathered
that the general suggestion is to run two separate instances (running
on 127.0.0.1, for example), and divert traffic from pf depending on
the connecting source-address.

I've successfully configured such a setup using two NSD servers,
listening on ports 53 and 8053, and using pf rdr-to and nat-to rules
to divert traffic. I tried to use divert-to instead, but for the life
of me I couldn't figure out why it wasn't working. This is what I'm
using right now:

pass in quick inet proto { tcp, udp } from { <internal_networks> } \
  to any port domain rdr-to localhost port 53
pass out quick inet proto { tcp, udp } from { <internal_networks> } \
  to any port domain nat-to self

pass in quick inet proto { tcp, udp } from any \
  to any port domain rdr-to localhost port 8053
pass out quick inet proto { tcp, udp } from any \
  to any port domain nat-to self

Management of this setup during boot is not so great, though. The
/etc/rc.d/nsd script more or less expects the configuration to reside
on /var/nsd/etc, so my best solution was to use nsd-control directly
from /etc/rc.local, which somewhat solves the problem (albeit not very
elegantly).

Perhaps someone has additional experiences to share on this kind of
setup. Is it possible to use divert-to on pf? What would be the
preferred method to manage two NSD daemons during boot?

Reply | Threaded
Open this post in threaded view
|

Re: Dual-NSD setup management

Craig Skinner-3
On 2015-05-26 Tue 11:39 AM |, Felipe Scarel wrote:
>
> after reading some documentation on the NSD manpage and online, it
> seems there's no support for views as offered with BIND.

It can sort of be done via an unbound stub (proxy)
to a different NSD served zone for internal hosts

5.5:

http://marc.info/?l=openbsd-misc&m=141113669300630
http://marc.info/?l=openbsd-misc&m=141146791726116

Cheers.
--
Q:  What is the worst story Helen Keller ever read?
A:  A cheese grater.

Reply | Threaded
Open this post in threaded view
|

Re: Dual-NSD setup management

Stuart Henderson
In reply to this post by Felipe Scarel
On 2015-05-26, Felipe Scarel <[hidden email]> wrote:
> after reading some documentation on the NSD manpage and online, it
> seems there's no support for views as offered with BIND. I've gathered
> that the general suggestion is to run two separate instances (running
> on 127.0.0.1, for example), and divert traffic from pf depending on
> the connecting source-address.

What are you using views *for*?

If it's to present some internal-only hosts to a trusted network that
is also using you as a resolver, just use local-data entries in unbound
for internal use, and run NSD facing external hosts. Simple setup and
fairly easy to use.

If it's something more complex (i.e. where you have other resolvers
querying you and need to present different views to these based on IP
address etc) then yes you will need two separate authoritative servers
(or you could keep using BIND for this job of course).

Reply | Threaded
Open this post in threaded view
|

Re: Dual-NSD setup management

Bryan Irvine
Additionally to all this good advice, you can create multiple loopback
interfaces if you did want to use divert-to. 'ifconfig create lo1' then you
don't need to use weird ports to accomplish things.

On Wed, May 27, 2015 at 4:06 AM, Stuart Henderson <[hidden email]>
wrote:

> On 2015-05-26, Felipe Scarel <[hidden email]> wrote:
> > after reading some documentation on the NSD manpage and online, it
> > seems there's no support for views as offered with BIND. I've gathered
> > that the general suggestion is to run two separate instances (running
> > on 127.0.0.1, for example), and divert traffic from pf depending on
> > the connecting source-address.
>
> What are you using views *for*?
>
> If it's to present some internal-only hosts to a trusted network that
> is also using you as a resolver, just use local-data entries in unbound
> for internal use, and run NSD facing external hosts. Simple setup and
> fairly easy to use.
>
> If it's something more complex (i.e. where you have other resolvers
> querying you and need to present different views to these based on IP
> address etc) then yes you will need two separate authoritative servers
> (or you could keep using BIND for this job of course).

Reply | Threaded
Open this post in threaded view
|

Re: Dual-NSD setup management

Felipe Scarel
Thanks for the input Stuart and Bryan, I think the dual-authoritative
setup might indeed be overkill.
I'll look into unbound local-data options, hadn't considered that.

On Wed, May 27, 2015 at 3:10 PM, Bryan Irvine <[hidden email]> wrote:

> Additionally to all this good advice, you can create multiple loopback
> interfaces if you did want to use divert-to. 'ifconfig create lo1' then you
> don't need to use weird ports to accomplish things.
>
> On Wed, May 27, 2015 at 4:06 AM, Stuart Henderson <[hidden email]>
> wrote:
>
>> On 2015-05-26, Felipe Scarel <[hidden email]> wrote:
>> > after reading some documentation on the NSD manpage and online, it
>> > seems there's no support for views as offered with BIND. I've gathered
>> > that the general suggestion is to run two separate instances (running
>> > on 127.0.0.1, for example), and divert traffic from pf depending on
>> > the connecting source-address.
>>
>> What are you using views *for*?
>>
>> If it's to present some internal-only hosts to a trusted network that
>> is also using you as a resolver, just use local-data entries in unbound
>> for internal use, and run NSD facing external hosts. Simple setup and
>> fairly easy to use.
>>
>> If it's something more complex (i.e. where you have other resolvers
>> querying you and need to present different views to these based on IP
>> address etc) then yes you will need two separate authoritative servers
>> (or you could keep using BIND for this job of course).