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

Ilya Bakulin Ilya_Bakulin at genua.de
Thu Jul 19 11:51:08 UTC 2012


Hi Willem,
thank you for your reply.
OK, I understand the purpose of allow-notify better now.

I have updated to nsd 3.2.11 and tried to test the case where nsd as slave has 
multiple master servers (which are all listed in allow-notify and request-xfr 
lists) and receives DNS NOTIFY from one of them. If I read your email 
properly, in this case nsd should send AXFR to the server that has sent him 
DNS NOTIFY.
Unfortunately, this is not the case.

My config:

zone:
        name: "black"
        zonefile: "/var/nsd/zones/black.zone"
        allow-notify: 172.16.0.1/32 NOKEY
        request-xfr: 172.16.0.1 NOKEY
        allow-notify: 192.168.254.1/32 NOKEY
        request-xfr: 192.168.254.1 NOKEY
        allow-notify: 172.16.100.114/32 NOKEY
        request-xfr: 172.16.100.114 NOKEY


172.16.0.1 is just some host in the test network.
192.168.254.1 is a DNS server that serves the test network, but it doesn't 
know anything about "black.zone".
172.16.100.114 is the master server for "black.zone".

Now I update the zone contents on 100.114.

I see the following in the logfile of slave nsd:
Jul 19 13:45:39 ggd115 <nsd> nsd[27117]: Notify received and accepted, forward 
to xfrd
Jul 19 13:45:39 ggd115 <nsd> nsd[15476]: Handle incoming notify for zone black
Jul 19 13:45:49 ggd115 <nsd> nsd[15476]: xfrd: zone black received error code 
SERVER NOT AUTHORITATIVE FOR ZONE from 192.168.254.1
Jul 19 13:45:49 ggd115 <nsd> nsd[15476]: xfrd: zone black written received XFR 
from 172.16.100.114 with serial 1342698338 to disk
Jul 19 13:45:49 ggd115 <nsd> nsd[15476]: xfrd: zone black committed "xfrd: 
zone black received update to serial 1342698338 at time 1342698349 from 
172.16.100.114 in 1 parts"
Jul 19 13:45:49 ggd115 <nsd> nsd[16641]: signal received, reloading...
Jul 19 13:45:49 ggd115 <nsd> nsd[17632]: memory recyclebin holds 0 bytes
Jul 19 13:45:49 ggd115 <nsd> nsd[27117]: NSTATS 1342698349 1342698318 SOA=1
Jul 19 13:45:49 ggd115 <nsd> nsd[27117]: XSTATS 1342698349 1342698318 RR=0 
RNXD=0 RFwdR=0 RDupR=0 RFail=0 RFErr=0 RErr=0 RAXFR=0 RLame=0 ROpts=0 SSysQ=0 
SAns=1 SFwdQ=0 SDupQ=0 SErr=0 RQ=0 RIQ=0 RFwdQ=0 RDupQ=0 RTCP=0 SFwdR=0 
SFail=0 SFErr=0 SNaAns=0 SNXD=0 RUQ=0 RURQ=0 RUXFR=0 RUUpd=0
Jul 19 13:45:49 ggd115 <nsd> nsd[15476]: Zone black serial 1342698298 is 
updated to 1342698338.

So, what's strange is "error code SERVER NOT AUTHORITATIVE FOR ZONE from 
192.168.254.1" -- that means that nsd tried to contact 192.168.254.1 despite 
that he received NOTIFY from 172.16.100.114. When I run tcpdump on ggd115, I 
see that nsd also tried to contact 172.16.0.1, but received nothing because 
that host doesn't provide DNS at all.
And yes, first it tries 172.16.0.1, then 192.168.254.1, and only after that 
172.16.100.114...

What am I doing wrong here?

On Wednesday 18 July 2012 23:51:29 Willem Toorop wrote:
> 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
>
> _______________________________________________
> nsd-users mailing list
> nsd-users at NLnetLabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/nsd-users

-------------- 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/20120719/ac31ad83/attachment.bin>


More information about the nsd-users mailing list