bind-8.2.3, zone transfer ACLs, and slave server log silence.

Ted_Rule at Ted_Rule at
Wed May 9 14:09:40 UTC 2001

Apologies in advance if this has been rectified in 8.2.4; I had a rummage
through the
Changelog and couldn't see anything which seemed to particularly apply, so here

Whilst trying to set up a new stealth slave secondary for a zone, I managed to
forget to
add the slave's IP to the master' allow-transfer acl. This highlighted a small
wherein the slave doesn't appear to log its failure to perform a zone transfer
due to
a DNS REFUSED response. The master, of course, logs an "unapproaved transfer"

This might have serious consequences for a slave where the master was initially
somewhat security lax, but where the master's admin tightened security a bit
by locking out unapproved zone transfers and made a typo leaving one the slaves
in limbo.

The syslog's I managed to get with no debug enabled between a bind 8.2.2-P7
and a bind-8.2.3 slave are as per below with fttvgpsutil2 slave to intranot for
the zone.

May  9 14:34:38 intranot named[692]: Sent NOTIFY for " IN
SOA" (; 1 NS, 1 A
May  9 14:34:38 intranot named[692]: Received NOTIFY answer from
for " IN SOA"
May  9 14:34:38 fttvgpsutil2 named[29074]: notify: info: rcvd
NOTIFY(, IN, SOA) from [].53253
May  9 14:34:38 intranot named[692]: unapproved AXFR from [].1510
for "" (acl)

The nearest I can easily see in some bind 8.2.2-P5 source I have to hand for
where this
falure to log the failure occurs is as per below from
An all too brief scan of the source suggests that this syslog:

                                  "[%s] transfer refused from [%s], zone %s\n",

is never reached because it is enclosed by:

     if (len < HFIXEDSZ) {

whlist the syslog is enclosed by

       (len >= HFIXEDSZ)) {

( I admit that there's a jump to badrec: here which probably invalidates my
quick reading of this bit of code )

In any event, I feel the transfer should be logged at LOG_WARNING level.

A related matter is that I managed to add the stealth server to the also-notify
list , but not
the allow-transfer acl. Since one fully expects any server which is notified to
perform a zone
transfer, one is strongly tempted to grant zone transfer rights to ANY server
which already
has also-notify enabled, and reduce the potential for a mismatch between the
and also-notify acls.

In a fully DNSSEC world, one could almost create the allow-transfer acl on the
fly based on
all the fully authenticated IPs of all the NS records for a zone - but that's
probably stretching
the issue far too far and trusting far too many DNS admins to get all their glue

Ted Rule,
Flextech Television.

Within named-xfer.c, ( from bind 8.2.2-P5 source )

                                if (len < HFIXEDSZ) {

                                        alen = sizeof my_addr;
                                        if (getsockname(s, (struct sockaddr *)
                                                        &my_addr, &alen) < 0)
                                                        "[errno %d]", errno);
                                        if ((hp->rcode == REFUSED) &&
                                            (len >= HFIXEDSZ)) {
                                  "[%s] transfer refused from [%s], zone %s\n",


This E-mail message, including any attachments, is intended only for the person
or entity to which it is addressed, and may contain confidential information.

If you are not the intended recipient, any review, retransmission, disclosure,
copying, modification or other use of this E-mail message or attachments is
strictly forbidden.

If you have received this E-mail message in error, please contact the author and
 delete the message and any attachments from your computer.

You are also advised that the views and opinions expressed in this E-mail
message and any attachments are the author's own, and may not reflect the views
and opinions of FLEXTECH Television Limited.

More information about the bind-workers mailing list