Link to home
Start Free TrialLog in
Avatar of bryan_homey
bryan_homey

asked on

Reverse DNS is working... But AOL is still blocking us.

Ok, need some help.  I walked into a situation where I have a bind server for our name servers.  I have setup Reverse DNS with AT&T delegating our name servers.  I have the zone records setup.  With a consultant we added the following two sections in my named.conf


zone "224-27.147.xx.xx.in-addr.arpa" {
        type master;
        file "/etc/namedb/master/224-27.147.xx.xx.in-addr.arpa";
        allow-transfer { localhost; };
        allow-query { any; };


};

zone "147.xx.xx.in-addr.arpa" {
        type master;
        file "/etc/namedb/master/147.xx.xx.in-addr.arpa";
        allow-transfer { localhost; };
        allow-query { any; };
};

ATT wanted us to make one 224- and he hadn't seen this before so he added both.

Here is my 224-147.xx.xx.in-addr.arpa file


$TTL 3D
@       IN      SOA     ns1.mydomain.com. ns2.mydomain.com. (
                        2011031103 ; Serial, todays date + todays serial
                        3H      ; Refresh
                        1H      ; Retry
                        1W      ; Expire
                        1H)     ; Minimum TTL
        IN      NS      ns1.mydomain.com.
        IN      NS      ns2.mydomain.com.

228     IN      PTR     mail.mydomain.com.
226     IN      PTR     ns1.mydomain.com.
227     IN      PTR     ns2.mydomain.com.

Here is my 147.xx.xx.in-addr.arpa file

$TTL 3D
@       IN      SOA     ns1.MyDomain.com. ns2.mydomain.com. (
                        2011031103 ; Serial, todays date + todays serial
                        3H      ; Refresh
                        1H      ; Retry
                        1W      ; Expire
                        1H)     ; Minimum TTL
        IN      NS      ns1.mydomain.com.
        IN      NS      ns2.mydomain.com.

228     IN      PTR     mail.mydomain.com.
226     IN      PTR     ns1.mydomain.com.
227     IN      PTR     ns2.mydomain.com.


When I go to MXToolBox it correctly reverses my mail.mydomain.com from its IP Address.
When I run a DNS Test on DNSStuff.com it passes all the MX tests EXCEPT for the LOW PORT TEST.

When I run nslookup -q=mx mydomain.com

DNS requist timed out.
timeout was 2 seconds.
Non-authoritative answer:

mydomain.com MX Preference = 10 mail exchanger = mail.mydomain.com

mydomain.com nameserver = ns2.mydomain.com
mydomain.com nameserver = ns1.mydomain.com
mail.mydomain.com internet address = xx.xx.147.228

I'm missing something, because when I try to telnet to port 25 to one of AOL's servers I am getting:

Trying 205.188.159.42...
Connected to mailin-01.mx.aol.com.
Escape character is '^]'.
421 4.7.1 : (DNS:NR) http://postmaster.info.aol.com/errors/421dnsnr.html

I was having issues with any sbcglobal.net email addresses but that was resolved with setting up the reversing entries.  Now it is just AOL.

Some things you might need to know.  We just started with ATT last week.  I just changed the IP Address of ns1.mydomain.com on Tuesday over to the ATT side.  The IP Address of ns2.mydomain.com was just changed on Friday.

What am I missing?

Thanks for your time,

Bryan
Avatar of noci
noci

You do have to consider the TTL times with your RR's als of upstream TTL's where
it can be slightly longer TTL's te prevent a lot of unneeded DNS traffic.

Or you can try (from an AOL clients p.o.v. try to resolve your domain name to see what the view of yahoo is on your names...)

If it's TTL releated i would expect it to resolve in about a week or two weeks max.
What is the ip addres of the server you are actually using to telnet to port 25 at aol?  Also, is there any chance you are going through some sort of nat or proxy server along the way?

Try going to www.cmyip.com and see if it tells you the same ip address you think you have.

Avatar of bryan_homey

ASKER

