Solved Reverse DNS not Resolving

rtwingfield · Sep 30, 2015

I apparently cannot successfully configure reverse DNS (BIND 9.10.2) for our mail server. This became a problem after converting from our legacy AT&T DSL service to AT&T's U-verse. Now, attempts to send eMail to (for example) a sbcglobal.net recipient fails with the following messages: (FYI, no problem mailing to a non-DNS aware server.)

The original message was received at Fri, 25 Sep 2015 10:41:33 ‑0500 (CDT)
from [192.168.1.75]

‑‑‑‑‑ The following addresses had permanent fatal errors ‑‑‑‑‑
<john.doe@sbcglobal.net>
(reason: 550 5.7.1 Connections not accepted from servers without a valid sender domain.alph144 Fix reverse DNS for 162.202.233.81)

‑‑‑‑‑ Transcript of session follows ‑‑‑‑‑
... while talking to al‑ip4‑mx‑vip1.prodigy.net.:
>>> MAIL From:<Ron.Wingfield@Archaxis.net>
<<< 550 5.7.1 Connections not accepted from servers without a valid sender domain.alph144
Fix reverse DNS for 162.202.233.81
554 5.0.0 Service unavailable

My question is: How do I "Fix reverse DNS " for my domain(s)?

Just yesterday, 29 SEP 2015, AT&T's tech help admitted that they had some errors in their configuration regarding delegation of our IP 29/block to our servers, and implemented changes on their side. Additionally, they suggested that I should add a PTR RR configured as follows:

Code:

81.233.202.162.IN-ADDS.ARPA  IN  PTR  alpha.archaxis.net.

(To wit, see the PTR RR in the /var/namedb/zonefiles/db.233.202.162.rev file.)

Unfortunately, this just does not resolve and dig returns the following information:

# dig -t ptr 81.233.202.162.in-addr.arpa

Code:

; <<>> DiG 9.10.2 <<>> -t ptr 81.233.202.162.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26799
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;81.233.202.162.in-addr.arpa.  IN  PTR

;; ANSWER SECTION:
81.233.202.162.in-addr.arpa. 7200 IN  CNAME  81.233.202.162.in-addr.arpa.

;; Query time: 34 msec
;; SERVER: 68.94.156.9#53(68.94.156.9)
;; WHEN: Wed Sep 30 11:28:42 CDT 2015
;; MSG SIZE  rcvd: 70

Why does dig return an answer with a CNAME?
Where did the CNAME come from?
For that matter, shouldn't a Canonical Name point to a FQDN (domain name)?

EDIT - 20151103: Actually it does. See https://forums.freebsd.org/threads/reverse-dns-not-resolving.53410/#post-302936 (this forum)

Also, the queried server is pointing to one of AT&T's name servers (68.94.156.9).

I just don't understand why rDNS will not resolve.

The zone files:

Code:

; /var/namedb/zonefiles/db.233.202.162.rev
$ORIGIN 81.233.202.162.in-addr.arpa.
$TTL 3h

@  IN  SOA  archaxis.net.  rtwingfield.archaxis.net. (
  2015093007  ; Serial
  3h  ; Refresh
  1h  ; Retry
  3w  ; Expire
  1h )  ; Negative cashing TTL

  IN  NS  ns1.archaxis.net.
  IN  NS  ns2.archaxis.net.
  IN  PTR  alpha.archaxis.net.

Code:

; /var/named/zonefiles/db.archaxis.net
$ORIGIN archaxis.net.
$TTL  3h
@  IN  SOA  archaxis.net.  rtwingfield.archaxis.net. (
  2015093006  ; Serial number
  3h  ; Refresh
  1h  ; Retry
  3w  ; Expire
  1h )  ; Negative caching TTL

