Re: Anyone from AT&T DNS?

[Christopher Morrow <morrowc.lists () gmail com>]

On Wed, Oct 4, 2017 at 11:03 PM, Matt Peterman <mpeterman () 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.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...