DDI4U
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.
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.
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.
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.
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.
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.
@DDI4U -- check the TTL value for the PTR record as well, which could also be playing a part in this.
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-add r.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
; <<>> DiG 9.3.2 <<>> 131.xx.xx.xx.in-addr.arpa.
;; 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
;; ANSWER SECTION:
131.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
ASKER
@ Papaertrip: The TTL on the PTR is 60min
MXToolbox sent me the following response when after my communications with them regarding the issue:
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.
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
[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.
[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
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.
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
*EDIT by modus_in_rebus* obfuscated IP addresses
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!
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 :-/
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
[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.
*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.
[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.
[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
[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
*EDIT by modus_in_rebus* obfuscated IP addresses
ASKER
That was it! Looks good now!
Thanks a lot for your help. As you said, certainly a learning experience!
Thanks a lot for your help. As you said, certainly a learning experience!
Awesome! It seems so obvious now :p
http://www.debouncer.com/reverse-dns-check