@portabletech I am telneting from my ironport from inside my cisco Asa. I changed the routing satement to send out all port 25 traffic on the mail.mydomain.com public IP Address.

Speaking of the Asa, I did the fixup utility to take out the * charaters on the SMTP Banner. Obviously it doesn't apply to the telnet sessions.

Can anyone tell me if the reverse PTR entries are good?  Or Should I say good enough for AOL's servers.

Thanks,

Bryan
Well, the verification is where I was heading with this, based on the files you posted, you have 1 or 2, was not quite sure, octets specified, but only list one in the file itself.  If you give me an ip address or two I would be happy to do some testing to see how it looks from this end.
Our mail server is 12.29.147.228. Luxco.com is the domain. Ns1.luxco.com and ns2.luxco.com are 12.29.147.226 and .227.

Thanks

Bryan
Here is what I get when I do a reverse lookup on your maill server.  It strikes me a bit odd, as it points to a CNAME or an in-addr.arpa (228.224-27.147.29.12.in-addr.arpa.) which does not even appear to be in the correct format with that 224-27 in the middle there, and then that CNAME is pointing to your mail server name (mail.luxco.com)

What I should be seeing in this answer section is

228.147.29.12.in-addr.arpa.         IN       PTR             mail.luxco.com

I would have to double check the DNS specs, but I am not sure that a CNAME reference to an in-addr is technically a legit format.  

I would recomend you get rid of the 224-27 file completely, and just use the 147.29.12 one, and then use a line in there as you did above of

228       IN        PTR       mail.luxco.com.

and see if this makes thing appear a bit better.


; <<>> DiG 9.7.1-P2 <<>> -x 12.29.147.228
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47514
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2

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

;; ANSWER SECTION:
228.147.29.12.in-addr.arpa. 83000 IN    CNAME   228.224-27.147.29.12.in-addr.arpa.
228.224-27.147.29.12.in-addr.arpa. 259200 IN PTR mail.luxco.com.

;; AUTHORITY SECTION:
224-27.147.29.12.in-addr.arpa. 259200 IN NS     ns1.luxco.com.
224-27.147.29.12.in-addr.arpa. 259200 IN NS     ns2.luxco.com.

;; ADDITIONAL SECTION:
ns1.luxco.com.          10799   IN      A       12.29.147.226
ns2.luxco.com.          10799   IN      A       216.114.64.186

;; Query time: 1860 msec
;; SERVER: 192.168.1.34#53(192.168.1.34)
;; WHEN: Sat Mar 12 13:45:05 2011
;; MSG SIZE  rcvd: 165

CNAMES are undefined for PTR records, they are synonyms for A records.
Also the revers lookup is defined as the ip address in byte reversed format and then in-addr.arpa. as trailer.
So then 224-27 clearly cannot work.
This most probable is the cause of disaproval by YAHOO.
Thanks I will update soon.
Ok, at 10:45pm CST I removed zone “224-27.147.29.12.in-addr.arpa” from named.conf now only the 147.12.29.in-addr.arpa is in there.  I removed the 224-27.147.29.12.in-addr.arpa file in the master directory.  My 147.29.12.in-addr.arpa now looks like this:

$TTL 3D
@       IN      SOA     ns1.luxco.com. ns2.luxco.com. (
                        2011031201 ; Serial, todays date + todays serial
                        3H      ; Refresh
                        1H      ; Retry
                        1W      ; Expire
                        1H)     ; Minimum TTL
;        IN      NS      ns1.luxco.com.
;        IN      NS      ns2.luxco.com.


228     IN      PTR     mail.luxco.com.
;226     IN      PTR     ns1.luxco.com.
;227     IN      PTR     ns2.luxco.com.


I did a rndc reload.  I believe ATT runs a DNS reload at the top of every hour.  

Bryan
Ok, I did some more testing, and it appears while many other DNS servers still have your old information, your ns1 server is reporting good data (see below).  That being said, I did want to let you know that your ns2 is not respond to my tests at all.  Not the end of the world, but might want to check into it.  Based on the times I saw in the other DNS servers, I believe most of your old data should clear in the next 23 hours at worst case.

