IP Networking

I'm not sure where this really fits in the Unix.com forums, but this seemed to be a good spot for it. If not, please let me know:
I've been trying to track down an issue that I've had for quite a while with reverse lookups. I've got a primary and secondary DNS that are authoritative for some four IP address ranges and 30+ domains. The forward lookups work just fine. But within the past year I've been getting more and more issues with certain ISPs not accepting mail from our domains due to reverse lookup failures. A few years ago I ran all of our domains through various tests at DNSStuff.com and cleaned up a lot of mistakes from years past. Everything seemed to be working fine then, and even now excepting the reverse zone errors I see every so often. (We're using a port of BIND 8 to VMS [Multinet], but the principles of DNS are the same as *nix)

In our named.conf file I have a reverse zone defined as such:

zone "1.168.192.in-addr.arpa" {
type master;
file "192-168-1.REV";
};

In the actual zone file itself I have entries in the following manner:

@ IN SOA dns1.mydomain.com. myname.mydomain.com. (
2006092601 21600 1800 86400 86400 )
IN NS dns1.mydomain.com.
IN NS dns2.mydomain.com.
IN NS ns1.state.mystate.us.
IN NS ns2.state.mystate.us.
IN NS ns4.state.mystate.us.
;
4 IN PTR srv2.mydomain.com.
7 IN PTR srv5.mydomain.com.
8 IN PTR srv6.mydomain.com.

...and so on

If I do an nslookup for 192.168.1.4 I get 'srv2.mydomain.com' as I would expect. However, if I do an nslookup for 4.1.168.192.in-addr.arpa I get "no A records for this zone". My reason for doing both queries is that the DNSStuff site has a semi-FAQ about reverse DNS. And they point out:

Exceprted from DNSStuff.com

Based on that suggestion it would seem that my reverse zone files are incorrectly formatted? Or... there are two styles either of which work? Or... that newer versions of BIND use the in-addr.arpa formatting and our BIND 8 is just fine? I honestly can't tell which. Most web references and tutorials I've seen regarding DNS setup seem to illustrate the method we employ and not the suggested method that DNSStuff indicates. Am I misunderstanding something here?

I don't understand why you think that dnsstuff.com faq is suggesting that your reverse dns is wrong. They say reverse dns uses PTR and you are using PTR. You don't show a $ORIGIN. I assume you have it if "nslookup 192.168.1.4" is working.

Hmmm... I somehow managed to leave out a very important piece of information in the original post. When I run my zones through the DNSstuff I get this big fat warning:

WARNING: Duplicate zone found (zone 1.168.192.in-addr.arpa. is repeated). This can prevent the lookup from continuing
(BIND8 and BIND9 will cause a 'server failure' response). Although I will continue, be aware that
most DNS servers will not see your reverse DNS entry.

The duplicate zone warning is what leads me to believe that there is a problem with the configuration. I have control over two of the servers involved in the name resolution tree: the primary and secondary. There are four other slaves that another organization controls and they pull their updates from our primary. If I query our primary directly from the internet for a reverse lookup, I get an immediate response. Same for our secondary. But if I query one of the four servers that I don't have access to, they will occasionally give me no response. If I query the same servers multiple times, I eventually get a response. My main concern is the duplicate zone error.

My assumption is that it implies that some other delegation is configured as authoritative, but I've checked our configurations and this is not the case. I've asked the people responsible for the other servers to check their and they've also confirmed they are only set up as secondary/slaves to our primary.

My other assumption (I know I shouldn't be making assumptions about this but sadly I'm too overtaxed right now to research the definition of duplicate zone errors) is that it might mean two zone definitions for the same arpa reverse zone in a file. I've verified that this isn't the case as well on our servers. And I assume that since the other servers pull updates from our primary, they should be identical data. I am meeting with the people who manage the secondaries this week so I'm hoping to work with them to get this resolved, but I also don't mind asking in forums in case they might provide more insight. Hopefully, once it's resolved I can post the cause and resolution in case anyone else runs into the same.

Well, yeah, I can see DNSstuff freaking out over that! Those are private IP addresses. You can't use them on the Internet. See: http://en.wikipedia.org/wiki/Private_network

I should have mentioned that I replaced the real IPs with the 192.168.1.0 network because... well I don't know why.

The real zone info contains routable IPs that were assigned to us by our ISP. Here's the real output from dnsstuff.com on my first attempt:

Code:

How I am searching:
Asking h.root-servers.net for 23.13.213.66.in-addr.arpa PTR record:  
       h.root-servers.net says to go to dill.arin.net. (zone: 66.in-addr.arpa.)
Asking dill.arin.net. for 23.13.213.66.in-addr.arpa PTR record:  
       dill.arin.net [192.35.51.32] says to go to ns1.state.oh.us. (zone: 13.213.66.in-addr.arpa.)
Asking ns1.state.oh.us. for 23.13.213.66.in-addr.arpa PTR record:  
       ns1.state.oh.us [156.63.130.100] says to go to front1.cpl.org. (zone: 13.213.66.in-addr.arpa.)

WARNING: Duplicate zone found (zone 13.213.66.in-addr.arpa. is repeated).  This can prevent the lookup from continuing
         (BIND8 and BIND9 will cause a 'server failure' response).  Although I will continue, be aware that
         most DNS servers will not see your reverse DNS entry.

Asking front1.cpl.org. for 23.13.213.66.in-addr.arpa PTR record:  Reports ntsrv4.cpl.org. [from 192.58.246.5]

Answer:
66.213.13.23 PTR record: ntsrv4.cpl.org. [TTL 86400s] [A=66.213.13.23]

Here's the reply after two attempts:

Code:

How I am searching:
Asking d.root-servers.net for 23.13.213.66.in-addr.arpa PTR record:  
       d.root-servers.net says to go to dill.arin.net. (zone: 66.in-addr.arpa.)
Asking dill.arin.net. for 23.13.213.66.in-addr.arpa PTR record:  
       dill.arin.net [192.35.51.32] says to go to ns2.state.oh.us. (zone: 13.213.66.in-addr.arpa.)
Asking ns2.state.oh.us. for 23.13.213.66.in-addr.arpa PTR record:  Reports ntsrv4.cpl.org. [from 156.63.130.68]

Answer:
66.213.13.23 PTR record: ntsrv4.cpl.org. [TTL 86391s] [A=66.213.13.23]

No changes were made during the subsequent attempts to any of the servers. The attempts were actually only a few seconds apart as well. If I do the lookups manually I usually get no response until after a few multiple attempts as well. If I do the lookups directly against our primary and secondary that we manage, everything's great. If I do it against ns1 through ns4 listed in the results above, it takes a few attempts. So, my conclusion is that something is failing in the communication between our DNS servers and the secondaries maintained by the other organization. It COULD be BIND version issues. Our DNS servers are based off of BIND 8.2.x. I don't know what version the other organization is using, but I would suspect they are in the 9.x.x series and utilizing Unix rather than VMS. Oh well... my supervisors have finally accepted that we should probably move DNS off of those aging Alphas. I can't wait to see what the folks from the other organization have to say when they come up.

I'm confused with what is fiction and what is fact in this thread. My guess is that you need to remove:
IN NS ns1.state.mystate.us.
IN NS ns2.state.mystate.us.
IN NS ns4.state.mystate.us.

If they delegated the domain to you, you cannot delegate the domain back to them. That creates a loop.

Hmmm... I just made the change and forced updates on our servers. A test for one of the failing IPs appears to have worked. I tried one other and it failed, but it also mentioned something about possible "negative caching". I think if I wait for the state DNS servers to update. It's possible that the error was cleared up by removing the entries you suggested and I should know for sure tomorrow. Thanks very much.