Unable to transfer IPv4 reverse zone

[Daniel Lintott]

Hi,

I have two BIND DNS servers both running 9.9.4-P1.

I have configured them as master and slave, but have a strange issue.
The IPv4 reverse zone, fails to transfer to the slave.

I have tested the AXFR from the command line and this also fails with
SERVFAIL.

Out of 5 zones (3 forward, 1 IPv6 reverse, 1 IPv4 Reverse) the IPv4
reverse zone is the only one which fails.

The configuration on the master is the same for all zones.

Any ideas?

Regards

Daniel Lintott

[Matus UHLAR - fantomas]

On 19.12.13 18:11, Daniel Lintott wrote:
>I have two BIND DNS servers both running 9.9.4-P1.
>
>I have configured them as master and slave, but have a strange issue.
>The IPv4 reverse zone, fails to transfer to the slave.
>
>I have tested the AXFR from the command line and this also fails with
>SERVFAIL.
>
>Out of 5 zones (3 forward, 1 IPv6 reverse, 1 IPv4 Reverse) the IPv4
>reverse zone is the only one which fails.

Does the master answer SOA requests for all requests correctly?
Does it answer AXFR requests from slave correctly?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
WinError #99999: Out of error messages.

[Daniel Lintott]

On 19/12/13 18:37, Timothe Litt wrote:
> I doubt you'll get help without providing configuration data for
> master
> and slaves and exact log and error messages.
>
> But I'll take one blind guess. DNSSEC validation enabled and your
> in-addr.arpa zones are not delegated and not in DLV?
>

DNSSEC is not currently used on these servers.

The following is logged on the slave:
Dec 19 17:51:48 server2 named[7866]: transfer of
'5.168.192.in-addr.arpa/IN' from 192.168.5.1#53: connected using
192.168.5.2#47108

Dec 19 17:51:48 server2 named[7866]: transfer of
'5.168.192.in-addr.arpa/IN' from 192.168.5.1#53: failed while receiving
responses: SERVFAIL

Dec 19 17:51:48 server2 named[7866]: transfer of
'5.168.192.in-addr.arpa/IN' from 192.168.5.1#53: Transfer completed: 0
messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec)

Dig returns the following:
[root@server2 ~]# dig @192.168.5.1 5.168.192.in-addr.arpa AXFR

; <<>> DiG 9.9.4-P1 <<>> @192.168.5.1 5.168.192.in-addr.arpa AXFR
; (1 server found)
;; global options: +cmd
; Transfer failed.

There are no errors reported on the master server.

Master - named.conf

include "/etc/named.conf.local";

options {
directory "/var/named";
pid-file "/var/run/named/named.pid";
};

zone "." {
type hint;
file "/etc/db.cache";
};

key rndc-key {
algorithm hmac-md5;
secret "XXX";
};
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; };
};

Configuration of the problem reverse zone:

zone "5.168.192.in-addr.arpa" {
type master;
file "/var/named/5.168.192.in-addr.arpa.hosts";
allow-transfer {
192.168.5.2;
};
allow-update {
key rndc-key;
};
};

Slave Zone Configuration:

zone "5.168.192.in-addr.arpa" {
type slave;
masters {
192.168.5.1;
};
file "/var/named/slaves/192.168.5.rev";
};

[Daniel Lintott]

On 19/12/13 18:50, Matus UHLAR - fantomas wrote:
> Does the master answer SOA requests for all requests correctly?

It would appear so, yes:

dig @192.168.5.1 5.168.192.in-addr.arpa SOA

; <<>> DiG 9.9.4-P1 <<>> @192.168.5.1 5.168.192.in-addr.arpa SOA

; (1 server found)
;; global options: +cmd

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12356
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;5.168.192.in-addr.arpa. IN SOA

;; ANSWER SECTION:
5.168.192.in-addr.arpa. 38400 IN SOA server1.internal.serverb.co.uk.
daniel.serverb.co.uk. 1234478001 10800 3600 604800 38400