Anyway, it looks much better, now is just the waiting game, let me know if you have more questions,

root@ryoko:~# dig -x 12.29.147.228 @ns1.luxco.com

; <<>> DiG 9.7.1-P2 <<>> -x 12.29.147.228 @ns1.luxco.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8633
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available

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

;; ANSWER SECTION:
228.147.29.12.in-addr.arpa. 259200 IN   PTR     mail.luxco.com.

;; AUTHORITY SECTION:
147.29.12.in-addr.arpa. 259200  IN      NS      ns1.luxco.com.
147.29.12.in-addr.arpa. 259200  IN      NS      ns2.luxco.com.

;; ADDITIONAL SECTION:
ns1.luxco.com.          10800   IN      A       12.29.147.226
ns2.luxco.com.          10800   IN      A       216.114.64.186

;; Query time: 57 msec
;; SERVER: 12.29.147.226#53(12.29.147.226)
;; WHEN: Sun Mar 13 03:54:03 2011
;; MSG SIZE  rcvd: 140



I don't know guys the Reverse DNS tool from DNSStuff says I don't have a PTR record!  
Reverse DNS for 12.29.147.228Location: United States [City: Marathon, Wisconsin]

Preparation:
The  reverse DNS entry for an IP is found by reversing the IP, adding it to "in-addr.arpa", and looking up the PTR record.
So, the reverse DNS entry for 12.29.147.228 is found by looking up the PTR record for
 228.147.29.12.in-addr.arpa.
All DNS requests start by asking the root servers, and they let us know what to do next.
See How Reverse DNS Lookups Work for more information.

How I am searching:
Asking d.root-servers.net for 228.147.29.12.in-addr.arpa PTR record:  
       d.root-servers.net says to go to cmtu.mt.ns.els-gms.att.net. (zone: 12.in-addr.arpa.)
Asking cmtu.mt.ns.els-gms.att.net. for 228.147.29.12.in-addr.arpa PTR record:  Got CNAME referral to 228.224-27.147.29.12.in-addr.arpa. at server ns2.luxco.com. (zone 224-27.147.29.12.in-addr.arpa.) [from 12.127.16.69]
Asking h.root-servers.net for 228.224-27.147.29.12.in-addr.arpa. PTR record:  
       h.root-servers.net [128.63.2.53] says to go to c.in-addr-servers.arpa. (zone: in-addr.arpa.)
Asking c.in-addr-servers.arpa. for 228.224-27.147.29.12.in-addr.arpa. PTR record:  
       c.in-addr-servers.arpa [196.216.169.10] 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 228.224-27.147.29.12.in-addr.arpa. PTR record:  
       dmtu.mt.ns.els-gms.att.net [12.127.16.70] says to go to ns1.luxco.com. (zone: 224-27.147.29.12.in-addr.arpa.)
Asking ns1.luxco.com. for 228.224-27.147.29.12.in-addr.arpa. PTR record:  Reports that no PTR records exist [from 12.29.147.226].

Answer:
No PTR records exist for 12.29.147.228. [Neg TTL=3600 seconds]
Details:
ns1.luxco.com. (an authoritative nameserver for 147.29.12.in-addr.arpa., which is in charge of the reverse DNS for 12.29.147.228)
says that there are no PTR records for 12.29.147.228.

To get reverse DNS set up for 12.29.147.228, you need to speak to your Internet provider.  You could also
check with ns2@luxco.com., who is in charge of the 147.29.12.in-addr.arpa. zone.

Note that all Internet accessible hosts are expected to have a reverse DNS entry (per RFC1912 2.1),
and many mailservers (such as AOL) will likely block E-mail from mailservers with no reverse DNS entry.
To see the reverse DNS traversal, to make sure that all DNS servers are reporting the correct results, you can Click Here.





hrmmm...  The records changed a bit from the last time I looked at them....

I bet the line that looks like this in your dns records

228       IN        PTR       mail.luxco.com.

