Ilya Bakulin
2012-Jul-18 16:00 UTC
[nsd-users] allow-notify SUBNET and request-xfr inconsistency
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>
Willem Toorop
2012-Jul-18 21:51 UTC
[nsd-users] allow-notify SUBNET and request-xfr inconsistency
Hi Ilya, When the notifying host is listed in the request-xfr's, it will be tried first. Having allow-notify and request-xfr separated is convenient in many cases. For example you could add allow-notify: 127.0.0.0/8 to trigger a transfer from a master server from the localhost with nsd-notify. Or perhaps the master has multiple interfaces and will send out from one, but only serve on another interface. Op 18-07-12 18:00, Ilya Bakulin schreef:> 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 > > > > _______________________________________________ > nsd-users mailing list > nsd-users at NLnetLabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/nsd-users >