[nsd-users] allow-notify SUBNET and request-xfr inconsistency

[Ilya Bakulin]

Hi list,
We are observing strange behavior of nsd v3.2.9 acting as slave DNS server.

The environment is set up as follows:
0. We are using 172.16.0.0/16 subnet;
1. Primary Master server at 172.16.100.114;
2. Slave server at 172.16.100.115. The config file is 
in /etc/nsd-dns-slave.conf;
3. There may be also other Master servers im the given subnet.

Now I want to permit DNS NOTIFY messages to come from 172.16/16 subnet.
To do this, I use allow-notify in the slave config file:

zone:
        name: "black"
        zonefile: "/var/nsd/zones/black.zone"
        allow-notify: 172.16.0.0/24 NOKEY

Then I receive error message from nsd-checkconf:
/etc/nsd-dns-slave.conf: zone black has allow-notify but no request-xfr items. 
Where can it get a zone transfer when a notify is received?
/etc/nsd-dns-slave.conf: 1 semantic errors in 1 zones, 0 keys.

Hm, ok, I need request-xfr. But request-xfr does not allow to use subnets!
When I use:
zone:
        name: "black"
        zonefile: "/var/nsd/zones/black.zone"
        allow-notify: 172.16.0.0/24 NOKEY
        request-xfr: 172.16.0.0/24 NOKEY

I get:
/etc/nsd-dns-slave.conf:33: error: address range used for request-xfr
read /etc/nsd-dns-slave.conf failed: 1 errors in configuration file

OK. So I can use only host address here. Here I thought that I can put some 
random address from my /16 network just to make nsd-checkconf shut up :-)
So:

zone:
        name: "black"
        zonefile: "/var/nsd/zones/black.zone"
        allow-notify: 172.16.0.0/16 NOKEY
        request-xfr: 172.16.100.199 NOKEY

The host 172.16.100.199 does not exist at all :-)

Now nsd-checkconf doesn't complain.
What I expect now is that any server from /16 network can send me a NOTIFY 
message and it should be accepted. Furthermore, RFC-1996, Section 3.11 says:
> Because a deep server dependency graph may have multiple paths
>       from the primary master to any given slave, it is possible that
>       a slave will receive a NOTIFY from one of its known masters even
>       though the rest of its known masters have not yet updated their
>       copies of the zone.  Therefore, when issuing a QUERY for the
>       zone's SOA, the query should be directed at the known master who
>       was the source of the NOTIFY event, and not at any of the other
>       known masters
therefore I expect that upon receiving NOTIFY from 172.16.100.114, my slave 
server will send AXFR to it.
But this doesn't happen, I see the following in the logs:
[1342626791] nsd[12538]: info: Notify received and accepted, forward to xfrd
[1342626791] nsd[7729]: info: Handle incoming notify for zone black
[1342626791] nsd[7729]: error: xfrd: connect 172.16.100.199 failed: Host is 
down
[1342626791] nsd[7729]: error: xfrd: connect 172.16.100.199 failed: Host is 
down
[1342626791] nsd[7729]: error: xfrd: connect 172.16.100.199 failed: Host is 
down

So, the question is: why did nsd try to connect to 172.16.100.199, if it 
received DNS NOTIFY from 172.16.100.114?
Or 172.16.100.114 is not considered a "known master" despite being allowed to 
send DNS NOTIFY by allow-notify ACL? What's the meaning of allow-notify ACL
in this case if nsd sends AXFR only to hosts from request-xfr list?

Thanks!

--
Best regards,
Ilya Bakulin

genua
Gesellschaft fuer Netzwerk- und Unix-Administration mbH
Domagkstrasse 7, 85551 Kirchheim bei Muenchen
tel +49 89 991950-0, fax -999, www.genua.de
Geschaeftsfuehrer: Dr. Magnus Harlander, Dr. Michaela Harlander,
Bernhard Schneck. Amtsgericht Muenchen HRB 98238
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20120718/2802552b/attachment.bin>