is missing a period at the end of the line.  The one after the .com

I may see a second issue as well, though I think what I put in the last post is still an issue.

If you look at the dns trace below, it would appear that one of the AT&T DNS servers is answering authoritatively for your domain prior to delegation.  This means there is a match for the specific ip address in their DNS servers in addition to the delegated NS records.  In cases it still reports the record it has.

If you look, what they are reporting is quite a bit wrong, and they need to remove that 228 record from their DNS Servers so it will pass to yours, specified by the correct appearing NS records.  Also, as a side note, your NS2 is still unresponsive.

I am going to guess the AT&T tech that set this up what not totally on his game that day, or did not really understand what he was doing.

================

root@ryoko:~# dig +trace -x 12.29.147.228 @8.8.8.8

; <<>> DiG 9.7.1-P2 <<>> +trace -x 12.29.147.228 @8.8.8.8
;; global options: +cmd
.                       37305   IN      NS      a.root-servers.net.
.                       37305   IN      NS      b.root-servers.net.
.                       37305   IN      NS      c.root-servers.net.
.                       37305   IN      NS      d.root-servers.net.
.                       37305   IN      NS      e.root-servers.net.
.                       37305   IN      NS      f.root-servers.net.
.                       37305   IN      NS      g.root-servers.net.
.                       37305   IN      NS      h.root-servers.net.
.                       37305   IN      NS      i.root-servers.net.
.                       37305   IN      NS      j.root-servers.net.
.                       37305   IN      NS      k.root-servers.net.
.                       37305   IN      NS      l.root-servers.net.
.                       37305   IN      NS      m.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 91 ms

in-addr.arpa.           172800  IN      NS      b.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      d.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      e.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      f.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      a.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      c.in-addr-servers.arpa.
;; Received 420 bytes from 128.8.10.90#53(d.root-servers.net) in 108 ms

12.in-addr.arpa.        86400   IN      NS      cmtu.mt.ns.els-gms.att.net.
12.in-addr.arpa.        86400   IN      NS      cbru.br.ns.els-gms.att.net.
12.in-addr.arpa.        86400   IN      NS      dmtu.mt.ns.els-gms.att.net.
12.in-addr.arpa.        86400   IN      NS      dbru.br.ns.els-gms.att.net.
;; Received 144 bytes from 2001:500:13::73#53(a.in-addr-servers.arpa) in 119 ms

228.147.29.12.in-addr.arpa. 83000 IN    CNAME   228.224-27.147.29.12.in-addr.arpa.
224-27.147.29.12.in-addr.arpa. 83000 IN NS      ns2.luxco.com.
224-27.147.29.12.in-addr.arpa. 83000 IN NS      ns1.luxco.com.
;; Received 114 bytes from 199.191.128.106#53(dbru.br.ns.els-gms.att.net) in 158 ms

========================

When I query your DNS server directly, I get the following, which is why I suspect the missing period in your dns files on your ns1 server

========================

root@ryoko:~# dig -x 12.29.147.228 @ns1.luxco.com

; <<>> DiG 9.7.1-P2 <<>> -x 12.29.147.228 @ns1.luxco.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48957
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

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

;; ANSWER SECTION:
228.147.29.12.in-addr.arpa. 259200 IN   PTR     mail.luxco.com.147.29.12.in-addr.arpa.

;; AUTHORITY SECTION:
147.29.12.in-addr.arpa. 259200  IN      NS      ns1.luxco.com.

;; ADDITIONAL SECTION:
ns1.luxco.com.          10800   IN      A       12.29.147.226

;; Query time: 83 msec
;; SERVER: 12.29.147.226#53(12.29.147.226)
;; WHEN: Sun Mar 13 23:34:42 2011
;; MSG SIZE  rcvd: 116


Ok.  You caught me messing with my file...  I changed it back and I am still getting the same error.....

Notice that the dns stuff is still looking for the zone 224-27-147.29.12.in-addr.arpa.  Should I have removed it? : Asking ns1.luxco.com. for 228.224-27.147.29.12.in-addr.arpa. PTR record:  Reports that no PTR records exist [from 12.29.147.226].



