Very Strange Reverse DNS problems

Thu Apr 20 17:15:23 UTC 2006

This sounds suspiciously like some stuff I ran into when we moved to new
networks on AT&T.   I found that in addition to updating my DNS
registrars for my Name Servers I also had to provide the Name Servers to
AT&T.  Since it is a reverse lookup they have to know your name servers
to delegate to them.   (We changed both the IP and the names of our DNS
servers during the process.)

That is to say it doesn't matter if you have registered at the registrar
because a reverse lookup finds AT&T as the owner of your IP range rather
than you.

Also if you have an external web hosting company that your DNS servers
point to you likely need to get them to update as well for reverse
lookups on the IPs they own.

-----Original Message-----
From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
Behalf Of Gary Galloway
Sent: Thursday, April 20, 2006 1:01 PM
To: Kevin Darcy; bind-users at isc.org
Subject: RE: Very Strange Reverse DNS problems

The response seem to be different depending on who does the lookup. For
example our upstream provider AT&T who deligated the addresses to us
gets good responses. However dnsstuff.com and roadrunner.com fail to do
proper reverse lookups.  One of the address is 12.109.202.11  which is
my mail server.  You can look at this using ns2.budgetphone.com as it is
one of the DNS servers that does not respond properly.  It however
responds correctly when you look at 12.109.202.9,  12.109.202.89, and
12.109.202.251 as well as many other addresses in the range. Below is
what happens at dnsstuff.com  As you can see ns2 refers the request for
.11 back to AT&T in this case but will often send it back to the root
server as well. However it responds properly to the request for .251
which is in the same zone. Also below is a copy of an nslook session
with ns2 from outside my local network showing proper responses for the
lookup of 12.109.202.11  I suspect a cname or ptr problem at AT&T but
have not been able to prove it.

How I am searching:
Asking b.root-servers.net for 11.202.109.12.in-addr.arpa PTR record:  
       b.root-servers.net says to go to dmtu.mt.ns.els-gms.att.net.
(zone: 12.in-addr.arpa.)
Asking dmtu.mt.ns.els-gms.att.net. for 11.202.109.12.in-addr.arpa PTR
record:  
       dmtu.mt.ns.els-gms.att.net [12.127.16.70] says to go to
ns2.budgetphone.com. (zone: 202.109.12.in-addr.arpa.)
Asking ns2.budgetphone.com. for 11.202.109.12.in-addr.arpa PTR record:  
       ns2.budgetphone.com [12.109.202.3] says to go to
cbru.br.ns.els-gms.att.net. (zone: 12.in-addr.arpa.)
Asking cbru.br.ns.els-gms.att.net. for 11.202.109.12.in-addr.arpa PTR
record:  
       cbru.br.ns.els-gms.att.net [199.191.128.105] says to go to
ns1.budgetphone.com. (zone: 202.109.12.in-addr.arpa.)
Asking ns1.budgetphone.com. for 11.202.109.12.in-addr.arpa PTR record:
Reports mail.budgetphone.com. [from 12.109.202.2]

Answer:
12.109.202.11 PTR record: mail.budgetphone.com. [TTL 3600s]
[A=12.109.202.11]

How I am searching:
Asking c.root-servers.net for 251.202.109.12.in-addr.arpa PTR record:  
       c.root-servers.net says to go to dmtu.mt.ns.els-gms.att.net.
(zone: 12.in-addr.arpa.)
Asking dmtu.mt.ns.els-gms.att.net. for 251.202.109.12.in-addr.arpa PTR
record:  
       dmtu.mt.ns.els-gms.att.net [12.127.16.70] says to go to
ns2.budgetphone.com. (zone: 202.109.12.in-addr.arpa.)
Asking ns2.budgetphone.com. for 251.202.109.12.in-addr.arpa PTR record:
Reports host251.budgetphone.com. [from 12.109.202.3]

Answer:
12.109.202.251 PTR record: host251.budgetphone.com. [TTL 3600s]
[A=12.109.202.251]

> server ns2.budgetphone.com.

Default Server:  ns2.budgetphone.com

Address:  12.109.202.3

> set type=any

> 11.202.109.12.in-addr.arpa.

Server:  ns2.budgetphone.com

Address:  12.109.202.3

11.202.109.12.in-addr.arpa      name = mail.budgetphone.com

202.109.12.in-addr.arpa nameserver = ns2.budgetphone.com

202.109.12.in-addr.arpa nameserver = ns1.budgetphone.com

ns1.budgetphone.com     internet address = 12.109.202.2

ns2.budgetphone.com     internet address = 12.109.202.3

>                                                           

-----Original Message-----
From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org]On
Behalf Of Kevin Darcy
Sent: Wednesday, April 19, 2006 5:50 PM
To: bind-users at isc.org
Subject: Re: Very Strange Reverse DNS problems

Gary Galloway wrote:

>I need some help resolving some very strange problems with Bind 9.3.1
running on FreeBSD 6.0
>I have a reverse zone that will answer as authoritative with some
address in the zone but will answer non-authoritative with other
addresses in the same zone file and then refer the query to the root
servers.  The zone is setup as a master and is properly deligated to my
server.  I am trying to migrate my DNS off of a couple of a windows
server but have been unable to do so as Bind will not resolve the
reverse addresses for my mail servers correctly.  Does anyone have any
idea as to what would cause this server to think it is not authoritative
on some IP address while still being authoritative on others in the same
zone ????
>
The behavior as you describe it would be a violation of the RFCs, and 
not anything I've ever seen BIND do.

However, it is possible that you are mistaken about the zone from which 
the nameserver is answering. If the techniques of RFC 2317 are being 
employed, for instance, then there may be a CNAME in the main reverse 
zone, pointing to a name in *some*other* zone, and maybe the PTR record 
in that zone file has been deleted. If the authoritative nameserver for 
the main reverse zone doesn't also happen to be authoritative for the 
zone to which the CNAME points, it might properly give a 
non-authoritative response to the query.

It would help if you just told us what reverse zone you're talking 
about, assuming it's a public one, so that we could just look at it 
instead of having to engage in all of this speculation as to the cause 
of your problem. If it's not a public one, at least you could post the 
relevant part(s) of the zone file.

      - Kevin

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.4/319 - Release Date: 4/19/2006

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.4/319 - Release Date: 4/19/2006