some definitions of terms im searching for

[Kevin Darcy]

Jonathan Horne wrote:
> i was reading the article on bind and views with master/slaves here:
>
> http://www.oreillynet.com/pub/a/oreilly/networking/news/views_0501.html
>
> and i saw:
>
>         recursion yes;
>         recursion no;
>
> ...with yes being allowed on internal views, and no for external views.  what 
> exactly is recursion and what does it affect from the clients point of view 
> or operation?
>   
When a resolver provides "recursive" service to a client that requests 
it, what that means is that it will do all of the work of resolving that 
query -- which may mean making several queries of its own to various 
nameservers or possibly one or more other resolvers -- and then passing 
an answer, or, if no answer is available, an error indication, back to 
the client. Recursive resolvers are therefore much more complex 
programs/subsystems, and generally work a lot harder at DNS, than "stub" 
resolvers, such as one might find on a regular desktop or laptop PC 
running Windows, which only generate recursive queries and then parse 
the responses they get back from those queries.

Note that a resolver itself may make recursive queries to another 
resolver, if it is set up to "forward" all queries, or some specific set 
of queries. It is thus possible to set up resolvers in a cascade, 
although this is generally considered bad architecture, since it doesn't 
scale well (the resolvers at the apex of the forwarding hierarchy tend 
to get hammered) and in practice tends to be not very resilient to 
failures (each step in the hierarchy can be considered another potential 
Point of Failure).
> my second question was the:
>
>          allow-transfer { any; };
>          allow-transfer { none; };
>
> ...also used within internal and external respectively.  how exactly do those 
> affect a client?  i did notice that my slave was unable to transfer 
> the 'none' zone until i changed 'none' to 'ip-alias-of-slave'.  
The 'none' zone? I think you're misunderstanding the syntax of that 
substatement. What's inside the curly braces there identifies a 
particular set of zone-transfer *clients*, not zones. You can use either 
addresses or TSIG keys to identify the clients of interest. 
"allow-transfer { any; };" means that all clients are allowed to 
transfer, "allow-transfer { none; };" means that no clients are allowed 
to transfer.

The way that you restrict transfers on a zone-by-zone basis is not to 
specify a zone in the curly braces of the "allow-transfer" substatement, 
but to place the "allow-transfer" within the zone definition itself, e.g.

zone "example.com" {
type master;
file "example.com";
allow-transfer { 1.2.3.4; };
};

This would restrict transfers of the "example.com" zone to only the 
client at address 1.2.3.4. If you wanted a "global" restriction on zone 
transfers you'd put that allow-transfer substatement within the 
"options" substatement. This "global" restriction could then be 
overridden on a zone-by-zone basis if you desired.
> i would 
> assume that having just a single ip listed (of my slave) is basically the 
> same as 'none' security wise, 
No, it means the slave is allowed to transfer, but no-one else is. With 
"none" in that position, no client is allowed to transfer, not even the 
slave.

Bear in mind that there is nothing "automatic" about identifying the 
slaves for a zone, for purposes of allowing or disallowing zone-transfer 
access. Just because a particular box may show up in the apex NS records 
for a zone, for instance, or in the delegation NS records, doesn't mean 
the slave is automatically permitted for zone transfers. You'd have to 
explicitly allow the slave to transfer, if your default is to disallow 
zone transfers. Note that the default, when no allow-transfer statements 
are present in named.conf, is "allow-transfer { any; };" for all zones, 
i.e. zone transfers completely open. So you don't need to define that at 
a global level if you don't feel like it.

- Kevin