[Dnsmasq-discuss] Zone transfer fails without any error

[Wojtek Swiatek]

Hello everyone

I wanted to set up another DNS server (unfortunately bind as, again
unfortunately, dnsmasq does not support being a secondary server).

The zone transfer is initiated from the secondary but I see (on that
secondary):

02-Aug-2018 23:05:33.160 zone swtk.info/IN: refresh: unexpected rcode
(SERVFAIL) from master 192.168.0.10#53 (source 0.0.0.0#0)
02-Aug-2018 23:06:52.662 zone swtk.info/IN: refresh: retry limit for master
192.168.0.10#53 exceeded (source 0.0.0.0#0)
02-Aug-2018 23:06:52.663 zone swtk.info/IN: Transfer started.
02-Aug-2018 23:06:52.664 transfer of 'swtk.info/IN' from 192.168.0.10#53:
connected using 192.168.0.13#40223
02-Aug-2018 23:06:52.665 transfer of 'swtk.info/IN' from 192.168.0.10#53:
failed while receiving responses: SERVFAIL
02-Aug-2018 23:06:52.666 transfer of 'swtk.info/IN' from 192.168.0.10#53:
Transfer status: SERVFAIL
02-Aug-2018 23:06:52.666 transfer of 'swtk.info/IN' from 192.168.0.10#53:
Transfer completed: 0 messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec)
02-Aug-2018 23:08:07.161 zone swtk.info/IN: refresh: unexpected rcode
(SERVFAIL) from master 192.168.0.10#53 (source 0.0.0.0#0)


On dnsmasq's host, when running dnsmasq with "-d -q --log-queries=extra" ,
I just see

dnsmasq: 32 192.168.0.13/34310 query[SOA] swtk.info from 192.168.0.13
dnsmasq: 33 192.168.0.13/54967 query[SOA] swtk.info from 192.168.0.13
dnsmasq: 34 10.100.10.30/60009 query[A] www.google.com from 10.100.10.30
dnsmasq: 34 10.100.10.30/60009 cached www.google.com is 216.58.206.228

Is there a better indication where the problem may be located? All traffic
between the bind and dnsmasq host is open (both ways) and a dig @
192.168.0.10 is successful (this is the IP of the dnsmasq host, the same
which is used in the bind transfer configuration file)

Wojtek

[Simon Kelley]

Post by Wojtek Swiatek
Hello everyone
I wanted to set up another DNS server (unfortunately bind as, again
unfortunately, dnsmasq does not support being a secondary server).
The zone transfer is initiated from the secondary but I see (on that
refresh: unexpected rcode (SERVFAIL) from master 192.168.0.10#53 (source
0.0.0.0#0)
refresh: retry limit for master 192.168.0.10#53 exceeded (source 0.0.0.0#0)
Transfer started.
02-Aug-2018 23:06:52.664 transfer of 'swtk.info/IN
<http://swtk.info/IN>' from 192.168.0.10#53: connected using
192.168.0.13#40223
02-Aug-2018 23:06:52.665 transfer of 'swtk.info/IN
<http://swtk.info/IN>' from 192.168.0.10#53: failed while receiving
responses: SERVFAIL
02-Aug-2018 23:06:52.666 transfer of 'swtk.info/IN
<http://swtk.info/IN>' from 192.168.0.10#53: Transfer status: SERVFAIL
02-Aug-2018 23:06:52.666 transfer of 'swtk.info/IN
<http://swtk.info/IN>' from 192.168.0.10#53: Transfer completed: 0
messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec)
refresh: unexpected rcode (SERVFAIL) from master 192.168.0.10#53 (source
0.0.0.0#0)
On dnsmasq's host, when running dnsmasq with "-d -q --log-queries=extra"
, I just see
dnsmasq: 32 192.168.0.13/34310 <http://192.168.0.13/34310> query[SOA]
swtk.info <http://swtk.info> from 192.168.0.13
dnsmasq: 33 192.168.0.13/54967 <http://192.168.0.13/54967> query[SOA]
swtk.info <http://swtk.info> from 192.168.0.13
dnsmasq: 34 10.100.10.30/60009 <http://10.100.10.30/60009> query[A]
www.google.com <http://www.google.com> from 10.100.10.30
dnsmasq: 34 10.100.10.30/60009 <http://10.100.10.30/60009> cached
www.google.com <http://www.google.com> is 216.58.206.228
Is there a better indication where the problem may be located? All
traffic between the bind and dnsmasq host is open (both ways) and a dig
@192.168.0.10 <http://192.168.0.10> is successful (this is the IP of the
dnsmasq host, the same which is used in the bind transfer configuration
file)

What's the result of doing

dig @192.168.0.10 SOA swtk.info


It looks like that could be what's failing, rather than the actual zone
transfer.

Simon.

[Wojtek Swiatek]

Post by Simon Kelley
What's the result of doing
It looks like that could be what's failing, rather than the actual zone
transfer.