;; AUTHORITY SECTION:
5.168.192.in-addr.arpa. 38400 IN NS server1.internal.serverb.co.uk.
5.168.192.in-addr.arpa. 38400 IN NS server2.internal.serverb.co.uk.

;; ADDITIONAL SECTION:
server1.internal.serverb.co.uk. 38400 IN A 192.168.5.1
server1.internal.serverb.co.uk. 38400 IN AAAA 2a01:348:1db::1
server2.internal.serverb.co.uk. 38400 IN A 192.168.5.2
server2.internal.serverb.co.uk. 38400 IN AAAA 2a01:348:1db::2

;; Query time: 0 msec
;; SERVER: 192.168.5.1#53(192.168.5.1)
;; WHEN: Thu Dec 19 19:16:15 GMT 2013
;; MSG SIZE rcvd: 248

> Does it answer AXFR requests from slave correctly?
>

All except the aforementioned reverse zone:

dig @192.168.5.1 5.168.192.in-addr.arpa AXFR

; <<>> DiG 9.9.4-P1 <<>> @192.168.5.1 5.168.192.in-addr.arpa AXFR
; (1 server found)
;; global options: +cmd
; Transfer failed.

Regards

Daniel

[/dev/rob0]

On Thu, Dec 19, 2013 at 07:27:51PM +0000, Daniel Lintott wrote:
> On 19/12/13 18:37, Timothe Litt wrote:
> > I doubt you'll get help without providing configuration data for
> > master
> > and slaves and exact log and error messages.
> >
> > But I'll take one blind guess. DNSSEC validation enabled and
> > your in-addr.arpa zones are not delegated and not in DLV?

I'll offer a guess as well.

> DNSSEC is not currently used on these servers.
>
> The following is logged on the slave:
> Dec 19 17:51:48 server2 named[7866]: transfer of
> '5.168.192.in-addr.arpa/IN' from 192.168.5.1#53: connected using
> 192.168.5.2#47108
>
> Dec 19 17:51:48 server2 named[7866]: transfer of
> '5.168.192.in-addr.arpa/IN' from 192.168.5.1#53: failed while
> receiving responses: SERVFAIL
>
> Dec 19 17:51:48 server2 named[7866]: transfer of
> '5.168.192.in-addr.arpa/IN' from 192.168.5.1#53: Transfer
> completed: 0 messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec)
>
> Dig returns the following:

> [root@server2 ~]# dig @192.168.5.1 5.168.192.in-addr.arpa AXFR

>
> ; <<>> DiG 9.9.4-P1 <<>> @192.168.5.1 5.168.192.in-addr.arpa AXFR
> ; (1 server found)
> ;; global options: +cmd
> ; Transfer failed.
>

> There are no errors reported on the master server.

How about when the zone loaded initially? I suspect a problem in the
master zone file itself. Try named-checkzone(8) on it.

Can you query SOA and PTR records from the master?
dig 5.168.192.in-addr.arpa. any @192.168.5.1
dig 1.5.168.192.in-addr.arpa. any @192.168.5.1
Try this also on the master itself.

Note also, regarding logging, that depending on your syslogd's
configuration you might see errors in a different file than logs of
lower syslog priority.

--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

[David Forrest]

On Thu, 19 Dec 2013, Daniel Lintott wrote:
(...)

>
> ;; ANSWER SECTION:
> 5.168.192.in-addr.arpa. 38400 IN SOA server1.internal.serverb.co.uk.
> daniel.serverb.co.uk. 1234478001 10800 3600 604800 38400
>
> ;; AUTHORITY SECTION:
> 5.168.192.in-addr.arpa. 38400 IN NS server1.internal.serverb.co.uk.
> 5.168.192.in-addr.arpa. 38400 IN NS server2.internal.serverb.co.uk.
>
> ;; ADDITIONAL SECTION:
> server1.internal.serverb.co.uk. 38400 IN A 192.168.5.1
> server1.internal.serverb.co.uk. 38400 IN AAAA 2a01:348:1db::1
> server2.internal.serverb.co.uk. 38400 IN A 192.168.5.2
> server2.internal.serverb.co.uk. 38400 IN AAAA 2a01:348:1db::2

