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.
    ICANN is Expensive | Log in/Create an Account | Top | 16 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.
    Re:The Root Servers Now Run as Anycast in Your ISP
    by Anonymous on Tuesday May 18 2004, @07:12AM (#13611)
        * To: ietf at ietf.org
        * Subject: Re: Root Anycast
        * From: Paul Vixie <vixie at vix.com>
        * Date: 18 May 2004 00:16:49 +0000
        * In-reply-to: <DFC3BD05-A84A-11D8-AC18-000A95CD987A@muada.com>
        * List-help: <mailto:ietf-request@ietf.org?subject=help>
    &nbsp ;   * List-id: IETF-Discussion <ietf.ietf.org>
        * List-post: <mailto:ietf@ietf.org>
        * List-subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,<mai lto:ietf-request@ietf.org?subject=subscribe>
    &nbs p;   * List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,<mai lto:ietf-request@ietf.org?subject=unsubscribe>
    &n bsp;   * References: <DFC3BD05-A84A-11D8-AC18-000A95CD987A@muada.com>
        * Sender: ietf-admin at ietf.org
        * User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

    iljitsch@muada.com (Iljitsch van Beijnum) writes:

    > Unicast: A, E, H, L
    > Anycast: B, C, D, F, G, I, J, K, M (now or planned)
    >
    > The thing that worries me is that apparently, there is no policy about
    > this whatsoever, the root operators each get to decide what they want
    > to do.

    The table is round.  Policies are discussed as a group but set individually.
    The result is a service which has never been "down hard", not ever, not for
    any millisecond out of the last 15 years.  This is "strength by diversity."

    > The fact that .org is run using only two anycast addresses also indicates
    > that apparently the ICANN doesn't feel the need to throw their weight
    > around in this area.

    Apparently you have your facts wrong about how much sway ICANN had about
    the anycasting of .ORG, but those details aren't mine, let others speak.

    > Now obviously anycasting is a very useful mechanism to reduce latency
    > and increase capacity and robustness. However, these properties are
    > best served by careful design rather than organic growth.

    Careful design by whom?  Organic compared to what?  I assure you that f-root
    has grown by careful design.  It's only organic in that we go where we're
    invited rather than having a gigantic budget that could be used as a leash.

    Check out <http://www.isc.org/ops/f-root/> and the list of mirror sites, and
    look for some sponsors you know, and call them, and ask why they sponsored
    f-root and whether they're happy about it.  Then find someone in that region
    and ask them to do "dig @192.5.5.241 hostname.bind chaos txt" and tell you
    whether they're talking to a local f-root.  What could scale better, or
    allocate resources more efficiently?  (Central planning didn't help USSR.)

    > If we consider the number of actual servers/server clusters and the
    > number of root IP addresses as given, there are still many ways to skin
    > this cat.  One would be using 12 unicast servers and anycast just one
    > address.

    Who is "we", though?  That's always the excluded middle of this debate.  I
    know who I am -- a root operator.  But who are "we"?  And which of the
    million different answers to "who are 'we'?" would you like to see govern
    the choice of "who gets to decide how this stuff ought to work?"  E.g., I'm
    sure, without even having heard it, that you wouldn't want the choice of
    "who decides?" governed by Dean Anderson's answer to "who are 'we'?"

    > It seems to me that any design that makes the root addresses seem as
    > distributed around the net as possible would be optimal, as in this
    > case the changes of an outage triggering rerouting of a large number of
    > root addresses is as small as possible. In order to do this, the number
    > of root addresses that are available within a geographic region (where
    > "region" < RIR region) should be limited.

    In counterpoint, it seems to me that any unified design will make the system
    subject to monoculture attacks or ISO-L9 capture, and that the current
    system which you call "unplanned and organic" (but which is actually just
    "diversity by credo") yields a stronger system overall.

    > (Just having the roots close is of little value: good recursive servers
    > hone in to the one with the lowest RTT anyway, so having one close by
    > is enough. However, when this one fails it's important that after the
    > timeout, the next root address that the recursive server tries is
    > highly likely to be reachable, in order to avoid stacking timeout upon
    > timeout. A couple 100 ms extra round trip delay doesn't mean much in
    > cases where the recursive server suffers a timeout anyway.)

    What would help overall DNS robustness would be if more DNS clients used
    recursion, and cached what they heard (both positive and negative).  A
    frightfully large (and growing) segment of the client population always
    walks from the top down (I guess these are worms or viruses or whatever)
    and another growing/frightful segment asks the same question hundreds of
    times a minute and doesn't seem to care whether the response is positive or
    negative, only that it has to arrive so that the (lockstepped) next (same)
    query can be sent.

    If you'd like to unify something, perhaps it could be DNS client behaviour
    and network-owner recursive caching forwarder design.  And while you're at
    it, please outlaw those fiendish DNS-based load balancers.  f-root should
    still be a 486DX2-66 like it was in ~1995, rather than fifty 1GHz pentiums,
    and the 500X load 10 years later is due to client stupidity, not population
    growth or backbone speed increases.
    --
    Paul Vixie

    _________________________________________ ______
    Ietf mailing list
    Ietf@ietf.org
    https://www1.ietf.org/mailman /listinfo/ietf

    [ Reply to This | Parent ]
    Re:The Root Servers Now Run as Anycast in Your ISP by Anonymous


    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