; Name Server & Mail Server defination list:
  IN  NS  ns1.archaxis.net.
  IN  NS  ns2.archaxis.net.
  IN  MX  10 archaxis.net.
  IN  MX  20 alpha.archaxis.net.
  IN  MX  30 bravo.archaxis.net.
  IN  TXT  "v=spf1 a include:_spf.google.com ~all"

; Localhost defination:
localhost  IN  A  127.0.0.1

; Hosts in this zone:
@  IN  A  162.202.233.81 ; without '@', no A record generated! Why?
ns1  IN  A  162.202.233.81
ns2  IN  A  162.202.233.81 ; If bravo running DNS, point to 82.
alpha  IN  A  162.202.233.81
bravo  IN  A  162.202.233.82
www  IN  A  162.202.233.81
loghost  IN  A  162.202.233.81

da1 · Oct 1, 2015

One step at a time. First see if your dns server responds correctly to the rdns dig ( dig @your_dns_srv_ip_here -x 162.202.233.81).
Second, is the rdns delegated to you? ie: did your ISP confirm this?
Third, your rdns zone file looks interesting

Here is an example of how I would see your rdns file from my point of view (file name should be 233.202.162.in-addr.arpa):

Code:

$TTL 3h  ; 1 hour default TTL
@  IN  SOA  ns1.archaxis.net. rtwingfield.archaxis.net. (
2015093007  ; Serial
  3h  ; Refresh
  1h  ; Retry
  3w  ; Expire
  1h  ; Negative Reponse TTL
  )


NS ns1.archaxis.net.
NS ns2.archaxis.net.

81  PTR alpha.archaxis.net.

rtwingfield · Oct 1, 2015

Already late leaving for day trip. I will respond with details when I return this evening.

Thanks,
Ron W.

rtwingfield · Oct 16, 2015

Finally back from a two-week "southern tour" vacation through Vicksburg and Natches, MS, New Orleans, and Ft. Worth TX. (Picking up where I left off.)

When I try the syntax, (notice the ampersand)
# dig @162.202.233.81 -x 162.202.233.81

. . .the results is failure to resolve as follows:

Code:

# dig @162.202.233.81 -x 162.202.233.81

; <<>> DiG 9.10.2 <<>> @162.202.233.81 -x 162.202.233.81
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