> All except the aforementioned reverse zone:
>

> dig @192.168.5.1 5.168.192.in-addr.arpa AXFR
>
> ; <<>> DiG 9.9.4-P1 <<>> @192.168.5.1 5.168.192.in-addr.arpa AXFR

(...)

This is an unrouteable private zone. I slave root as you appear to do and
serve your own 5.168.192.in-addr.arpa. as I do. I don't expect it to
transfer out as it only has meaning in an internal view.

Dave
--
David Forrest e-mail: drf at maplepark dot com
St. Louis, Missouri

[Daniel Lintott]

On 19/12/13 19:37, /dev/rob0 wrote:
> How about when the zone loaded initially? I suspect a problem in the
> master zone file itself. Try named-checkzone(8) on it.
>

named-checkzone seems to be happy:
zone 5.168.192.in-addr.arpa/IN: loaded serial 1234478001
OK

> Can you query SOA and PTR records from the master?
> dig 5.168.192.in-addr.arpa. any @192.168.5.1

; <<>> DiG 9.9.4-P1 <<>> 5.168.192.in-addr.arpa. any @192.168.5.1

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51816
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:

;5.168.192.in-addr.arpa. IN ANY

;; ANSWER SECTION:
5.168.192.in-addr.arpa. 38400 IN SOA server1.internal.serverb.co.uk.
daniel.serverb.co.uk. 1234478001 10800 3600 604800 38400

5.168.192.in-addr.arpa. 38400 IN NS server2.internal.serverb.co.uk.
5.168.192.in-addr.arpa. 38400 IN NS server1.internal.serverb.co.uk.

;; ADDITIONAL SECTION:
server1.internal.serverb.co.uk. 38400 IN A 192.168.5.1
server1.internal.serverb.co.uk. 38400 IN AAAA 2a01:348:1db::1
server2.internal.serverb.co.uk. 38400 IN A 192.168.5.2
server2.internal.serverb.co.uk. 38400 IN AAAA 2a01:348:1db::2

;; Query time: 0 msec
;; SERVER: 192.168.5.1#53(192.168.5.1)

;; WHEN: Thu Dec 19 19:44:26 GMT 2013
;; MSG SIZE rcvd: 248


> dig 1.5.168.192.in-addr.arpa. any @192.168.5.1

; <<>> DiG 9.9.4-P1 <<>> 1.5.168.192.in-addr.arpa. any @192.168.5.1

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37083

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:

;1.5.168.192.in-addr.arpa. IN ANY

;; ANSWER SECTION:
1.5.168.192.in-addr.arpa. 38400 IN PTR server1.internal.serverb.co.uk.

;; AUTHORITY SECTION:
5.168.192.in-addr.arpa. 38400 IN NS server1.internal.serverb.co.uk.
5.168.192.in-addr.arpa. 38400 IN NS server2.internal.serverb.co.uk.

;; ADDITIONAL SECTION:
server1.internal.serverb.co.uk. 38400 IN A 192.168.5.1
server1.internal.serverb.co.uk. 38400 IN AAAA 2a01:348:1db::1
server2.internal.serverb.co.uk. 38400 IN A 192.168.5.2
server2.internal.serverb.co.uk. 38400 IN AAAA 2a01:348:1db::2

;; Query time: 0 msec
;; SERVER: 192.168.5.1#53(192.168.5.1)

;; WHEN: Thu Dec 19 19:45:19 GMT 2013
;; MSG SIZE rcvd: 221

> Try this also on the master itself.
>

; <<>> DiG 9.9.4-P1 <<>> 5.168.192.in-addr.arpa. any @127.0.0.1

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10899
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:

;5.168.192.in-addr.arpa. IN ANY

;; ANSWER SECTION:
5.168.192.in-addr.arpa. 38400 IN SOA server1.internal.serverb.co.uk.
daniel.serverb.co.uk. 1234478001 10800 3600 604800 38400

5.168.192.in-addr.arpa. 38400 IN NS server2.internal.serverb.co.uk.
5.168.192.in-addr.arpa. 38400 IN NS server1.internal.serverb.co.uk.

