On Wed, Oct 4, 2017 at 11:03 PM, Matt Peterman <mpeter...@apple.com> wrote:
> 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. > 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> > 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... > > > >