Allowing resolution of off-server CNAMEs

Kevin Darcy kcd at chrysler.com
Mon Jul 11 19:26:05 UTC 2011


On 7/8/2011 12:11 PM, Joseph S D Yao wrote:
> 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,
         Look at how RFC 1034 distinguishes "recursive" from "iterative":


    - In any system that has a distributed database, a particular name
    server may be presented with a query that can only be answered by
    some other server. The two general approaches to dealing with this
    problem are "recursive", in which the first server pursues the query
    for the client at another server, and "iterative", in which the
    server refers the client to another server and lets the client
    pursue the query.


I think it's pretty clear that what BIND calls "forwarding" is just a 
subset of what the standards consider "recursive" resolution, and the 
distinction you're trying to make between "forwarding" and "recursion" 
isn't sanctioned by the standards. Moreover, in terms of bits and bytes, 
a forwarded query *is* recursive (it has the RD set).

Maybe you need to ask yourself why you want to run a "non-authoritative" 
nameserver in the first place (?) Are you following best practices for 
purposes of security? Well, if you selectively poke "forwarding" holes 
in that non-authoritative "wall", then you're deviating from the best 
practices and compromising your security. Think about it: when you 
forward, you're trusting your forwarders (usually either by IP address 
or TSIG key), validating their responses (hopefully there's enough 
randomness to prevent a Kaminsky-style attack), populating a cache, etc. 
All the things that have led to security issues in the past. It's 
exactly those things which led to the "authoritative-only" best practice 
in the first place -- it simplifies the interaction, reduces the number 
of "moving parts", and thus prevents all sorts of issues. I don't think 
you want to be in the position of creating a *false*, Potemkin-Village 
sense of security by claiming outwardly to be "authoritative-only", yet 
all the while engaging in questionable forwarding practices behind the 
proverbial facade. Authoritative-only means authoritative-only: no 
recursive resolution allowed, not even on the back-end and/or going by a 
different name ("forwarding").

                                                                         
                                                                         
                                                                         
                 - Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110711/ded869c2/attachment.html>


More information about the bind-users mailing list