;; ADDITIONAL SECTION:
server1.internal.serverb.co.uk. 38400 IN A 192.168.5.1
server1.internal.serverb.co.uk. 38400 IN AAAA 2a01:348:1db::1
server2.internal.serverb.co.uk. 38400 IN A 192.168.5.2
server2.internal.serverb.co.uk. 38400 IN AAAA 2a01:348:1db::2

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Dec 19 19:47:20 GMT 2013
;; MSG SIZE rcvd: 248


; <<>> DiG 9.9.4-P1 <<>> 1.5.168.192.in-addr.arpa. any @127.0.0.1

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41850

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:

;1.5.168.192.in-addr.arpa. IN ANY

;; ANSWER SECTION:
1.5.168.192.in-addr.arpa. 38400 IN PTR server1.internal.serverb.co.uk.

;; AUTHORITY SECTION:
5.168.192.in-addr.arpa. 38400 IN NS server1.internal.serverb.co.uk.
5.168.192.in-addr.arpa. 38400 IN NS server2.internal.serverb.co.uk.

;; ADDITIONAL SECTION:
server1.internal.serverb.co.uk. 38400 IN A 192.168.5.1
server1.internal.serverb.co.uk. 38400 IN AAAA 2a01:348:1db::1
server2.internal.serverb.co.uk. 38400 IN A 192.168.5.2
server2.internal.serverb.co.uk. 38400 IN AAAA 2a01:348:1db::2

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Dec 19 19:47:46 GMT 2013
;; MSG SIZE rcvd: 221

Regards

Daniel

[Daniel Lintott]

On 19/12/13 19:44, David Forrest wrote:
> This is an unrouteable private zone. I slave root as you appear to do
> and serve your own 5.168.192.in-addr.arpa. as I do. I don't expect it
> to transfer out as it only has meaning in an internal view.
>
> Dave

I'm not expecting the zone to transfer out of the current network, just
within the current network

Regards

Daniel

[Daniel Lintott]

I have now tried recreating the zone file on the master, removed and
re-added the configuration for the zone on both master and slave, yet
still I am unable to transfer the zone.

I have also added the following logging to the master server:

logging {
channel xfer {
file "/var/log/named/xfer.log";
print-category yes;
print-severity yes;
print-time yes;
};
category xfer-out {
xfer;
};
};

But this fails to log anything, despite transfers taking place. I've
checked the permissions on the log and it is writeable by the user which
bind is running under.

As yet... I'm no closer in working this one out.

Regards

Daniel

[Cathy Almond]

Noting this in the master zone:
> allow-transfer {
> 192.168.5.2;
> };

Check that the slave actually is using that source address for the TCP
transfer (which I grant would be odd to be different, if your other
zones transfer OK).

Do you have the same ACL on your other zones that transfer OK?

And depending on the 'big' configuration - this might also be relevant:
https://kb.isc.org/article/AA-00904/47/Why-is-my-slave-server-trying-sometimes-to-use-a-different-source-IP-address-for-zone-transfers.html

---

If still unresolved, I think I'd be at the point of doing a network
packet trace on this one to find out which end is dropping it. The
earlier logging messages suggest that the TCP connection for the
transfer did establish (or start to establish - it may not yet have been
'connected' all the way to the named server).

Trace at both ends simultaneously, so that you get both sides of the
'story'. And also trace a good transfer between master and slave for
comparison purposes.

---

It shouldn't be relevant to the problem in-hand, but are you missing
this record from your reverse zone (I didn't see it in the ANY query
result):

2.5.168.192.in-addr.arpa. IN PTR server2.internal.serverb.co.uk.

Cathy

[Daniel Lintott]

On 20/12/13 09:16, Cathy Almond wrote:
> Noting this in the master zone:
>> allow-transfer {
>> 192.168.5.2;
>> };
>
> Check that the slave actually is using that source address for the TCP
> transfer (which I grant would be odd to be different, if your other
> zones transfer OK).
>

