[196143] in North American Network Operators' Group
Re: Anyone from AT&T DNS?
daemon@ATHENA.MIT.EDU (Matt Peterman)
Fri Oct 6 06:57:54 2017
X-Original-To: nanog@nanog.org
From: Matt Peterman <mpeterman@apple.com>
Date: Wed, 04 Oct 2017 23:18:25 -0400
In-reply-to: <CAL9jLabZaCZfvy0XJnGjA=ZurEt9=OhrkwHomhoZOs2JtRWwOg@mail.gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
Cc: nanog list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Got it! You=E2=80=99re the winner here. I just setup both of my zones =
the name way and obviously AT&T changed the way they did RDNS entries =
from when I got a /25 last November and this second /25 in June. Oh =
well!
Now I am running into the challenge of Route53 does seem to support =
creating an authoritative zone for "128/25.168.207.107.in-addr.arpa.=E2=80=
=9D It changes it to "128\05725.168.207.107.in-addr.arpa.=E2=80=9D every =
time=E2=80=A6 *sigh* If it isn't one thing its something else.=20
> On Oct 4, 2017, at 11:11 PM, Christopher Morrow =
<morrowc.lists@gmail.com> wrote:
>=20
>=20
>=20
> On Wed, Oct 4, 2017 at 11:07 PM, Matt Peterman <mpeterman@apple.com =
<mailto: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=E2=80=A6 Guess I need to do more =
digging.=20
>=20
>=20
> 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.
>=20
> 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!) :)
> =20
> Matt
>=20
>=20
>=20
>> On Oct 4, 2017, at 10:53 PM, Christopher Morrow =
<morrowc.lists@gmail.com <mailto:morrowc.lists@gmail.com>> wrote:
>>=20
>>=20
>>=20
>> 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.
>>=20
>> Which is obviously a completely invalid DNS entry. I have opened a =
ticket through the web portal for =E2=80=9Cprov-dns=E2=80=9D but =
Haven=E2=80=99t gotten a response for 7 days.
>>=20
>> If anyone from AT&T DNS or knows anyone from AT&T DNS that can help =
it would be appreciated!
>>=20
>>=20
>> isn't this one of the proper forms of reverse delegation in CIDR =
land?=20
>>=20
>> like:
>> =
http://support.simpledns.com/kb/a146/how-to-sub-delegate-a-reverse-zone.as=
px =
<http://support.simpledns.com/kb/a146/how-to-sub-delegate-a-reverse-zone.a=
spx>
>>=20
>> describes, or in a (perhaps more wordy fashion) in RFC2317?
>> http://tools.ietf.org/html/rfc2317 =
<http://tools.ietf.org/html/rfc2317>
>>=20
>> 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:
>>=20
>>=20
>> 128/25.168.207.107.in-addr.arpa.
>>=20
>> and have a bunch of PTR records like:
>>=20
>> 128 IN PTR foo.you.com <http://foo.you.com/>.
>> 129 IN PTR bar.you.com <http://bar.you.com/>.
>>=20
>> etc...
>>=20
>>=20
>=20
>=20
