subdomain forwarding on a domain-authoritative dns

[Chris Buxton]

On Apr 16, 2009, at 7:11 AM, <Philippe.Simonet at swisscom.com> <Philippe.Simonet at swisscom.com 
 > wrote:
> Hello ISC users
>
> in a special environment, I have to forward 'sub.domain.com', on a  
> dns where I'm
> master for 'domain.com'. all subsequent subdomains of  
> 'sub.domain.com' must
> be reachede through this forwarder. I cannot use iteration here  
> because the
> dns authoritative for e.g. 'sub1.sub.comain.com' are not reachable  
> from this dns.
>
> zone domain.com {
> 	type master;
> 	file "db.domain.com";
> }
> zone sub.domain.com {
> 	type forward;
> 	forwarders { 1.2.3.4; };
> }
>
> all this is is working only if I define a NS for sub.domain.com in  
> 'domain.com' :
> ----
> sub.domain.com	IN NS	subns.domain.com
> subns.domain.com  IN A  1.2.3.4
> ----
> I also observed that this NS is not used by bind, because a dummy  
> address is enough
> to do the forward correctly. this NS has only to be present and the  
> forwarding works.
>
>
> my question is : is this a bind 'feature' or is this a bad idea to  
> use that ?
> I have to ensure that this behaviour will be the same in the next  
> bind releases.

What you're seeing is the expected behavior.

- Without the delegation record (the NS record), named thinks it's  
authoritative for the zone and won't forward recursive queries.  
Instead, it returns a negative answer.

- With the delegation but without the conditional forwarding zone,  
named would try to follow the delegation (and glue) in response to a  
recursive query.

- With both delegation and conditional forwarding zone, named forwards  
recursive queries for the subzone as expected.

The reason to care about the content of the delegation and glue  
records is in case the server gets an iterative query, from another  
name server. If it will never get such an iterative query, then you  
can use bogus data as you have done.

Chris Buxton
Professional Services
Men & Mice