DNS, rDNS, & PTR problems

Discussion in 'Installation/Configuration' started by Ashaman074, Sep 18, 2007.

  1. Ashaman074

    Ashaman074 New Member

    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!
     
  2. catdude

    catdude ISPConfig Developer ISPConfig Developer

    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.
     
  3. chancer

    chancer New Member

    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.
     
  4. Ashaman074

    Ashaman074 New Member

    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?
     
  5. catdude

    catdude ISPConfig Developer ISPConfig Developer

    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.
     
  6. Ashaman074

    Ashaman074 New Member

    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?
     
  7. catdude

    catdude ISPConfig Developer ISPConfig Developer

    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.
     
  8. Ashaman074

    Ashaman074 New Member

    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?
     
    Last edited: Sep 19, 2007
  9. catdude

    catdude ISPConfig Developer ISPConfig Developer

    Exactly how are you using the "dig" command? What command line are you using?
     
  10. Ashaman074

    Ashaman074 New Member

    dig -t ptr domain.com
     
  11. catdude

    catdude ISPConfig Developer ISPConfig Developer

    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.
     
  12. Ashaman074

    Ashaman074 New Member

    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...?
     
  13. catdude

    catdude ISPConfig Developer ISPConfig Developer

    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.
     
  14. Ashaman074

    Ashaman074 New Member

    Yes, that does return the entire list - but what does this mean?
     
  15. catdude

    catdude ISPConfig Developer ISPConfig Developer

    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.
     
  16. Ashaman074

    Ashaman074 New Member

    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!
     
  17. Ashaman074

    Ashaman074 New Member

    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!
     
  18. Ashaman074

    Ashaman074 New Member

    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.
     
  19. dabro

    dabro New Member

    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
     
  20. daveb

    daveb Member

    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
     

Share This Page