Recursive Domain Query on Restricted Recursive DNS

[Kevin Darcy]

Forwarding is incompatible with "recursion no"; if you're not recursing, 
you're not forwarding. So you _have_ to open up recursion. Your access 
control will be implemented via allow-query, not via allow-recursion or 
"recursion no".

                                                                         
                        - Kevin

Nicolas Pence wrote:
> Forwarding seems to be the only functional option 
> but, still have the "how to limit" issue.
>
> I read that the only way to "secure" forward zones
> is to use "views", but didn´t find too much 
> documentation about limiting forwards with views.
>
> The following configuration, doesn´t work properly,
> I think I'm not understanding right how forwards
> works in this case.
>
> acl internals { allowedips/mask; allowedips2/mask; };
>
> view "internal" {
> 	match-clients { internals; }; 
> 	recursion yes;
> };
>
> view "allclients" {
> 	match-clients { any; };
> 	recursion no;
> zone "subdom.example.com" {
>         type forward;
>         forwarders { ip1; ip2; };
>   };
> };
>  
> thanks
>
>
> -----Mensaje original-----
> De: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] En nombre de Kevin Darcy
> Enviado el: Jueves, 29 de Noviembre de 2007 02:23
> Para: bind-users at isc.org
> Asunto: Re: Recursive Domain Query on Restricted Recursive DNS
>
> 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
>>
>>
>>
>>
>>
>>
>>   
>>     
>
>
>
>
>
>