-----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-----