# Reverse DNS and AOL [Quasi-solved]

## gpeangel

I'm in a bit of a bind (sorry, couldn't resist).

AOL has begun enforcing reverse DNS in order to validate e-mail sent to AOL accounts. This has forced me into the fabulous realm of DNS, admittedly a weak area in my SA capabilities.

I have a DSL line with a static IP NAT'ed via a firewall to a mail server on the inside. My DNS servers (primary and secondary) are run by the registrar of my domain name (DomainMonger.com). I now appears I need to run a primary DNS server at my IP address since there doesn't seem to be a way to modify the DNS records at the domain registrar to enable reverse DNS.

I'm in the process of configuring BIND on my server at the moment. It's proving to be slow and confusing so any pointers would be appreciated. I'll be posting my successes in this thread for others.

Has anyone else encountered and solved this issue with AOL and reverse DNS? The forums revealed one thread but no usable specifics for my situation.

Many thanks...

----------

## adaptr

I'll go you one worse: you can't actually influence rDNS yourself at all - in no way.

AOL rents you the line, so AOL sets your IP address and its reverse name.

The only way you can set rDNS yourself is if you get authority over your own IP.

Or the day dawns that AOL lets you set it yourself (as my ISP does...) which basically is the same as the above.

----------

## gpeangel

 *adaptr wrote:*   

> I'll go you one worse: you can't actually influence rDNS yourself at all - in no way.
> 
> AOL rents you the line, so AOL sets your IP address and its reverse name.
> 
> The only way you can set rDNS yourself is if you get authority over your own IP.
> ...

 

OK, I should clarify. I do not do business with AOL. Never have. Never will. My ISP/DSL provider is Qwest and I lease a block of static IP addresses from them.

----------

## adaptr

Phew, saved from the edge of madness..  :Wink: 

In that case, as long as you can get your ISP and the people you get the domain from to let you handle all nameserver requests, you should be good.

By now you have already discovered that DNS is composed of two separate parts: your domain resolution and your IP ranges.

These have to come together at your nameserver in order to do your own rDNS.

In other words:

- your nameserver = authoritative AND primary nameserver for your domain; the only entries the domain provider has for your domain is that you are its primary NS and they are your secondary NS.

- your nameserver = authoritative for your IP range, i.e. your ISP points to your nameservers for rDNS on that block

Then you have to set up a master / slave relationship to do zone transfers (not hard) and populate your DNS with values that seem vaguely entertaining to you  :Wink: 

NS and MX realnames are mandatory, the rest is up to you.

----------

## gpeangel

Well, I'm getting closer. I installed and configured BIND, starting simple to just handle a zone for my primary domain. Via the DNS Plus panel with DomainMonger.com (my domain registrar) I then set this box to be the primary DNS server and DomainMonger.com's DNS servers as secondary and tertiary. I also tried setting up a PTR reference with DomainMonger.com, but it ended up looking like

```
1.212.102.65.javazen.com     IN PTR     bigc.javazen.com
```

Which didn't look right, so this morning I removed it. Here's a snippet from my BIND query log:

```
Mar 25 07:57:52.396 info: client 127.0.0.1#41314: query: aol.com IN MX

Mar 25 07:57:52.439 info: client 127.0.0.1#41314: query: mailin-03.mx.aol.com IN AAAA

Mar 25 07:57:52.473 info: client 127.0.0.1#41314: query: mailin-03.mx.aol.com.javazen.com IN AAAA

Mar 25 07:57:52.473 info: client 127.0.0.1#41314: query: mailin-03.mx.aol.com IN A

Mar 25 07:57:52.474 info: client 127.0.0.1#41314: query: mailin-04.mx.aol.com IN AAAA

Mar 25 07:57:52.508 info: client 127.0.0.1#41314: query: mailin-04.mx.aol.com.javazen.com IN AAAA

Mar 25 07:57:52.508 info: client 127.0.0.1#41314: query: mailin-04.mx.aol.com IN A

Mar 25 07:57:52.509 info: client 127.0.0.1#41314: query: mailin-01.mx.aol.com IN AAAA

Mar 25 07:57:52.542 info: client 127.0.0.1#41314: query: mailin-01.mx.aol.com.javazen.com IN AAAA

Mar 25 07:57:52.543 info: client 127.0.0.1#41314: query: mailin-01.mx.aol.com IN A

Mar 25 07:57:52.543 info: client 127.0.0.1#41314: query: mailin-02.mx.aol.com IN AAAA

Mar 25 07:57:52.580 info: client 127.0.0.1#41314: query: mailin-02.mx.aol.com.javazen.com IN AAAA

Mar 25 07:57:52.581 info: client 127.0.0.1#41314: query: mailin-02.mx.aol.com IN A
```

