Recursive Domain Query on Restricted Recursive DNS

[Kevin Darcy]

Nicolas Pence wrote
>   
>> I think this is doable if you drop the global "allow-recursion" 
>> restriction (which at the global level is extraneous anyway because of the global allow-query), and then define the zones of interest as >"type stub" with "allow-query" opened up.
>>     
>  
> Ok is true, I should remove allow-recursion, is limited by allow-query & allow-query-cache
>
> I read about stub zones and there is the need of a "already known"
> (that if I understand how stub works)
>
> zone "subdom.example.com" {
> 	type stub;
> 	file "slaves/"subdom.example.com.zone";
> 	masters { ip1; ip2; };
> };
>
> so I don´t really have masters servers, but if the info is
> on cache can't just query this domain locally and allow anybody to do it?
>
>   
The problem is, you need to have _some_ way of telling named to allow 
queries for this particular domain. This implies a need for a "zone" 
definition, with your only options for type being "forward", "slave", 
"stub" or "master". Obviously "master" is not appropriate if you're not 
the source of the zone's data. "forward" might work, if you can find 
someone to recurse for you (don't use anyone's recursors without their 
permission of course). Forwarding can, however, be inefficient, in the 
case where there are descendant zones which are "closer" to your 
resolver than they are to your forwarders. Even in the case where they 
are equidistant, the forwarding "hop" adds a variable amount of latency 
to every query that you don't answer from your cache (more latency if 
the forwarders are busy of course, less if they aren't) that you 
generally don't want, as well as adding more potential points of 
failure. On the plus side, if the forwarders are serving several 
downstream resolvers, sometimes there is a synergy in that popular 
records are likely to be in the forwarders' cache, i.e. the "cache hit 
ratio" is high and, correspondingly, the frequency of having to go out 
to the authoritative nameservers is relatively low. This synergy can 
sometimes, but not usually, make up for the extra latency caused by the 
forwarding "hop" and the lack of adaptability to "closer" nameservers.

Both "slave" or "stub" require access to authoritative servers of the 
zone, and in comparing the two, as I explained earlier, "slave" requires 
_more_ permission (zone-transfer permission, as opposed to only the 
permission to query SOA and NS records), and generally speaking incurs 
more overhead, so that's why I usually recommend "stub" over "slave". 
There are exceptions, of course, unusual environments in which "stub" is 
actually more resource-intensive than "slave" (e.g. a zone that changes 
very infrequently and has a high REFRESH setting, where the query 
traffic is predominantly for RRsets in the zone which have low TTL 
values and thus must be fetched often). Moreover, "slave" zones provide 
redundancy that "stub" zones do not, which is sometimes a requirement.

So, to summarize:

master: only appropriate if you are the source of the data. You're 
authoritative for the zone data, so the TTLs on the RRsets in the zone 
have no effect on your performance in resolving queries.

slave: requires SOA access to one or more authoritative servers for the 
zone, and
additionally requires zone-transfer permission. You're authoritative for 
the zone, so the TTLs of the RRsets in the zone don't matter to you, but 
you may incur significant overhead costs if the zone changes frequently, 
especially if your "masters" don't support IXFR. Also, if the REFRESH 
setting of the zone is set low, significant overhead might also be 
incurred from all of the refresh queries you make periodically to the 
masters.

forward: requires that your forwarders honor recursion. Adds a 
guaranteed "hop", to every query which isn't answered directly from 
cache, which can impact latency negatively. Can be even more inefficient 
when there are descendant zones with nameservers close to yours, since 
everything still needs to go through the forwarders regardless, even 
though it's not the most efficient resolution path (forwarding defeats 
the inherent adaptability of regular iterative forwarding, in other 
words). It should be noted, however, that in some cases forcing 
everything through forwarders is a *requirement* rather than a 
detriment, since your nameservers might not be able to talk directly to 
the nameservers of the relevant descendant zones. With forwarding, 
you're *not* authoritative for the zone, so this can be inefficient if 
many of your incoming queries are for low-TTL records.

stub: requires SOA/NS access to one or more authoritative servers for 
the zone. You're *not*authoritative for the zone, so this can 
inefficient if many of your incoming queries are for low-TTL records. 
Even though "stub" doesn't replicate the whole zone, refresh queries are 
still sent, so if the REFRESH setting of the zone is set low, 
significant overhead might also be incurred from this traffic.

                                                                         
                        - Kevin

>
>
> -----Mensaje original-----
> De: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] En nombre de Kevin Darcy
> Enviado el: Miércoles, 28 de Noviembre de 2007 01:19
> Para: bind-users at isc.org
> Asunto: Re: Recursive Domain Query on Restricted Recursive DNS
>
> Nicolas Pence wrote:
>   
>> Hi, I need to know how to set up the following solution:
>>  
>> - I have a Recursive DNS that is restricted to only wanted IP ranges, 
>> running Bind 9.3.2
>>  
>> acl mynet { iprange1/mask; iprange2/mask; iprange3/mask; };
>>  
>> options {
>> allow-recursion { mynet; };
>> allow-query { mynet; };
>> allow-query-cache { mynet; };
>> };
>>   
>>     
> Is this a working configuration? allow-query-cache doesn't exist in 9.3.2.
>
>   
>>  
>> - But I see some people with my NS configured doing queries to a 
>> domain name that I really want them to reach, so what I need is to 
>> enable queries "only"
>> to this domain name
>> "subdom.example.com" to anybody who query my server like doing:
>>  
>> allow-query { any; };
>>  
>> - subdom.example.com is not mine so I can't be auth for this domain 
>> and resolve the issue setting a master nor a slave zone.
>>  
>>  
>> Is this task possible? 
>>   
>>     
> I think this is doable if you drop the global "allow-recursion" 
> restriction (which at the global level is extraneous anyway because of the global allow-query), and then define the zones of interest as "type stub" with "allow-query" opened up.
>
> "Type slave" should work also, of course, but that would, in addition to the above, require zone-transfer permission/authority and is likely to incur more overhead than "type stub" (depending on a variety of factors, e.g. zone REFRESH setting, whether the remote side supports/honors IXFR, TTL of the most popularly-queried records, frequency of changes to the zone, etc.)
>
>                                                                          
>                            - Kevin
>
>
>
>
>
>
>