some definitions of terms im searching for

[Jonathan Horne]

On Friday 08 September 2006 22:02, Kevin Darcy wrote:
> 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

thanks for your reply, and for answering my questions.

btw, when i said "the none zone" before, i really meant "the external zone 
that had 'none' specified, as opposed to my other internal zone that 
had 'any' specified".

so let me ask one more questions to clarify... transfering a zone is an act 
that another dns server does?  this setting doesnt affect clients who query 
does it?

cheers,
jonathan