There are numerous entries like this throughout the night. However, AOL's reverse DNS checker ([url=http://postmaster.info.aol.com/tools/rdns.html]http://postmaster.info.aol.com/tools/rdns.html[url]) still shows failure.

Several other reverse DNS checkers ([url=http://www.dnsstuff.com]http://www.dnsstuff.com[url], [url=http://remote.12dt.com/rns/]http://remote.12dt.com/rns/[url]) are now unable to resolve the IP address whereas previously they reported "no PTR reference" type errors (eg. "No PTR records exist for 65.102.212.1.")

These are my relevent zone files:

zone: javazen.com.zone

```
$ORIGIN .

$TTL 10800      ; 3 hours

javazen.com             IN SOA  bigc.javazen.com. postmaster.javazen.com. (

                                2005032401 ; serial

                                10800      ; refresh (3 hours)

                                3600       ; retry (1 hour)

                                604800     ; expire (1 week)

                                86400      ; minimum (1 day)

                                )

javazen.com.            NS      bigc.javazen.com.

                        MX      10 bigc.javazen.com.

$ORIGIN javazen.com.

$TTL 10800      ; 3 hours

bigc                  A       10.10.10.6

mail                    CNAME   bigc

www                     CNAME   bigc
```

zone: bigc.javazen.com.zone

```
$ORIGIN .

$TTL 10800      ; 3 hours

bigc.javazen.com      IN SOA  bigc.javazen.com. postmaster.bigc.javazen.com. (

                                2005032401 ; serial

                                10800      ; refresh (3 hours)

                                3600       ; retry (1 hour)

                                604800     ; expire (1 week)

                                86400      ; minimum (1 day)

                                )

                        NS      bigc.javazen.com.

                        MX      10 bigc.javazen.com.
```

zone: javazen.com.rev

```
$ORIGIN .

$TTL 10800      ; 3 hours

212.201.65.in-addr.arpa   IN SOA  bigc.javazen.com. postmaster.javazen.com. (

                                2005032401 ; serial

                                10800      ; refresh (3 hours)

                                3600       ; retry (1 hour)

                                604800     ; expire (1 week)

                                86400      ; minimum (1 day)

                                )

212.201.65.in-addr.arpa   NS      bigc.javazen.com.

$ORIGIN 212.201.65.in-addr.arpa.

$TTL 10800      ; 3 hours

6                       PTR     bigc.javazen.com.
```

zone: bigc.javazen.com.rev

```
$ORIGIN .

$TTL 10800      ; 3 hours

10.10.10.in-addr.arpa   IN SOA  bigc.javazen.com. postmaster.javazen.com. (

                                2005032401 ; serial

                                10800      ; refresh (3 hours)

                                3600       ; retry (1 hour)

                                604800     ; expire (1 week)

                                86400      ; minimum (1 day)

                                )

                        NS      bigc.javazen.com.

$ORIGIN 10.10.10.in-addr.arpa.

$TTL 10800      ; 3 hours

6                       PTR     bigc.javazen.com.
```

zone: localhost.zone

```
$TTL 3h

@       IN SOA  bigc.javazen.com. postmaster.javazen.com. (

                                2005032401 ; serial

                                10800      ; refresh (3 hours)

                                3600       ; retry (1 hour)

                                604800     ; expire (1 week)

                                86400      ; minimum (1 day)

                                )

                IN      NS      bigc.javazen.com.

localhost.      IN      A       127.0.0.1
```

zone: localhost.rev

```
$TTL 3h

@        IN SOA bigc.javazen.com. postmaster.javazen.com. (

                                2005032401 ; serial

                                10800      ; refresh (3 hours)

                                3600       ; retry (1 hour)

                                604800     ; expire (1 week)

                                86400      ; minimum (1 day)

                                )

                        IN      NS      bigc.javazen.com.

1                       IN      PTR     localhost.
```

A dig on the local server (bigc) shows:

```
# dig www.javazen.com

; <<>> DiG 9.2.3 <<>> www.javazen.com

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15202

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:

;www.javazen.com.               IN      A

;; ANSWER SECTION:

www.javazen.com.        10800   IN      CNAME   bigc.javazen.com.

;; AUTHORITY SECTION:

bigc.javazen.com.     10800   IN      SOA     bigc.javazen.com. postmaster.bigc.javazen.com. 2005032401 10800 3600 604800 86400

;; Query time: 1 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)

;; WHEN: Fri Mar 25 09:04:20 2005

;; MSG SIZE  rcvd: 101
```

whereas from a different box on a different network shows:

```
# dig www.javazen.com

; <<>> DiG 9.2.3 <<>> www.javazen.com

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44477

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:

;www.javazen.com.               IN      A

;; ANSWER SECTION:

www.javazen.com.        4674    IN      A       65.102.212.1

;; AUTHORITY SECTION:

javazen.com.            4478    IN      NS      ns1.domainmonger.com.

javazen.com.            4478    IN      NS      ns2.domainmonger.com.

;; ADDITIONAL SECTION:

ns1.domainmonger.com.   129790  IN      A       216.98.150.33

ns2.domainmonger.com.   134697  IN      A       216.122.4.81

;; Query time: 50 msec

;; SERVER: 205.171.3.65#53(205.171.3.65)

;; WHEN: Fri Mar 25 09:04:37 2005

;; MSG SIZE  rcvd: 130

```

Does the javazen.com.rev reverse zone need to specify the last octal (i.e. ".1") in the lines which include "in-addr.arpa"?

Does the PTR for this zone need to reflect the last octal for the public IP (i.e. ".1") or the last octal of the actual server IP (i.e. ".6")?

What might be preventing the reverse DNS from functioning?

Does this change need more time to filter through the Internet to more DNS servers?

Many thanks for giving this a scan,

Greg

----------

## adaptr

Phew... it's never easy trying to explain DNS to first-timers  :Wink: 

1. You should never create a zone for a host - which is what you're doing with bigc.

2. You should never mix internal and external addresses - which is what you're doing on javazen.

3. No, the origin may obviously not include the final host; it is an origin - the root of a zone.

4. You should never hang localhost off your regular domain - it's merely confusing and may screw things up.

5. What IP you should enter for rDNS depends on where you want to resolve it - for external queries you should of course always reply with the external IP.

I'll try to run through it again:

1. create a javazen.com zone file with the following info:

- SOA (mandatory)

- NS (mandatory)

- MX (mandatory)

- short hostnames of each and every host that should be reachable from the outside; at least the MX host's name has to resolve to an actual address right here.

2. create a reverse zone file for javazen with the following:

- SOA

- NS

- host pointers to equal the forward zone, with the final dot appended to the FQDN hostnames (absolutely mandatory, don't ask why)

3. now, in order for this to work at all, the host you specify as NS in the forward zone has to be duplicated in the providers' root zone file (he administers part of the .com uber-zone) as the primary NS.

This is not shown by your outputs, and is the primary reason it dun't work.

If I

```
dig javazen.com ns
```

it should always and immediately respond with your own NS (bigc.javazen.com in this case) and its IP, which in turn should be resolvable to its reverse name - bigc.javazen.com.

That final step is the most important - mess that up and it simply won't do what you expect.

Refresh times may have something to do with that - as I now see it DomainMonger doesn't even admit that you run your own NS.

If you could post your named.conf I'll see if I can post you a complete set back  :Wink: 

----------

## adaptr

As an add-on: I just digged javazen.com, and it resolves directly to your IP.

This is not what you want - if you don't take control of your domain then you can't set up rDNS.

The provider's DNS web panel thingy probably doesn't do exactly what you expected...

As an MX, you have set carbon - which again reslves to the same IP.

This is exactly what causes the mail servers' reverse lookup to fail.

It will query carbon.javazen.com, which is 65.102.212.1, then does an rDNS query and it gets... javazen.com.

Which means it fails.

The only thing that matters for the mail servers is that the MX host resolves correctly in both directions.

----------

## gpeangel

Thanks for you patience, it is greatly appreciated. I hope the forum will benefit from my trip up the learning curve. :Shocked: 

See below for my current named.conf. It references other zone files which I have not posted as they didn't seem relevant to the issue. I can post those if necessary.

As I understand it, the localhost is included for the benefit of the internal network. It appeared in a number of examples, however, its certainly possible I didn't understand the examples. Would I include localhost references if DNS was for the benefit of an internal network and not intended as a primary DNS, but not include localhost references if the DNS server is meant to be a primary DNS (public) server?

```
#

# named.conf

#

include "/etc/bind/rndc.key";

acl "internal-net" { 10.10.10.0/24; 127.0.0.1; };

acl "external-net" { any; };

controls {

    inet 127.0.0.1 allow { any; } keys { "rndc-key"; };

};

logging {

    channel "named_log" {

        // send most BIND logs to a dedicated log file

        file "/var/log/named.log" versions 10 size 500k;

        severity dynamic;

        print-category yes;

        print-severity yes;

        print-time yes;

    };

    channel "query_log" {

        // query logs go to a separate file

        file "/var/log/query.log" versions 10 size 500k;

        severity debug;

        print-severity yes;

        print-time yes;

    };

    

    category default { named_log; };

    category queries { query_log; };

};

options {

    directory "/";

    pid-file "/var/run/named/named.pid";

    statistics-file "/var/log/named.stats";

    dump-file "/var/log/named.dump";

    listen-on-v6 { none; };

    //listen-on { 127.0.0.1; };

    listen-on { "internal-net"; };

    allow-query { "internal-net"; "external-net"; };

    allow-transfer { none; };

    notify yes;

    forwarders { 205.171.3.65; 205.171.2.65; };

};

view "standard-in" in {

    zone "." {

        type hint;

        file "/var/bind/pri/named.root";

    };

    

    zone "bigc.javazen.com" {

        type master;

        file "/var/bind/pri/bigc.javazen.com.zone";

        update-policy { grant javazen-com-dhcp subdomain javazen.com. A TXT; };

        allow-query { any; }; 

        notify yes;

    };

    zone "javazen.com" {

        type master;

        file "/var/bind/pri/javazen.com.zone";

        allow-query { any; }; 

        notify yes;

    };

    

    zone "10.10.10.in-addr.arpa" {

        type master;

        file "/var/bind/pri/bigc.javazen.com.rev";

        update-policy { grant javazen-com-dhcp subdomain 10.10.10.in-addr.arpa. PTR TXT; };

        notify yes;

    };

    zone "localhost" {

        type master;

        file "/var/bind/pri/localhost.zone";

    };

    zone "0.0.127.in-addr.arpa" {

        type master;

        file "/var/bind/pri/localhost.rev";

    };

    zone "0.in-addr.arpa" {

        type master;

        file "/var/bind/pri/named.network";

    };

    zone "255.in-addr.arpa" {

        type master;

        file "/var/bind/pri/named.broadcast";

    };

};

view "ultimate-chaos" chaos {

    recursion no;

# Comment out because this was causing a fatal error.

# Supposidly, BIND 9.x doesn't need this.

#

#    zone "." {

#        type hint;

#        file "/var/bind/pri/named.root";

#    };

 

    zone "bind" {

        type master;

        file "/var/bind/pri/named.bind";

    };

};
```

----------

## gpeangel

 *adaptr wrote:*   

> As an add-on: I just digged javazen.com, and it resolves directly to your IP.
> 
> This is not what you want - if you don't take control of your domain then you can't set up rDNS.
> 
> The provider's DNS web panel thingy probably doesn't do exactly what you expected...
> ...

 

This clarifies things a bit.  I should say "bigc" and "carbon" are one and the same. Before I post, I run my text through a macro which strips user names, passwords, changes machine names and various other items - never like to accidentally disclose sensitive information. Even then, I still slip on occasion. :Embarassed: 

----------

## gpeangel

 *adaptr wrote:*   

> As an add-on: I just digged javazen.com, and it resolves directly to your IP.
> 
> This is not what you want - if you don't take control of your domain then you can't set up rDNS.
> 
> 

 

If I understand this point correctly, in order for this to work, I should not manage any of my DNS stuff with my domain registrar, or ISP, etc. I should manage all javazen.com's DNS records on my box, carbon, and cancel/delete any DNS/zone information with the third party.

----------

## gpeangel

 *adaptr wrote:*   

> As an MX, you have set carbon - which again reslves to the same IP.
> 
> This is exactly what causes the mail servers' reverse lookup to fail.
> 
> It will query carbon.javazen.com, which is 65.102.212.1, then does an rDNS query and it gets... javazen.com.
> ...

 

My domain registrar allow me to associate any number of subdomains with an IP address. Currently, I have:

```
javazen.com --> 65.102.212.1

*.javazen.com -->   65.102.212.1

carbon.javazen.com -->  65.102.212.1

ftp.javazen.com --> 65.102.212.1

mail.javazen.com -->    65.102.212.1

www.javazen.com --> 65.102.212.1
```

Additionally, I have a mail server (MX entry) defined as carbon.javazen.com. This all looks like it needs some clean up (set it up 3-4 years ago) in the form of removing the IP address associations with carbon.javazen.com and mail.javazen.com. Looking at it, it seems to me the only entries I need are

```
javazen.com --> 65.102.212.1

*.javazen.com -->   65.102.212.1
```

Will this resolve the issue you observed with dig?

----------

## adaptr

None of this will ever set your rDNS correctly, as you are not an autoritative NS for the domain.

```
dig -x 65.102.212.1

;; QUESTION SECTION:

;1.212.102.65.in-addr.arpa.     IN      PTR

;; AUTHORITY SECTION:

212.102.65.in-addr.arpa. 900    IN      SOA     authns1.mpls.qwest.net. dns-admin.qwestip.net.
```

No rDNS - no mail server checks...

EDIT: sure, you could at least try that - I've been running my domain like that for years (I'm a lazy sod) and no MTA has ever complained about it...

----------

## gpeangel

This is interesting. Before making the above changes to my domain DNS record with the domain registrar, dig reported

```
# dig any javazen.com

; <<>> DiG 9.2.3 <<>> any javazen.com

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48885

;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:

;javazen.com.                   IN      ANY

;; ANSWER SECTION:

javazen.com.            7106    IN      MX      0 carbon.javazen.com.

javazen.com.            4395    IN      A       65.102.212.1

javazen.com.            7106    IN      NS      ns2.domainmonger.com.

javazen.com.            7106    IN      NS      ns1.domainmonger.com.

;; AUTHORITY SECTION:

javazen.com.            7106    IN      NS      ns1.domainmonger.com.

javazen.com.            7106    IN      NS      ns2.domainmonger.com.

;; Query time: 3 msec

;; SERVER: 10.5.10.10#53(10.5.10.10)

;; WHEN: Fri Mar 25 10:56:15 2005

;; MSG SIZE  rcvd: 145
```

After making these changes, dig reports:

```
# dig any javazen.com

; <<>> DiG 9.2.3 <<>> any javazen.com

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23909

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:

;javazen.com.                   IN      ANY

;; ANSWER SECTION:

javazen.com.            4952    IN      NS      ns1.domainmonger.com.

javazen.com.            4952    IN      NS      ns2.domainmonger.com.

;; AUTHORITY SECTION:

javazen.com.            4952    IN      NS      ns2.domainmonger.com.

javazen.com.            4952    IN      NS      ns1.domainmonger.com.

;; Query time: 3 msec

;; SERVER: 10.5.10.10#53(10.5.10.10)

;; WHEN: Fri Mar 25 12:59:38 2005

;; MSG SIZE  rcvd: 106
```

However, this does not seem to have helped reverse DNS. Neither does DomainMonger seem to allow me to set my local box (carbon) as the primary DNS server. It keeps resetting it back to ns1 and ns2 at DomainMonger. I'm still able to send and receive email from the javazen.com domain.

Each of these dig commands was run from a remote computer, i.e. not from javazen.com's internal network or from carbon.javazen.com itself. Rather, from my PC at work.

----------

## ak7

Reverse DNS is a huge weakness for most ISPs.  Its a fairly simple process until you try to define it on an ip by ip basis.

The official name servers for your domain are defined when your domian is registered.  To change the authoritative DNS servers you will need to change your domain registration so the defined DNS servers point at your own DNS servers.

Your ISP should be able to create the reverse entries you need.  If they won't then it might be time to find a smarter ISP.

RFC 2317 defines a classless reverse technique that does not require your ISP to delegate an IP address to you.  In essence, they would create an alias that you would later define.  The RFC explains the process in detail.  About 25% of the ISP's I've worked with will support Classless Reverse Addressing, the other 75% charge a monthly fee for DNS and don't want to lose their cash cow.

The O'Reiley book on DNS is a must read for anyone contemplating hosting their own DNS!

----------

## gpeangel

After much effort, I have been unable to configure a DNS server to properly handle reverse DNS requests. My sense is there is a way, but my understanding of DNS is weak. I've acquired the O'Reilly book on BIND and DNS (as well as the cookbook) and once I've worked my way through these, I'll try again.

In the short term, I discovered that my ISP (Qwest) has a feature for those of us who have leased a small block of IP addresses which allows us to specify a single domain per IP address for reverse DNS lookup. This seems to have solved the issue. But not everyone uses Qwest so I don't consider this issue completely resolved. Here's what dig reports now:

```
# dig any javazen.com

; <<>> DiG 9.2.3 <<>> any javazen.com

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5893

;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 2

;; QUESTION SECTION:

;javazen.com.                   IN      ANY

;; ANSWER SECTION:

javazen.com.            172800  IN      NS      carbon.javazen.com.

javazen.com.            172800  IN      NS      ns1.domainmonger.com.

javazen.com.            172800  IN      NS      ns2.domainmonger.com.

;; AUTHORITY SECTION:

javazen.com.            172800  IN      NS      carbon.javazen.com.

javazen.com.            172800  IN      NS      ns1.domainmonger.com.

javazen.com.            172800  IN      NS      ns2.domainmonger.com.

;; ADDITIONAL SECTION:

ns1.domainmonger.com.   151106  IN      A       216.98.150.33

carbon.javazen.com.     172800  IN      A       65.102.212.1

;; Query time: 2202 msec

;; SERVER: 205.171.2.65#53(205.171.2.65)

;; WHEN: Sun Mar 27 16:15:45 2005

;; MSG SIZE  rcvd: 173
```

Thanks for the excellent input provided by those who posted to this thread.

----------

