Need help explaining in-addr.arpa to Limelight

Hi,

  I seem to be having a problem. Limelight has SWIP'd
69.28.185.0/24 to me, and I asked for IN-ADDR.ARPA control.
I recently went to check and it seemed not to be working
right. I sent them an email around 11p Eastern Sunday nite
asking it to be fixed. I even included a reference to a
web page on how to delegate in-addr.arpa. I received the
following back :

"This is done, but you will need to rename the zone on your
end to: tboh.185.28.69.in-addr.arpa."

  Is there someone out there that might be able
to help me explain this to the techs there. That you
can't "subdomain" an in-addr.arpa like you do a domain
name?

    Thanks, Tuc/TBOH

Tuc!

Tuc at T-B-O-H.NET wrote:

Hi,

  I seem to be having a problem. Limelight has SWIP'd
69.28.185.0/24 to me, and I asked for IN-ADDR.ARPA control.
I recently went to check and it seemed not to be working
right. I sent them an email around 11p Eastern Sunday nite
asking it to be fixed. I even included a reference to a
web page on how to delegate in-addr.arpa. I received the
following back :

"This is done, but you will need to rename the zone on your
end to: tboh.185.28.69.in-addr.arpa."

In case they do a:
1.185.28.69.in-addr.arpa. CNAME 1.tboh.185.28.69.in-addr.arpa.

That would partially make sense, though it still wouldn't as you don't
have control over tboh.x.x.x... unless they delegate that to you, but
that wouldn't make sense either as they can just NS the 185 also already...

  Is there someone out there that might be able
to help me explain this to the techs there. That you
can't "subdomain" an in-addr.arpa like you do a domain
name?

Why not? Reverse DNS is just another domain, you can also stick MX
records in there or have a nice website if you want :wink:

tuc@tboh.185.28.69.in-addr.arpa can work quite well as an email address
if you stick the MX's in the right spot. Not very useful but still.
Quite a number of operators stick stuff like TXT records in there too to
describe topology and other informational elements related to that
domain. There are even some anti-spam proposals doing that afaik.

That is though probably not what you want to accomplish though.

According to dig the domain is currently pointing to zoneedit:

;; ANSWER SECTION:
185.28.69.in-addr.arpa. 7200 IN NS ns13.zoneedit.com.
185.28.69.in-addr.arpa. 7200 IN NS ns8.zoneedit.com.

You'll have to insert your cruft there or have them repoint it to a dns
server under your control.

And remember kids, don't spam the dns; there is a better use for IP
addresses by for instance hungry children with hand-winded laptops.

Greets,
Jeroen

No, because in fact you can. There is nothing magic about an
in-addr.arpa domain.

I'd say there is some magic. Possibly.

If an admin were granted the authority for a /25 worth of space, then you can't just delegate that part of the in-addr.arpa domain. That's the RFC Joe Abley cited.

A /24 can be delegated (assuming we are talking about 255 addresses, from .0 to .255). Perhaps, and this is weak speculation, the ISP in question is not used to SWIPing /24 and has an institutional policy of using RFC 2317 in all cases.

As far as the DNS protocol goes, there's nothing different between the forward and reverse. But there are differences in the conventions used for placing data.

Ah, so you smell an apex CNAME. They might be using DNAME, though :slight_smile:

Joe

>No, because in fact you can. There is nothing magic about an
>in-addr.arpa domain.

I'd say there is some magic. Possibly.

There are conventions. There is RFC 2317. There is no magic. :wink:

You can have subdomains neustar.16.154.156.in-addr.arpa and
lewis.0.127.in-addr.arpa. You can have a pointer at
456.24.154.156.in-addr.arpa, much good it will do you.

The "magic" in reverse DNS is keeping it aligned properly with forward
DNS according to all the conventions we've established, including RFC
2317 - which, OBTW, explicitly allows for non-standard subdomains used
in reverse DNS. How about 158.16.neustar.com? :wink:

If an admin were granted the authority for a /25 worth of space, then
you can't just delegate that part of the in-addr.arpa domain. That's
the RFC Joe Abley cited.

A /24 can be delegated (assuming we are talking about 255 addresses,
from .0 to .255). Perhaps, and this is weak speculation, the ISP in
question is not used to SWIPing /24 and has an institutional policy
of using RFC 2317 in all cases.

I've noticed of late less understanding of DNS in the people charged
with maintaining it out there. Sad.

As far as the DNS protocol goes, there's nothing different between
the forward and reverse. But there are differences in the
conventions used for placing data.

Yup. :wink:

