acl's and some suggestions for ISC

[Kevin Darcy]

/dev/rob0 wrote:

>I'm setting up BIND at a customer site, freeing them (me) from the
>dreaded djbdns. Ahhh, nice. I set up a master (on an internal server)
>and a slave (on the gateway/router.) I thought I'd try using some acl
>statements to ease the transition.
>
>The new master BIND server is still running djbdns: tinydns on localhost
>and dnscache on its Ethernet interface. So I made an eth0:dns alias on
>another IP and used that as the "listen-on" address. 
>
>I was hoping to use an acl on the slave server, rather than put the IP
>in the masters option for each of several zone statements. That way I'd
>only have one place to edit when I change over with BIND on the main IP.
>It seems that "masters" can't use an acl. (Yes, the acl statement came
>before the zone statement.)
>
>Why not? The BIND 9 Configuration Reference implied that acl's could be
>used anywhere one might need a list of IP's or netblocks. There really
>wasn't much said about "masters" syntax, but I see on closer examination
>now that some options say "address_match_list", but masters does not.
>Why can't "masters" use an address_match_list?
>
I don't speak for ISC, but I suspect one reason might be to prevent 
admins from accidentally making their slaves less secure than they 
realize. What's in the "masters" clause is not just for the internal use 
of that box, but actually establishes a form of trust between the slave 
and its master(s), a trust relationship which could potentially be 
exploited or abused. For instance, what if someone included an address 
match list of 192.168.1.0/24 -- either directly or via a named acl -- in 
a "masters" clause? That might seem a nifty thing to do if you have 2 or 
more masters in that address range. But what if the address range is 
later subdivided, with part of it becoming "untrusted"? Then something 
in that untrusted range could potentially spoof a NOTIFY to the slave 
and voila! inject a spoofed version of a DNS zone into it. (Sure, 
address spoofing itself is also possible but significantly more 
difficult if the proper controls are in place in the routers, switches, 
firewalls, etc. And granted, anyone who is really *serious* about 
security is going to TSIG-authenticate zone transfers anyway, so I'm 
talking about the middle ground here between super-paranoid and 
trivially spoofed).

You could say "okay, then just have a separate kind of 'acl' which 
doesn't permit fancy combinations of address prefixes and/or negation", 
i.e. this new "lite" acl would just be a symbolic name for a bunch of 
enumerated addresses, keys and/or nested "lite" acls. Sure, but if 
you're going to special-case things like that *solely* for the "masters" 
clause, why not special-case the "masters" clause itself and just say 
one can't use address_match_lists in it? Keep It Simple.

                                                                         
                                                         - Kevin