On Wed, Oct 4, 2017 at 11:07 PM, Matt Peterman <mpeterman@apple.com> wrote:
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!) :)
Matt
On Oct 4, 2017, at 10:53 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Oct 4, 2017 at 10:43 PM, Matt Peterman <mpeterman@apple.com> wrote:
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!
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...