[nsd-users] nsd & ip-addresses

[Matthijs Mekking]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Michael,

See my comments in between lines...

Michael Tokarev wrote:
> Hello.
> 
> I'm trying to set up nsd here, after using it for more than a
> year on several machines.  And I come across several.. issues.
> 
> nsdc assumes that nsd is listening on 127.0.0.1, or else the
> program does not work.  But usually, 127.0.0.1 is used by
> _recursive_ resolver (it's the default entry if no 'nameserver'
> line is specified in /etc/resolv.conf).  It is more: it's a
> good idea to bind nsd to an external IP address only, and
> don't listen on 127.0.0.1 at all.  Obviously nsdc will fail
> with this setup.

nsdc assumes that nsd is on the same machine. It is a shell script
calling (nsd) binaries and sending signals to NSD.

Are you perhaps saying that nsdc update does not work, because it needs
the localhost address serving the slave zones?

> So in order to work around this, I bind nsd to 2 addresses --
> the proper 'external' IP and 127.0.0.1 for nsdc to work.
> At the same time, i'm forced to bind unbound (which is used
> for cache) to 127.0.0.2, and specify 127.0.0.2 in resolv.conf.
> It works, it's just slightly ugly.
> 
> So far so good.
> 
> Now, I'm on a multihomed host.  The two IP addresses are here
> because I'm forced to use two due to two different nameservers.
> One main IP address is used for everything, and another,
> additional IP is for nsd.  Because I need to provide both
> recursive and authoritative zones.
> 
> Nsd is bound to "second" IP.  Now, when it tries to send
> AXFR requests, it receives REFUSED replies, since it comes
> from the primary IP address, even if "ip-address" config
> item is specified (it'd be logical to use that instead of
> 0.0.0.0).  So I specify outgoing-interface (why the first
> is -address and second is -interface?).  This way, AXFR
> between the two machines works, but at the same time it
> completely breaks nscd.

Basically, the ip-address: is to set the listen-address for queries. The
outgoing-interface: is to set the source-address with respect to zone
transfer requests.

> Because now, nscd uses the same outgoing-interface when
> sending notifies to localhost!  And sure there's no
> acl entry for that.  After changing 127.0.0.1 to the
> same value as outgoing-interface, nsdc refuses to work
> saying that there's no zones for which 127.0.0.1 is
> allowed to sent notifies.  Wow.

Ah ok, so nsdc update fails, because of the outgoing interface?

It works for me with the following settings:

server:
    ip-address: 127.0.0.1
    ip-address: 213.1.1.1
...
zone:
    ...
    allow-notify: 127.0.0.1
    allow-notify: 213.1.1.1
    outgoing-interface: 213.1.1.1

Please note that NSD will take care of updates automatically. It has
built-in expire timers for zones and nsdc update is only here to force
an update.

> So I revert outgoing-interface back to the default, and
> allow different IP address on the primary.  Which becomes
> "notify: a" and "provide-xfr: b" with different a and b
> for the same host.

...

> Either I don't understand something important here,
> or... dunno.
> 
> To sum it up:
> 
> o why nsdc requires nsd to listen on 127.0.0.1?

nsdc does not require nsd to listen on 127.0.0.1, only if you want to
notify your zones with nsdc.

> o why ip-address but outgoing-interface?

For historic reasons and different developers, it grew like this.
I agree that these option names could be more consistent.

> o why not use ip-address by default for outgoing?

This was questioned before and maybe we will adopt this. The outgoing
interface is still needed for overriding though.

> o why nsdc uses outgoing-interface when contacting
>   local nsd?

For nsdc notify it makes sense, since the slave servers don't have to be
on the localhost. For nsdc update, I guess we could have skipped reading
the outgoing-interface:. However, the setup I provided earlier works.

> o why nsdc only checks zones that has acl for 127.0.0.1
>   (even if it actually uses outgoing-interface)?

nsdc update is about forcing zone updates. I think it is to prevent
sending unnecessary NOTIFYs to other servers out there, though I am not
sure about that...

> And an additional question:
> 
> o why it's not possible to provide some defaults in
>   a global section, like outgoing-interface and
>   provide-xfr and allow-* things, in order to not
>   repeat the same thing for every zone?  When trying
>   to list any of that in the "server" zection nsd
>   complains about syntax error...

That is a nice feature request. We will think about it.

Hope this helps.

Best regards,

Matthijs Mekking
NLnet Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEcBAEBAgAGBQJK+YKaAAoJEA8yVCPsQCW5KvAH/RgYQdODR1sJ28lP/0WPNoki
M6RcbUzArNQpWNbXlxbvLFoRAVuGHKiQDWyieKQgvElqdgxMit591XmH3HlYny3g
lPeEwo0wuAaVWCBQpBA4rFFZg5ys6QK0/+29S1r+IKrdooLVbh/yltGd9LYRMshY
3Cn/wJX8gWAkMch9F05QQKJaWBt3+0BrV0J52/iW1iX9ytCsnWPpW3Tsvrc/TuGJ
zYLiesf391XhXjLgNiCWi6FGixqyZwg58TlmJ2TQa8hue6ItYcr413qB5sIKAY6P
Rr02dWM6fEk6ar5mWCZligrGeFcQVKaqOTMLcVaI2NgBcosUoS8c0d8U/dMbvMg=
=tLZ1
-----END PGP SIGNATURE-----