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.a rpa";
allow-transfer { localhost; };
allow-query { any; };
};
zone "147.xx.xx.in-addr.arpa" {
type master;
file "/etc/namedb/master/147.xx .xx.in-add r.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
zone "224-27.147.xx.xx.in-addr.
type master;
file "/etc/namedb/master/224-27
allow-transfer { localhost; };
allow-query { any; };
};
zone "147.xx.xx.in-addr.arpa" {
type master;
file "/etc/namedb/master/147.xx
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
$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
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.
Try going to www.cmyip.com and see if it tells you the same ip address you think you have.
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
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.
ASKER
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
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-a ddr.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.arp a. IN PTR
;; ANSWER SECTION:
228.147.29.12.in-addr.arpa . 83000 IN CNAME 228.224-27.147.29.12.in-ad dr.arpa.
228.224-27.147.29.12.in-ad dr.arpa. 259200 IN PTR mail.luxco.com.
;; AUTHORITY SECTION:
224-27.147.29.12.in-addr.a rpa. 259200 IN NS ns1.luxco.com.
224-27.147.29.12.in-addr.a rpa. 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
What I should be seeing in this answer section is
228.147.29.12.in-addr.arpa
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.arp
;; ANSWER SECTION:
228.147.29.12.in-addr.arpa
228.224-27.147.29.12.in-ad
;; AUTHORITY SECTION:
224-27.147.29.12.in-addr.a
224-27.147.29.12.in-addr.a
;; 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.
;; 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.
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.
ASKER
Thanks I will update soon.
ASKER
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.a rpa 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
$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.arp a. 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
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.arp
;; ANSWER SECTION:
228.147.29.12.in-addr.arpa
;; 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
;; WHEN: Sun Mar 13 03:54:03 2011
;; MSG SIZE rcvd: 140
ASKER
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-ad dr.arpa. at server ns2.luxco.com. (zone 224-27.147.29.12.in-addr.a rpa.) [from 12.127.16.69]
Asking h.root-servers.net for 228.224-27.147.29.12.in-ad dr.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-ad dr.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-ad dr.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.a rpa.)
Asking ns1.luxco.com. for 228.224-27.147.29.12.in-ad dr.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.
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
d.root-servers.net says to go to cmtu.mt.ns.els-gms.att.net
Asking cmtu.mt.ns.els-gms.att.net
Asking h.root-servers.net for 228.224-27.147.29.12.in-ad
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-ad
c.in-addr-servers.arpa [196.216.169.10] says to go to dmtu.mt.ns.els-gms.att.net
Asking dmtu.mt.ns.els-gms.att.net
dmtu.mt.ns.els-gms.att.net
Asking ns1.luxco.com. for 228.224-27.147.29.12.in-ad
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 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-serv ers.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-ad dr-servers .arpa) in 119 ms
228.147.29.12.in-addr.arpa . 83000 IN CNAME 228.224-27.147.29.12.in-ad dr.arpa.
224-27.147.29.12.in-addr.a rpa. 83000 IN NS ns2.luxco.com.
224-27.147.29.12.in-addr.a rpa. 83000 IN NS ns1.luxco.com.
;; Received 114 bytes from 199.191.128.106#53(dbru.br .ns.els-gm s.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.arp a. IN PTR
;; ANSWER SECTION:
228.147.29.12.in-addr.arpa . 259200 IN PTR mail.luxco.com.147.29.12.i n-addr.arp a.
;; 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
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-serv
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-ad
228.147.29.12.in-addr.arpa
224-27.147.29.12.in-addr.a
224-27.147.29.12.in-addr.a
;; Received 114 bytes from 199.191.128.106#53(dbru.br
========================
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.arp
;; ANSWER SECTION:
228.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
;; WHEN: Sun Mar 13 23:34:42 2011
;; MSG SIZE rcvd: 116
ASKER
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.a rpa. Should I have removed it? : Asking ns1.luxco.com. for 228.224-27.147.29.12.in-ad dr.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-ad dr.arpa. at server ns1.luxco.com. (zone 224-27.147.29.12.in-addr.a rpa.) [from 199.191.128.106]
Asking a.root-servers.net for 228.224-27.147.29.12.in-ad dr.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-ad dr.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-ad dr.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.a rpa.)
Asking ns1.luxco.com. for 228.224-27.147.29.12.in-ad dr.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.
Notice that the dns stuff is still looking for the zone 224-27-147.29.12.in-addr.a
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
h.root-servers.net says to go to dbru.br.ns.els-gms.att.net
Asking dbru.br.ns.els-gms.att.net
Asking a.root-servers.net for 228.224-27.147.29.12.in-ad
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-ad
e.in-addr-servers.arpa [203.119.86.101] says to go to dbru.br.ns.els-gms.att.net
Asking dbru.br.ns.els-gms.att.net
dbru.br.ns.els-gms.att.net
Asking ns1.luxco.com. for 228.224-27.147.29.12.in-ad
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-ad dr.arpa.
;; Received 114 bytes from 199.191.128.106#53(dbru.br .ns.els-gm s.att.net) in 158 ms
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
;; Received 114 bytes from 199.191.128.106#53(dbru.br
ASKER
@PortableTech
I missed your post about ATT. Firing off email to ATT Now!
Bryan
I missed your post about ATT. Firing off email to ATT Now!
Bryan
ASKER
@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.a rpa (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-ad dr.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-ad dr.arpa. at server ns2.luxco.com. (zone 224-27.147.29.12.in-addr.a rpa.) [from 12.127.16.70]
Asking b.root-servers.net for 228.224-27.147.29.12.in-ad dr.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-ad dr.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-ad dr.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.a rpa.)
Asking ns2.luxco.com. for 228.224-27.147.29.12.in-ad dr.arpa. PTR record: Timed out [at 12.29.147.227]. Trying again.
Asking ns1.luxco.com. for 228.224-27.147.29.12.in-ad dr.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-serv ers.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-ad dr-servers .arpa) in 119 ms
228.147.29.12.in-addr.arpa . 83000 IN CNAME 228.224-27.147.29.12.in-ad dr.arpa.
224-27.147.29.12.in-addr.a rpa. 83000 IN NS ns2.luxco.com.
224-27.147.29.12.in-addr.a rpa. 83000 IN NS ns1.luxco.com.
;; Received 114 bytes from 199.191.128.106#53(dbru.br .ns.els-gm s.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,
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.a
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
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
Thanks,
Bryan
From: DNS Services, MIS Lifecycle [mailto:RM-dnschanges@att.
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
f.root-servers.net says to go to dmtu.mt.ns.els-gms.att.net
Asking dmtu.mt.ns.els-gms.att.net
Asking b.root-servers.net for 228.224-27.147.29.12.in-ad
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-ad
b.in-addr-servers.arpa [199.253.183.183] says to go to dmtu.mt.ns.els-gms.att.net
Asking dmtu.mt.ns.els-gms.att.net
dmtu.mt.ns.els-gms.att.net
Asking ns2.luxco.com. for 228.224-27.147.29.12.in-ad
Asking ns1.luxco.com. for 228.224-27.147.29.12.in-ad
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
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-serv
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-ad
228.147.29.12.in-addr.arpa
224-27.147.29.12.in-addr.a
224-27.147.29.12.in-addr.a
;; Received 114 bytes from 199.191.128.106#53(dbru.br
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
@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.
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.
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.a rpa
and the NS records for them ... ns2.luxco.com and ns1.luxco.com
the PTR lookup for 228.224-27.29.12.in-addr.a rpa 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.a rpa
...
255.224-27.29.12.in-addr.a rpa
(sea earlier comment)
that make a query for a zone named:
228.147.29.12.in-addr.arpa
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.a
and the NS records for them ... ns2.luxco.com and ns1.luxco.com
the PTR lookup for 228.224-27.29.12.in-addr.a
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.a
...
255.224-27.29.12.in-addr.a
(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
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
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
ASKER
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.a rpa";
Here is my 224-27.147.29.12.in-addr.a rpa file.
$TTL 3D
224-27.147.29.12.in-addr.a rpa. 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.a rpa. IN NS ns1.luxco.com.
224-27.147.29.12.in-addr.a rpa. IN NS ns2.luxco.com.
228.224-27.147.29.12.in-ad dr.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.
Here is my zone entry in name.conf
zone "224-27.147.29.12.in-addr.
type master;
file "/etc/namedb/master/224-27
Here is my 224-27.147.29.12.in-addr.a
$TTL 3D
224-27.147.29.12.in-addr.a
2011031404 ; Serial, todays date + todays serial
3H ; Refresh
1H ; Retry
1W ; Expire
1H) ; Minimum TTL
224-27.147.29.12.in-addr.a
224-27.147.29.12.in-addr.a
228.224-27.147.29.12.in-ad
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.
ASKER
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.
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.
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.