Forward zone problem

Fri Mar 17 00:56:50 UTC 2006

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
>
>
>
>
>
>
>
>
>
>  
>