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