Reverse DNS for 12.29.147.228Location: United States [City: Marathon, Wisconsin]

Preparation:
The  reverse DNS entry for an IP is found by reversing the IP, adding it to "in-addr.arpa", and looking up the PTR record.
So, the reverse DNS entry for 12.29.147.228 is found by looking up the PTR record for
 228.147.29.12.in-addr.arpa.
All DNS requests start by asking the root servers, and they let us know what to do next.
See How Reverse DNS Lookups Work for more information.

How I am searching:
Asking h.root-servers.net for 228.147.29.12.in-addr.arpa PTR record:  
       h.root-servers.net says to go to dbru.br.ns.els-gms.att.net. (zone: 12.in-addr.arpa.)
Asking dbru.br.ns.els-gms.att.net. for 228.147.29.12.in-addr.arpa PTR record:  Got CNAME referral to 228.224-27.147.29.12.in-addr.arpa. at server ns1.luxco.com. (zone 224-27.147.29.12.in-addr.arpa.) [from 199.191.128.106]
Asking a.root-servers.net for 228.224-27.147.29.12.in-addr.arpa. PTR record:  
       a.root-servers.net [198.41.0.4] says to go to e.in-addr-servers.arpa. (zone: in-addr.arpa.)
Asking e.in-addr-servers.arpa. for 228.224-27.147.29.12.in-addr.arpa. PTR record:  
       e.in-addr-servers.arpa [203.119.86.101] says to go to dbru.br.ns.els-gms.att.net. (zone: 12.in-addr.arpa.)
Asking dbru.br.ns.els-gms.att.net. for 228.224-27.147.29.12.in-addr.arpa. PTR record:  
       dbru.br.ns.els-gms.att.net [199.191.128.106] says to go to ns1.luxco.com. (zone: 224-27.147.29.12.in-addr.arpa.)
Asking ns1.luxco.com. for 228.224-27.147.29.12.in-addr.arpa. PTR record:  Reports that no PTR records exist [from 12.29.147.226].

Answer:
No PTR records exist for 12.29.147.228. [Neg TTL=3600 seconds]

Details:
ns1.luxco.com. (an authoritative nameserver for 147.29.12.in-addr.arpa., which is in charge of the reverse DNS for 12.29.147.228)
says that there are no PTR records for 12.29.147.228.

To get reverse DNS set up for 12.29.147.228, you need to speak to your Internet provider.  You could also
check with ns2@luxco.com., who is in charge of the 147.29.12.in-addr.arpa. zone.

Note that all Internet accessible hosts are expected to have a reverse DNS entry (per RFC1912 2.1),
and many mailservers (such as AOL) will likely block E-mail from mailservers with no reverse DNS entry.
To see the reverse DNS traversal, to make sure that all DNS servers are reporting the correct results, you can Click Here.

Ok,

The big issue you are missing is not your issue at all.  The DNS servers just upstream from you (AT&T) are reporting a CNAME record for your reverse DNS, which they should not be, it is not even technically legal.  But since there is a record on their servers for 228 systems which issue DNS queries are not even bothering to proceed on to your name servers.  As such all the correct info you have is not being queried at all.  Until AT&T fixes (deletes) this authoritative record, it will not matter what you have on your server.

Does this all make sense?

228.147.29.12.in-addr.arpa. 83000 IN    CNAME   228.224-27.147.29.12.in-addr.arpa.
;; Received 114 bytes from 199.191.128.106#53(dbru.br.ns.els-gms.att.net) in 158 ms
@PortableTech

I missed your post about ATT.  Firing off email to ATT Now!  

Bryan
@PortableTech:

Here is my string of emails to ATT,  They are saying there is only a delegation.

------


Dear AT&T Managed Internet Service Customer:

Our records indicate that AT&T MIS does not host any DNS for you. We show only a  delegation for the IP block listed below:

224-27.147.29.12.in-addr.arpa (effective 3/9/11)