The slave is using 192.168.5.2 for the TCP transfer, to be sure I have
set the transfer source and confirmed this with a packet trace.

> Do you have the same ACL on your other zones that transfer OK?
>
> And depending on the 'big' configuration - this might also be relevant:
> https://kb.isc.org/article/AA-00904/47/Why-is-my-slave-server-trying-sometimes-to-use-a-different-source-IP-address-for-zone-transfers.html
>

All of the zones have identical ACL's as above.

> ---
>
> If still unresolved, I think I'd be at the point of doing a network
> packet trace on this one to find out which end is dropping it. The
> earlier logging messages suggest that the TCP connection for the
> transfer did establish (or start to establish - it may not yet have been
> 'connected' all the way to the named server).
>
> Trace at both ends simultaneously, so that you get both sides of the
> 'story'. And also trace a good transfer between master and slave for
> comparison purposes.
>

Looking at a packet trace, I can see the TCP session establish, the AXFR
request is sent to the master which responds with 'SERVFAIL'

Pkt 160: Standard query 0x3a9c AXFR 5.168.192.in-addr.arpa

Pkt 173: Standard query response 0x3a9c Server failure

As a thought, I have tried running the AXFR on the master server, which
also fails.... so it would seem the problem lies on the master server.

[root@server1 ~]# dig 5.168.192.in-addr.arpa @127.0.0.1 AXFR

; <<>> DiG 9.9.4-P1 <<>> 5.168.192.in-addr.arpa @127.0.0.1 AXFR

;; global options: +cmd
; Transfer failed.

> ---
>
> It shouldn't be relevant to the problem in-hand, but are you missing
> this record from your reverse zone (I didn't see it in the ANY query
> result):
>
> 2.5.168.192.in-addr.arpa. IN PTR server2.internal.serverb.co.uk.
>

The record does appear to to be in the zone.

Regards

Daniel

[Matus UHLAR - fantomas]

On 19.12.13 19:27, Daniel Lintott wrote:
>The following is logged on the slave:
>Dec 19 17:51:48 server2 named[7866]: transfer of
>'5.168.192.in-addr.arpa/IN' from 192.168.5.1#53: connected using
>192.168.5.2#47108
>
>Dec 19 17:51:48 server2 named[7866]: transfer of
>'5.168.192.in-addr.arpa/IN' from 192.168.5.1#53: failed while receiving
>responses: SERVFAIL
>
>Dec 19 17:51:48 server2 named[7866]: transfer of
>'5.168.192.in-addr.arpa/IN' from 192.168.5.1#53: Transfer completed: 0
>messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec)

what's in logs on master?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.

WinError #98652: Operation completed successfully.

[Daniel Lintott]

On 20/12/13 11:12, Matus UHLAR - fantomas wrote:
> On 19.12.13 19:27, Daniel Lintott wrote:
>> The following is logged on the slave:
>> Dec 19 17:51:48 server2 named[7866]: transfer of
>> '5.168.192.in-addr.arpa/IN' from 192.168.5.1#53: connected using
>> 192.168.5.2#47108
>>
>> Dec 19 17:51:48 server2 named[7866]: transfer of
>> '5.168.192.in-addr.arpa/IN' from 192.168.5.1#53: failed while receiving
>> responses: SERVFAIL
>>
>> Dec 19 17:51:48 server2 named[7866]: transfer of
>> '5.168.192.in-addr.arpa/IN' from 192.168.5.1#53: Transfer completed: 0
>> messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec)
>
>
> what's in logs on master?

Nothing seems to be logged for any transfers on the master... even with
the following logging statement added

[Matus UHLAR - fantomas]

>> what's in logs on master?

On 20.12.13 11:21, Daniel Lintott wrote:
>Nothing seems to be logged for any transfers on the master... even with
>the following logging statement added
>
>logging {
> channel xfer {
> file "/var/log/named/xfer.log";
> print-category yes;
> print-severity yes;
> print-time yes;
> };
> category xfer-out {
> xfer;
> };
> };

that's why I prefer logging everything somewhere...
maybe it's in other category...

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.

