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.lists@gmail.com> wrote:
On Wed, Oct 4, 2017 at 10:43 PM, Matt Peterman <mpeterman@apple.com <mailto: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 <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...