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 > On Oct 4, 2017, at 10:53 PM, Christopher Morrow <morrowc.li...@gmail.com> > wrote: > > > > On Wed, Oct 4, 2017 at 10:43 PM, Matt Peterman <mpeter...@apple.com > <mailto:mpeter...@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 > <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 <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 <http://foo.you.com/>. > 129 IN PTR bar.you.com <http://bar.you.com/>. > > etc... > >
