forwarding a subdomain

Barry Margolin barmar at
Wed Nov 17 04:26:10 UTC 2004

In article <cndfgm$gpa$1 at>,
 Edward Buck <ed at> wrote:

> So, is this a limitation by design?  Is there a workaround for what I'm 
> trying to do?

Configure your server as a slave, rather than a forwarder.

> If I delegate a subdomain to a nameserver, intuitively I would expect 
> that nameserver to be authoritative for that subdomain regardless of 
> whether the zone data is master, slave or a forward.

That's the point.  Since the zone is delegated to the server, other 
servers expect that nameserver to be authoritative, so they don't ask it 
to recurse.  But when you configure the zone as "type forward", the 
server is *not* authoritative.

Being authoritative is a consequence of how the server is configured, 
*not* how the zone is delegated.  Delegation specifies who *should* be 
authoritative, but it doesn't actually cause a server to be 

> The use case I'm referring to is a private RBL on an internal lan 
> running rbldnsd.  I was planning to run rbldnsd on an internal address 
> and front-end it with bind to take advantage of bind's ACL support.  The 
> scenario would be something like:
> public rbl query
> 	|
> 	v
> nameserver (bind with ACLs)
> 	|
> 	v
> forward to internal server running rbldnsd
> 	|
> 	v
> answer back to original query
> At the moment, this only works for cached data.  Is there a way to force 
> recursion on a forwarded subdomain for which the server is authoritative?

Servers only recurse when they're asked to.  If the client says "don't 
recurse", BIND won't.

The source code is available, so you could always patch your copy to 
ignore the setting of the RD bit, and act as if it's always set.

Barry Margolin, barmar at
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

More information about the bind-users mailing list