asked on

Reverse dns lookup duplicate zone problem

Our mail server mail.magnabyte.com (64.116.135.11) is having problems related to reverse dns lookups. Our ISP, supposedly delegated zone control, to our web hosting company, at dns970.dizinc.com and dns971.dizinc.com. These guys use cpanel to administer our dns, and normal services work fine. When trying to fix the rdns problem, they added a new zone to their dns, called 0.135.116.64.in-addr.arpa. The program added some default additional records, such as NS'S, A, etc. They deleted the irrelevant records, and added a PTR record 64.116.135.11-> mail.magnabyte.com. Testing the solution, response from dnsstuff was : (i only copy the relevant parts ) :
------------------------------------------------------------------------------------------------------------------------
Asking auth20.ns.wcom.com. for 11.0.135.116.64.in-addr.arpa. PTR record:
auth20.ns.wcom.com [198.6.100.37] says to go to dns970.dizinc.com. (zone: 0.135.116.64.in-addr.arpa.)
Asking dns970.dizinc.com. for 11.0.135.116.64.in-addr.arpa. PTR record:
dns970.dizinc.com [72.29.82.211] says to go to dns970.dizinc.com. (zone: 0.135.116.64.in-addr.arpa.)

WARNING: Duplicate zone found (zone 0.135.116.64.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 dns970.dizinc.com. for 11.0.135.116.64.in-addr.arpa. PTR record:
dns970.dizinc.com [72.29.82.211] says to go to dns970.dizinc.com. (zone: 0.135.116.64.in-addr.arpa.)

WARNING: Duplicate zone found (zone 0.135.116.64.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.
---------------------------------------------------------------------------------------------------------------------------
Obviously we have 2 issues, apparently the 0.135.116.64.in-addr.arpa zone is "duplicated" and theres a loop in the process.

How can i find where the duplication occurs ? how can i determine what's wrong ? can anybody find me a link to a reference of reverse dns in apache dns ?

Kevin Aleshire

Looking at the reverse DNS traversal for 64.116.135.11,
( http://www.dnsstuff.com/tools/traversal.ch?domain=11.135.116.64.in-addr.arpa&type=PTR )
it looks as though the problem is residing with your parent servers.

Looking up at the 2 11.135.116.64.in-addr.arpa. parent servers:
Server Response Time
dns970.dizinc.com [72.29.82.211] [Broken DNS server: Reports a server failure] 311ms
dns971.dizinc.com [72.29.82.212] [Broken DNS server: Reports a server failure] 327ms
dns971.dizinc.com [72.29.82.212] [Broken DNS server: Reports a server failure] 327ms
Status: Records all match.

What does your ISP say about the errors?

Kevin Aleshire

Ran some nslookup queries against your two parents servers.
You'll notice below that when querying 'mail.magnabyte.com' the response is sent with the corrent dns name and ip address.
Yet when querying '64.116.135.11' for reverse lookup the response is sent with an incorrent dns name and correct ip address.
Reverse lookup should send back the same dns name.

> mail.magnabyte.com
Server: dns970.dizinc.com
Address: 72.29.82.211
Name: mail.magnabyte.com
Address: 64.116.135.11

> 64.116.135.11
Server: dns970.dizinc.com
Address: 72.29.82.211
Name: mail.magnabyte.com.11.135.116.64.in-addr.arpa
Address: 64.116.135.11

jsonnenvzla

ASKER

Thank you Kaleshire, that's exactly the problem im having. The question is how to solve it

northcide

dns970 dns servers are completely misconfigured. they are in a loop.

Asking dns970.dizinc.com. for 11.0.135.116.64.in-addr.arpa. PTR record:
dns970.dizinc.com [72.29.82.211] says to go to dns970.dizinc.com. (zone: 0.135.116.64.in-addr.arpa.)

that obviously says "asking dns970, dns970 says ask dns970". the problem is most likely with the NS records. paste those here and we can probably get them cleaned right up (even they you are paying your hosting company to do it! :) )

jsonnenvzla

ASKER

thanks northcide, i've noticed the loop ("Obviously we have 2 issues, apparently the 0.135.116.64.in-addr.arpa zone is "duplicated" and theres a loop in the process.")
What i need to know is exactly how would the reverse zone looks like when properly configured. Could use an example from other domain. Need to see SOA, NS'S, A'S, and PTR's required (or not) to compare with the current zone config. Obviously the company in charge of the zone doesnt have a clue to the matter, but please don't tell me the solution is changing companies.

northcide

the solution isnt to change providers, it would just be a good idea :)

there arent two different problems (from the info i have so far). the duplicate recoard IS the loop. dns970 and dns971 dont think they are authoritative and keep saying "ask me".

might be a better idea to show your zone file and what is in there. it is most likely a problem with your NS records but seeing the whole zone would be helpful

Jan Bacher

I'm going to go out on a limb here and hope you are running a bind server.

If that's the case, the fully qualified domain name must be terminated witha period "." It looks like it isn't and the domain will be appended to the end.

Example:

11.135.116.64 IN PTR mail.magnabyte.com.

jsonnenvzla

ASKER

jesper : thanks that's very important. Im making the correction in the next few hours. Also i found that the ISP erroneously created the zone as 11.135.116.64.in-addr.arpa instead of the correct 0.135.116.64.in-addr.arpa. I guess that has a lot to do with the problem. Now seems you know much about this subject, so let me ask you : when they create the zone in the server, it automatically adds some NS'S, A'S and even an A to localhost 127.0.0.1. It would be of great help to know which of these default created records is relevant to the process. The records i suspect are out of order are : (the real records currently state 11 as first component. not zero, but im assuming that when creating the new zone these default records will appear)
0.135.116.64.in-addr.arpa. NS dns970.dizinc.com
0.135.116.64.in-addr.arpa. NS dns971.dizinc.com
0.135.116.64.in-addr.arpa. A 72.29.82.210
localhost.0.135.116.in-addr.arpa. A 127.0.0.1
0.135.116.64.in-addr.arpa. MX 0
mail CNAME 0.135.116.64.in-addr.arpa.
www CNAME 0.135.116.64.in-addr.arpa.
ftp CNAME 0.135.116.64.in-addr.arpa.

Thanks for your help. we're getting closer

northcide

jsonnenvzla - do you have a full class c? has a full class c been delegated down for delegation? if you have indeed NOT been delegated a full class c then dizinc needs to do whats called classless delegation. the in addr's will only be 0.135.116.64.in-addr.arpa if you have the whole class c. read more about it here: http://www.csh.rit.edu/~jon/text/papers/classless/

i'd imagine thats one of your biggest problems. i suspect that cpanel isnt capable of classless subdelegation like that.

Jan Bacher

Additional information can be found in RFC2317 (that's what this is).

jsonnenvzla's netblock according to ARIN falls on a CIDR boundary and should be easy to setup.

The relevant document:

http://www.ietf.org/rfc/rfc2317.txt?number=2317

I'll see if I can put together an inverse db for that zone here in just a bit.

jsonnenvzla

ASKER

and i thougt we were getting closer. Obviuosly we dont have the full class C. I guess we have only from 2 to 14 or so. So the name of the zone would be : 11.0.135.116.64.in-addr.arpa? im soooooo confused here

northcide

jesper, how have you determined that? uu net has the class c. the whole point of a classess ip delegation is so that uu net can just be a rung on the ladder and give out individual netblocks to its customers.

northcide

jesper, i see what you are say, duh, because it is .11 then it is on the edge of the possible subnet and thus the network number would be 0

northcide

your zone is actually 0/28.135.116.64.in-addr.arpa.

so when machine out on the net asks what does 64.116.135.11 resolve to...

root servers say ask arin
arin says ask uunet
uunet says 0/28 is owned by diznic so ask them (0/28 is your classless subnet. its just a broken down piece of the bigger class c that uunet owns.).

so when you actually have this setup in bind or whatever dns server your cpanel is using, 0/28.135.116.64.in-addr.arpa. is the actual zone, much like if you were doing forward lookup "domain.com" would be your zone in the setup.

I'm not sure cpanel even supports classless reverse dns setup like this.

Jan Bacher

Yes, while classless doesn't require a boundary, it's common for an ISP to assign on boundary and that makes delegation easier (and you are assigned on a CIDR boundary).

You should act as master for the zone 0.135.116.64 with the appropriate SOA, NS, and PTR records for each IP. I've only delegated down so perhaps someone can correct me on the customer end.

jsonnenvzla

ASKER

jesper, can you comment on post ID: 19648846 in this same thread ? is it what you mean ?

Jan Bacher

To clarify, I have not done the customer side, just the ISP delegation side.

From what I've read, it looks like a standard inverse zone entry.

(standard SOA entry and NS entries)

1 IN PTR router.example.com.
2 IN PTR mail.example.com.
..
11 IN PTR www.example.com

According to the zone delegation by UU:

0.135.116.64.in-addr.arpa. IN NS dns970.dizinc.com.
0.135.116.64.in-addr.arpa. IN NS dns971.dizinc.com.

Your zone that you would be authoritative for is "0.135.116.64.in-addr.arpa."

jsonnenvzla

ASKER

Thanks Jesper, you've been of great help. In summary, please let's confirm if i understood:
At dns level (dns970.dizinc.com, dns971.dizinc.com) :
1.- Create a zone named 0.135.116.64.in-addr.arpa. (dot at the end)
2.- Leave the standard SOA and NS records created by default
3.- Delete any CNAME, A, etc records created by default since the standard CNAMES and A's for the domain reside in the normal dns lookup zones
4.- Create PTR records for each addres in my list that needs reverse dns. In my case only mail (64.116.135.11) :
11 IN PTR mail.magnabyte.com. (with the dot at the end)
Please let me know if i got it right, and thanks again for your great help

Jan Bacher

Your named.conf (example, identify location of file if necessary):

zone "0.135.116.64.in-addr.arpa" {
type master;
file "64-116-135-0.rev";
};

File 64-116-135-0.rev (this is an example, put your SOA record all on one line)

@ IN SOA dns971.dizinc.com. postmaster.dns971.dizinc.com. (
2007012901 3600 1800 1209600 86400 )

IN NS dns970.dizinc.com.
IN NS dns971.dizinc.com.

1 IN PTR whatever1.magnabyte.com.
2 IN PTR whatever2.magnabyte.com.
...
11 IN PTR mail.magnabyte.com.
etc

Don't forget the "." at the end of the fully qualified domain name in the PTR records.
You can call your file whatever you want as long as it's consistent with the 'file' specified in the named configuration file.
Change the domain (dns970 vs dns971) in your SOA record as applicable if both machines are master. If one is master and one is slave, put whichever host is appropriate.

I *think* this should work.

ASKER CERTIFIED SOLUTION

Jan Bacher

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

jsonnenvzla

ASKER

thanks jesper, you're earning your points. Ill this and let you know.

jsonnenvzla

ASKER

Jesper : the following is the zone file uploaded :

; Modified by Web Host Manager
; Zone File for 0.135.116.64.in-addr.arpa.
$TTL 14400
@      86400      IN      SOA      dns970.dizinc.com.      root.server.gruposcreenmedia.com.      (
                              2007070208
                              86400
                              7200
                              3600000
                              86400
                              )

0.135.116.64.in-addr.arpa.      86400      IN      NS      dns970.dizinc.com.
0.135.116.64.in-addr.arpa.      86400      IN      NS      dns971.dizinc.com.

11      14400      IN      PTR      mail.magnabyte.com.

About 3 hours after configuring the whole thing (named.conf etc) still getting a loop :

auth02.ns.uu.net [198.6.1.82] says to go to dns970.dizinc.com. (zone: 0.135.116.64.in-addr.arpa.)
Asking dns970.dizinc.com. for 11.0.135.116.64.in-addr.arpa. PTR record:
dns970.dizinc.com [72.29.82.211] says to go to auth03.ns.uu.net. (zone: 116.64.in-addr.arpa.)
Asking auth03.ns.uu.net. for 11.0.135.116.64.in-addr.arpa. PTR record:
auth03.ns.uu.net [198.6.1.83] says to go to auth20.ns.wcom.com. (zone: 135.116.64.in-addr.arpa.)
Asking auth20.ns.wcom.com. for 11.0.135.116.64.in-addr.arpa. PTR record:
auth20.ns.wcom.com [198.6.100.37] says to go to dns971.dizinc.com. (zone: 0.135.116.64.in-addr.arpa.)

at which point does DIZINC sends back the request ? who do i talk to ??

Jan Bacher

Did you add this zone in your named.conf? dns970 and dns971 shouldn't be handing any 0.135.116.64.in-addr.arpa requests back if they presume to be authoritative.

What do the logs say when you restart your DNS server regarding this zone?

jsonnenvzla

ASKER

Thanks Jesper it worked !!!!

Jan Bacher

I can see the entry. Wonderful!