ICANNWatch
 
  Inside ICANNWatch  
Submit Story
Home
Lost Password
Preferences
Site Messages
Top 10 Lists
Latest Comments
Search by topic

Our Mission
ICANN for Beginners
About Us
How To Use This Site
ICANNWatch FAQ
Slash Tech Info
Link to Us
Write to Us

  Useful ICANN sites  
  • ICANN itself
  • Bret Fausett's ICANN Blog
  • Internet Governance Project
  • UN Working Group on Internet Governance
  • Karl Auerbach web site
  • Müller-Maguhn home
  • UDRPinfo.com;
  • UDRPlaw.net;
  • CircleID;
  • LatinoamerICANN Project
  • ICB Tollfree News

  •   At Large Membership and Civil Society Participation in ICANN  
  • icannatlarge.com;
  • Noncommercial Users Constituency of ICANN
  • NAIS Project
  • ICANN At Large Study Committee Final Report
  • ICANN (non)Members page
  • ICANN Membership Election site

  • ICANN-Related Reading
    Browse ICANNWatch by Subject

    Ted Byfied
    - ICANN: Defending Our Precious Bodily Fluids
    - Ushering in Banality
    - ICANN! No U CANN't!
    - roving_reporter
    - DNS: A Short History and a Short Future

    David Farber
    - Overcoming ICANN (PFIR statement)

    A. Michael Froomkin
    - When We Say US™, We Mean It!
    - ICANN 2.0: Meet The New Boss
    - Habermas@ discourse.net: Toward a Critical Theory of Cyberspace
    - ICANN and Anti-Trust (with Mark Lemley)
    - Wrong Turn in Cyberspace: Using ICANN to Route Around the APA & the Constitution (html)
    - Form and Substance in Cyberspace
    - ICANN's "Uniform Dispute Resolution Policy"-- Causes and (Partial) Cures

    Milton Mueller
    - Ruling the Root
    - Success by Default: A New Profile of Domain Name Trademark Disputes under ICANN's UDRP
    - Dancing the Quango: ICANN as International Regulatory Regime
    - Goverments and Country Names: ICANN's Transformation into an Intergovernmental Regime
    - Competing DNS Roots: Creative Destruction or Just Plain Destruction?
    - Rough Justice: A Statistical Assessment of the UDRP
    - ICANN and Internet Governance

    David Post
    - Governing Cyberspace, or Where is James Madison When We Need Him?
    - The 'Unsettled Paradox': The Internet, the State, and the Consent of the Governed

    Jonathan Weinberg
    - Sitefinder and Internet Governance
    - ICANN, Internet Stability, and New Top Level Domains
    - Geeks and Greeks
    - ICANN and the Problem of Legitimacy

    Highlights of the ICANNWatch Archive
    (June 1999 - March 2001)


     
    This discussion has been archived. No new comments can be posted.
    The DoC and XXX | Log in/Create an Account | Top | 72 comments | Search Discussion
    Click this button to post a comment to this story
    The options below will change how the comments display
    Threshold:
    Check box to change your default comment view
    The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
    Root Server Operators Planning to Add .XXX Anyway
    by Anonymous on Monday August 22 2005, @10:09PM (#16044)
    Root Server Operators Planning to Add .XXX Anyway

    With or without ICANN, the Root Server operators
    are planning to add .XXX to make it more widely
    used. About 180,000,000 people, mostly in the .US
    currently can access it.

    Now that there are thousands of root servers all
    around the world, it is just a matter of time
    before more and more add .XXX. As it is entered,
    it spreads like a virus.

    http://www.isoc.org/isoc/conferences/wsi s/wgigcomments.shtml

    ROOT SERVERS – STABILITY THOURGH DIVERSITY8

    A clear benefit of the WGIG process has been the opportunity to share how things such as the root name server system operates. For instance, it now seems to be widely understood that the root name server operators do not determine the content of the root zone file, that no Internet traffic passes through the root name servers at all, and that these servers do not route Internet traffic. Furthermore, many root server operators now provide service from multiple locations using a method called "anycast" which increases the availability and resilience of the DNS system while providing increased benefits “in-region”. In fact, as of December 2004, there were root name servers being operated at more than 80 locations in 34 countries, most of them outside the United States of America. And, this number has grown considerably over the last 6 months and will continue to do so.

    This diversity and the distributed authority has been a critical element of the reliability of the root name service. We are happy to see that a consensus seems to be emerging that today’s arrangements have significant value to the Internet, as it is far from clear what value would be added by creating a new authority to oversee the root name server system. In fact, there is a real risk that this could weaken the robustness of the current operations by creating a single point of failure, or a potential target for capture and abuse. The costs of such an exercise, both in direct terms and in terms of the time and energies of those who would need to participate, do not appear to be sufficiently justified.
    [ Reply to This | Parent ]
    Re:Root Server Operators Planning to Add .XXX Anyw
    by Anonymous on Tuesday August 23 2005, @05:36AM (#16051)
    "service from multiple locations using a method called "anycast""

    There really are no root server operators.

    There are a dozen IP addresses which, via consensus,
    have become hard-wired into software as good
    addresses to use to find TLDs.

    Some of those IP addresses were backed up
    by the U.S. Government but they are now hosted
    local by your ISP.

    They are on sub-nets tagged as "public address
    space" [similar to 10.X.X.X].

    Anycast means that anyone can broadcast for
    those 12 IP addresses. As the ISOC points out,
    this creates diversity and a "distributed
    authority".

    Your software can send a query to any of the
    12 IP addresses and look at the results. It
    could also send queries to 6 or 8 or all and
    compare the results. Since your ISP or your
    country typically hosts all 12 IP addresses,
    the results should be the same.

    Because of the migration to high-speed,
    always-on broad-band .NET, your software and
    systems can become more intelligent and
    consider the distance [number of hops] to
    servers commonly used. Some software is able
    to take the 12 addresses and locate 3 or 4
    that are "closer" or more reliable or more
    consistent.

    The 12 IP addresses are really just boot-strap
    addresses. In the example of .XXX, they are
    not the location of the .XXX servers. Instead,
    you can send queries to those 12 addresses
    [or your closest ones] and ask where .XXX is
    located. Some may be able to give a hint. In
    the boot-strap phase, hints are what the
    software uses. One of the 12 IP addresses may
    result in a reply (a suggestion) to try a
    different set of addresses for .XXX. At some
    point, the software will find the .XXX name
    servers, remember their location and then lock
    on to them for future hints. The original 12
    addresses are no longer needed.

    .XXX is out there. Modern software finds it.
    Many parents do not want to encourage their
    .KIDS to go looking for it. Many employers do
    not want to encourage their employees to go
    looking for it.

    Some countries or States do not want their
    citizens to go looking for it. In some cases,
    we see groups from one country willing to move
    equipment to another country in order to host
    one or more of the 12 addresses.

    One solution is to block or control the access
    and hosting for all 12 of the public addresses
    used to find hints. The low-cost WIFI Routers
    take this approach. They give parents all sorts
    of controls for their family access.

    Ultimately, in the .USA, the telco controls the
    routing and access to the 12 addresses. The
    telcos are under the .FCC regulatory regime.
    The .FCC determines what can and can not be
    broadcast or anycast from those 12 addresses
    at least in the .USA on telco and cable nets.
    Wireless is also under the .FCC because of the
    need to avoid collisions when using the radio
    spectrum. The .FCC performs "the IANA Function"
    for the .USA, they help Americans avoid
    collisions.
    [ Reply to This | Parent ]


    Search ICANNWatch.org:


    Privacy Policy: We will not knowingly give out your personal data -- other than identifying your postings in the way you direct by setting your configuration options -- without a court order. All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 by ICANNWatch.Org. This web site was made with Slashcode, a web portal system written in perl. Slashcode is Free Software released under the GNU/GPL license.
    You can syndicate our headlines in .rdf, .rss, or .xml. Domain registration services donated by DomainRegistry.com