Allowing resolution of off-server CNAMEs
Joseph S D Yao
jsdy at tux.org
Fri Jul 8 16:11:42 UTC 2011
It should be possible to set up an authoritative-only name server so
that it does not recurse for anyone [except perhaps itself], but still
allow someone to get a full resolution of a name whose canonical name is
elsewhere. IMHBUCO.
I started with this:
view all {
match-clients { any; };
allow-query { any; };
allow-query-cache { any; }; // Only on those RHEL servers
// which allowed it (*sigh*)
allow-recursion { none; };
zone "tld.example" {
type master;
file "data/zone.tld.example";
};
};
zone.tld.example:
$TTL 3h
@ SOA ...
@ NS ns1.tld.example.
@ NS ns2.tld.example.
sub NS ns1.sub.tld.example.
sub NS ns2.sub.tld.example.
ns1 A ...
ns2 A ...
ns1.sub A ...
ns2.sub A ...
target CNAME target.sub
In this case, trying to look up target.tld.example directly from
ns1.tld.example just gets you the CNAMEs but no A record. Of course, I
says to myself, it is trying to do recursion, which is not allowed. I
will fix it so that it does not have to do recursion, but to do
forwarding, which is an entirely completely and totally different
operation. I added to the view:
zone "sub.tld.example" {
type "forward";
forward only;
forwarders { ns1.sub's IP; ns2.sub's IP; };
};
Still not working. Unless I allow recursion! Which is SUPPOSED to be
an entirely etc.
Any ideas how to have a conceptually correct non-recursive authoritative
name server but still allow it to serve the A records?
Yes, I could have a slaved copy of the zone, but the master copy of the
zone is on an appliance, and one support person was horrified that I
used the GUI they supplied to do something else that BIND can do but
that is not part of the specific value-added software they supply.
(*sigh*) I'd rather that recursion controls only control recursion.
And not forwarding - have separate forwarding controls, says I.
--
/*********************************************************************\
**
** Joe Yao jsdy at tux.org - Joseph S. D. Yao
**
\*********************************************************************/
More information about the bind-users
mailing list