Forward zone problem

Kevin Darcy kcd at daimlerchrysler.com
Fri Mar 17 03:43:39 UTC 2006


"Forward first" is the default. Unless you explicitly specify "forward 
only", that's the forwarding mode you're using.

- Kevin

Stefanick, Andrew wrote:

>Agreed, but there are not forward first directives.
>
>I am sure it is some stupid/ hidden thing I am missing.
>
>These DNS servers have over 20 forward bind directives, and they work
>fine.
>
>I am baffled as to why this one won't work.
>
>
>
>-----Original Message-----
>From: Kevin Darcy [mailto:kcd at daimlerchrysler.com] 
>Sent: Thursday, March 16, 2006 7:29 PM
>To: bind-users at isc.org
>Subject: Re: Forward zone problem
>
>Stefanick, Andrew wrote:
>
>  
>
>>I think what I really am asking is:
>>
>>Given a simple 3 line forward directive, if it is not working, what are
>>the potential causes?
>>
>>1.  The DNS server thinks it is authoritive for this zone, so it will
>>never forward.  If so, how do I prove that theory and correct it.
>>
>>    
>>
>Unlikely that you would have missed that scenario. If you already had an
>
>authoritative (master or slave) zone definition, then the "type forward"
>
>definition would be a duplicate. You'd see an error message to that 
>effect in the logs or if you ran named-checkconf.
>
>  
>
>>2.  syntax error
>>
>>    
>>
>Syntax error in what? In the "type forward" zone definition? From what 
>you posted before, the syntax looks fine. You could run named-checkconf 
>to make sure.
>
>  
>
>>3.  Network connection.  But I can do nslookup and set the server to
>>    
>>
>the
>  
>
>>IP I use in the forwarder, and I can resolve the query.
>>
>>    
>>
>Probably not the *direct* cause then. However, as I mentioned in a 
>previous message, if you are (mis)configured for "forward first" (which 
>is the default forwarding mode), and there is a transient problem with 
>your forwarder, maybe your nameserver would try to query the .gprs name 
>on the Internet, get an NXDOMAIN response, and store that "negative" 
>cache entry for some period of time. It's a possibility that's worth 
>considering, at least...
>
>- Kevin
>
>  
>
>>-----Original Message-----
>>From: Kevin Darcy [mailto:kcd at daimlerchrysler.com] 
>>Sent: Thursday, March 16, 2006 4:57 PM
>>To: bind-users at isc.org
>>Subject: Re: Forward zone problem
>>
>>You're aware the that the .gprs TLD *doesn't*actually*exist* in the 
>>Internet DNS, right? So if your nameserver ever tries to look up .gprs 
>>names on the Internet, it'll probably get a "no such domain" response, 
>>and it will cache that "negative" response for some period of time, and
>>    
>>
>
>  
>
>>any .gprs queries it gets in the interim will be responded to with
>>NXDOMAIN.
>>
>>For this reason, in the absence of some special "hints" file, you'll 
>>need to specify your forwarding mode as "forward only". This will 
>>prevent your nameserver from going out and trying to resolve names in 
>>the Internet DNS if there is some sort of transient problem talking to 
>>the forwarder. That's what I suspect is happening here.
>>
>>- Kevin
>>
>>Stefanick, Andrew wrote:
>>
>> 
>>
>>    
>>
>>>Here is a dig for a name that works with a forward zone on the system
>>>currently:
>>>
>>>
>>># ./dig wap.cingular.mnc410.mcc310.gprs a
>>>
>>>; <<>> DiG 9.2.2 <<>> wap.cingular.mnc410.mcc310.gprs a
>>>;; global options:  printcmd
>>>;; Got answer:
>>>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1122
>>>;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
>>>
>>>;; QUESTION SECTION:
>>>;wap.cingular.mnc410.mcc310.gprs. IN    A
>>>
>>>;; ANSWER SECTION:
>>>wap.cingular.mnc410.mcc310.gprs. 234 IN A       66.102.184.193
>>>wap.cingular.mnc410.mcc310.gprs. 234 IN A       66.102.185.193
>>>
>>>;; AUTHORITY SECTION:
>>>mnc410.mcc310.gprs.     447     IN      NS
>>>wcrdns1.mnc410.mcc310.gprs.
>>>mnc410.mcc310.gprs.     447     IN      NS
>>>atlrdns1.mnc410.mcc310.gprs.
>>>
>>>;; ADDITIONAL SECTION:
>>>wcrdns1.mnc410.mcc310.gprs. 604647 IN   A       66.102.185.70
>>>atlrdns1.mnc410.mcc310.gprs. 604647 IN  A       66.102.184.70
>>>
>>>;; Query time: 9 msec
>>>;; SERVER: 12.25.118.5#53(12.25.118.5)
>>>;; WHEN: Thu Mar 16 16:43:06 2006
>>>;; MSG SIZE  rcvd: 158
>>>
>>>#
>>>
>>>
>>>This is a dig against the forwarder that is not working:
>>>
>>>
>>>********************** from epictouch *********************
>>>
>>># ./dig internet.epictouch.mnc610.mcc310.gprs a
>>>
>>>; <<>> DiG 9.2.2 <<>> internet.epictouch.mnc610.mcc310.gprs a
>>>;; global options:  printcmd
>>>;; Got answer:
>>>;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47408
>>>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>>>
>>>;; QUESTION SECTION:
>>>;internet.epictouch.mnc610.mcc310.gprs. IN A
>>>
>>>;; AUTHORITY SECTION:
>>>.                       10800   IN      SOA     a.root-servers.net.
>>>nstld.verisi
>>>gn-grs.com. 2006031600 1800 900 604800 86400
>>>
>>>;; Query time: 118 msec
>>>;; SERVER: 12.25.118.10#53(12.25.118.10)
>>>;; WHEN: Thu Mar 16 16:44:38 2006
>>>;; MSG SIZE  rcvd: 130
>>>
>>>The is no zone file on the machine for any of the configured forward
>>>zone.  They only exist as directives in named.conf.
>>>
>>>But I see the posts that DNS will not forward for something it is
>>>authoritive for.  Where would this authority reside?  There are no
>>>      
>>>
>zone
>  
>
>>>files with any matching names of the forward zones.
>>>
>>>My only thought is perhaps the segment   mcc310.gprs  is somehow
>>>authoritive on the server, but that would not explain how the cingular
>>>dig worked then.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: Stefanick, Andrew 
>>>Sent: Thursday, March 16, 2006 12:58 PM
>>>To: bind-users at isc.org
>>>Subject: Forward zone problem
>>>
>>>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"
>>>
>>>
>>>
>>>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.
>>>
>>>
>>>
>>>I really don't get it.
>>>
>>>
>>>
>>>I ONLY put in the 3 line directive, and I am done.
>>>
>>>
>>>
>>>I don't even know what to change/try.  It is too simple to implement.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>># ./dig mnc150.mcc310.gprs
>>>
>>>
>>>
>>>; <<>> DiG 9.2.2 <<>> mnc150.mcc310.gprs
>>>
>>>;; global options:  printcmd
>>>
>>>;; Got answer:
>>>
>>>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61159
>>>
>>>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>>>
>>>
>>>
>>>;; QUESTION SECTION:
>>>
>>>;mnc150.mcc310.gprs.            IN      A
>>>
>>>
>>>
>>>;; AUTHORITY SECTION:
>>>
>>>mnc150.mcc310.gprs.     600     IN      SOA
>>>wcrdns1.mnc410.mcc310.gprs. root
>>>
>>>.wcrdns1.mnc410.mcc310.gprs. 2006030303 600 3600 1209600 600
>>>
>>>
>>>
>>>;; Query time: 115 msec
>>>
>>>;; SERVER: 12.25.118.5#53(12.25.118.5)
>>>
>>>;; WHEN: Thu Mar 16 15:37:45 2006
>>>
>>>;; MSG SIZE  rcvd: 92
>>>
>>>
>>>
>>># ./dig mnc170.mcc310.gprs
>>>
>>>
>>>
>>>; <<>> DiG 9.2.2 <<>> mnc170.mcc310.gprs
>>>
>>>;; global options:  printcmd
>>>
>>>;; Got answer:
>>>
>>>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3961
>>>
>>>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>>>
>>>
>>>
>>>;; QUESTION SECTION:
>>>
>>>;mnc170.mcc310.gprs.            IN      A
>>>
>>>
>>>
>>>;; AUTHORITY SECTION:
>>>
>>>mnc170.mcc310.gprs.     600     IN      SOA
>>>wcrdns1.mnc410.mcc310.gprs. root
>>>
>>>.wcrdns1.mnc410.mcc310.gprs. 2006030303 600 3600 1209600 600
>>>
>>>
>>>
>>>;; Query time: 99 msec
>>>
>>>;; SERVER: 12.25.118.5#53(12.25.118.5)
>>>
>>>;; WHEN: Thu Mar 16 15:38:05 2006
>>>
>>>;; MSG SIZE  rcvd: 92
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>   
>>>
>>>      
>>>
>>
>>
>>
>>
>>
>>
>>
>> 
>>
>>    
>>
>
>
>
>
>
>
>
>
>  
>




More information about the bind-users mailing list