acl's and some suggestions for ISC
kcd at daimlerchrysler.com
Fri Jan 23 02:40:50 UTC 2004
>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
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.
More information about the bind-users