Queries for secondary partial reverse DNS being blocked by good ACLs

Fri Jul 16 23:04:02 UTC 1999

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

BIND 8.2.1, Solaris 2.6 (Sparc)

I recently started secondarying a set of domains for a friend. One of the
domains is his partial reverse DNS (a-la RFC 2317) for his network, a /29.
I use ACLs to lock down access for various things, one of which is that so
outside networks can only query my DNS server for the domains I host
(primary and secondary), rather than use it as a general query server.

Now, everything works fine with the 6 or so other domains I brought up
last night. However, the *exact same ACL* is apparently being ignored on
the partial reverse DNS domains. It looks as if BIND is ignoring the
specific allow-query statement in the zone record for the partial reverse
domain, and is instead only looking at the general allow-query I have at
the top of the file. I tested this out by replacing the global allow-query
with an any statement, and lo and behold, I can query from outside now.

The global statement is:

allow-query { internal; kabir; };

where internal is my network (a /28), and kabir is his network (the
aforementioned /29).

These are the statements for the partial reverse domain:

zone "144.101.216.in-addr.arpa" {
        type slave;
        masters { 216.101.144.149; };
        file "db.216.101.144";
        check-names fail;
        allow-update {internal; kabir; };
        allow-query { any; };
        allow-transfer { internal; kabir; audit; };
};

zone "144/29.144.101.216.in-addr.arpa" {
        type slave;
        masters { 216.101.144.149; };
        file "db.216.101.144";
        check-names fail;
        allow-update { internal; kabir; };
        allow-query { any; };
        allow-transfer { internal; kabir; audit; };
};

with specific allow-query { any; }; statements.

As it stands, any queries for this partial reverse from outside my and his
networks is refused, and generates a message like this:

Jul 16 14:11:28 veris3 named[1689]: unapproved query from
[206.13.28.11].59891 for "144.144.101.216.in-addr.arpa" 

which is completely correct if the query was supposed to be blocked, which
it's not.