Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The former master dns server crashed. I'm trying to use dig to get zone data from the slaves servers, which I don't control (, and I get transfer failed messages

root@dnsserver:# dig +tcp -t ixfr=0

; <<>> DiG 9.8.1-P1 <<>> +tcp -t ixfr=0
; (1 server found)
;; global options: +cmd     38400   IN  SOA 2012010301 10800 3600 604800 38400
; Transfer failed.

Slaves aren't capable to transfers zones?

Is there a way to build bind's zone files?

about the backup the backup disk somehow trashed and is unreadable, according to the data center team. It was a secondary disk which on weekends was mounted and rsynced with primary, apparently it got corrupted months ago, I didn't noticed it. I had a remote backup of /root /etc /var/lib/mysql & /home so when I heard that the backup disk was unreadable I didn't blink, but after seeing that my remote backup didn't include bind -> /var/named/chroot/etc/bind I started to feel a cold shiver on my back.

update 2 In desperate times comes desperate measures, I managed to write a script that helps me somewhat.

# 2013/01/21
# Building hosts files for bind9 from a list of domains in a txt file

for d in `cat domains`; do
    echo "\$ttl 38400" > $d.hosts
    dig +nocmd @$DNS $d any +multiline +noall +answer >> $d.hosts
    for cname in 'www' 'ftp' 'mail' 'webmail'; do
        dig +nocmd @$DNS $cname.$d CNAME +multiline +noall +answer >> $d.hosts
    # now include input in /etc/bind/named.conf.local
    echo -e "zone \"$d\" {" >> /etc/bind/named.conf.local
    echo -e "\ttype master;" >> /etc/bind/named.conf.local
    echo -e "\tfile \"/var/lib/bind/$d.hosts\";" >> /etc/bind/named.conf.local
    echo -e "\t};" >> /etc/bind/named.conf.local

With this script I was able, at least, to have the basic zone info... I couldn't find a way to query for subdomains. Google is my friend, but I couldn't find it. gist

share|improve this question

Of course you realize, that the slave in a bind implementation generates a copy (without your comments) of the zone files. You could simply copy these zone copy files into the master and use them while you are retrieving the original zone files on the masters from backups.

share|improve this answer
It is correct, but I don't have access to those files. – Juparave Jan 21 '13 at 6:46
In your case, i would take a chance at contacting the fine folks at to request copies of these zones. – Flash Sep 8 '15 at 16:08

Restore from Backup

Slaves are transfer capable by RFC, but it's generally administratively disabled.

share|improve this answer

Slaves are perfectly capable of acting as the source for zone transfers. Yours are probably just not configured to allow it, or at least not to allow it from the IP address you're querying from.

It's common for authoritative nameservers to be configured to only allow zone transfers from a whitelist of IP addresses of slave servers that are expected to be used. Since it's unusual for any slaves to be slaving off other slaves, servers that are themselves slaves usually permit no zone transfers as a result.

If you did obtain the contents of the zone from the slave server, you could install the file as is on the rebuilt master server (ugly though it may look).

share|improve this answer
I get some contents, but no enough to set the complete zone. I thought slaves could, by default, transfer a zone back to it's master. – Juparave Jan 21 '13 at 3:10
You are correct: by default, they can: see under "allow-transfer" which says "If not specified, the default is to allow transfers to all hosts.". It's just that it's unusual for DNS server operators to leave the default configuration in place. – Celada Jan 21 '13 at 16:32

As was noted by others, zone transfers from slaves do work assuming the slaves are configured to allow it.

Regarding the method of performing a zone transfer, however, I want to note that AXFR (full transfer) would be a better choice than IXFR=0 (incremental transfer of changes since serial number 0).

There are several reasons for this, first of all AXFR was in the original spec while IXFR was added later (meaning that if you don't know what software the slaves run there is at least a chance that they could support full transfers even if they don't support incremental transfers). But, maybe more importantly, since you don't actually have any zone data at all, you don't want to have just some incremental changes. Sure, if you try to IXFR in a way that can't be fulfilled the server will give you the full zone contents but 0 very well could exist in the zone's history and it doesn't need to be the first version either, this all based on how serial number arithmetic and comparison works and how that means there is no actual min or max value (the serial rolls over in a defined manner instead of ending at the integer max value).

If the slaves do not allow zone transfers and the system administrators for the slave servers cannot help you, the remaining option to get the full data would seem to be restoring the data from backups.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.