Hi, I have been tinkering with the DNS settings on my server for the last few days trying to get things right, but I seem to have come to a standstill so I thought I would ask for some help... Original problem - I cannot send Email to AOL. AOL has a diagnostic tool posted at http://postmaster.aol.com/tools/rdns.html for testing. When I run the test, I get: Code: DNS Server Response: No PTR but got: 75.255.167.12.in-addr.arpa. 171613 IN CNAME 75.72/29.255.167.12.in-addr.arpa. Failure! Unfortunately we were unable to resolve Reverse DNS for the IP address you entered. Contact your ISP or e-mail administrator to modify these settings. Also please note the following points: AOL does require that all connecting Mail Transfer Agents have established reverse DNS, regardless of whether it matches the domain. Reverse DNS must be in the form of a fully-qualified domain name. Reverse DNSes containing in-addr.arpa are not acceptable, as these are merely placeholders for a valid PTR record. Reverse DNSes consisting only of IP addresses are also not acceptable, as they do not correctly establish the relationship between domain and IP address. OK, so for some reason it seems that my mail server is not being associated with the address. I did a dig -x 12.167.255.xx and got: Code: ; <<>> DiG 9.3.2 <<>> -x 12.167.255.xx ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32401 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;xx.255.167.12.in-addr.arpa. IN PTR ;; ANSWER SECTION: xx.255.167.12.in-addr.arpa. 42424 IN CNAME xx.xx/xx.255.167.12.in-addr.arpa. ;; Query time: 21 msec ;; SERVER: 4.2.2.1#53(4.2.2.1) ;; WHEN: Tue Sep 18 15:56:07 2007 ;; MSG SIZE rcvd: 67 Which doesn't seem right to me, shouldn't I see a mail.domain.com type entry there? If so, where is this defined? I have been poking around in bind files and things look right to me - any pointers? Secondly, and I don't know if this is a problem or not - but when I run a test at DNSstuff.com, I have the following warnings: Code: Fail - Missing (stealth) nameservers: FAIL: You have one or more missing (stealth) nameservers. The following nameserver(s) are listed (at your nameservers) as nameservers for your domain, but are not listed at the parent nameservers (therefore, they may or may not get used, depending on whether your DNS servers return them in the authority section for other requests, per RFC2181 5.4.1). You need to make sure that these stealth nameservers are working; if they are not responding, you may have serious problems! The DNSreport will not query these servers, so you need to be very careful that they are working properly. ns1.domain.net. ns2.domain.net. This is listed as an ERROR because there are some cases where nasty problems can occur (if the TTLs vary from the NS records at the root servers and the NS records point to your own domain, for example). --- Fail - Missing nameservers 2: ERROR: One or more of the nameservers listed at the parent servers are not listed as NS records at your nameservers. The problem NS records are: ns1.domain.com. ns2.domain.com. ---- Fail - Stealth NS record leakage: Your DNS servers leak stealth information in non-NS requests: Stealth nameservers are leaked [ns2.domain.net.]! Stealth nameservers are leaked [ns1.domain.net.]! This can cause some serious problems (especially if there is a TTL discrepancy). If you must have stealth NS records (NS records listed at the authoritative DNS servers, but not the parent DNS servers), you should make sure that your DNS server does not leak the stealth NS records in response to other queries. I am not sure what is causing the above errors either, or why it is .net in the first error but .com in the second. I do have both a domain.net and domain.com, but only ns1.domain.net exists, is there supposed to be one for each hosted domain? I don't know if these are related to the first error or not, but since they were flagged on dnsstuff it seemed like it was worth checking out also! Thanks!
Most ISPs don't automatically provide reverse mapping to the IP addresses they assign you. And it's likely that the reverse-DNS authority for the netblock your IP is a part of belongs to your ISP, or possibly to their upstream. In order to get a reverse DNS lookup to resolve to your domain name you would most likely have to talk to your ISP's tech support department and ask them to set up the reverse mapping.
catdude is right, but that shouldn't stop you setting an spf record for the domain. That is usually, but not always, enough to satisfy AOL. In case it's of interest, I usually tell clients and correspondents with AOL accounts to set up an alternative method of access if they require stable communications. Each of AOL's frequent attempts to blackmail email users into paying them, essentially landgrabbing email services into a single proprietary block with AOL at its head, causes a lot more trouble than it's worth.
Thanks for the input. I actually did contact the ISP, and I asked them to "change the delegation" to ns1.domain.net and ns2.domain.net (the name servers for ISPConfig) because I thought that was correct. Was it not? I thought that that would mean any rdns requests would then be sent to ns1.domain.net and ns2.domain.net which would them provide the PTR records. Unfortunately I am not 100% sure if this was correct...? Or maybe it was correct but they way they did it is not acceptable to AOL? How about the second section with the problems regarding missing/stealth nameservers and such - cause for alarm, or is that something that isn't necessarily a problem?
It appears that your provider did indeed SWIP your netblock to you. I'm surprised by that - a lot of big providers won't do that. DNSStuff.com says that your netblock is served up by your servers, but that your servers aren't responding. At least, no PTR (reverse DNS) records are avalable. Frankly, I'm not sure what the errors messages you mentioned mean. I haven't sued that tool much.
Well, it is on a T1 line - so that is why they made the changes. I thought it looked like everything was winding up at my name servers as well, yet the PTR records are not being found. How about the results of the dig I did on my IP, isn't that wrong? I don't know this stuff very well yet, but it said: ";; ANSWER SECTION: xx.255.167.12.in-addr.arpa. 42424 IN CNAME xx.xx/xx.255.167.12.in-addr.arpa." It has no mention of an actual domain name, is that a bit of a clue as to what is wrong?
Ideally, I think it should. Looking through the ISPConfig DNS tool screens, it looks like we can set up A, CNAME, MX, and SPF (txt) records. I don't see a tool for creating PTR records manually. In my setup, ISPConfig is automatically building ptr records for me. Take a look in your bind9 data file directory (probably /var/lib/named/etc/bind) and see if you have a file named pri.z.y.x.in-addr.arpa, where your IP address is in the x.y.z block. Note: doing "dig -t ptr @w.x.y.z w.x.y.z" where w.x.y.z is your IP address won't return your PTR records. The command needs to be "dig -t ptr @w.x.y.z z.y.x.z.in-addr.arpa". That ought to return your reverse DNS records.
I thought that ISPConfig set them up automatically, because when I check my pri.255.167.12.in-addr.arpa file it says: Code: $TTL 86400 @ IN SOA ns1.domain.net. hostmaster.domain.net. ( 2007091805 ; serial, todays date + todays serial # 28800 ; Refresh 7200 ; Retry 604800 ; Expire 86400) ; Minimum TTL NS ns1.domain.net. NS ns2.domain.net. 75 PTR domain3.com. 75 PTR www.domain3.com. 75 PTR gallery.domain3.com. 75 PTR mail.domain3.com. 75 PTR domain.net. 75 PTR www.domain.net. 75 PTR mail.domain.net. 75 PTR domain.com. 75 PTR www.domain.com. 75 PTR gallery.domain.com. 75 PTR ftp.domain.com. 75 PTR mail.domain.com. 75 PTR domain2.com. 75 PTR www.domain2.com. ;;;; MAKE MANUAL ENTRIES BELOW THIS LINE! ;;;; Which actually does look right to me, there is an entry for all the domains I have created with ISPConfig. Here is the output of a dig on the PTR for the domain: Code: ; <<>> DiG 9.3.2 <<>> -t ptr domain.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39802 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;domain.com. IN PTR ;; AUTHORITY SECTION: domain.com. 10779 IN SOA ns1.domain.net. admin.domain.com. 2007091808 28800 7200 604800 86400 ;; Query time: 334 msec ;; SERVER: 4.2.2.1#53(4.2.2.1) ;; WHEN: Wed Sep 19 11:48:39 2007 ;; MSG SIZE rcvd: 84 Does that help at all?
That's the problem - a ptr record is associated with an IP address, not with a domain name. That command by definition won't generate a valid PTR record return. Try using "dig -t ptr z.y.x.w.in-addr.arpa", where your IP address is w.x.y.z.
Oops. OK, here is the output of dig -t ptr 75.255.167.12.in-addr.arpa: Code: ; <<>> DiG 9.3.2 <<>> -t ptr 75.255.167.12.in-addr.arpa ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25615 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;75.255.167.12.in-addr.arpa. IN PTR ;; ANSWER SECTION: 75.255.167.12.in-addr.arpa. 43182 IN CNAME 75.72/29.255.167.12.in-addr.arpa. ;; Query time: 15 msec ;; SERVER: 4.2.2.1#53(4.2.2.1) ;; WHEN: Wed Sep 19 14:35:19 2007 ;; MSG SIZE rcvd: 67 Which is what I was AOL's test was returning I believe...with no reference to the associated domains...?
Yeah.... that's a bummer. That's not what I expected to see. How about "dig -t ptr @12.167.255.75 75.255.167.12.in-addr.arpa"? I'm assuming that will return the host names for all the domains you've defined in ISPConfig.
It means that your ISPConfig server is properly configured for DNS and is returning the proper PTR records, but that the authority records that define where to look for reverse-IP mappings for your subnet are pointing somewhere other than your server. I'm afraid my understanding of DNS internals fails at this point. I'm not sure how to determine where such requests are directed, or how to get them redirected to your server. The best I can offer at this point is to maybe contact tech support at your ISP (AT&T, was it?) and ask them.
Interesting. Well, I very much appreciate your help with these steps! I suppose it can't hurt to give them a call, they may be able to shed some light on this mystery for me - too strange. Of course, if anyone else has thoughts on this Probl...err...that is "learning experience" I would appreciate it also. Thanks again catdude for the assistance!
Hi, I thought I would add something new to this old thread as I never did resolve it. It has now become a bigger problem however, as apparently Comcast has tightened things up a bit and I can no longer send to them either I contacted my ISP, who sent me the following information: Code: Following is an example of how a partial c class should be set up. 0/27.161.2.12.in-addr.arpa. 3600 SOA dns2.anydomain.com. administrator.anydomain.com. ( 2002050202 ; serial 14400 ; refresh (4 hour) 600 ; retry (10 mins) 600000 ; expire (7 day) 86400) ; minimum (1 day) 0/27.161.2.12.in-addr.arpa. 3600 NS dns2.anydomain.com. 0/27.161.2.12.in-addr.arpa. 3600 NS cbru.br.ns.els-gms.att.net. 0/27.161.2.12.in-addr.arpa. 3600 NS dbru.br.ns.els-gms.att.net. 1.0/27.161.2.12.in-addr.arpa. 3600 PTR gw.anydomain.com. 10.0/27.161.2.12.in-addr.arpa. 3600 PTR hidden4.anydomain.com. 11.0/27.161.2.12.in-addr.arpa. 3600 PTR hidden5.anydomain.com. 12.0/27.161.2.12.in-addr.arpa. 3600 PTR hidden6.anydomain.com. 13.0/27.161.2.12.in-addr.arpa. 3600 PTR www.anydomain.com. 14.0/27.161.2.12.in-addr.arpa. 3600 PTR www.adomain.org. 2.0/27.161.2.12.in-addr.arpa. 3600 PTR dns2.anydomain.com. 3.0/27.161.2.12.in-addr.arpa. 3600 PTR firewall.anydomain.com. 4.0/27.161.2.12.in-addr.arpa. 3600 PTR mail.anydomain.com. 5.0/27.161.2.12.in-addr.arpa. 3600 PTR ftp.anydomain.com. 6.0/27.161.2.12.in-addr.arpa. 3600 PTR www.anydomain.com. 7.0/27.161.2.12.in-addr.arpa. 3600 PTR hidden1.anydomain.com. 8.0/27.161.2.12.in-addr.arpa. 3600 PTR hidden2.anydomain.com. 9.0/27.161.2.12.in-addr.arpa. 3600 PTR hidden3.anydomain.com. 0/27.161.2.12.in-addr.arpa. 3600 SOA dns2.anydomain.com. administrator.anydomain.com. ( 2002050202 ; serial 14400 ; refresh (4 hour) 600 ; retry (10 mins) 600000 ; expire (7 day) 86400 ) ; minimum (1 day) Unfortunately, I am not sure WHERE this should be set up - should I manually edit config files on my server? Or is there a better way to do this? If I understand them correctly, any PTR requests are being handed off by them to my name servers; but they say that something must not be configured right at my end, and they have sent me this sample. Does anyone understand this or know what might be causing the problem? Thanks!
Well, as a followup (I always hate abandoned threads when I am searching!), I had someone with extensive Linux experience do a little troubleshooting since I felt I had exhausted all of my resources. It seems the the problem came down to one simple entry: In named.conf the entry was: PHP: zone "255.167.12.in-addr.arpa" { type master; file "pri.255.167.12.in-addr.arpa"; This was changed to: PHP: zone "72/29.255.167.12.in-addr.arpa" { type master; file "pri.255.167.12.in-addr.arpa"; Apparently all this trouble was as simple as the naming convention used. Interestingly enough, as I typed this today I noticed the changes had been overwritten to their original state! I'll have to keep an eye on it to see if it happens again, maybe manually editing the file wasn't the best way to go about it... Thanks to everyone who tried to help with this problem.
This Solution Works Thanks for the information, I'm in the same boat, we installed an ATT T1 line and they delegated the r-dns to us. Adding the zone to named.conf with the subnet information as you described did start it to working. As in "zone "192/27.xxx.xxx.xx.in.addr.arpa" pointing to the same zone file "pri.xxx.xxx.xx.in-addr-arpa" does work. The zone file basically works without any mods except for too many entries. Now I need to figure out how to limit the reverse hostname to one host without ISPConfig overwriting the zone file with every domain on the server. Thanks again, it did save some hair pulling, Dave
I had the same problems with att and rdns delegation. Copy and edit the named.master template and you shouldn't have to worry about your changes being overwritten during updates. Code: cp /root/ispconfig/isp/conf/named.conf.master /root/ispconfig/isp/conf/customized_templates/named.conf.master then edit Code: vi /root/ispconfig/isp/conf/customized_templates/named.conf.master here is a link on how I changed named.conf http://www.howtoforge.com/forums/showpost.php?p=123585&postcount=2 Also here is a faq I was sent from att for Methods of Reverse Delegation Code: Customers using UNIX or Linux with BIND should follow the outline below. A. Classless Reverse Delegation – Less than /24 For more information RFC 2317 (Section 5.2). 1. At SBC Name Server: a. Example – Classless reverse delegation of 192.68.10.8/29 is delegated to customer’s ns1.custdom.net 192.68.10.9. b. The zone 192.68.10.net would have these CNAME entries to in-addr.arpa. ; rev del custdom.net 192.68.10.8/29 8 NS ns1.custdom.net. NS ns1.swbell.net. ;an SBC server will be used only if secondary service is requested NS ns2.swbell.net. ;an SBC server will be used only if secondary service is requested 9 CNAME 9.8.10.68.192.in-addr.arpa. 10 CNAME 10.8.10.68.192.in-addr.arpa. 11 CNAME 11.8.10.68.192.in-addr.arpa. 12 CNAME 12.8.10.68.192.in-addr.arpa. 13 CNAME 13.8.10.68.192.in-addr.arpa. 14 CNAME 14.8.10.68.192.in-addr.arpa. c. Optional Secondary DNS Service - At SBC named.conf.in-addr with slave statement as secondary to 192.68.10.9. zone "8.10.68.192.in-addr.arpa" { type slave; file "SECONDARY/192.68.10.8.net"; masters {192.68.10.9;};}; 2. At Customer Name Server: a. The following statement would be included at the customer’s named.conf file. zone "8.10.68.192.in-addr.arpa" { type master; file "db.8.10.68.192.in-addr.arpa";}; b. The zone 8.10.68.192.in-addr.arpa for the PTR records would look similar to this, edit the PTR records as desired… $ORIGIN 8.10.68.192.in-addr.arpa. @ IN NS your-ns.custdom.net. IN NS ns1.swbell.net. ;use an SBC server if secondary DNS service was requested IN NS ns2.swbell.net. ;use an SBC server if secondary DNS service was requested 9 IN PTR host1.custdom.net. 10 IN PTR host2.custdom.net. 11 IN PTR host3.custdom.net. 12 IN PTR host4.custdom.net. 13 IN PTR host5.custdom.net. 14 IN PTR host6.custdom.net. B. Full Class/es Reverse Delegation - /24 Plus 1. At SBC Name Server: a. Example – Reverse delegation of 192.68.10.0/24 is delegated to customer’s server, ns1.custdom.net 192.68.10.9. The zone 192.68.net would have this NS record to ns1.custdom.net. ; rev del custdom.net 192.68.10.0/24 10 NS ns1.custdom.net. NS ns1.swbell.net. ;only when specifically requested for secondary DNS service NS ns2.swbell.net. ;only when specifically requested for secondary DNS service b. Optional Secondary DNS Service - At SBC named.conf.in-addr with slave statement to 192.68.10.9. zone "10.68.192.in-addr.arpa" { type slave; file "SECONDARY/192.68.10.net"; masters {192.68.10.9;};}; 2. At Customer Name Server: a. The following statement would be included at the customer’s named.conf file. zone "10.68.192.in-addr.arpa" { type master; file "db.10.68.192.in-addr.arpa";}; b. The zone 10.68.192.in-addr.arpa for the PTR records would look similar to this, edit the PTR records as desired… $ORIGIN 10.68.192.in-addr.arpa. @ IN NS your-ns.custdom.net. IN NS ns1.swbell.net. ;use an SBC server only when secondary DNS service was specifically requested IN NS ns2.swbell.net. ;use an SBC server only when secondary DNS service was specifically requested IN PTR host1.custdom.net. 2 IN PTR host2.custdom.net. ;cont… 254 IN PTR host254.custdom.net. 255 IN PTR host255.custdom.net. Hope this helps Ashaman074 and dabro