The reverse ip zone is currently being delegated to the following name servers:

ns1.luxco.com
ns2.luxco.com


It is a common misconception that the owner of the IP block has to create the PTR records or only the owners of the IP address can add the PTR record, but that is not the case.

Please refer to:
RFC 2317
http://www.faqs.org/rfcs/rfc2317.html
For more information on IP delegations.                                  
_______________________________________________________________________________________________________

You will either need to have your current dns provider set up the reverse zone and add the pointer records, or as you have most recently requested, have us take over the reverse.   However, in order to do this AT&T must provide primary DNS for at least 1 domain name that your company owns.  

Below is information explaining our policies & procedures if you desire to have AT&T maintain your DNS records.

Find below a listing of criteria that needs to be met for AT&T Worldnet MIS to provide reverse look-up services:

(1) At least one forward domain must be hosted on our servers for all of the conditions listed below.  
(2) The one forward domain must not be a lame delegation* but must contain valid DNS records and not be a “dead” zone.
(3) The domain we host must be owned by your Company as evidenced by the Registrant information shown when doing a WHOIS look-up.
(4) If a customer owns their own IP block it must be delegated to our name servers.
(5) If a customer has a IP block from another ISP it must be delegated to our name servers.  



AT&T will host up to 15 domain names at no extra charge for each MIS Circuit your company has with AT&T. Please provide us with a list of the host domains with associated IP records.

Once we have added the request to our name servers, we will send an email response to you confirming we have added the domain name and give you the name server information so that changes can be made with the registrar of your choice for your domain name.  

 

Thank you,

AT&T MIS DNS Tech Team
d-92628
1 888 613 6330,prompts 3, 1
rg

From: Bryan Homrighous [mailto:B.Homrighous@luxco.com]
Sent: Monday, March 14, 2011 8:43 AM
To: DNS Services, MIS Lifecycle
Subject: RE: Multiple Entries for LUXCO????

I am totally confused why would a server respond with a CNAME?  Please check there is nothing more than just delegation for my block of IPs.  Our interface is 12.29.147.225 and our block is 226 through 254


228.147.29.12.in-addr.arpa. 83000 IN    CNAME   228.224-27.147.29.12.in-addr.arpa.  


Thanks,

Bryan


From: DNS Services, MIS Lifecycle [mailto:RM-dnschanges@att.com]
Sent: Monday, March 14, 2011 8:21 AM
To: Bryan Homrighous
Subject: RE: Multiple Entries for LUXCO????

Here is the info we get from www.dnsstuff.com

Reverse DNS for 12.29.147.228
Location: United States [City: Marathon, Wisconsin]

Preparation:
The  reverse DNS entry for an IP is found by reversing the IP, adding it to "in-addr.arpa", and looking up the PTR record.
So, the reverse DNS entry for 12.29.147.228 is found by looking up the PTR record for
 228.147.29.12.in-addr.arpa.
All DNS requests start by asking the root servers, and they let us know what to do next.
See How Reverse DNS Lookups Work for more information.

How I am searching:
Asking f.root-servers.net for 228.147.29.12.in-addr.arpa PTR record:  
       f.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 228.147.29.12.in-addr.arpa PTR record:  Got CNAME referral to 228.224-27.147.29.12.in-addr.arpa. at server ns2.luxco.com. (zone 224-27.147.29.12.in-addr.arpa.) [from 12.127.16.70]
Asking b.root-servers.net for 228.224-27.147.29.12.in-addr.arpa. PTR record:  
       b.root-servers.net [192.228.79.201] says to go to b.in-addr-servers.arpa. (zone: in-addr.arpa.)
Asking b.in-addr-servers.arpa. for 228.224-27.147.29.12.in-addr.arpa. PTR record:  
       b.in-addr-servers.arpa [199.253.183.183] 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 228.224-27.147.29.12.in-addr.arpa. PTR record:  
       dmtu.mt.ns.els-gms.att.net [12.127.16.70] says to go to ns2.luxco.com. (zone: 224-27.147.29.12.in-addr.arpa.)