Hello Simon

After one night spent on the subject I finally managed this morning to have
it working (and finally read the man page from beginning to end :))

I think that what worked was to add to the config file

auth-zone=swtk.info
auth-sec-servers=rpi-dmz

and define rpi-dmz in /etc/hosts

Before I had only

auth-sec-servers=192.168.0.13

which was probably not enough on its own (the docs suggested that parameter
for zone transfers).

The transfer works but unfortunately the serial is not updated when I make
changes (by adding hosts to /etc/hosts for instance, and maybe when the IPs
provided by dnsmasq change (I do not know yet)). It stays at 1.
I have to manually delete the zone on the slave to have it re-transferred
upon changes.

Not being sure of the right etiquette for this list: should i send a new
email with that question?

Thank you for your help!
Wojtek

[Simon Kelley]

Post by Simon Kelley
What's the result of doing
It looks like that could be what's failing, rather than the actual zone
transfer.
Hello Simon
After one night spent on the subject I finally managed this morning to
have it working (and finally read the man page from beginning to end :))
I think that what worked was to add to the config file
auth-zone=swtk.info <http://swtk.info>
auth-sec-servers=rpi-dmz
and define rpi-dmz in /etc/hosts
Before I had only 
auth-sec-servers=192.168.0.13
which was probably not enough on its own (the docs suggested that
parameter for zone transfers).
The transfer works but unfortunately the serial is not updated when I
make changes (by adding hosts to /etc/hosts for instance, and maybe when
the IPs provided by dnsmasq change (I do not know yet)). It stays at 1.
I have to manually delete the zone on the slave to have it
re-transferred upon changes.
Not being sure of the right etiquette for this list: should i send a new
email with that question?
Thank you for your help!
Wojtek
 

I'm happy to answer the second question here.

After you've made changes to /etc/hosts, you need to send SIGHUP to the
dnsmasq process to get it to re-read the file. That should also
increment the serial. Changes to DHCP allocated addresses should also
increment the serial.



Cheers,


Simon.

[Wojtek Swiatek]

Post by Simon Kelley
After you've made changes to /etc/hosts, you need to send SIGHUP to the
dnsmasq process to get it to re-read the file. That should also
increment the serial. Changes to DHCP allocated addresses should also
increment the serial.

Thank you. I restart the dnsmasq via

systemctl restart dnsmasq

which reads the configuration and /etc/hosts (I see in the logs that it has
taken into account the new entries in /etc/hosts and I can resolve them).

The serial is still 1, though:

***@srv ~# dig @127.0.0.1 swtk.info soa | grep SOA
swtk.info. 600 IN SOA . . 1 1200 180 1209600 600

Cheers
Wojtek

[w***@gmail.com]

Post by Simon Kelley
After you've made changes to /etc/hosts, you need to send SIGHUP to the
dnsmasq process to get it to re-read the file. That  should also
increment the serial. Changes to DHCP allocated addresses should also
increment the serial.
Thank you. I restart the dnsmasq via
systemctl restart dnsmasq

this is not a SIGHUP... the following is one correct way... it is chosen for
ease and not needing to find the process' PID...

pkill -SIGHUP dnsmasq


here is another way... slightly more complicated because it does look up the PID...

kill -SIGHUP ${pidof dnsmasq}


you may need to use sudo if you're doing these manually from the command line...
you can use the signal name or number... the following will show you the list of
signals, their numbers and a brief description...

man 7 signal


HTH

[Wojtek Swiatek]

Post by w***@gmail.com

Post by Wojtek Swiatek
systemctl restart dnsmasq

this is not a SIGHUP... the following is one correct way... it is chosen for
ease and not needing to find the process' PID...
pkill -SIGHUP dnsmasq
here is another way... slightly more complicated because it does look up the PID...
kill -SIGHUP ${pidof dnsmasq}
you may need to use sudo if you're doing these manually from the command line...
you can use the signal name or number... the following will show you the list of
signals, their numbers and a brief description...
man 7 signal

I know that this is not a signal but a restart of the service (I use
signals on a regular basis in my code as well).
My understanding is that this is a way to reload the configuration (as
mentioned by Simon) without stopping the service.

Do you mean that the right / only way to increase the serial is by sending
the signal?

I do not think so as it would make hosts management very awkward (one would
need not to forget to send the signal) and
another thread in the past mentioned that the serial is calculated in a
smart way to always reflect changes.

Cheers
Wojtek

[Simon Kelley]

The serial number is initialised when dnsmasq starts up to the current
time (seconds since 1st Jan 1970). This should ensure that it always
increases when dnsmasq is restarted. The serial number is also increased
by one when /etc/hosts is re-read by sending SIGHUP and when the DHCP
lease database changes. This should ensure it increases whenever the
zone changes without dnsmasq restarting.

If your serial starts a one each time dnsmasq starts up then something
is wrong. Maybe dnsmasq is started before the time is set in your machine?


