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! On 23-Oct-2006, at 18:03, Tuc at T-B-O-H.NET wrote:
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?
RFC 2317. A zone's a zone's a zone, and zones can contain CNAMEs. Joe
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 ;) 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
Hi all, (And especially to those emailing privately, Joe Abley and Adam Rothschild... I never disappeared... ;) ) 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
On Tue, Oct 24, 2006 at 09:40:24AM -0400, Tuc at T-B-O-H.NET wrote: ...
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. -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
On Mon, Oct 23, 2006 at 06:03:22PM -0400, 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."
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
No, because in fact you can. There is nothing magic about an in-addr.arpa domain. -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
At 18:48 -0400 10/23/06, Joseph S D Yao wrote:
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. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch.
On 23-Oct-2006, at 21:13, Edward Lewis wrote:
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.
Ah, so you smell an apex CNAME. They might be using DNAME, though :-) Joe
On Mon, Oct 23, 2006 at 09:13:03PM -0400, Edward Lewis wrote:
At 18:48 -0400 10/23/06, Joseph S D Yao wrote:
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. ;-) 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? ;-)
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. ;-) -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
At 22:43 -0400 10/23/06, Joseph S D Yao wrote:
I've noticed of late less understanding of DNS in the people charged with maintaining it out there. Sad.
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. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch.
On Tue, Oct 24, 2006 at 11:26:08AM -0400, Edward Lewis wrote:
At 22:43 -0400 10/23/06, Joseph S D Yao wrote:
I've noticed of late less understanding of DNS in the people charged with maintaining it out there. Sad.
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. -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
participants (5)
-
Edward Lewis -
Jeroen Massar -
Joe Abley -
Joseph S D Yao -
Tuc at T-B-O-H.NET