Link to home
Start Free TrialLog in
Avatar of DDI4U
DDI4UFlag for Afghanistan

asked on

Reverse DNS is going to be the end of me!

Hello again EE!

A client of mine recently upgraded their ATT service which included the need to reassign IP addresses. I didnt receive any preliminary cutsheets which would contain the new addresses so I had to make all of the changes onsite quickly including the Firewall (NAT, ACL) and DNS (Forward and Reverse). Everything was checking out ok, mail was flowing, internet works, VPN works, etc. However.... now I have delayed emails to AOL, Windstream, and a few others. They are all complaining about a reverse DNS. To put a timeline on this project, the cutover was 7 days ago. 4 days ago I contacted ATT to make sure they were delegating DNS to our nameservers, which they were not, but they are now. After they updated their changes, about an hour or so later instead of seeing no PTR for our IP I was seeing their standard "in-arpa" PTR. The next day I am now seeing the proper PTR when using MXToolbox.com but some other sites report no PTR or still show the "in-arpa".

I am at my wit's end here because everything that I have control over seems to be set up properly but yet the emails will still not leave the queue and many are expiring. the client is not happy but I don't know what to do. Any idea what the issue is and what I can do to fix it? I can supply the IP via PM if that will help.
Avatar of Carl Dula
Carl Dula
Flag of United States of America image

Check your reverse dns entry here. Enter ip address.

http://www.debouncer.com/reverse-dns-check
Avatar of DDI4U

ASKER

Reverse DNS for x.x.x.x not found.

Then that tells you that the reverse pointers are not in place.

I doubt that you are really controlling public internet DNS for your site on your own internal names servers. Only the largest of companies ever do that.

I suspect what you have is an internal name server for your LAN that you point all your inside devices to. You should contact ATT and tell them you need reverse DNS set for your site. They do not do this by default.

Once it is set correctly you will be able to repeat the test and get the correct answer.
You are probably just having issues with the negative cache TTL for the PTR record.  That value states that if a caching resolver gets an NXDOMAIN for a record, to cache that NXDOMAIN result until the negative cache TTL has expired.

If you are able to see your updated PTR through mxtoolbox, then it's probably safe to say that your changes have been pushed.

Goto http://www.kloth.net/services/dig.php and put in your arpa zone, then select query type of SOA, and the last value in the SOA record is the negative cache TTL, also known as the minimum value.  If that value is something very high, then you are almost certainly dealing with a cached NXDOMAIN result.

As far as the syntax for your arpa zone, it's your IP reversed minus the last octet +in-addr.arpa

If your IP is 1.2.3.4, then you would use 3.2.1.in-addr.arpa

If you could provide me with the IP like you mentioned in your question, I will check everything out for you.

I doubt that you are really controlling public internet DNS for your site on your own internal names servers. Only the largest of companies ever do that.
That isn't very accurate.  As long as your provider offers delegation, then anyone can manage their own in-addr.arpa zones.  I for example have delegation authority over my /29... size of the company really plays no role in any of this.
Didn't mean it from a technical point of view, but rather for the responsibility.

Small sites typically don't want to, or know how to do this. One mistake and you are down.

IMHO, allowing your ISP to take responsibility is the norm.
@carl No arguments there.

@DDI4U -- check the TTL value for the PTR record as well, which could also be playing a part in this.
Avatar of DDI4U

ASKER

@ Papertrip Here is the output from your link and query. Ip in tact.

 ; <<>> DiG 9.3.2 <<>> 131.xx.xx.xx.in-addr.arpa. SOA
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34866
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;131.xx.xx.xx.in-addr.arpa.      IN      SOA
 
 ;; ANSWER SECTION:
 131.xx.xx.xx.in-addr.arpa. 82955 IN      CNAME      131.128/27.xx.xx.xx.in-addr.arpa.
 
 ;; Query time: 212 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Thu Oct 20 19:28:54 2011
 ;; MSG SIZE  rcvd: 69

@ Carlmd: We host DNS for about 1,300 websites, servers, etc. It is actually the norm for us to have the control over DNS for each of our clients. This is not the first time I have set up a PTR either, only the first time it was set up and not showing even after almost a week.

*EDIT by modus_in_rebus* obfuscated IP addresses
Avatar of DDI4U

ASKER

@ Papaertrip: The TTL on the PTR is 60min