Asking ns2.luxco.com. for 228.224-27.147.29.12.in-addr.arpa. PTR record:  Timed out [at 12.29.147.227].  Trying again.
Asking ns1.luxco.com. for 228.224-27.147.29.12.in-addr.arpa. PTR record:  Reports that no PTR records exist [from 12.29.147.226].

Answer:
No PTR records exist for 12.29.147.228. [Neg TTL=3600 seconds]

Details:
ns1.luxco.com. (an authoritative nameserver for 147.29.12.in-addr.arpa., which is in charge of the reverse DNS for 12.29.147.228)
says that there are no PTR records for 12.29.147.228.

To get reverse DNS set up for 12.29.147.228, you need to speak to your Internet provider.  You could also
check with ns2@luxco.com., who is in charge of the 147.29.12.in-addr.arpa. zone.

Note that all Internet accessible hosts are expected to have a reverse DNS entry (per RFC1912 2.1),
and many mailservers (such as AOL) will likely block E-mail from mailservers with no reverse DNS entry.
To see the reverse DNS traversal, to make sure that all DNS servers are reporting the correct results, you can Click Here.



AT&T Global DNS TECH TEAM
1 888 613 6330,prompts 3, 1
rg

From: Bryan Homrighous [mailto:B.Homrighous@luxco.com]
Sent: Sunday, March 13, 2011 11:10 PM
To: DNS Services, MIS Lifecycle
Subject: Multiple Entries for LUXCO????
Importance: High

We have a DNS delegation setup for ns1.luxco.com and ns2.luxco.com.  

If you look at the dns trace below, it would appear that one of the AT&T DNS servers is answering authoritatively for our domains prior to delegation.  This means there is a match for the specific ip address in your DNS servers in addition to the delegated NS records.  

Look below at the bold line in the results of my DiG trace, you are reporting our reverse delegation quite a bit wrong, you need to remove that 228 record from your DNS Servers so it will pass to ns1.luxco.com.

; <<>> DiG 9.7.1-P2 <<>> +trace -x 12.29.147.228 @8.8.8.8
;; global options: +cmd
.                       37305   IN      NS      a.root-servers.net.
.                       37305   IN      NS      b.root-servers.net.
.                       37305   IN      NS      c.root-servers.net.
.                       37305   IN      NS      d.root-servers.net.
.                       37305   IN      NS      e.root-servers.net.
.                       37305   IN      NS      f.root-servers.net.
.                       37305   IN      NS      g.root-servers.net.
.                       37305   IN      NS      h.root-servers.net.
.                       37305   IN      NS      i.root-servers.net.
.                       37305   IN      NS      j.root-servers.net.
.                       37305   IN      NS      k.root-servers.net.
.                       37305   IN      NS      l.root-servers.net.
.                       37305   IN      NS      m.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 91 ms

in-addr.arpa.           172800  IN      NS      b.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      d.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      e.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      f.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      a.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      c.in-addr-servers.arpa.
;; Received 420 bytes from 128.8.10.90#53(d.root-servers.net) in 108 ms

12.in-addr.arpa.        86400   IN      NS      cmtu.mt.ns.els-gms.att.net.
12.in-addr.arpa.        86400   IN      NS      cbru.br.ns.els-gms.att.net.
12.in-addr.arpa.        86400   IN      NS      dmtu.mt.ns.els-gms.att.net.
12.in-addr.arpa.        86400   IN      NS      dbru.br.ns.els-gms.att.net.
;; Received 144 bytes from 2001:500:13::73#53(a.in-addr-servers.arpa) in 119 ms

228.147.29.12.in-addr.arpa. 83000 IN    CNAME   228.224-27.147.29.12.in-addr.arpa.
224-27.147.29.12.in-addr.arpa. 83000 IN NS      ns2.luxco.com.
224-27.147.29.12.in-addr.arpa. 83000 IN NS      ns1.luxco.com.
;; Received 114 bytes from 199.191.128.106#53(dbru.br.ns.els-gms.att.net) in 158 ms