Due to unexpected conditions Windows 2000 will be released
in first quarter of year 1901

[Daniel Lintott]

On 20/12/13 11:40, Matus UHLAR - fantomas wrote:
>>> what's in logs on master?
>
> On 20.12.13 11:21, Daniel Lintott wrote:
>> Nothing seems to be logged for any transfers on the master... even with
>> the following logging statement added
>>
>> logging {
>> channel xfer {
>> file "/var/log/named/xfer.log";
>> print-category yes;
>> print-severity yes;
>> print-time yes;
>> };
>> category xfer-out {
>> xfer;
>> };
>> };
>
> that's why I prefer logging everything somewhere...
> maybe it's in other category...
>

Even logging every category each to separate files, doesn't seem to
yield anything.

But... as a way of eliminating the various components, I have setup 2
master zones on the second server (server2).

These both transfer fine to the first server (server1)... and when I add
the logging clause for xfer-out it generates logs.

Which leads to believe that maybe the build of 9.9.4-P1 on server1,
might be at fault. I think I will try and rebuild bind as there seems to
be several issues... that don't exist on the other server, which has an
identical OS.

Regards

Daniel

[Cathy Almond]

It might be a silly question - but have you checked how many instances
of named you have running on the master (thinking that you might not be
'talking to' the one you think you are)?

Cathy

[Daniel Lintott]

There appears to only be one instance, from what I can see

[root@server1 ~]# ps aux | grep named
named 29523 0.0 0.9 43536 9608 ? Ss 22:01 0:00
/usr/local/sbin/named -u named

I'm completely out of ideas on this one now, as I've tried the config on
another machine and it worked fine... Something very odd appears to be
going on!

Daniel

[Mark Andrews]

I think this has got to the point of running named in the
foreground with debugging on the master.

named -g -d 100 <usual arguments>

This will log everything to stderr.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

[Daniel Lintott]

On 21/12/13 01:15, Mark Andrews wrote:
>
> I think this has got to the point of running named in the
> foreground with debugging on the master.
>
> named -g -d 100 <usual arguments>
>
> This will log everything to stderr.
>

I have pasted the output from running named as above here:
http://pastebin.com/FprFEkyb

I had changed the zone on the master and reloaded named a couple of
times on the slave.

Interestingly even when I've stopped named and I attempt a transfer it
replies with the same SERVFAIL... whereas I'd have expected it to be
unreachable (or similar)

Regards

Daniel

[Matus UHLAR - fantomas]

On 21.12.13 14:00, Daniel Lintott wrote:
>I have pasted the output from running named as above here:
>http://pastebin.com/FprFEkyb
>
>I had changed the zone on the master and reloaded named a couple of
>times on the slave.
>
>Interestingly even when I've stopped named and I attempt a transfer it
>replies with the same SERVFAIL... whereas I'd have expected it to be
>unreachable (or similar)

I see two SOA requests but no AXFR.

I see this:

21-Dec-2013 12:53:34.560 binding TCP socket: address in use

two times. Who is listening on TCP port 53?
Apparently the one DNS server that is replying SERVFAIL...

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.

"They say when you play that M$ CD backward you can hear satanic messages."
"That's nothing. If you play it forward it will install Windows."

[Barry Margolin]

In article <mailman.1893.1387635...@lists.isc.org>,

Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:

> On 21.12.13 14:00, Daniel Lintott wrote:
> >I have pasted the output from running named as above here:
> >http://pastebin.com/FprFEkyb
> >
> >I had changed the zone on the master and reloaded named a couple of
> >times on the slave.
> >
> >Interestingly even when I've stopped named and I attempt a transfer it
> >replies with the same SERVFAIL... whereas I'd have expected it to be
> >unreachable (or similar)
>
> I see two SOA requests but no AXFR.
>
> I see this:
>
> 21-Dec-2013 12:53:34.560 binding TCP socket: address in use
>
> two times. Who is listening on TCP port 53?
> Apparently the one DNS server that is replying SERVFAIL...

Try doing:

lsof -i :53

to see what process is listening on port 53.

--
Barry Margolin
Arlington, MA