If you're running on something like a router that doesn't have a battery
backed RTC, dnsmasq may be compiled with HAVE_BROKEN_RTC. In that case
you have to initialise the serial using the --auth-soa option. (dnsmasq
will not start up if you don't). If that's always setting the serial to
one, then that would explain the problem.


Cheers,

Simon.

Post by w***@gmail.com

Post by Wojtek Swiatek
systemctl restart dnsmasq

this is not a SIGHUP... the following is one correct way... it is chosen for
ease and not needing to find the process' PID...
   pkill -SIGHUP dnsmasq
here is another way... slightly more complicated because it does look up the PID...
   kill -SIGHUP ${pidof dnsmasq}
you may need to use sudo if you're doing these manually from the command line...
you can use the signal name or number... the following will show you the list of
signals, their numbers and a brief description...
   man 7 signal
I know that this is not a signal but a restart of the service (I use
signals on a regular basis in my code as well).
My understanding is that this is a way to reload the configuration (as
mentioned by Simon) without stopping the service.
Do you mean that the right / only way to increase the serial is by
sending the signal?
I do not think so as it would make hosts management very awkward (one
would need not to forget to send the signal) and
another thread in the past mentioned that the serial is calculated in a
smart way to always reflect changes.
Cheers
Wojtek
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Wojtek Swiatek]

Post by Simon Kelley
The serial number is initialised when dnsmasq starts up to the current
time (seconds since 1st Jan 1970).
If your serial starts a one each time dnsmasq starts up then something
is wrong. Maybe dnsmasq is started before the time is set in your machine?

I run it on a "normal" server, the time is maintained via ntp (chrony
actually).
The problem is there when I restart dnsmasq as well:

***@srv:~# dig @127.0.0.1 swtk.info soa | grep SOA
swtk.info. 600 IN SOA . . 15 1200 180 1209600 600
***@srv:~# systemctl stop dnsmasq.service && systemctl start
dnsmasq.service
***@srv:~# dig @127.0.0.1 swtk.info soa | grep SOA
swtk.info. 600 IN SOA . . 1 1200 180 1209600 600
***@srv:~# systemctl stop dnsmasq.service && systemctl start
dnsmasq.service
***@srv:~# dig @127.0.0.1 swtk.info soa | grep SOA
swtk.info. 600 IN SOA . . 1 1200 180 1209600 600
***@srv:~# date +'%s'
1533316912

I do not know how the first serial ended up being 15, but a restart sets it
at 1.

Cheers
Wojtek

[Simon Kelley]

Post by Simon Kelley
The serial number is initialised when dnsmasq starts up to the current
time (seconds since 1st Jan 1970).
 
If your serial starts a one each time dnsmasq starts up then something
is wrong. Maybe dnsmasq is started before the time is set in your machine?
I run it on a "normal" server, the time is maintained via ntp (chrony
actually).
<http://swtk.info> soa | grep SOA
swtk.info <http://swtk.info>.              600     IN      SOA     . .
15 1200 180 1209600 600
dnsmasq.service
<http://swtk.info> soa | grep SOA
swtk.info <http://swtk.info>.              600     IN      SOA     . . 1
1200 180 1209600 600
dnsmasq.service
<http://swtk.info> soa | grep SOA
swtk.info <http://swtk.info>.              600     IN      SOA     . . 1
1200 180 1209600 600
1533316912
I do not know how the first serial ended up being 15, but a restart sets
it at 1. 
Cheers
Wojtek

What version of dnsmasq are you running?


Cheers,

Simon.

[Wojtek Swiatek]

Post by Simon Kelley
What version of dnsmasq are you running?

2.79, this is the latest version packaged with Ubuntu bionic (the LTS
version from a few weeks ago). It seems to be the latest one if I compare
it to your download site.

***@srv ~# dnsmasq --version
Dnsmasq version 2.79 Copyright (c) 2000-2018 Simon Kelley
Compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP
conntrack ipset auth DNSSEC loop-detect inotify


Cheers
Wojtek

[Simon Kelley]

OK, I'm confused about the serial problem. I just tested here, and it
works as I described.

Could you post you complete config here, or mail it direct to me?


Cheers,

Simon.

Post by Simon Kelley
What version of dnsmasq are you running?
2.79, this is the latest version packaged with Ubuntu bionic (the LTS
version from a few weeks ago). It seems to be the latest one if I
compare it to your download site.
Dnsmasq version 2.79  Copyright (c) 2000-2018 Simon Kelley
Compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua
TFTP conntrack ipset auth DNSSEC loop-detect inotify
 
Cheers
Wojtek

[w***@gmail.com]

Post by Simon Kelley
OK, I'm confused about the serial problem. I just tested here, and it
works as I described.

do you mean that dnsmasq only increments the serial when a SIGHUP is received
*OR* it increments the serial any time it is (re)started?

[w***@gmail.com]

This post might be inappropriate. Click to display it.