[nsd-users] nsd & ip-addresses

[Michael Tokarev]

Matthijs Mekking wrote:
[]
>> 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?

Sorta.  _Here_ I'm saying that it is more common to have
_recursive_ resolver listening on 127.0.0.1 and have
authoritative one on an externally-visible IP address.
Maybe a better idea will be to parse 'ip-address'
directive in the nsd.conf than to go stright to 127.0.0.1.

But that one can be easily worked around, once one
understands what it is all around, for example by
moving recursive/caching resolver to 127.0.0.2 as
I did.

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

Sure.... see below.

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

Yes that works, and I figured it out yesterday too.

It's just illogical (to me anyway) to check for zones
with allow-notify set to 127.1 _and_, at the same time,
try to notify them from different address.  Either nsdc
should stop using outgoing-interface here (which seems
to be for nsd itself when it asks for zone content or
sends notifies), or it should see for ACL matching
outgoing-interface.  What it does now is two halves
of two _different_ things.

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

Yes.  But when you first set things up, or doing some
updates that require immediately changes or debugging
ACL setup or in a bunch of other cases, you need to
perform an update _now_, and `nsdc update' is the way
to go here.  It isn't (usually) needed on a day-to-day
basis.

It's even more "interesting" this way: since you don't
use `nsdc update' all the time, when you play with the
ACLs or with bind addresses you realize something is
Not Right (like non-recursive resolver bound to 127.1
as per above) and "fix" things to look more traditionally,
to realize looooong time after that something broke -
exactly when you actually need nsdc and need it _now_
and don't understand why the thing does not work :)

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

That's what I actually mean.  In order to nsdc to work completely,
nsd should be listening on 127.0.0.1.  Some functionality still
works if nsd is not listening on 127.0.0.1 but not all of it.
And that's not obvious at all ;)

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

It's in fact more interesting than that.  Because
outgoing-interface must be only one, while ip-address
can be specified multiple times.

But it'll be enough really to be able to specify
outgoing-interface globally instead of per-zone.

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

I already commented about that setup.  Sure for notify it makes sense,
but definitely not for update where we're talking with _local_ nsd.
For update, maybe even better is to grab first ip-address and use
it for both sending the notify (destination IP) *and* for ACL checks.

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

See above ;)

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

For things like outgoing-interface and ACLs it is quite
stright-forward.  Global server config has the same
structure as used per-zone, and when in zone config we
check zone-specific things first and global one second,
first match wins.  Zone-specific ACL can evaluate to
"BLOCKED" to overwrite an allow in global section.

But for things like notify and request-xfr it's not
that obvious, because there's no sane way to combine
two sets (from global and per-zone sections).

So, there are 3 choices (at least how I see it):

1) disallow notify and request-xfr in global,
  just like it is now.  Quite unexpected to the
  user, and it's half a solution.

2) in case some parameter is specified per-zone,
  it *overwrites* any global parameter of the same
  name.  So that if you've, say, global ACL and want
  to add something per-zone, you have to repeat the
  _whole_ global ACL _and_ the addition in the zone
  config.  Somewhat ugly but understandable, and
  works consistently.  Not very practical.

3) implement one semantic for ACLs and different one
  for notify & request-xfr.  Namely, ACLs gets
  combined (global and per-zone), while per-zone notify
  and request-xfr overwrites any global settings like
  in 2).  Inconsistent.

So it's not that easy really - I mean not the implementation
which is trivial but the right interface.  And using
special "acl" sections and referring to them from
zones it too much in my opinion (makes whole thing
unnecessary complicated).

In any way, outgoing-interface is trivial to implement
in global section too, since it's a single value, and
it is often interpreted per-server logically.

> Hope this helps.

Yeah, I hope too... ;)

Thank you!

/mjt