nsdc update implementation details

NSD
1

Hi,

I have a query regarding running a manual update of nsd via:

# nsdc update

My NSD server is accepting notifications from two servers. From my nsd.conf:
  # master 1
         allow-notify: X.X.X.X NOKEY
         request-xfr: AXFR X.X.X.X NOKEY
         # master 2
         allow-notify: Y.Y.Y.Y NOKEY
         request-xfr: AXFR Y.Y.Y.Y NOKEY

Are both servers sequentially queried each time the update is run? Or is it a random one of the two servers that answers and the second one ignored?

Many thanks,

David

2

David Prangnell wrote:

My NSD server is accepting notifications from two servers. From my
nsd.conf:
  # master 1
         allow-notify: X.X.X.X NOKEY
         request-xfr: AXFR X.X.X.X NOKEY
         # master 2
         allow-notify: Y.Y.Y.Y NOKEY
         request-xfr: AXFR Y.Y.Y.Y NOKEY

Are both servers sequentially queried each time the update is run?
Or is it a random one of the two servers that answers and the second
one ignored?

Subsequent master servers are queried if the previous server either
didn't respond or had no updates. They are always queried in the order
of the configuration file.

So if master 1 answers, but with the same SOA serial as the current one,
master 2 is queried too. If master 1 has a higher serial, an XFR is
performed with master 1, and master 2 is not queried.

Jelte

3

Jelte Jansen wrote:

David Prangnell wrote:

My NSD server is accepting notifications from two servers. From my
nsd.conf:
  # master 1
         allow-notify: X.X.X.X NOKEY
         request-xfr: AXFR X.X.X.X NOKEY
         # master 2
         allow-notify: Y.Y.Y.Y NOKEY
         request-xfr: AXFR Y.Y.Y.Y NOKEY

Are both servers sequentially queried each time the update is run?
Or is it a random one of the two servers that answers and the second
one ignored?

Subsequent master servers are queried if the previous server either
didn't respond or had no updates. They are always queried in the order
of the configuration file.

So if master 1 answers, but with the same SOA serial as the current one,
master 2 is queried too. If master 1 has a higher serial, an XFR is
performed with master 1, and master 2 is not queried.

The algorithm is like that but slightly more complicated, with NOTIFY.

If no zone information is available at all, the above happens.
If a notify/nsdc update/zone timeout is happening, the above happens.

If a NOTIFY message is sent, and the source IP address is the IP address
of a master, that master is queried first. [mandated by NOTIFY RFC]. If
that master fails to respond, it will continue from that point in the
list, in the order from the config file; it will run through the list
several times if no masters are answering.

If a NOTIFY message is sent and it contains the new SOA serial number
inside the NOTIFY message (this is what master servers send out), then
NSD will query the source IP address if its a master and if not, it will
run through the list of masters, in order from the config file,
accepting updates, until it gets an update that brings the zone to the
new SOA serial number from the NOTIFY. So, if it knows version x is out
there, it will keep trying until it gets version x or later.

If a NOTIFY message is sent, with new SOA serial number, but its already
searching for updates, then it will update the SOA serial number it is
looking for, but only if the new serial number is newer.

Commandline (debug) tools (like dig, drill, nsd-notify and nsdc update)
do not allow including a serial number in notify messages. Master
servers, like NSD3 and Bind include a serial number in notify messages.
LDNS (svn version) example ldns-notify can accept a -s option to include
a serial version number inside the NOTIFY message.

Best regards,
   Wouter

4

If a NOTIFY message is sent and it contains the new SOA serial number
inside the NOTIFY message (this is what master servers send out), then
NSD will query the source IP address if its a master and if not, it will
run through the list of masters, in order from the config file,

shouldn't the slave ignore any NOTIFY messages from non-masters instead?

accepting updates, until it gets an update that brings the zone to the
new SOA serial number from the NOTIFY. So, if it knows version x is out
there, it will keep trying until it gets version x or later.

So with a single spoofed (or not even that) NOTIFY one could make the slaves
rapidly query all their masters?

-Peter

5

Peter Koch wrote:

If a NOTIFY message is sent and it contains the new SOA serial number
inside the NOTIFY message (this is what master servers send out), then
NSD will query the source IP address if its a master and if not, it will
run through the list of masters, in order from the config file,

shouldn't the slave ignore any NOTIFY messages from non-masters instead?

By default all notify messages are refused. You have to list the masters
and non-masters explicitly to give notify permission.

accepting updates, until it gets an update that brings the zone to the
new SOA serial number from the NOTIFY. So, if it knows version x is out
there, it will keep trying until it gets version x or later.

So with a single spoofed (or not even that) NOTIFY one could make the slaves
rapidly query all their masters?

Well, after 3 rounds along the masters it will wait for the zone retry
timeout. And try again.

Use TSIG on the notify messages to combat spoofing.

If you bombard the server with spoofed notify messages, it will poll the
masters even more often; since that will wake it up from the retry wait.

Best regards,
   Wouter