. . .however with the ampersand omitted (Perhaps I'm misunderstanding this syntax?):

Code:

# dig 162.202.233.81 -x 162.202.233.81

; <<>> DiG 9.10.2 <<>> 162.202.233.81 -x 162.202.233.81
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51442
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;162.202.233.81.  IN  A

;; AUTHORITY SECTION:
.  10800  IN  SOA  a.root-servers.net. nstld.verisign-grs.com. 2015101600 1800 900 604800 86400

;; Query time: 33 msec
;; SERVER: 68.94.156.9#53(68.94.156.9)
;; WHEN: Fri Oct 16 11:53:54 CDT 2015
;; MSG SIZE  rcvd: 118

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16384
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;81.233.202.162.in-addr.arpa.  IN  PTR

;; ANSWER SECTION:
81.233.202.162.in-addr.arpa. 7200 IN  CNAME  81.233.202.162.in-addr.arpa.

;; Query time: 35 msec
;; SERVER: 68.94.156.9#53(68.94.156.9)
;; WHEN: Fri Oct 16 11:53:56 CDT 2015
;; MSG SIZE  rcvd: 70

. . .or simply

Code:

# dig  -x 162.202.233.81

; <<>> DiG 9.10.2 <<>> -x 162.202.233.81
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38776
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;81.233.202.162.in-addr.arpa.  IN  PTR

;; ANSWER SECTION:
81.233.202.162.in-addr.arpa. 7200 IN  CNAME  81.233.202.162.in-addr.arpa.

;; Query time: 34 msec
;; SERVER: 68.94.156.9#53(68.94.156.9)
;; WHEN: Fri Oct 16 11:56:07 CDT 2015
;; MSG SIZE  rcvd: 70

Second, is the rdns delegated to you? ie: did your ISP confirm this?

. . .as I mentioned in my original post 29-SEP-2015 (see above), AT&T "assures" me that they delegated our 29-block, and additionally that they had some errors on their side . . .now should be corrected.

file name should be 233.202.162.in-addr.arpa

. . .shouldn't matter how the file name is spelled, as long as it agrees with the file name as designated in the /var/named/named.conf file.

Notice the spelling in the $ORIGIN clause:

Code:

$ORIGIN     81.233.202.162.in-addr.arpa.

Code:

zone "81.233.202.162.in-addr.arpa" {
  type master;
  file "./zonefiles/db.233.202.162.rev";
};

. . .content of the /var/namedb/zonefiles/db.233.202.162.rev file:

Code:

; /var/namedb/zonefiles/db.233.202.162.rev
; currently configured as zone 81.233.202.162.in-addr.arpa in named.conf.

$ORIGIN 81.233.202.162.in-addr.arpa.
$TTL 3h

@  IN  SOA  archaxis.net.  rtwingfield.archaxis.net. (
  2015093007  ; Serial
  3h  ; Refresh
  1h  ; Retry
  3w  ; Expire
  1h )  ; Negative cashing TTL

  IN  NS  ns1.archaxis.net.
  IN  NS  ns2.archaxis.net.
  IN  PTR  alpha.archaxis.net.

You have suggested that the PTR record be specified as follows:

Code:

81 PTR alpha.archaxis.net.

. . .so I will tray that (not sure I understand why).
. . .and I did, but results are still the same as before.

rtwingfield · Nov 2, 2015

AT&T has assured that our 80/29 block is delegated to us; however, reverse DNS is still not resolving. To my knowledge, the classless network per RFC-2317 specified as follows (/var/namedb/zonefiles/db.233.202.162.rev) should work. Can anyone suggest why this would not be expected to work? . . .or is the problem still with AT&T's DNS server(s)?

Code:

$ORIGIN 80/29.233.202.162.in-addr.arpa.
$TTL 3h

@  IN  SOA  ns1.archaxis.net.  rtwingfield.archaxis.net. (
  2015110201  ; Serial
  1h  ; Refresh
  1h  ; Retry
  1h  ; Expire
  1h )  ; Negative cashing TTL

  3600  IN  NS  ns1.archaxis.net.
  3600  IN  NS  ns2.archaxis.net.
0  3600  IN  PTR  network.archaxis.net.
1  3600  IN  PTR  archaxis.net.
1  3600  IN  PTR  ns1.archaxis.net.
2  3600  IN  PTR  ns2.archaxis.net.
7  3600  IN  PTR  broadcast.archaxis.net.

usdmatt · Nov 2, 2015

Going down the tree, I eventually get the following response from ns2.swbell.net

Code:

;; ANSWER SECTION:
81.233.202.162.in-addr.arpa. 7200 IN    CNAME   81.80/29.233.202.162.in-addr.arpa.

;; AUTHORITY SECTION:
80/29.233.202.162.in-addr.arpa. 7200 IN NS      ns2.archaxis.net.
80/29.233.202.162.in-addr.arpa. 7200 IN NS      ns1.archaxis.net.

This seems to tie up with the RFC-2317 spec you mention in the previous post. DNS normally works by just delegating at each dot. Obviously they can't just delegate 233.202.162.in-addr.arpa to you as you don't own the entire /24. So they have created a 80/29.233.202.162.in-addr.arpa zone, and delegated that to you. They have added 2 NS records for this pointing at your nameservers as shown above. They have then added a CNAME for 81.233.202.162.in-addr.arpa, which points to a record under this new zone, which you control, 81.80/29.233.202.162.in-addr.arpa. I've never actually done DNS like this before but it seems pretty clever. Fortunately I have enough IP addresses that we just get nice simple /24 networks delegated to us.

So basically you just need a zone for 80/29.233.202.162.in-addr.arpa.
Inside that zone you should have a record for the 81 address (FQDN 81.80/29.233.202.162.in-addr.arpa).

Code:

$TTL 3h

@ IN SOA ns1.archaxis.net. rtwingfield.archaxis.net. (
  2015110201 ; Serial
  1h ; Refresh
  1h ; Retry
  1h ; Expire
  1h ) ; Negative cashing TTL

     3600 IN NS ns1.archaxis.net.
     3600 IN NS ns2.archaxis.net.
81 3600 IN PTR archaxis.net.

You don't really need the $ORIGIN statement. The origin is set to the zone name by default anyway. The only thing I don't understand is why you have 1,2,7,etc as the resource for the PTR records, when your IP addresses are 80-87.

usdmatt · Nov 2, 2015

Just to add, it seems like you have the zone working fine, just with the wrong addresses. I can look up 1.80/29.233.202.162.in-addr.arpa at your server:

Code:

1.80/29.233.202.162.in-addr.arpa. 3600 IN PTR   archaxis.net.
1.80/29.233.202.162.in-addr.arpa. 3600 IN PTR   ns1.archaxis.net.

(Well ns1 seems to respond at least)

The only thing I would say is that 2 PTR records for the same IP address doesn't make much sense. I think I'd just keep ns1.archaxis.net (assuming that's the hostname of 162.202.233.81).

rtwingfield · Nov 2, 2015

First, I understand that the "$ORIGIN" statement is superfluous . . .included mainly for documentation clarity.

usdmatt said:
You don't really need the $ORIGIN statement.

The nuance regarding the

Code:

0  3600  IN  PTR  network.archaxis.net.
1  3600  IN  PTR  archaxis.net.
1  3600  IN  PTR  ns1.archaxis.net.
2  3600  IN  PTR  ns2.archaxis.net.
7  3600  IN  PTR  broadcast.archaxis.net.

numerical notation is to point to the addresses in our 80/29 block (perhaps I really don't understand this . . .and have it wrong?) Regardless, to my understanding, 0 would point to 80, 1 to 81, 2 to 82, . . . 7 to 87. In other words, pointing to 0 through 7 octets in the block. (Somewhere, I have read that it is a good idea to define all addresses in the delegated block, particularly with regard to the network gateway and broadcast addresses. See the $GENERATE directive.) Simplified, your suggested code indicates that "81" should be used to point to the octet address of the host.

Also, ns1.archaxis.net is running on alpha.archaxis.net; ns2.archaxis.net actually isn't currently running on bravo.archaxis.net. (Two separate boxes, i.e., installations -- the named is only running on alpha.archaxis.net. No slave configured yet.)

Regarding

usdmatt said:
I think I'd just keep ns1.archaxis.net (assuming that's the hostname of 162.202.233.81)

perhaps I should ask how I should address the host name of alpha.archaxis.net? Archaxis.net is the registered FQDN for both server hosts. For example, I do receive eMail addressed to Ron.Wingfield@archaxis.net.

I have just reconfigured the zone as per your suggestion:

Code:

$TTL 3h

@ IN SOA ns1.archaxis.net. rtwingfield.archaxis.net. (
2015110201 ; Serial
1h ; Refresh
1h ; Retry
1h ; Expire
1h ) ; Negative cashing TTL

3600 IN NS ns1.archaxis.net.
3600 IN NS ns2.archaxis.net.
81 3600 IN PTR archaxis.net.

. . .tested, and it resolves!

Additionally, as an experiment, I added back and changed the code to

Code:

$ORIGIN 80/29.233.202.162.in-addr.arpa.
$TTL 3h

@  IN  SOA  ns1.archaxis.net.  rtwingfield.archaxis.net. (
  2015110210  ; Serial
  1h  ; Refresh
  1h  ; Retry
  1h  ; Expire
  1h )  ; Negative cashing TTL

  3600  IN  NS  ns1.archaxis.net.
  3600  IN  NS  ns2.archaxis.net.
80  3600  IN  PTR  network.archaxis.net.
81  3600  IN  PTR  alpha.archaxis.net.
82  3600  IN  PTR  bravo.archaxis.net.
87  3600  IN  PTR  broadcast.archaxis.net.

. . .and we're resolving both alpha and bravo hosts.

FYI, In/etc/rc.conf (on alpha), I have designated

Code:

hostname="alpha.archaxis.net"

. . .so apparently the PTR RR

Code:

81  3600  IN  PTR  alpha.archaxis.net.

should point to the 81st. octet, rather than simply "1" (i.e., my misunderstanding).

Also for clarity, the zonefile described in /var/named/named.conf is

Code:

zone "80/29.233.202.162.in-addr.arpa" {
  type master;
  file "[FILE]./zonefiles/db.233.202.162.rev[/FILE]";
};

(as you've suggested),

usdmatt said:
So basically you just need a zone for 80/29.233.202.162.in-addr.arpa.

I appreciate your help and suggestions. This has been a real challenge.

. . .and a final observation, this is the first time dig has returned a PTR to the host (in addition to the CNAME):

Code:

; <<>> DiG 9.10.2 <<>> -x 162.202.233.81
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22542
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;81.233.202.162.in-addr.arpa.  IN  PTR

;; ANSWER SECTION:
81.233.202.162.in-addr.arpa. 7200 IN  CNAME  81.80/29.233.202.162.in-addr.arpa.
81.80/29.233.202.162.in-addr.arpa. 3600 IN PTR  alpha.archaxis.net.

;; Query time: 870 msec
;; SERVER: 68.94.156.9#53(68.94.156.9)
;; WHEN: Mon Nov 02 15:48:38 CST 2015
;; MSG SIZE  rcvd: 111

usdmatt · Nov 2, 2015

Regardless, to my understanding, 0 would point to 80, 1 to 81, 2 to 82, . . . 7 to 87

I think you're over thinking/complicating how rDNS works. DNS records are just text strings. If your IP address is 162.202.233.81, you need a DNS PTR record for 81.233.202.162.in-addr.arpa. There is no clever processing done here to treat these as IP addresses, they are just strings.

In your case, because AT&T (or whoever) control 233.202.162.in-addr.arpa, they have created a sub domain, 80/29.233.202.162.in-addr.arpa, and delegated that to your DNS servers. They have then added a CNAME where you would normally have the PTR record (81.233.202.162.in-addr.arpa), pointing at a name under this new sub domain. Just try and think of these like normal domain names - just ones that contain a lot of numbers. 80/29 isn't defining some DNS CIDR network range, it's no different to you going out and registering "80/29.com", then having a DNS record for "81.80/29.com".

So when someone tries to look up the PTR for 81.233.202.162.in-addr.arpa, they get told "this is just an alias of 81.80/29.233.202.162.in-addr.arpa, so go look up the PTR on that instead".

Because they have pointed the CNAME at 81.80/29.233.202.162.in-addr.arpa, you just need a DNS record that exactly matches that.
So you need a zone for 80/29.233.202.162.in-addr.arpa., and a PTR record for 81.80/29.233.202.162.in-addr.arpa..

Somewhere, I have read that it is a good idea to define all addresses in the delegated block, particularly with regard to the network gateway and broadcast addresses

I would be interested in wherever you have read that. It makes no sense to me. I see no reason to create PTR records for IP addresses that are unused, including the network address or broadcast.

I can however see it being appropriate for AT&T, as in order to do their delegation correctly, they need to make sure they create a CNAME record for each of your IP addresses. You have 8 addresses, and they need to point the DNS to your server for each of them. So they should have 8 CNAME records in their server:

Code:

80.233.202.162.in-addr.arpa.    IN CNAME 80.80/29.233.202.162.in-addr.arpa.
... 81 through to 86 ...
87.233.202.162.in-addr.arpa.    IN CNAME 87.80/29.233.202.162.in-addr.arpa.

This is where the $GENERATE command would make perfect sense.
It doesn't matter if you actually have PTR records for all of them, or that having PTR for the network/broadcast address makes no sense (to me at least), the 8 addresses are allocated to you, and they should delegate the DNS to you for the entire block.

perhaps I should ask how I should address the host name of alpha.archaxis.net?

If the hostname is alpha.archaxis.net, I would have the PTR the same, as you already have. ns1.archaxis.net can just be an A record in your archaxis.net. zone to the appropriate IP.

usdmatt · Nov 2, 2015

Interestingly enough, the first reference to $GENERATE on the net is an online book showing the following:

Code:

$ORIGIN 199.168.192.IN-ADDR.ARPA.
...
65 IN CNAME 65.64/26
66 IN CNAME 66.64/26
67 IN CNAME 67.64/26
...
125 IN CNAME 125.64/26
126 IN CNAME 126.64/26

Code:

$GENERATE 65-126 $ CNAME $.64/26

Firstly they are actually using these RFC-2317 style records in the example.
However the more intriguing thing is that this example doesn't bother creating entries for the network & broadcast addresses - 64 & 127.

rtwingfield · Nov 2, 2015

usdmatt said:
I would be interested in wherever you have read that. It makes no sense to me. I see no reason to create PTR records for IP addresses that are unused, including the network address or broadcast.

In the discussion of Traditional Delegation in this web article, http://www.gettingemaildelivered.com/how-to-set-up-reverse-dns-rdns, I got the idea of filling-in "place holders". Note that further reading of the article suggests that it's not a good idea to use $GENERATE with unused IP-V6 addresses.

Now it should be easier to add a specific name to the unused parts of our network. In this case, let’s use name `unused.mydomain.example` for those areas that we’re not actively using at the moment. We can do this by updating the serial and adding this macro:

$GENERATE 30-254 $ 3600 IN PTR unused.mydomain.example.

Note however that each resource record will have an impact in the memory utilization of your DNS servers. For this reason, you likely do not want to attempt this on IPv6 delegation. Adding entries for the unused IP addresses in a `/64` block will likely exhaust all available memory in most name servers.

Regarding the CNAME's that AT&T apparently generated, I'm still not clear why they show up as a CNAME in what appears to me to be a dotted octet address, rather than a canonical name, e.g., a FQDN. I suppose they are analogous to a canonical name composed of dotted numeric strings followed by *.in-addr.arpa?

usdmatt · Nov 2, 2015

I'm still not clear why they show up as a CNAME in what appears to me to be a dotted octet address, rather than a conical name, e.g., a FQDN. I suppose they are analogous to a conical name composed of dotted numeric strings followed by *.in-addr.arpa?

Yes it is a FQDN, just one that looks like an IP address.

They could of just of easily done the following

Code:

81.233.202.162.in-addr.arpa. IN CNAME 81.archaxis.233.202.162.in.addr.arpa.
archaxis.233.202.162.in.addr.arpa. IN NS ns1.archaxis.net

Hell they could of even done this

Code:

81.233.202.162.in-addr.arpa. IN CNAME 81.rdns.archaxis.net.

Then you could of created a PTR record for 81.rdns.archaxis.net under your normal domain.

The reason they used 80/29.233.202.162.in-addr.arpa is because it delegates a sub domain to you that makes the most sense.
Not only does it fit under the original 233.202.162.in-addr.arpa zone, but it also neatly references the range that is allocated to you.

rtwingfield · Nov 3, 2015

Yeah,

usdmatt said:
The reason they used 80/29.233.202.162.in-addr.arpa is because it delegates a sub domain to you that makes the most sense.

. . .that's my understanding of RFC-2317 (http://dloads.infoblox.com/direct/kb_attach/1441_RFC2317_FAQ.pdf). I feel like I'm learning way more than I ever wanted to know about this esoteric nuance . . .like joining a very small fraternity

Here is yet another "read" on the subject: https://www.ietf.org/rfc/rfc2317.txt

Also, I think a lot of difficulty has been "getting on the same page" with AT&T . . .just the "spelling" of the names, etc.

usdmatt · Nov 3, 2015

Part of your original problem would of been this from post #4

Code:

;; ANSWER SECTION:
81.233.202.162.in-addr.arpa. 7200 IN CNAME 81.233.202.162.in-addr.arpa.

At that point it looks like they'd messed up the DNS records and CNAME'd 81.233.202.162.in-addr.arpa. to itself. There's no way it would of worked until their CNAME looked like it does now.

Code:

81.233.202.162.in-addr.arpa. IN CNAME 81.80/29.233.202.162.in-addr.arpa.

rtwingfield · Nov 3, 2015

Just a little follow-up venting :beer:

This is the type of discussions I've had with Tier-2 AT&T DNS Provisioning:

9/25/2015 9:39 PM . . .regarding confirmation of delegation of our /29 block:

We have the IP block delegated to your requested servers. That takes all DNS lookups out of our hands and on your listed servers. I do see that there is nothing resolving on a lookup. We do not provide support for name server configuration and issues involved.

Well good, our Apache hosts are finally serving, but rDNS is screwed.

10/22/2015 12:08 PM -- Results of my dig test (this is about a month later; I'm still assuming that I'm to blame and that I've created a configuration error somewhere):

Code:

; <<>> DiG 9.10.2 <<>> -x 162.202.233.81
~
;; ANSWER SECTION:
81.233.202.162.in-addr.arpa. 7200 IN  CNAME  81.233.202.162.in-addr.arpa.

Notice that the CNAME "points" back to its self (I didn't notice or otherwise understand the significance of this.); regardless, rDNS still not successful. More calls to AT&T Tier-2.

10/23/2015 3:01 PM

Mr. [not-named] suggested that I provide info such as our FQDN, and our classless IN-ADDR.ARPA delegation. Well, the suggested information is all included in the following information that I sent yesterday . . .if you'd just read it.

I need rDNS to work for our 80/29.233.202.162.in-addr.arpa. IP block. It's just that simple! I have struggled with this since the first of August and DNS-aware mailers are still rejecting eMail from our server.

What do we have to do to coordinate with your (I assume) implementation (e.g., syntax, etc.) of RFC-2317.

10/23/2015 8:59 PM

We had the admins verify the delegation once more, they said they made a minor tweak and asked you try it again.

. . .notice still no suggestion regarding what they actually did -- still not working; yet another call back to T-2.

10/24/2015 8:13 PM, Prior to AT&T's "adjustments and tweaks", I received the following eMail msg. from Tier-2 AT&T DNS Provisioning:

Ron, . . .the Admins have made another adjustment to the delegation, please check again.

OK . . .did so the next day (allowed plenty of time for zone transfers to propagate throughout the ether) but still having problems; however, their last "adjustment" to the CNAME syntax was probably correct at that point (but I can't see the forest for the trees). I leave for two weeks out of the office (vacation). After returning (plus another week) at this point, help from USDMATT (this forum) resolves the problem. Thanks, thanks again!

Finally in fairness to the AT&T T-2 techs, most are truly courteous and listen well and are willing to help, albeit difficult to contact (I'd suggest using the speaker phone while on hold) before I seemed to establish a "first name" relationship with a few guys (call 'em enough times and it gets that way) . . .and was given a direct phone number to T-2. There were a few who seemed to think that we should not be operating our own private DNS, SMTP, HTTP servers, and defer to their services. Ultimately, I think that they are "too big" to be bothered with little RFC-2317 classless networks like our /29 block and most of their people don't know how to deal with the same.