Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
The Internet Your Rights Online

ICANN vs. Alternate DNSs To Be Tested 15

Posted by michael from the getting-down-to-bizness dept.
Masem writes: "Yahoo news is reporting that a legal challege to ICANN's control on the DNS system is going to be pushed by Atlantic Root, a group that has been controlling the .biz domain (as given to them by the Open Root Server Confederation) since May. When ICANN issued the 7 new TLDs, they did recognize that there were alternative DNS systems out there and tried to avoid obvious conflicts (one reason why .web wasn't granted). However, Atlantic Root argues that ICANN willing knew about the alternate .biz when they made their ruling, and are only representing big businesses in their practices."
This discussion has been archived. No new comments can be posted.

ICANN vs Alternate DNSs to be Tested More

ICANN vs Alternate DNSs to be Tested

Comments Filter:
  • This is a direct challenge to the authority of ICANN to do anything with the domain name system
    The authority ICANN enjoys is based entirely on the fact that the overwhelming majority of DNS servers resolve to their designated root servers. There is no law forcing anyone to do so, only the desire we all share to be able to communicate. It seems to me that DNS servers that use "augmented" roots, in the fine tradition of "embrace and extend", do nothing to break the existing domains.

    So, if emough operators of DNS servers can be persuaded to do this, and users can be educated as to the benefits, ICANN may one day find its deliberations as relevant as resolutions on global affairs enacted by the Student Council at your local high school.

  • This doesn't sound extremely difficult. If BIND had a method for handling multiple root server domains (in the generic meaning of domain), there would be the possibility for competition. I hear the alternate TLD groups do a great job of being roots, but I don't want to trust them to handle their TLD's and ICANN's TLD's. I suspect reverse lookups would be the harder part, but it doesn't sound like an intractable problem. Of course, sysadmins would have to understand what root servers are.
  • It's a real shame that the TLDs were not originally treated as seperate orginisations: .edu would have been required by law to prevent non-universities from obtaining domain names, .org would have been a non-profit orginisation who's charter prevented them from allowing corperations to own .org domains, .net would have been some orginisation which gave priority to "network" related orginisations (i.e. joe.net could belong to any one until some network protocol called joe gained a signifcant following), and .com would have been a free-for-all. All the TLDs would have diffrent root servers and all the TLDs would have diffrent arbitration rules. Anyone could create a new TLD by putting up a root server, but they would then need to convince people to use their server too.

    Hopefully, only the TLD with reasonable arbitration rules would have a following. Ok, this last bit is a stupid libertarian pipe dream, but you would be able to create a rouge .com which did not cheat the common people like the real .com inevitibly would.

    Jeff
  • Vixie has (so I hear) declared that BIND will never support multiple roots, FWIW. However, djbdns [cr.yp.to] easily handles different roots for different TLDs.

    I don't want to trust them to handle their TLD's and ICANN's TLD's.

    No one but ICANN handles delegations for the legacy TLDs. The dot-com zone is still resolved through the ICANN roots. The delegation to the NS for dot-com is given by whichever roots you're using. Once your cache has the glue for dot-com cached, it never has to consult the roots (any roots) again for resolution of a dot-com domain - until the glue expires, of course. A typical client cache with good uptime hits the roots only a few times a week to refresh the glue for the TLDs its clients are making queries for. With glue in cache, recursion all the way to the roots is unnecessary; to resolve a dot-com domain, the cache goes directly to the dot-com servers for which it already has records.

    You can also slave an augmented root file to your own client nameserver, instead of installing a root.cache file. This permits you to see first hand what the root zone is delegating to, so you can easily verify its correctness yourself. Your cache won't ever hit the roots, since the root zone loads all the glue it needs.

  • This really should be on the front page, instead of just YRO. This is a direct challenge to the authority of ICANN to do anything with the domain name system, and could prove to be a bellwether case for the future of the domain name space.
  • Are there any outstanding security issues with djbdns? And what are some other secure DNS servers to check out?
  • Do tell me where on their website is a webpage which shows that they already have an interest in .biz.

    The ORSC "How To" page shows how to resolve the .BIZ domain (you do know how to use dig, right?):
    http://support.open-rsc.org/How_To/ [open-rsc.org]

    Or you can use SetDNS:
    http://www.open-rsc.org/setdns/ [open-rsc.org]

    The root zone file containing .BIZ (and also containing an ICANN board member's TLD) can be found here:
    http://dns.vrx.net/tech/rootzone/db.root [vrx.net] or
    http://www.superroot.org/root.db [superroot.org]

    The following "spoofed" addresses also work:
    http://www.icann.org&search=gtld&type=all@12017761 667/root.db [12017761667]
    http://www.internic.net&search=gtld&type=all@12017 761667/root.db [12017761667]

    FYI, the ORSC web site was written in 1997 to meet the US Gov's submission process criteria for the "new corp" (which is now known as ICANN). You are correct, the ORSC site does need to be updated. Instead of a pretty web site there is over six years of consensus and running code in the ORSC root zone. This is preferable to vaporware and marketing drivel driving banner ad counters.

    --
    Clowns Rule!

  • I did submit this as "The Internet/Article". It's not even a good YRO, IMO, as we're talking something that does not have a direct effect on our rights.

  • "willingly knew", sorry. Since ICANN denied .web as it's already served by an alternate DNS, they should have said the same with .biz.

  • Dr Bernstein is doing a Knuth - if you find a verified security bug in the package, you get $500 (Knuth offered an exponentially increasing reward for bugs in TeX).

    He's a very solid programmer (I know his mathematical code extremely well). I don't think he'll ever pay out.

    FatPhil
    -- Real Men Don't Use Porn. -- Morality In Media Billboards
  • The subject matter caused me to wonder about something else:

    What's to stop Microsoft from configuring their ubiquitous Internet Explorer to resolve to an alternate DNS...e.g. one of their own devising, in much the same way they already have IE supporting the (IMO execrable) RealNames?

    For example, if you type www.news.com, you get the normal C|Net page. But under this scenario, if you type www.news.soft, you would get an alternate site hosted by Microsoft. Seems to me that if they pick an appropriately "cool" sounding TLD, they could slowly appropriate namespace the way they've appropriated web browswers. Or, at the very least, they could flood namespace with cheep TLDs (.soft, .cool, .stuff, .site, .space, .place , .cola, .free, .etc) until ICANNs names are valueless.

    Not to mention, if enough companies were to use one of MS's alternate TLDs (let's say they make them extraordinarily cheap at first), then other browsers would be "broken". In particular, surfing on Linux would become problematic if MS didn't allow Linux browsers to access their TLDs.
  • Step-by-step instructions [unrated.net] are available on OpenNIC's web site on getting your nameserver to support both ICANN and OpenNIC TLDs.
    Tetris on drugs, NES music, and GNOME vs. KDE Bingo [pineight.com].
  • I understand djb is very picky in what he considers a vulnerability. For instance I understand there are a few DoSes for qmail (possibly older versions), but he claims they arn't his fault.

    I'm short on facts...
  • If he can say "not my fault, blame the TCP stack", then I agree with him. Even if he needs to change his code to get around weaknesses in other parts of the system I still don't think it's fair to call it a bug in his code.
    FP


    -- Real Men Don't Use Porn. -- Morality In Media Billboards
  • In particular, surfing on Linux would become problematic if MS didn't allow Linux browsers to access their TLDs.
    That would be an antitrust violation of the first order.

Slashdot Top Deals

Stellar rays prove fibbing never pays. Embezzlement is another matter.

Close