Your immediate attention to this matter is GREATLY Appreciated as AOL is blocking our email because the reverse DNS is not working correctly!

Please do not hesitate to call if you have any questions.

Thanks,
ASKER CERTIFIED SOLUTION
Avatar of noci
noci

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
SOLUTION
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
@PortableTech... Please read up on the RFC 2317 specs...

They are valid....   http://www.faqs.org/rfcs/rfc2317.html
It's even a rather convenient way to be able to host your own reverse lookups.

Yeah, I was reading through the RFC 2317 specs, and I can see where it is somewhat convient in some ways, but I just hate creating extra lookups when not needed.  This is what I was starting to think when I made the last post.  

I am still not entirely certain that some sites may have issues when it comes to special tests for various reasons not seeing this record as they expect, but per the spec it is technically allowed, and if the tests fail due to it, it should be blamed on the test.

Still just seems it would have been easier to just NS delegate his domains to him, but alas, here we are.  It seems we will need to follow their CNAME path.
According to the RFC the flow is meant:

228.147.29.12.in-addr.arpa  delivers a lookup on

arpa   delegate to:
in-addr.arpa delegate to:
12.in-addr.arpa  delegate to: att.net nameservers

which deliver a CNAME to: 228.224-27.29.12.in-addr.arpa
  and the NS records for them ... ns2.luxco.com and ns1.luxco.com

the PTR lookup for  228.224-27.29.12.in-addr.arpa  is now redirected to ns1 & ns2 for domain luxco.com
which should have a complete zone for THIS zone: 224-27.29.12.in-addr.arpa including NS records (authority) + SOA to indicate it is a valid delegate zone.

inside the zone valid entries need to exist for:
 224.224-27.29.12.in-addr.arpa
...
 255.224-27.29.12.in-addr.arpa
(sea earlier comment)



that make a query for a zone named:
Somewhat the same issues:
http://www.linuxquestions.org/questions/linux-networking-3/reverse-dns-for-partial-block-of-class-c-689616/

This is the URL: you can use to validate your address with AOL (without sending mail, and hopefully without waiting for timeouts on TTL cached RR's.)
http://postmaster.aol.com/cgi-bin/plugh/rdns.pl

@portabletech,

 they are needed unless AT&T will manage the reverse lookup for all their addresses (and changes to it) on a frequest basis or you can live with wild names that are generated.
If current updated names under usercontrol are needed then RFC2317 is an usable workaround around the short sightedness in the 1970's era wrt. addresses & lookups (which became DNS much later).

Also for IPv6 this is mitigated by creating sub zones for digit in the address.  Leaving a minimal delegate of 16 address at the bottom.
See also:

http://www.simpledns.com/help/v52/index.html?df_reverse.htm
SUCCESS!  


Here is my zone entry in name.conf


zone "224-27.147.29.12.in-addr.arpa" {
        type master;
        file "/etc/namedb/master/224-27.147.29.12.in-addr.arpa";


Here is my 224-27.147.29.12.in-addr.arpa file.

$TTL 3D
224-27.147.29.12.in-addr.arpa. IN      SOA     ns1.luxco.com. ns2.luxco.com. (
                        2011031404 ; Serial, todays date + todays serial
                        3H      ; Refresh
                        1H      ; Retry
                        1W      ; Expire
                        1H)     ; Minimum TTL

224-27.147.29.12.in-addr.arpa. IN       NS      ns1.luxco.com.
224-27.147.29.12.in-addr.arpa. IN       NS      ns2.luxco.com.
228.224-27.147.29.12.in-addr.arpa. IN   PTR     mail.luxco.com.

THANK YOU!!!  

Guys:  email me @ b-r-y-a-n-h at l-u-x-c-o-.-c-o-m
take out the spaces and dashes of course.



Thanks guys.
OK,
btw using this as TTL is a tad long.   259200
Cab you afford to wait 72 hours if you need to change the address?

Maybe a bit shourter is more  prudent.
43200 (12 Hours) is allready quite long.

Please consider lowering the TTL.