Subdomain nameserver configuration question...

Chris Buxton cbuxton at menandmice.com
Tue Jul 8 18:58:36 UTC 2008


On Jul 8, 2008, at 11:33 AM, Kyle McDonald wrote:
> Chris Buxton wrote:
>> Your basic problem is that your authoritative name servers are also
>> doing recursion. If you can avoid this, do so - turn recursion off on
>> the name servers that host the subdomain.
> Ok. I have, and want, the clients in the subdomain to use these  
> servers
> (in their resolv.conf) to resolve queries. Doesn't that mean I need
> recursion on?  Is that a bad idea?
>>

Using your servers for recursion makes things more complex, and can  
cause problems in certain circumstances. However, in your case, it may  
be a reasonable thing to do.

>> If your authoritative name servers must also perform recursion, set  
>> up
>> either stub zones or slave zones for the apex(es) of the internal
>> domain(s) - this may be the "parent domain" you mentioned, or the
>> parent of that domain, or possibly even further upstream in the
>> namespace hierarchy. If you have any global forwarding turned on,
>> conditionally turn it off for these stub or slave zones.
>>
> I'm not sure I'm understanding this. Create stub or slave zones on my
> name servers? or on the parent?

On your servers. You've already done this (with a slave zone), so I  
was simply pointing out that either a slave zone or a stub zone would  
be the best solution. (Personally, I favor the stub zone.)

> The parent domain is managed by Win2k3
> DNS servers and I don't think they have the concept of 'stub' zones.

Yes they do. But that wasn't the point - a stub zone there should not  
be necessary.

> I did make my servers slaves of the parent. That solved it, but it  
> seems
> like a hack. After reading up more on forwarders, I was thinking of
> adding a 'forward' zone named after the parent which pointed to the
> parent domain's nameservers like:

Don't use forwarding. Just don't. (There has been some discussion on  
the list on this topic, but in this particular situation, you almost  
certainly should not use forwarding. It would be a very strange  
situation indeed if forwarding were required, and if it is not  
required, you should not use it here.)

> Is this what you mean by stub? Actually if you mean that I should  
> create
> a stub on my server, then I guess you're right, that should work
> similiar to the forwarder or slave.

Somewhat similar to a slave zone, except the data is considered cached  
rather than authoritative, and there's a lot less data retrieved from  
the parent zone's servers. Also, it means they don't have to open zone  
transfers to you.

> So it seems I have a bunch of options:
>
>  1)  Disable  recursion. Optionally:
>       a)  configure  clients to resolve with parent servers.
>       b)  configure global forwarding to parent servers.

Not quite right.

1) Disable recursion. Set up separate recursion servers that know  
where to find the parent zone(s) (using one or more stub zones).

Do not use forwarding. And the servers for the parent zone absolutely  
should not be doing recursion. (If they are, ask the admins to turn it  
off, and set up replacement resolving name servers elsewhere.)

>   2) Setup Selective forwarding with a 'forward' zone for the parent  
> domain.

Not a good option.

>   3) Setup a 'stub' zone for the parent domain. (Is this any different
> than the 'forward' zone?)

Yes. The crucial difference (not the only difference) is that, with a  
stub zone, your server sends iterative queries upstream. With  
forwarding, it sends recursive queries.

>   4) Setup 'slave' zones of the partent, complete with zone transfers,
> updates, etc.

Almost as good as the previous option, in my opinion, but close enough  
as to be debatable.

> Right now I'm thinking tha #2 sounds best, with 1b as a second choice.

My replacement option 1 is your best bet. Second best is 3 (or  
possibly 4, but I like 3 better).

> Anything wrong with my logic or understanding?

Don't use forwarding. It's a hazard to troubleshooting.

Chris Buxton
Professional Services
Men & Mice



More information about the bind-users mailing list