Forward zone problem

Stefanick, Andrew astefanick at metasolv.com
Fri Mar 17 04:48:25 UTC 2006




This is the email that started this whole thing.

Look at the final result of this nslookup.  Are you saying that this
negative respone will now be in the cache, and even if it COULD work,
this negative response will mask it?  Does the  expire=604800  in the
final response mean that this negative result will remain in place for
one week??




Andrew, I have followed you direction and created a new domain/zone for
a new roaming partner but we are unable to do nslookups. It does not
appear to be forwarding to the IP address I specified. I have attached
the output from an nslookup with debug turned on. What appears strange
to me is I lookup "internet.epictouch.mnc610.mcc560.gprs" and I see it
trying to resolve
"internet.epictouch.mnc610.mcc310.gprs.mnc560.mcc310.gprs"




> internet.epictouch.mnc610.mcc310.gprs 
Server:  youndns1.mnc560.mcc310.gprs 
Address:  12.25.118.5 

;; res_nmkquery(QUERY, internet.epictouch.mnc610.mcc310.gprs, IN, A) 
------------ 
SendRequest(), len 55 
    HEADER: 
        opcode = QUERY, id = 27698, rcode = NOERROR 
        header flags:  query, want recursion 
        questions = 1,  answers = 0,  authority records = 0,  additional
= 0 

    QUESTIONS: 
        internet.epictouch.mnc610.mcc310.gprs, type = A, class = IN 

------------ 
------------ 
Got answer (130 bytes): 
    HEADER: 
        opcode = QUERY, id = 27698, rcode = NXDOMAIN 
        header flags:  response, want recursion, recursion avail. 
        questions = 1,  answers = 0,  authority records = 1,  additional
= 0 

    QUESTIONS: 
        internet.epictouch.mnc610.mcc310.gprs, type = A, class = IN 
    AUTHORITY RECORDS: 
    ->  (root) 
        type = SOA, class = IN, dlen = 64 
        ttl = 10782 (10782) 
        origin = A.ROOT-SERVERS.NET 
        mail addr = NSTLD.VERISIGN-GRS.COM 
        serial = 2006031401 
        refresh = 1800 (30M) 
        retry   = 900 (15M) 
        expire  = 604800 (1W) 
        minimum ttl = 86400 (1D) 

------------ 
;; res_nmkquery(QUERY,
internet.epictouch.mnc610.mcc310.gprs.mnc560.mcc310.gprs, 
 IN, A) 
------------ 
SendRequest(), len 74 
    HEADER: 
        opcode = QUERY, id = 27699, rcode = NOERROR 
        header flags:  query, want recursion 
        questions = 1,  answers = 0,  authority records = 0,  additional
= 0 

    QUESTIONS: 
        internet.epictouch.mnc610.mcc310.gprs.mnc560.mcc310.gprs, type =
A, clas 
s = IN 

------------ 
------------ 
Got answer (125 bytes): 
    HEADER: 
        opcode = QUERY, id = 27699, rcode = NXDOMAIN 
        header flags:  response, auth. answer, want recursion, recursion
avail. 
        questions = 1,  answers = 0,  authority records = 1,  additional
= 0 

    QUESTIONS: 
        internet.epictouch.mnc610.mcc310.gprs.mnc560.mcc310.gprs, type =
A, clas 
s = IN 
    AUTHORITY RECORDS: 
    ->  mnc560.mcc310.gprs 
        type = SOA, class = IN, dlen = 39 
        ttl = 0 (0S) 
        origin = youndns1.mnc560.mcc310.gprs 
        mail addr = admin.mnc560.mcc310.gprs 
        serial = 143 
        refresh = 3600 (1H) 
        retry   = 900 (15M) 
        expire  = 604800 (1W) 
        minimum ttl = 43200 (12H) 

------------ 
;; res_nmkquery(QUERY,
internet.epictouch.mnc610.mcc310.gprs.mcc310.gprs, IN, A) 
------------ 
SendRequest(), len 67 
    HEADER: 
        opcode = QUERY, id = 27700, rcode = NOERROR 
        header flags:  query, want recursion 
        questions = 1,  answers = 0,  authority records = 0,  additional
= 0 

    QUESTIONS: 
        internet.epictouch.mnc610.mcc310.gprs.mcc310.gprs, type = A,
class = IN 

------------ 
------------ 
Got answer (142 bytes): 
    HEADER: 
        opcode = QUERY, id = 27700, rcode = NXDOMAIN 
        header flags:  response, want recursion, recursion avail. 
        questions = 1,  answers = 0,  authority records = 1,  additional
= 0 

    QUESTIONS: 
        internet.epictouch.mnc610.mcc310.gprs.mcc310.gprs, type = A,
class = IN 
    AUTHORITY RECORDS: 
    ->  (root) 
        type = SOA, class = IN, dlen = 64 
        ttl = 10782 (10782) 
        origin = a.root-servers.net 
        mail addr = nstld.verisign-grs.com 
        serial = 2006031401 
        refresh = 1800 (30M) 
        retry   = 900 (15M) 
        expire  = 604800 (1W) 
        minimum ttl = 86400 (1D) 

------------ 
*** youndns1.mnc560.mcc310.gprs can't find
internet.epictouch.mnc610.mcc310.gprs 
: Non-existent host/domain 
>

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