Forward zone problem
Stefanick, Andrew
astefanick at metasolv.com
Fri Mar 17 03:15:50 UTC 2006
OK.
But this is DNS working between Wireless service providers.
Each provider (Verizon, Cingular, Voicestream, etc) maintain DNS entries
for the APNs that they offer for their customers.
As customers roam into different coverage areas, their queries for APNs
are received by other carrier's DNS servers, and the carriers forward
these queries back to the correct DNS servers of the "home" DNS for
these roamers.
If I am Verizon, I maintain APNs for my zone, which is (say)
mnc340.mcc310.gprs . Inside that zone are A records for my wap server,
mms server, etc.
Your Roaming Partner agreements specifies which forward zone and
associated IPs you should use for the roamers passing into your area.
And I still don't understand how the forward zone:
zone "mnc410.mcc310.gprs" {
type forward;
forwarders { ips for the Cingular DNS server;};
};
works fine.
Yet, the new one I created for mnc610.mcc310.gprs is not working.
I have to look into every local zone file, and see if somehow this DNS
servers thinks it is somehow authoritive for this domain someplace.
-----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