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! Matt
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...
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. 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) 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… 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...
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...
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...
On Wed, Oct 4, 2017 at 11:07 PM, Matt Peterman <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… Guess I need to do more digging.
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. 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!) :)
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...
Got it! You’re 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.” It changes it to "128\05725.168.207.107.in-addr.arpa.” every time… *sigh* If it isn't one thing its something else.
On Oct 4, 2017, at 11:11 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
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… Guess I need to do more digging.
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.
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!) :)
Matt
On Oct 4, 2017, at 10:53 PM, Christopher Morrow <morrowc.lists@gmail.com <mailto: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...
On Wed, Oct 4, 2017 at 11:18 PM, Matt Peterman <mpeterman@apple.com> wrote:
Got it! You’re 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.” It changes it to "128\05725.168.207.107.in-addr.arpa.” every time… *sigh* If it isn't one thing its something else.
I've not messed with route53 but fortunately you are treading on well trodden ground: https://forums.aws.amazon.com/thread.jspa?messageID=674778 have a happy evening! (and I hope that the above works.. again I haven't and can't actually try it)
I can now confirm that Christopher is right about everything (not that I had any doubts! Just wanted to confirm all is working!!) ATT is now following the RFC (apparently has changed since November 2016 and June 2017 allocations and DNS changes) and that Route53 WebUI displays things strangely, however technically works fine on the backend. rDNS is now working properly. Thank you Christopher very much! I learned a lot in the last hour I can sure say that! Matt
On Oct 4, 2017, at 11:20 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Oct 4, 2017 at 11:18 PM, Matt Peterman <mpeterman@apple.com <mailto:mpeterman@apple.com>> wrote: Got it! You’re 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.” It changes it to "128\05725.168.207.107.in-addr.arpa.” every time… *sigh* If it isn't one thing its something else.
I've not messed with route53 but fortunately you are treading on well trodden ground: https://forums.aws.amazon.com/thread.jspa?messageID=674778 <https://forums.aws.amazon.com/thread.jspa?messageID=674778>
have a happy evening! (and I hope that the above works.. again I haven't and can't actually try it)
Yep, the notation with the slash used to be ATT's standard method. At my job (where we had some customers with ATT MIS T1 circuits) we transitioned to a web front end for our DNS that didn't allow for the slash, so we had to nudge ATT to allow us to use a dash notation instead for delegations. As far as to what can appear in a DNS entry, you'd be amazed. I encountered a PTR record containing a full URL, http:// and everything; it didn't actually work of course, but bind allowed it to exist. When I tracked down the cow-orker who had entered it, he said he knew it wasn't valid, but he did it that way when the customer insisted it had to be thus. :-D On Wed, Oct 4, 2017 at 11:33 PM, Matt Peterman <mpeterman@apple.com> wrote:
I can now confirm that Christopher is right about everything (not that I had any doubts! Just wanted to confirm all is working!!)
ATT is now following the RFC (apparently has changed since November 2016 and June 2017 allocations and DNS changes) and that Route53 WebUI displays things strangely, however technically works fine on the backend. rDNS is now working properly. Thank you Christopher very much! I learned a lot in the last hour I can sure say that!
Matt
On Oct 4, 2017, at 11:20 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Oct 4, 2017 at 11:18 PM, Matt Peterman <mpeterman@apple.com <mailto:mpeterman@apple.com>> wrote: Got it! You’re 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.” It changes it to "128\05725.168.207.107.in-addr.arpa.” every time… *sigh* If it isn't one thing its something else.
I've not messed with route53 but fortunately you are treading on well trodden ground: https://forums.aws.amazon.com/thread.jspa?messageID=674778 < https://forums.aws.amazon.com/thread.jspa?messageID=674778>
have a happy evening! (and I hope that the above works.. again I haven't and can't actually try it)
In message <CAN414UfOQH-rOsJ4V_idiv-2UQi0jVM=w5AOs6HmnA-NkDvESg@mail.gmail.com>, Jay Farrell via NANOG writes:
Yep, the notation with the slash used to be ATT's standard method. At my job (where we had some customers with ATT MIS T1 circuits) we transitioned to a web front end for our DNS that didn't allow for the slash, so we had to nudge ATT to allow us to use a dash notation instead for delegations.
As far as to what can appear in a DNS entry, you'd be amazed. I encountered a PTR record containing a full URL, http:// and everything; it didn't actually work of course, but bind allowed it to exist. When I tracked down the cow-orker who had entered it, he said he knew it wasn't valid, but he did it that way when the customer insisted it had to be thus. :-D
DNS labels can be octet string [0..63] with the zero length octet string being being reserved or the root label and '*' for the wildcard label (there is no way to turn this off). Hostnames on the other hand are restricted to LDH. Unfortunately many tools are not written by people who understand the difference. Additionally lots of administrators also don't know the difference. They also often don't understand why hostnames are restricted to LDH. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
In message <50298399-672D-4BA1-A726-7128B84B89FF@apple.com>, Matt Peterman writes:
Got it! You’re 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.” It changes it to "128\05725.168.207.107.in-addr.arpa.” every time… *sigh* If it isn't one thing its something else.
Which is "128925.168.207.107.in-addr.arpa." when fed into a domain name parser. DNS escapes sequences are DECIMAL not OCTAL. I suggest that you log a bug report. 128/25.168.207.107.in-addr.arpa. == 128\04725.168.207.107.in-addr.arpa RFC 1035 \DDD where each D is a digit is the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning. That said '/' is not special to DNS parsers and shouldn't need to be converted to \DDD. Mark % dig '128\05725.168.207.107.in-addr.arpa' ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0a1+hotspot+add-prefetch+marka <<>> 128\05725.168.207.107.in-addr.arpa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8078 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: ac2bc18c4e18f907a872f2b559dacb6ab6e64fb72a9c71d5 (good) ;; QUESTION SECTION: ;128925.168.207.107.in-addr.arpa. IN A ;; AUTHORITY SECTION: 168.207.107.in-addr.arpa. 3600 IN SOA ns1.swbell.net. rm-hostmaster.ems.att.com. 2 10800 900 604800 7200 ;; Query time: 1244 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Oct 09 12:05:46 AEDT 2017 ;; MSG SIZE rcvd: 163 % % dig '128\04725.168.207.107.in-addr.arpa' ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0a1+hotspot+add-prefetch+marka <<>> 128\04725.168.207.107.in-addr.arpa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54452 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: e6bdbbdf26697275cf492e9059dacbecc9eb8186d940bd69 (good) ;; QUESTION SECTION: ;128/25.168.207.107.in-addr.arpa. IN A ;; AUTHORITY SECTION: 128/25.168.207.107.in-addr.arpa. 900 IN SOA ns-1746.awsdns-26.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 ;; Query time: 1142 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Oct 09 12:07:56 AEDT 2017 ;; MSG SIZE rcvd: 175 % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
participants (4)
-
Christopher Morrow -
Jay Farrell -
Mark Andrews -
Matt Peterman