Allowing recursion for just specific zones

[Brian Candler]

Hello,

I am trying to configure a bind9 view to allow recursion just for certain
domains. (This is bind-9.2.4-16.EL4 under RHEL4).

In fact, it doesn't even have to be real recursion, just forwarding to an
upstream recursive nameserver. The point is that the clients are only
authorised to look up names under a handful of domains, and the rest should
be denied.

However, the various attempts I've tried have failed so far. As far as I can
tell:

1. "recursion no" can only be set at the top (view) level, not overridden
at the zone level.

2. If I set "recursion no" at the view level, then a "type forward"
zone has no effect:

view "foo" {
recursion no;
...
zone "example.com" {
type forward;
forward only;
forwarders {192.0.2.1;};
};

-- query for foo.example.com returns only referral to root servers
(i.e. it is not forwarded)

3. If I make the view authoritative for the root zone, then a "type forward"
zone also has no effect:

view "foo" {
recursion yes;
...
zone "." {
type master;
file "named.zero"; // just SOA
allow-update {none;};
};
zone "example.com" {
type forward;
forward only;
forwarders {192.0.2.1;};
};

-- query for foo.example.com gives NXDOMAIN and the root SOA

4. Setting forwarders to an empty list at the top level doesn't prevent
forwarding, it just falls back to normal recursive lookup instead.

view "foo" {
recursion yes;
forward only;
forwarders {};
..
zone "example.com" {
type forward;
forward only;
forwarders {192.0.2.1;};
};

-- queries for bar.example.com are forwarded as expected
-- queries for baz.anythingelse.com are looked up recursively, which
is what I'm trying to prevent :-(

5. I don't have AXFR access to the upstream zones, so making the server
a slave for these zones is not an option.

At the moment the best I can do is to forward to a non-existent IP in the
top level, which makes unauthorised queries time out - clearly not ideal.

Anyone have any better suggestions?

Many thanks,

Brian.

[Chris Buxton]

Recursion is enabled/allowed at the view level, not the zone level.

One strategy would be to set up a view that matches recursive queries
only. Set allow-query to none at the view, then set it any (or
whatever) in each zone of type forward or stub.

Or if you want to use your root zone idea, make sure to populate it
with delegations to the domains that should resolve.

I'm not sure if the match-recursive statement existed in 9.2. You may
need to upgrade to something current.

Chris Buxton
BlueCat Networks

> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>

--
Sent from my mobile device

[Brian Candler]

On Mon, May 10, 2010 at 11:54:57AM -0700, Chris Buxton wrote:
> One strategy would be to set up a view that matches recursive queries
> only. Set allow-query to none at the view, then set it any (or
> whatever) in each zone of type forward or stub.

Thank you Chris.

Unfortunately, allow-query is rejected in forward zones. The error is
explicit:

option 'allow-query' is not allowed in 'forward' zone 'example.com'

The 9.2.4 ARM doesn't make this clear, but the 9.4.2 ARM does show a
restricted grammar for forward zones:

zone zone_name [class] {
type forward;
[ forward (only|first) ; ]
[ forwarders { [ ip_addr [port ip_port] ; ... ] }; ]
[ delegation-only yes_or_no ; ]
};

> Or if you want to use your root zone idea, make sure to populate it
> with delegations to the domains that should resolve.

Interesting. It seems to work even if I just delegate to 'localhost',
without having to hardcode the real NS RRs for the zone. That seems like a
bit of a frig though, which may confuse people maintaining it. And ideally
I'd prefer a REFUSED response to NXDOMAIN.

> I'm not sure if the match-recursive statement existed in 9.2. You may
> need to upgrade to something current.

There is "match-recursive-only" (boolean). Does that match queries with the
RD flag set? If so it won't make a difference here, because all the clients
are dumb endpoints which will set RD always.

The application, by the way, is supporting a network of kiosk-like
terminals. They run some third-party applications which need to make
external access to certain services across the Internet. Of course, the
firewall only lets them make connections to specific hosts/ports they need.
However I want to give a similar level of control for DNS lookups too;
otherwise, in the event of a virus infection, the virus could use the DNS as
a covert channel.

Regards,

Brian.

[Chris Buxton]

Yes, of course. I've made that mistake before, in fact.

Use a custom root zone, as I believe you originally mentioned, with
delegations to just the zones that should be reachable.

Or else set up secure proxies and disallow all DNS resolution (an
empty root zone).

Chris Buxton
BlueCat Networks

--

[Brian Candler]

> Or else set up secure proxies and disallow all DNS resolution (an
> empty root zone).

I'm not sure what you mean by "secure proxies". Do you mean some non-BIND
software capable of forwarding and filtering DNS queries/responses? If so,
do you have anything particular in mind?

Thanks,

Brian.

[Chris Buxton]

Close. I mean a properly-configured instance of squid, or a SOCKS
proxy, or whatever other non-DNS, application level proxy you want to
provide. Just configure your kiosks to use them. Then the kiosks
themselves don't need DNS resolution at all.

Chris Buxton
BlueCat Networks

--