MXToolbox sent me the following response when after my communications with them regarding the issue:

I took a closer look at this and it appears to be an App River/Rackspace issue. Sometimes when we do a PTR lookup it is answering with App River and other times it answers Rackspace. When it queries Rackspace the PTR does not match and that is more than likely the source of your failure.

Avatar of DDI4U

ASKER

AppRiver was a dead end. We dont route outbound mail through them so I thought it might be but it was worth a shot. So do you think its a TTL issue?
[root@broken ~]# dig -x xx.xx.xx.131 +trace

; <<>> DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6_0.1 <<>> -x xx.xx.xx.131 +trace
;; global options: +cmd
<snip>
.                       474722  IN      NS      c.root-servers.net.
;; Received 244 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms
<snip>
in-addr.arpa.           172800  IN      NS      f.in-addr-servers.arpa.
;; Received 420 bytes from 198.41.0.4#53(a.root-servers.net) in 162 ms
<snip>
xx.in-addr.arpa.        86400   IN      NS      dbru.br.ns.els-gms.att.net.
xx.in-addr.arpa.        86400   IN      NS      cmtu.mt.ns.els-gms.att.net.
xx.in-addr.arpa.        86400   IN      NS      dmtu.mt.ns.els-gms.att.net.
xx.in-addr.arpa.        86400   IN      NS      cbru.br.ns.els-gms.att.net.
;; Received 144 bytes from 193.0.9.1#53(f.in-addr-servers.arpa) in 150 ms

131.xx.xx.xx.in-addr.arpa. 83000 IN    CNAME   131.128/27.xx.xx.xx.in-addr.arpa.
128/27.xx.xx.xx.in-addr.arpa. 83000 IN NS      ns.HIDDEN.com.
128/27.xx.xx.xx.in-addr.arpa. 83000 IN NS      ns1.HIDDEN.com.
;; Received 121 bytes from yy.yy.yy.69#53(cmtu.mt.ns.els-gms.att.net) in 73 ms

Open in new window

[root@broken ~]# dig @ns.HIDDEN.com -x xx.xx.xx.131 +short
remote.HIDDEN2.com.
[root@broken ~]# dig @ns1.HIDDEN.com -x xx.xx.xx.131 +short
remote.HIDDEN2.com.

Open in new window

[root@broken ~]# dig @8.8.8.8 -x xx.xx.xx.131

; <<>> DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6_0.1 <<>> @8.8.8.8 -x xx.xx.xx.131
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38205
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;131.xx.xx.xx.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
131.xx.xx.xx.in-addr.arpa. 80400 IN    CNAME   131.128/27.xx.xx.xx.in-addr.arpa.

;; AUTHORITY SECTION:
xx.xx.xx.in-addr.arpa. 1800    IN      SOA     dns.HIDDEN.com. hostmaster.HIDDEN.com. 10 900 600 86400 3600

Open in new window



I haven't had the opportunity to setup classless delegation from the delegator side, but it appears that everything is setup properly on their end.  It is possible I am overlooking something, but I'm still digging at this... it still might be a TTL issue, just wanted to update you on my progress.


*EDIT by modus_in_rebus* obfuscated IP addresses
4 days ago I contacted ATT to make sure they were delegating DNS to our nameservers, which they were not, but they are now.

When did they last make changes?
[root@broken ~]# dig @ns.HIDDEN.com soa xx.xx.xx.in-addr.arpa +short
dns.HIDDEN.com. hostmaster.HIDDEN.com. 10 900 600 86400 3600
[root@broken ~]# dig @ns.HIDDEN.com ns xx.xx.xx.in-addr.arpa +short
ns1.HIDDEN.com.
ns.HIDDEN.com.

Open in new window


Change the MNAME in your SOA for that zone to ns.HIDDEN.com like how you have it for your forward zone.

[root@broken ~]# dig soa HIDDEN.com +short
ns.HIDDEN.com. administrator.HIDDEN.com. 2006081906 3600 600 86400 3600

Open in new window


*EDIT by modus_in_rebus* obfuscated IP addresses
Avatar of DDI4U

ASKER

ATT made the delegation on Monday but it didnt show my PTR until late Tuesday. It only showed the in-arpa until late Tuesday. I will make the SOA change soon. Thank you for your investigation!
Avatar of DDI4U

