The PTR record CNAMEs for my /25 allocated prefix are all messed up. They are returning as
$ dig +short CNAME 128.168.207.107.in-addr.arpa
128.128/25.168.207.107.in-addr.arpa.
Which is obviously a completely invalid DNS entry. I have opened a ticket through the web portal for “prov-dns” but Haven’t gotten a response for 7 days.
If anyone from AT&T DNS or knows anyone from AT&T DNS that can help it would be appreciated!
Matt
isn't this one of the proper forms of reverse delegation in CIDR land?
like:
http://support.simpledns.com/kb/a146/how-to-sub-delegate-a-reverse-zone.aspx
describes, or in a (perhaps more wordy fashion) in RFC2317?
http://tools.ietf.org/html/rfc2317
I think it may be the case that the NS hosts are not prepared for such a
domain/record mapping though... the nameservers that would need to to be
authoritative for a zone like:
128/25.168.207.107.in-addr.arpa.
and have a bunch of PTR records like:
128 IN PTR foo.you.com.
129 IN PTR bar.you.com.
etc...
The correct format is as shown below (this is from another /25 I have from AT&T that has DNS setup correctly)
$ dig +short CNAME 1.120.232.108.in-addr.arpa
1.0.120.232.108.in-addr.arpa.
So for the block I am having an issue with the CNAME records should be
For 107.207.168.128 should be 128.128.168.207.107.in-addr.arpa (it shouldn't have “/25” in the middle of it - you can’t even have “/“ in a DNS entry AFAIK)
If I do another address from my block I get $ dig +short CNAME 191.168.207.107.in-addr.arpa
191.128/25.168.207.107.in-addr.arpa.
Again that would should be 191.128.168.207.107in-addr.arpa.
Somehow AT&T DNS got the “/25” prefix length in all of the DNS entries…
Matt
You are correct through that that link does show having the CIDR prefix length in the CNAME which is weird because AT&T did not do this on my other /25 block. Interesting… Guess I need to do more digging.
Matt
The correct format is as shown below (this is from another /25 I have from
AT&T that has DNS setup correctly)$ dig +short CNAME 1.120.232.108.in-addr.arpa
1.0.120.232.108.in-addr.arpa.
there are more than 1 way to skin the cat, sadly.
This tripped me up on a customer connection for a while as well, the RFC
example I provided earlier is also valid.
So for the block I am having an issue with the CNAME records should be
For 107.207.168.128 should be 128.128.168.207.107.in-addr.arpa (it
shouldn't have “/25” in the middle of it - you can’t even have “/“ in a DNS
entry AFAIK)
according to the rfc you can.
If I do another address from my block I get $ dig +short CNAME
191.168.207.107.in-addr.arpa
191.128/25.168.207.107.in-addr.arpa.Again that would should be 191.128.168.207.107in-addr.arpa.
Somehow AT&T DNS got the “/25” prefix length in all of the DNS entries…
nope, they are just following the rfc provided path for this.
yes it looks screwy, yes it also works fine.
You are correct through that that link does show having the CIDR prefix
length in the CNAME which is weird because AT&T did not do this on my other
/25 block. Interesting… Guess I need to do more digging.
if I had to guess I'd say that 'sometime long ago' they did one way, then
decided to just follow the RFC ... which probably also makes their
provisioning automation much simpler.
as I said, there are more than 1 way to skin the cat 
sadly you (and I,
at least) were used to the 'old fashioned method' welcome to 1998
(apparently!) 
Got it! You’re the winner here. I just setup both of my zones the name way and obviously AT&T changed the way they did RDNS entries from when I got a /25 last November and this second /25 in June. Oh well!
Now I am running into the challenge of Route53 does seem to support creating an authoritative zone for "128/25.168.207.107.in-addr.arpa.” It changes it to "128\05725.168.207.107.in-addr.arpa.” every time… *sigh* If it isn't one thing its something else.
I've not messed with route53 but fortunately you are treading on well
trodden ground:
https://forums.aws.amazon.com/thread.jspa?messageID=674778
have a happy evening! (and I hope that the above works.. again I haven't
and can't actually try it)
I can now confirm that Christopher is right about everything (not that I had any doubts! Just wanted to confirm all is working!!)
ATT is now following the RFC (apparently has changed since November 2016 and June 2017 allocations and DNS changes) and that Route53 WebUI displays things strangely, however technically works fine on the backend. rDNS is now working properly. Thank you Christopher very much! I learned a lot in the last hour I can sure say that!
Matt
Yep, the notation with the slash used to be ATT's standard method. At my
job (where we had some customers with ATT MIS T1 circuits) we transitioned
to a web front end for our DNS that didn't allow for the slash, so we had
to nudge ATT to allow us to use a dash notation instead for delegations.
As far as to what can appear in a DNS entry, you'd be amazed. I encountered
a PTR record containing a full URL, http:// and everything; it didn't
actually work of course, but bind allowed it to exist. When I tracked down
the cow-orker who had entered it, he said he knew it wasn't valid, but he
did it that way when the customer insisted it had to be thus. 
Which is "128925.168.207.107.in-addr.arpa." when fed into a domain
name parser. DNS escapes sequences are DECIMAL not OCTAL. I suggest
that you log a bug report.
128/25.168.207.107.in-addr.arpa. == 128\04725.168.207.107.in-addr.arpa
RFC 1035
\DDD where each D is a digit is the octet corresponding to
the decimal number described by DDD. The resulting
octet is assumed to be text and is not checked for
special meaning.
That said '/' is not special to DNS parsers and shouldn't need to be
converted to \DDD.
Mark
% dig '128\05725.168.207.107.in-addr.arpa'
;; BADCOOKIE, retrying.
; <<>> DiG 9.12.0a1+hotspot+add-prefetch+marka <<>> 128\05725.168.207.107.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8078
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ac2bc18c4e18f907a872f2b559dacb6ab6e64fb72a9c71d5 (good)
;; QUESTION SECTION:
;128925.168.207.107.in-addr.arpa. IN A
;; AUTHORITY SECTION:
168.207.107.in-addr.arpa. 3600 IN SOA ns1.swbell.net. rm-hostmaster.ems.att.com. 2 10800 900 604800 7200
;; Query time: 1244 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 09 12:05:46 AEDT 2017
;; MSG SIZE rcvd: 163
%
% dig '128\04725.168.207.107.in-addr.arpa'
;; BADCOOKIE, retrying.
; <<>> DiG 9.12.0a1+hotspot+add-prefetch+marka <<>> 128\04725.168.207.107.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54452
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: e6bdbbdf26697275cf492e9059dacbecc9eb8186d940bd69 (good)
;; QUESTION SECTION:
;128/25.168.207.107.in-addr.arpa. IN A
;; AUTHORITY SECTION:
128/25.168.207.107.in-addr.arpa. 900 IN SOA ns-1746.awsdns-26.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
;; Query time: 1142 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 09 12:07:56 AEDT 2017
;; MSG SIZE rcvd: 175
%
DNS labels can be octet string [0..63] with the zero length octet
string being being reserved or the root label and '*' for the
wildcard label (there is no way to turn this off).
Hostnames on the other hand are restricted to LDH.
Unfortunately many tools are not written by people who understand
the difference. Additionally lots of administrators also don't
know the difference. They also often don't understand why hostnames
are restricted to LDH.
Mark