Forward zone problem

[Barry Margolin]

In article <dvckf0$mfr$1 at sf1.isc.org>,
 "Stefanick, Andrew" <astefanick at metasolv.com> wrote:

> I am struggling with a forward zone issue in Bind 9
>  
> 
> We have many forward zones configured and they work fine.  They really
> amount to no more than a forward directive such as
> 
>  
> 
>  
> 
> zone "name.of.domain" {
> 
>     type forward;
> 
>     forwarders {w.x.y.z;};
> 
> };
> 
>  
> 
>  
> 
> We put in a new one, and it will not work.  nslookup shows it seemingly
> only trying to resolve the query internally.
> 
>  
> 
> If I set the server to the IP of the forwarder in the nslookup, then we
> can resolve the queries when posed directly to the remote DNS server.
> So, it is not a networking issue.
> 
>  
> 
> I do not understand the logic/sequence that occurs when a query is posed
> that should be sent to a forwarder.  Where do the root-server  records
> come in, and why even.  Doesn't the forward directive tell the server,
> "don't even bother, just go to w.x.y.z for the answer"

Only if it would already recurse.  It means "don't follow the NS records 
for the zone, go to w.x.y.z instead (or first, if you have "forward 
first" configured)."

If the server is authoritative for the containing zone, and doesn't 
delegate the subzone, it won't recurse and won't use the forwarders.

> here are some example of using dig against some of the forward zones
> that work.  The AUTHORITY section shows the name of the remote DNS that
> controls the domain.
> 
>  
> 
> When I try dig for the new forwarder, the only AUTHORITY that shows is
> the A.rootserver.

Are you getting an SOA record or NS records in the AUTHORITY section?  
Why don't you post the actual results, like you did for the successful 
cases, rather than just describing it vaguely?

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***