ASKER

Change made.
I'm not sure if the MNAME change is going to have any bearing on this, but it's worth a shot and good practice to keep your zones consistent anyways.

Starting to run out of ideas.  Wish I had more experience with classless delegation :-/
OK I'll give it a few and start digging again.
ASKER CERTIFIED SOLUTION
Avatar of Papertrip
Papertrip
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
131.xx.xx.xx.in-addr.arpa. 83000 IN    CNAME   131.128/27.xx.xx.xx.in-addr.arpa.
128/27.xx.xx.xx.in-addr.arpa. 83000 IN NS      ns.HIDDEN.com.
128/27.xx.xx.xx.in-addr.arpa. 83000 IN NS      ns1.HIDDEN.com.

Open in new window

[root@broken ~]# dig @ns.HIDDEN.com -x xx.xx.xx.131
<snip>
;; ANSWER SECTION:
131.xx.xx.xx.in-addr.arpa. 3600 IN     PTR     remote.HIDDEN2.com.

Open in new window


*EDIT by modus_in_rebus* obfuscated IP addresses
[root@broken ~]# dig -x 62.142.217.200

;; QUESTION SECTION:
;200.217.142.62.in-addr.arpa.   IN      PTR

;; ANSWER SECTION:
200.217.142.62.in-addr.arpa. 12708 IN   CNAME   200.128/25.217.142.62.in-addr.arpa.
200.128/25.217.142.62.in-addr.arpa. 84708 IN PTR x200.qnet.fi.

;; AUTHORITY SECTION:
128/25.217.142.62.in-addr.arpa. 84708 IN NS     ns2.qnet.fi.
128/25.217.142.62.in-addr.arpa. 84708 IN NS     ns5.sci.fi.
128/25.217.142.62.in-addr.arpa. 84708 IN NS     ns3.qnet.fi.
128/25.217.142.62.in-addr.arpa. 84708 IN NS     ns3.sci.fi.
128/25.217.142.62.in-addr.arpa. 84708 IN NS     ns1.qnet.fi.

Open in new window

[root@broken ~]# dig @ns3.sci.fi any 200.128/25.217.142.62.in-addr.arpa

;; QUESTION SECTION:
;200.128/25.217.142.62.in-addr.arpa. IN ANY

;; ANSWER SECTION:
200.128/25.217.142.62.in-addr.arpa. 86400 IN PTR x200.qnet.fi.

;; AUTHORITY SECTION:
128/25.217.142.62.in-addr.arpa. 86400 IN NS     ns2.qnet.fi.
128/25.217.142.62.in-addr.arpa. 86400 IN NS     ns3.qnet.fi.
128/25.217.142.62.in-addr.arpa. 86400 IN NS     ns5.sci.fi.
128/25.217.142.62.in-addr.arpa. 86400 IN NS     ns3.sci.fi.
128/25.217.142.62.in-addr.arpa. 86400 IN NS     ns1.qnet.fi.

Open in new window

[root@broken ~]# dig @8.8.8.8 -x xx.xx.xx.131

;; QUESTION SECTION:
;131.xx.xx.xx.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
131.xx.xx.xx.in-addr.arpa. 73996 IN    CNAME   131.128/27.xx.xx.xx.in-addr.arpa.

;; AUTHORITY SECTION:
xx.xx.xx.in-addr.arpa. 757     IN      SOA     ns.HIDDEN.com. hostmaster.HIDDEN.com. 11 900 600 86400 3600

Open in new window

[root@broken ~]# dig @ns.HIDDEN.com any 131.128/27.xx.xx.xx.in-addr.arpa

; <<>> DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6_0.1 <<>> @ns.HIDDEN.com any 131.128/27.xx.xx.xx.in-addr.arpa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 736
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;131.128/27.xx.xx.xx.in-addr.arpa. IN  ANY

;; AUTHORITY SECTION:
xx.xx.xx.in-addr.arpa. 3600    IN      SOA     ns.HIDDEN.com. hostmaster.HIDDEN.com. 11 900 600 86400 3600

Open in new window


*EDIT by modus_in_rebus* obfuscated IP addresses
Avatar of DDI4U

ASKER

That was it! Looks good now!

Thanks a lot for your help. As you said, certainly a learning experience!
Awesome!  It seems so obvious now :p