Hi all,

  (And especially to those emailing privately, Joe Abley
and Adam Rothschild... I never disappeared... :wink: )

  Yes, I've misspoke. Bad on me #1. You can subdomain
IN-ADDR.ARPA. I understand that if you do more than just simply
put NS records in, it can be done.

  The issue still stands though, that according to my
latest dig +trace of it, I see :

185.28.69.in-addr.arpa. 86400 IN NS dns.iad.llns.net.
185.28.69.in-addr.arpa. 86400 IN NS dns.lax.llns.net.
185.28.69.in-addr.arpa. 86400 IN NS dns.lga.llns.net.
185.28.69.in-addr.arpa. 86400 IN NS dns.sjc.llns.net.
;; Received 138 bytes from 192.35.51.32#53(dill.ARIN.NET) in 2880 ms

185.28.69.in-addr.arpa. 7200 IN SOA ns8.zoneedit.com. soacontact.zoneedit.com. 1115928761 14400 7200 950400 7200
;; Received 105 bytes from 69.28.156.99#53(dns.iad.llns.net) in 970 ms

  Which still is wrong I believe. If nothing else, it
should point to the ns13 and ns8 servers at zoneedit.com .

  Jeroen said he saw :

;; ANSWER SECTION:
185.28.69.in-addr.arpa. 7200 IN NS ns13.zoneedit.com.
185.28.69.in-addr.arpa. 7200 IN NS ns8.zoneedit.com.

  from a dig, but I'm not sure how. And yes, I'm using zoneedit
for diversity for this reverse.

  As for my bad #2, I incorrectly used SWIP. I guess I should
have said that if you do :

whois -h rwhois.llnw.net -p 4321 69.28.185.1

  It shows up as that I am the contact for that.

  Howerver, it still remains that after telling them twice
EXACTLY what to do, it seems like they are still wrong. I
would think I'd need to see something like what WCG did for
me for another subnet :

164.193.64.in-addr.arpa. 86400 IN NS ns8.zoneedit.com.
164.193.64.in-addr.arpa. 86400 IN NS ns13.zoneedit.com.
;; Received 126 bytes from 64.200.255.12#53(tuldns1.wcg.net) in 1030 ms

  Am I still wrong, or are they?

      Thanks, Tuc

Sad? I don't think so, it's natural and a sign of the technology's promise. As the work load grows, the percentage of the workers who are pioneers will fall.

If a system requires "pioneer" experience and knowledge to operate correctly there is more work to be done by the pioneers.

I'm not asking them to know how to put together a Conestoga wagon and
feed and maintain oxen. I'm asking them to know that when you see a
stop sign you stop, and when you come to a right turn, you turn into the
right-hand lane if it's safe and not "no right turn on red".

Then again, they don't know that, either.

A person who does RFC 2317 delegation should know how to communicate
that.

...

  The issue still stands though, that according to my
latest dig +trace of it, I see :

185.28.69.in-addr.arpa. 86400 IN NS dns.iad.llns.net.
185.28.69.in-addr.arpa. 86400 IN NS dns.lax.llns.net.
185.28.69.in-addr.arpa. 86400 IN NS dns.lga.llns.net.
185.28.69.in-addr.arpa. 86400 IN NS dns.sjc.llns.net.
;; Received 138 bytes from 192.35.51.32#53(dill.ARIN.NET) in 2880 ms

185.28.69.in-addr.arpa. 7200 IN SOA ns8.zoneedit.com. soacontact.zoneedit.com. 1115928761 14400 7200 950400 7200
;; Received 105 bytes from 69.28.156.99#53(dns.iad.llns.net) in 970 ms

  Which still is wrong I believe. If nothing else, it
should point to the ns13 and ns8 servers at zoneedit.com .

...

What they APPEAR to be doing is delegating, individually, each element
of 0.185.28.69.in-addr.arpa - 255.185.28.69.in-addr.arpa to
ns8.zoneedit.com and ns13.zoneedit.com. Try these:

dig ns 185.28.69.in-addr.arpa
dig any 1.185.28.69.in-addr.arpa @dns.lax.llns.net
dig any 0.185.28.69.in-addr.arpa @dns.lax.llns.net
dig any 255.185.28.69.in-addr.arpa @dns.lax.llns.net
dig any 256.185.28.69.in-addr.arpa @dns.lax.llns.net

Anything 0-255 returns the delegated name servers. I only tried 256
outside that range, but it returns an SOA as authority rather than the
delegated name servers.

dig ptr 1.185.28.69.in-addr.arpa
  -> gw.house.tucs-beachin-obx-house.com.

This is not how you or I would do it. But add a few more PTR records
and see how well it works.