Slashdot Mirror


ICANN, National Registrars Still Feuding

Damalloch writes: "The BBC website has this story about the EU's concern over ICANN's refusal to make guarantees about root server stability. Domain name registrars such as Nominet are threatening to withhold payment of ICAAN's fees unless something is done to reassure them. So far ICAAN has remained stubborn because of the huge lawsuit potential if a root server were to go down but with the possibility of having their income reduced, they might just be convinced to do something."

175 comments

  1. what.. by geekoid · · Score: 3, Funny

    ..no link to the root server? how can we /. it?

    this was a joke.

    --
    The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    1. Re:what.. by Anonymous Coward · · Score: 0

      I think you almost have the link in your post - isn't it http://. ?

    2. Re:what.. by Anonymous Coward · · Score: 0

      Everything's a link to the root servers. They get slashdotted everytime a new story gets posted.

    3. Re:what.. by Bob+McCown · · Score: 3, Funny

      You dont need a link, all you need to do is think "I think ICANN, I think ICANN, I think ICANN..."

    4. Re:what.. by SevenTowers · · Score: 2

      F.root-servers.net and I'm serious, check it!

      --
      Imperium et libertas
      Autocracy and freedom
    5. Re:what.. by Anonymous Coward · · Score: 0

      Why, there's nothing there...

  2. Well yes, but... by johnburton · · Score: 5, Interesting

    But if one server went down wouldn't the requests just go to the other root servers instead? Isn't that how DNS works?

    So presumably they've got decent machines and power supplies and connections for each server. And so the chance of one going down is quite low. The chance of enough of them going down at the same time to cause disaster has to be vanishingly small. If it's too big, add a few more servers.

    Unless they include the possibility of them being hacked I suppose. But then they could just use several different operating systems and name server software to hugely reduce the chances.

    I'm not sure I'm convinced that this is really the reason they won't give any guarantees, it seems like a reasonably safe thing to do to me.

    --
    Sig is taking a break!
    1. Re:Well yes, but... by RollingThunder · · Score: 5, Informative

      It would (go to another root) - but if these systems are already running close to capacity, then that may be enough to cause the next server to choke, crash, and the next server will fall even faster.

      It's a scenario much like the AT&T switch fiasco, where a seldom exercised chunk of code took out one server. Once one server was down, the others took more load, which, coupled with the fact part of the problem was a live switch receiving a "I'm back!" message while under heavy load, caused more switches to go. Cascade failure all the way.

      After reading the article, I'm actually rather surprised myself. These systems must chew a ton of bandwidth, but it seems ICANN doesn't pay for it? Not to mention that all but three are in the US - isn't that going to oversaturate the cross-oceanic links?

      I think I'm definately with the registrar organizations - ICANN should be having contracts in place to require certain things, rather than a wink and a nod and a handshake.

    2. Re:Well yes, but... by johnburton · · Score: 2

      DNS servers cache requests so the vast majority of requests are probably to a few common addresses and never see the root servers.

      So the bandwidth is probably not too bad.

      --
      Sig is taking a break!
    3. Re:Well yes, but... by RollingThunder · · Score: 2

      There's enough secondary servers and varied domains that even with said caching, the roots are likely under heavy load.

      Don't forget that in-addr's go there too.

    4. Re:Well yes, but... by Guppy06 · · Score: 1

      "I'm not sure I'm convinced that this is really the reason they won't give any guarantees, it seems like a reasonably safe thing to do to me."

      I'd have to say because they're cheap bastards and if they were to make such a guarentee, their insurance rates would spike.

    5. Re:Well yes, but... by Rev.LoveJoy · · Score: 2
      Matrix net carries some interesting statistics regarding TLD availability here.

      Reading through the page will give you an idea of the bandwidth matrix has at their disposal. The fact that most TLD servers are still 100+ msec ping on average would indicate, IMO, that those servers are under load.

      Cheers,
      -- RLJ

    6. Re:Well yes, but... by Anonymous Coward · · Score: 0

      If I'm reading that right....the root server that site is checking is getting 25% packet loss right now, not too good.

    7. Re:Well yes, but... by Isomer · · Score: 1

      The nameservers are near capacity at the moment, however since name servers effectively load balance it's rather difficult to notice. Theres a fascinating paper about it here The root/gTLD name servers are in a lot worse state than most people think. It is possible in a few years that they become too overloaded and just melt down. Imagine the internet without a functional DNS :)

    8. Re:Well yes, but... by Jon_E · · Score: 1

      very true! - when I was there last year a.root-server.net was around 11,000 UDP queries/sec and the others would peak up to around 5-6,000 .. occassionally they'd see things that would scare the daylights out of them. There are dependencies on the a.root server since DNS does have a hierarchy and a.root functions as a master of the masters .. in other words - master authoritative queries flow up and will hit a.root.

      Add to the queries the size of the zones - the .COM zone was over a 2gb flat file - try doing your basic DNS pointer record lookups on something that size at that rate!

      btw - when win2K first hit - sustained load on a.root gradually increased by a factor of 4-5x - they were working on a number of strategies to filter at line speed and redirect queries - you wouldn't believe (or maybe you would) the bogus DyDNS requests and poorly formed queries that hit every couple ms ..

    9. Re:Well yes, but... by johnburton · · Score: 2

      Well yes that would be pretty bad. Shame I can't read the article as it's a .ps file which I have no way of reading.
      But I can think of a number of ways to help with this.

      For example, set up a new set of root name servers. Make sure that the database is duplicated to those machines at more or less the same time as the original machines, and then pursade of of the big providers. AOL or someone to use those as their root name serves instead. They would get better service, having dedicated machines, and it would lessen the load on the existing servers.

      Not an ideal solution, but I'm sure it would work to reduce the load for a while.

      --
      Sig is taking a break!
    10. Re:Well yes, but... by Isomer · · Score: 1

      One of the problems that was discovered in this report was that the root name servers tended to do their zone transfers at the same time as other root name servers meaning that 2 or 3 nameservers could be offline at any given time due to handling a zone transfer.

  3. Run their own? by hogsback · · Score: 2, Interesting


    What are the obstacles to Nominet, say, running their own root server.

    They must already have bandwidth and physical security ... what else would they need?

    More redundency, especially outside the US, can only be a good thing, right?

    1. Re:Run their own? by jbf · · Score: 4, Informative

      They'd need ISPs who run DNS servers for their clients to point to their root servers. This is somewhat nontrivial.

    2. Re:Run their own? by Anonymous Coward · · Score: 1, Interesting
      What are the obstacles to Nominet, say, running their own root server ?

      Configuring every DNS on the planet to know about it ...

    3. Re:Run their own? by Anonymous Coward · · Score: 0

      They'd need a P3 with at least 256 meg of RAM. Oh, and a 10/100 NIC.

    4. Re:Run their own? by hogsback · · Score: 1

      Since DNS is a hierarchy, wouldn't it be just the DNS servers at the next level down that need modifying.

      How many of these are there?

    5. Re:Run their own? by Anonymous Coward · · Score: 0

      There probably aren't more than a few hundred thousand that need to be changed.

    6. Re:Run their own? by Anonymous Coward · · Score: 0

      Wrong, All DNS querries start top down.

    7. Re:Run their own? by hogsback · · Score: 1

      When was the last of the current 13 nameservers added? How problematic was that?

      And the DNS servers don't need to be changed at the same time ... the Europeans, say - since they're the ones complaining - can update theirs and the rest of the world can update as they feel like it.

    8. Re:Run their own? by Sloppy · · Score: 2

      Since DNS is a hierarchy, wouldn't it be just the DNS servers at the next level down that need modifying.

      No.

      Crash course in DNS: In a typical setup, your machine asks the DNS server at your ISP (this is called a "recursive resolver" and it's really not part of the DNS hierarchy) where www.foo.com is. Then it does the following (assuming all cache misses -- in real life, not all these connections would really happen most of the time): it has a list of root DNS servers stored in a config file somewhere. It picks a root DNS server and asks where the .com DNS server is. The root tells your ISP's DNS server where .com is, and then your ISP's DNS server asks the .com DNS server where foo.com is, and then when it gets the answer to that, it asks the DNS server for foo.com where www.foo.com is. Then your ISP's DNS server passes the result to you. (Glossing over a few details.)

      Queries start at the root, and work their way down the hierarchy.

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
  4. ICANN is about to lose big... by Bonker · · Score: 3, Insightful

    Firstly and foremost because it's a U.S. entity who pretends to be an international entity and the Internet quit being a U.S. entity a long time ago.

    I suspect that China will be the first to set up its own root DNS servers and start issuing non-ICANN-approved domain names, probably in competition with ICANN and Versign. Other's will soon follow. Soon every big ISP both in the U.S. will see the need to have its own root DNS server. Of course there will be some cooperation required between the different DNS roots if their customers are going to be happy. Hopefully, this new cooperation will end the monopoly ICANN has over the administration of the Internet, leaving unsportsman like players like Versign standing out in left field, wondering why nobody is tossing them the ball anymore.

    --
    The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
    1. Re:ICANN is about to lose big... by geekoid · · Score: 2

      Actually, I bet it ends up falling under the WTO treaties, and the WTO will apoint a board to control the Root DNS system. son't be surprised when VerSign ends up with members on that board.

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    2. Re:ICANN is about to lose big... by moncyb · · Score: 1

      Yeah, after the last story about DNS, I started considering switching to one of the alternate DNS systems. Hmmm...I wonder if uber.geek is taken?

      The claim that they're worried about lawsuits seems silly to me (at least to some degree). They can at least try to increase their redundancy, security and stability--then just put some blurb in their agreements that they don't guarantee stability (just like many modern corporations do). The article said they weren't even paying the companies/organizations that ran the root level servers! Isn't this a big part of what they are supposed to be doing? What kind of crap is that?

      I have to wonder if this is just some ploy so that the players can stuff their wallets with ICANN money...

    3. Re:ICANN is about to lose big... by rhekman · · Score: 2, Insightful
      Firstly and foremost because it's a U.S. entity who pretends to be an international entity and the Internet quit being a U.S. entity a long time ago.

      The catch for ICANN is it needs legitimacy to enforce policy both in the U.S. and especially abroad, but it can't gain global recognition and respect without enforcing policy and taking responsibility.

      From the article:
      Nigel Roberts, head of the Channel Island domain registry and a member of Icann's country code committee, said the row was leading people to question just what Icann was for."The issue is not the amount of money," he said. "It is about the role that Icann has."

      I think ICANN could help resolve this by giving guarantees to take an active role in use and abuse of the root servers. They could more closely track and monitor root server usage, make recommendations and requests to providers on where to put root servers to improve DNS efficiency and reliability. ICANN could also publish data on who's root servers are performing well and who's are not, shaming poor providers who create bottlenecks into better service. If ICANN performs those duties well and is responsive to concerns like those in the EU, it will become a more effective body.

      Regards,
      Reid

      --
      I like teamwork. It's easier to assign blame that way.
    4. Re:ICANN is about to lose big... by Peter+Dyck · · Score: 1
      Of course there will be some cooperation required between the different DNS roots if their customers are going to be happy.

      Didn't AOL try locking their userbase into AOL chatroom-sandbox and it worked for a while?

    5. Re:ICANN is about to lose big... by Anonymous Coward · · Score: 0

      Yes, but unfortunately, they let 'em loose.

      That'd be cool though, huge private networks that have user screening.

      "I'm sorry, sir, we can't create an account for you until you stop calling it 'that thar dern puter'."

      (:

    6. Re:ICANN is about to lose big... by Sloppy · · Score: 3, Informative

      I suspect that China will be the first to set up its own root DNS servers and start issuing non-ICANN-approved domain names,

      First? It is already several years too late for China to somehow be first. Alternate roots have been around for a long time. I use one, you can too.

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
    7. Re:ICANN is about to lose big... by Kanasta · · Score: 2

      Several people already host their own root servers with non-ICANN-approved TLDs. The problem is getting ISPs to point to those servers to see the domains.

      Of course, China prolly has an advantage that it can force all ISPs to point to its servers...

  5. Every time anyone looks for a webpage??? by mrroot · · Score: 3, Insightful

    Almost every time anyone looks for a webpage these root servers are consulted.

    Surely this cannot be true... Don't DNS servers cache address resolutions?

    --
    I Heart Sorting Networks
    1. Re:Every time anyone looks for a webpage??? by geekoid · · Score: 2

      unles you enter a computers addres in hex, in which case it goes straight to the system.
      There are also people who maintain there own DNS system, albeit smaller and personalized.
      But in general that is true.

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    2. Re:Every time anyone looks for a webpage??? by Anonymous Coward · · Score: 0

      Yes, but that depends on the TTL of the record. If the TTL has expired then the record is looked up again.

    3. Re:Every time anyone looks for a webpage??? by FFON · · Score: 1

      you are correct, unless the clients dns server doesn't have the answer, then it looks to the root servers, unless the dns server is set to forward queries, then it'd forward them to another dns server, who might or might not have the answer... "Almost every time anyone looks for a webpage these root servers are consulted..." is hyperbole.

      --
      .cig
    4. Re:Every time anyone looks for a webpage??? by cmckay · · Score: 1

      Yes, DNS servers do significant amounts of caching. When I worked at a small ISP a few years ago, they cached DNS lookups for a week. I believe that almost everyone caches for 48 hours or less nowadays.

      Plus, I'm sure that at least 10% of normal web browsing comes straight from the user's cache on their hard drive, so the internet isn't accessed at all.

    5. Re:Every time anyone looks for a webpage??? by Anonymous Coward · · Score: 0

      The length of time that the host/ip will stay in the cache's of other nameservers comes from the TTL in the zonefile on the origonal nameserver, iirc it's the expire time. You can't control other peoples expire times on your own server..only the expire times for your zone. Although killall -HUP named will flush the cache anyway.

    6. Re:Every time anyone looks for a webpage??? by kyras · · Score: 1

      Hex? Are you referring to the MAC address of a machine? That's only really valid on local lan. To route to a machine on the opposite "side" of the internet you need its IP number (thinking dotted-decimal), and DNS is the services used to obtain the IP number from readable names like "slashdot.org".

      --
      Tastes like burning! - Ralph Wiggum
    7. Re:Every time anyone looks for a webpage??? by egburr · · Score: 2

      An IP number is a 32-bit binary number. It can be represented in the familiar dotted-decimal format. It can be represented as a hex number. It can even be represented as a huge decimal number. Take your pick. If you convert the dotted decimal to a regular decimal number (and that isn't just taking out the dots and stringing the numbers together), and type that into your browser, you will get to the same destination as the dotted-decimal number. I don't know if the browsers will behave the same if you enter it in hex, though.

      --

      Edward Burr
      Having a smoking section in a restaurant is like having a peeing section in a swimming pool.
    8. Re:Every time anyone looks for a webpage??? by egburr · · Score: 2

      for an example, see this page on decimal URLs

      --

      Edward Burr
      Having a smoking section in a restaurant is like having a peeing section in a swimming pool.
  6. Sounds like a standard SLA is required by mccalli · · Score: 2
    the EU's concern over ICANN's refusal to make guarantees about root server stability.

    It sounds as if all that's required is a standard Service Level Agreement. The kind of thing that's standard through most big corporates, and has a clause along the lines of "we guarantee 99.5% uptime, if service drops below this we pay £x.xx per quarter percent below.".

    It seems that it's the refusal to provide something like this, rather than technical worries, that are underlying this dispute.

    Cheers,
    Ian

  7. ICANN doesn't OWN the root servers by dschuetz · · Score: 3, Insightful
    From the article:
    However, many of the servers are looked after on an ad hoc basis by very different companies. Icann does not pay the wages of the people that oversee the servers, nor has it signed contracts with the organisations that look after the root servers to establish service levels, standards of reliability or ecurity.

    If ICANN can't legally hold accountable the people running the root servers, then there's no way they'd provide any guarantees to anyone. That much makes sense.

    Furthermore, the root servers (again, from the article, don't flame me if I'm missing a nuance or two) don't really DO much. They just tell you where to go to get info for each of the top-level domains. Not exactly a whole lot to running one of these other than keeping it from crashing.

    My question, though, is why is anyone worried about a root server crashing? There are 13 of 'em. Wouldn't your DNS server ask someone else if the "preferred" root server suddenly went Tango Uniform? Are there backup root servers out there to jump in? Ways to route around the damage, as it were?

    What I still find amazing is that ICANN hasn't managed to take full physical and financial control of all the root servers. When I was in school, I remember thinking it was cool that we had one of the root servers (terp) in my building. It was amazing to see how a loose group of unrelated institutions had somehow set up a reliable, workable, DNS system.

    In fact, it sounds like this is still the case, somewhat. Do these root server operators have ANY contractual controls on what they do? If not, then why the hell can't we just get THEM to add new top level domains? Screw ICANN. The servers don't belong to them, they belong to the people running 'em. As long as the guys running the roots don't point .com to some other universe, they should be able to avoid getting sued into oblivion, right?

    And, if they were to do this, could ICANN even stop them? They'd have to repoint all the root.hints files across the entire globe, wouldn't they?

    Or is this the kind of Chaos that the EU is afraid of?
    1. Re:ICANN doesn't OWN the root servers by gorilla · · Score: 2
      Furthermore, the root servers (again, from the article, don't flame me if I'm missing a nuance or two) don't really DO much. They just tell you where to go to get info for each of the top-level domains. Not exactly a whole lot to running one of these other than keeping it from crashing.

      What a root server doesn't isn't very hard. What is hard is keeping the damm thing running. They a high load (every DNS server in the world hits once once a day for each TLD), they get all sorts of script kiddies hitting them, and because of their profile, it's very hard to make changes.

    2. Re:ICANN doesn't OWN the root servers by Rashkae · · Score: 1

      If a root server goes down, there are lots of redundant alternatives. However, the posability and damage of Domain name hijacking is much more serious... This is especially true since ICANN does not even operate the root servers!!. What's stopping one of the companies that operate root servers from suddenly deciding to take over the .uk top level domain? There is probably no law or contract stopping them from doing so.

    3. Re:ICANN doesn't OWN the root servers by Danse · · Score: 1

      You're probably right. NSI hijacks people's domains all the time and doens't get in trouble. Makes me wonder if there actually is any law that prevents it. If they hijacked a TLD, I'm sure everyone would make a law against it real quick though.

      --
      It's not enough to bash in heads, you've got to bash in minds. - Captain Hammer
  8. What's new? by zeiche · · Score: 2, Interesting

    Looks like another example of a company that does not want to guarantee services they have accepted payment for. Nothing new here.

  9. We need a new DNS system by _DMan_ · · Score: 1

    The real issue here is that many 1000's of companies have based their businesses on the assumption that DNS will always be available and reliable. The original intent of the DNS system was to provide a convenient service to Internet users, not to serve as a point-of-failure for the entire net.

    Why should ICANN promise to deliver something that they know they are unable to?

    What we really need is to start over with a new specification for domain names that reflects the needs of the current Internet - a systerm that can provide the security and reliability that we now depend on.

    1. Re:We need a new DNS system by GuNgA-DiN · · Score: 1

      Great idea... but, it has taken the entire community years of fighting to agree on things like IPv6. How long until that gets implemented? Can you even imagine how long it would take to: a) come up with a new spec and b) implement it?

      Don't think in human years.... try thinking in geological time. You know... eons, epochs, and eras.

  10. I don't know about anyone else, but... by f00zbll · · Score: 1
    It sounds like they are using this as an excuse to not pay. I doubt they really care, but it is a convienant excuse to use, since they know ICANN can't come up with a solution and implement it rapidly due to politics.

    It's all about money, pure and simple.

    1. Re:I don't know about anyone else, but... by nologin · · Score: 2, Insightful

      Yes, it is about money.

      If your company was administering a ccTLD and ICANN comes knocking at your door for money when they can't make any assurances of your ccTLD being served to the rest of the world, why should you pay them?

      To make an analogy, ICANN is to the Internet like the UN is to an international government; they are both generally ineffective but continuously demanding an ever increasing sum of money to be able to join the party.

      The simple fact is that ICANN can't... (make any assurances) because they ultimately can't step in and takeover the root servers. Otherwise, they'll find themselves in a bigger controversy. Mind you, ICANN is no stranger to controversy.

    2. Re:I don't know about anyone else, but... by f00zbll · · Score: 1

      Agree completely, though there is a slight difference between UN and ICANN. A couple hundred planes and a few thousand soldiers :)

  11. Money money money by zebs · · Score: 1


    Looks like ICANN just want the money without offering a guarantee of service.

    Any reason why the top level domain registers can't take over ICANNs role of handling root level DNS requests?

  12. They probably will do something by Steve+Cox · · Score: 1

    ICANN are likely to do something if Nominet stop their payments. Remove the .uk domain.

    1. Re:They probably will do something by geekoid · · Score: 2

      Man, it would really hit the fan. That would gaurentee that the WTO would take over the domain names.

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
  13. How much of the ICANN budget does JDRP get? by GuNgA-DiN · · Score: 1
    Maybe we should be wondering where all ICANN's money goes? According to their budget, the law firm Jones, Day, Reavis, and Pogue gets about $734,000.00 !!!

    ICANN should be less worried about the CCtlds and focus on their own organization! The total personnel costs for ICANN are projected at $2.217 million dollars! I would like to know what EXACTLY the staff members do to deserve this type of money? ICANN is the biggest bunch of hypocrites to come along since the US Congress!

  14. I doubt that. by Anonymous Coward · · Score: 0

    While it is true that China may become an internet superpower, from a traffic standpoint, I dounbt that they are going to take over the management of the internet.

    When they pull stuff like jailing people for posting disenting opinions of the government on the internet. Or restrict peoples internet activities, as they do, who will be willing to sign up with them as a root or any other higher level management function, for that matter.

    No, China will not take over root servers. Some other nation might, maybe. But, definitely not China. Frankly, I suspect that root servers as we know DNS today will continue to be managed/mismanaged from the US for a very long time to come.

    1. Re:I doubt that. by ethereal · · Score: 1

      China will not take over existing root servers. But if they establish their own root server for use within China, then that will actually further their goal of controlling Chinese citizens' access to information. Even if no one else in the world uses the China root server, it could still help to control the Chinese population, which is their overall goal.

      --

      Your right to not believe: Americans United for Separation of Church and

    2. Re:I doubt that. by JohnGalt42 · · Score: 1

      When they pull stuff like jailing people for posting disenting opinions of the government on the internet. Or restrict peoples internet activities, as they do, who will be willing to sign up with them as a root or any other higher level management function, for that matter.

      That's just it... they can make it law that everyone in China has to use the Chinese root servers. Those who dissent are jailed.

      No, China will not take over root servers. Some other nation might, maybe. But, definitely not China.

      I disagree. While taking over root servers may not be the most successful policy, it is certainly a viable option. It's not an issue of whether or not China can setup root servers, China definitely has people who can, and would be willing to, setup and maintain root servers. The bigger issue is their motivation. Given a desire to prevent people from posting and reading dissenting opinions, the Chinese government may perceive root servers as a very viable option.

  15. root server RFC by digitalsushi · · Score: 1

    doesnt the root server RFC say that there must always be three times the current estimated usage (that is if 2/3 of the root servers went down the internet would still server DNS)?

    --
    slashdot: where everyone yells sarcastic metaphors to themselves to understand the issue
  16. That's not quite what happened with AT&T by MemeRot · · Score: 5, Informative

    A faulty version of software was released. And yes the fault was buried waaay down in a giant case or if/elseif statement. Normally no big deal, right? Just roll back. But they had things set up so that any machine connected to another would poll it for the version of software it had. If what it connected to had a newer version, it would download that and then hand it off to all its fellows. So by the time the bad code triggered and they realized they had a problem it had already spread virus-like across the whole network. Going back to the older version one one machine was futile because as soon as it booted up it would connect to other machines and download the flawed software.

    They had to eventually take their old version, give it a new, higher number, and then compile and release that. So that that 'feature' once again became a feature and not a bug. Many lessons to be learned.

    1. Re:That's not quite what happened with AT&T by RollingThunder · · Score: 2

      I know, just didn't think it was relevant enough to go into detail. :)

      Specifically, the break statement was exercised when (iirc) over 50 incoming calls were being handled in the same second at the same time that the switch recieved a "I'm back!" message.

      Once one legitimately faulted out, it tripped the code in one other, which upped the load on it's neighbors, and when it came back, it took three out...

      This is covered very nicely in the Hacker Crackdown, which I think was placed online in an act of surprising generosity. I still prefer the paper though. :)

  17. A Geek's challenge: by SevenTowers · · Score: 2

    The "F" root server, located at the Internet Software Consortium offices in Redwood City, California, is fitted with eight gigabytes of Ram and handles over 272 million domain queries per day.

    I challenge us to slashdot it!

    --
    Imperium et libertas
    Autocracy and freedom
    1. Re:A Geek's challenge: by blibbleblobble · · Score: 1

      It has to store a database containing 200 entries, each of which has an name (3 bytes) and a value (8 bytes)

      So, that gives us 4.4K of data, plus presumably a little program to interpret it and send the results back.

      So what do they do with the other 8 gigabytes?

    2. Re:A Geek's challenge: by Anonymous Coward · · Score: 0

      I thought the name could be upto 64 chars long which is 64 bytes. Also where do you get the 200 entries from? Surely it will have one entry for every zone in the TLD that it serves. i.e. every single .net domain. Plus it may not stores values...wouldnt they just store NS records for every zone? man their named.conf must be a nightmare

    3. Re:A Geek's challenge: by arkanes · · Score: 2

      Thats ~3150 queries per second. I imagine a good chunk of that 8 gigs is ram used to create sockets and threads that do the lookups - I also suspect that is's a heavy SMP machine, each processor with it's own ram. If there were, say, 32 processors, each with 256 megs of ram, and each processor ran (X) threads to handle requests...

    4. Re:A Geek's challenge: by Anonymous Coward · · Score: 0

      .::127.53.0.1
      &1719::199.166.24.1
      &1719::205.189.73.102
      &1719::216.13.76.2
      &800::192.147.236.1
      &800::199.166.24.1
      &800::204.57.55.100
      &800::204.80.125.130
      &800::205.189.73.102
      &800::209.104.33.252
      &800::209.104.63.252
      &800::216.13.76.2
      &888::192.147.236.1
      &888::199.166.24.1
      &888::204.57.55.100
      &888::204.80.125.130
      &888::205.189.73.102
      &888::209.104.33.252
      &888::209.104.63.252
      &888::216.13.76.2
      &a::206.25.132.30
      &ac::128.250.1.21
      &ac::192.16.202.11
      &ac::193.0.0.193
      &ac::194.205.62.120
      &ac::198.6.1.82
      &ac::210.141.111.69
      &ad::194.158.64.7
      &ad::194.158.64.8
      &ad::194.158.67.1
      &ad::194.158.67.251
      &ad::194.65.3.21
      &ae::194.170.1.6
      &ae::194.170.1.7
      &af::212.53.64.60
      &af::212.53.77.28
      &ag::136.145.1.4
      &ag::207.42.132.226
      &ag::207.42.132.227
      &ag::212.53.64.60
      &ag::212.53.77.28
      &ai::209.68.1.11
      &ai::209.88.68.34
      &ai::216.148.218.250
      &ais::63.102.200.2
      &ais::63.102.204.130
      &al::128.250.1.21
      &al::146.48.65.46
      &al::147.28.0.39
      &al::192.16.202.11
      &al::192.36.125.2
      &al::193.0.0.193
      &al::198.6.1.82
      &alpha::199.166.24.1
      &alpha::205.189.73.102
      &alpha::216.13.76.2
      &am::147.28.0.39
      &am::193.0.0.193
      &am::194.67.2.97
      &am::195.250.64.65
      &am::195.250.64.90
      &am::202.12.28.131
      &amiga::199.166.24.1
      &amiga::205.189.73.102
      &amiga::216.13.76.2
      &an::128.250.1.21
      &an::128.86.1.20
      &an::137.39.1.3
      &an::192.36.125.2
      &an::193.0.0.193
      &an::193.63.94.20
      &an::200.44.117.129
      &an::200.44.117.130
      &an::208.136.52.74
      &anime::199.166.24.1
      &anime::205.189.73.102
      &anime::216.13.76.2
      &ao::192.16.202.11
      &ao::192.36.125.2
      &ao::193.136.7.17
      &ao::198.6.1.82
      &aq::202.37.240.13
      &aq::202.89.128.74
      &aq::209.240.128.25
      &ar::130.59.211.10
      &ar::137.39.1.3
      &ar::16.1.0.18
      &ar::16.1.0.19
      &ar::193.0.0.193
      &ar::200.10.202.3
      &ar::200.16.97.17
      &ar::200.16.98.2
      &ar::204.123.2.18
      &arpa::128.63.2.53
      &arpa::128.8.10.90
      &arpa::128.9.0.107
      &arpa::192.112.36.4
      &arpa::192.203.230.10
      &arpa::192.33.4.12
      &arpa::192.36.148.17
      &arpa::192.5.5.241
      &arpa::198.41.0.4
      &art::199.166.24.1
      &art::216.13.126.116
      &art::216.13.76.2
      &arts::199.166.24.1
      &arts::216.13.126.116
      &arts::216.13.76.2
      &as::128.250.1.21
      &as::198.6.1.82
      &as::209.207.221.1
      &as::212.250.25.101
      &asbl::195.206.104.1
      &asbl::195.206.104.201
      &asbl::195.206.104.211
      &asbl::195.206.105.1
      &asbl::195.206.105.101
      &asbl::195.206.105.102
      &asia::165.251.1.2
      &asia::165.251.1.239
      &asia::165.251.1.3
      &at::137.39.1.3
      &at::192.16.202.11
      &at::193.154.160.110
      &at::193.171.255.2
      &at::193.171.255.66
      &at::194.246.96.192
      &atm::199.166.24.1
      &atm::205.189.73.10
      &atm::216.13.76.2
      &atm::216.196.51.4
      &au::128.250.1.21
      &au::128.250.1.22
      &au::128.250.37.150
      &au::128.32.136.12
      &au::128.32.136.9
      &au::128.32.206.12
      &au::128.32.206.9
      &au::128.32.33.5
      &au::137.39.1.3
      &au::192.16.202.11
      &auto::212.162.54.243
      &auto::212.162.54.34
      &aw::144.228.254.10
      &aw::144.228.255.10
      &aw::206.228.179.10
      &aw::206.48.100.11
      &aw::206.48.100.5
      &az::147.28.0.39
      &az::194.87.0.8
      &az::194.87.0.9
      &b::194.113.40.45
      &b::195.238.228.131
      &ba::128.250.1.21
      &ba::192.16.202.11
      &ba::193.0.0.193
      &ba::195.130.35.3
      &ba::195.130.35.5
      &ba::198.6.1.83
      &bahn::212.162.54.243
      &bahn::212.162.54.34
      &bali::12.28.140.20
      &bali::204.107.129.10
      &bali::204.107.129.2
      &bali::204.107.129.3
      &bali::208.179.112.2
      &bali::209.166.167.208
      &bali::63.160.181.10
      &bali::63.160.181.11
      &bank::199.166.24.1
      &bank::216.13.126.116
      &bank::216.13.76.2
      &bb::205.214.192.201
      &bb::205.214.192.202
      &bd::209.58.24.3
      &bd::209.58.24.5
      &be::134.58.40.4
      &be::192.16.202.11
      &be::192.36.125.2
      &be::193.190.198.10
      &be::193.190.198.2
      &be::193.74.208.139
      &be::194.7.171.243
      &be::198.6.1.82
      &belize::12.28.140.20
      &belize::204.107.129.10
      &belize::204.107.129.2
      &belize::204.107.129.3
      &belize::208.179.112.2
      &belize::209.166.167.208
      &belize::63.160.181.10
      &belize::63.160.181.11
      &bf::192.33.151.1
      &bf::199.202.55.2
      &bf::206.82.130.195
      &bg::128.63.31.4
      &bg::128.63.5.4
      &bg::137.39.1.3
      &bg::139.91.1.1
      &bg::192.16.202.11
      &bg::192.36.125.2
      &bg::192.92.129.1
      &bh::193.188.124.227
      &bh::193.188.97.197
      &bh::193.188.97.212
      &bi::128.112.129.15
      &bi::192.36.125.2
      &bi::194.38.74.11
      &bio::12.28.140.20
      &bio::204.107.129.10
      &bio::204.107.129.2
      &bio::204.107.129.3
      &bio::208.179.112.2
      &bio::209.166.167.208
      &bio::63.160.181.10
      &bio::63.160.181.11
      &biz::12.28.140.20
      &biz::204.107.129.10
      &biz::204.107.129.2
      &biz::204.107.129.3
      &biz::208.179.112.2
      &biz::209.166.167.208
      &biz::63.160.181.10
      &biz::63.160.181.11
      &bj::194.51.163.253
      &bj::194.51.3.49
      &bm::128.63.58.18
      &bm::137.39.1.3
      &bm::192.16.202.11
      &bm::192.36.125.2
      &bm::199.172.192.1
      &bn::165.21.100.11
      &bn::165.21.83.11
      &bn::193.0.0.193
      &bn::195.13.10.226
      &bn::198.6.1.83
      &bn::202.160.8.2
      &bo::166.114.1.40
      &bo::198.6.1.202
      &bofh::193.141.75.1
      &bofh::193.174.15.34
      &bofh::193.174.5.2
      &bofh::194.122.210.3
      &bofh::194.152.163.253
      &bofh::194.221.90.34
      &bofh::194.231.54.2
      &bofh::194.45.71.1
      &bofh::195.179.28.17
      &bofh::195.21.255.252
      &bofh::195.88.150.3
      &bofh::212.172.21.254
      &bofh::212.86.129.142
      &bofh::62.204.1.1
      &book::216.86.199.114
      &book::216.86.199.115
      &books::216.86.199.114
      &books::216.86.199.115
      &bot::199.166.31.250
      &bot::199.166.31.3
      &box::206.16.77.10
      &box::206.16.77.11
      &box::209.166.167.208
      &box::63.160.181.10
      &br::143.108.23.2
      &br::192.134.0.49
      &br::200.19.119.99
      &br::200.255.253.234
      &br::204.152.184.64
      &bs::128.8.10.14
      &bs::136.145.1.4
      &bt::128.250.1.21
      &bt::156.106.192.121
      &bt::193.0.0.193
      &bt::198.6.1.182
      &bt::198.6.1.65
      &bt::202.144.128.200
      &buch::212.162.54.243
      &buch::212.162.54.34
      &bv::129.240.2.40
      &bv::158.38.0.181
      &bv::193.10.252.19
      &bw::137.39.1.3
      &bw::146.230.192.18
      &bw::146.231.128.1
      &bw::147.28.0.34
      &by::147.45.15.34
      &by::193.0.0.193
      &by::193.124.22.65
      &by::193.59.201.28
      &by::194.226.121.36
      &by::194.67.193.130
      &by::195.50.5.103
      &bz::146.230.192.18
      &bz::147.28.0.39
      &bz::192.189.54.17
      &bz::193.0.0.193
      &ca::128.100.102.201
      &ca::142.77.1.5
      &ca::192.26.210.1
      &ca::192.73.5.1
      &ca::216.168.224.206
      &ca::64.26.149.98
      &cal::12.28.140.20
      &cal::204.107.129.10
      &cal::204.107.129.2
      &cal::204.107.129.3
      &cal::208.179.112.2
      &cal::209.166.167.208
      &cal::63.160.181.10
      &cal::63.160.181.11
      &cam::194.229.138.6
      &cam::213.196.2.97
      &cars::12.28.140.20
      &cars::204.107.129.10
      &cars::204.107.129.2
      &cars::204.107.129.3
      &cars::208.179.112.2
      &cars::209.166.167.208
      &cars::63.160.181.10
      &cars::63.160.181.11
      &cash::199.166.24.1
      &cash::205.189.73.10
      &cash::216.13.76.2
      &cash::216.196.51.4
      &casino::199.166.24.1
      &casino::204.57.55.100
      &casino::216.13.76.2
      &cc::206.253.214.11
      &cc::206.253.214.13
      &cc::207.82.50.166
      &cc::212.62.6.38
      &cc::216.32.212.86
      &cc::64.56.164.118
      &cd::128.112.129.15
      &cd::192.36.125.2
      &cd::194.38.74.11
      &cf::193.0.0.193
      &cf::194.206.73.253
      &cf::194.51.3.49
      &cg::128.112.129.15
      &cg::192.36.125.2
      &cg::194.38.74.11
      &cgi::199.166.31.250
      &cgi::199.166.31.3
      &ch::128.112.129.15
      &ch::130.59.1.80
      &ch::130.59.211.10
      &ch::147.28.0.39
      &ch::164.128.36.34
      &ch::192.16.202.11
      &ch::200.16.97.77
      &ch::203.37.255.97
      &chem::12.28.140.20
      &chem::204.107.129.10
      &chem::204.107.129.2
      &chem::204.107.129.3
      &chem::208.179.112.2
      &chem::209.166.167.208
      &chem::63.160.181.10
      &chem::63.160.181.11
      &chick::209.136.161.192
      &chick::63.119.253.254
      &children::12.28.140.20
      &children::204.107.129.10
      &children::204.107.129.2
      &children::204.107.129.3
      &children::208.179.112.2
      &children::209.166.167.208
      &children::63.160.181.10
      &children::63.160.181.11
      &ci::193.50.53.1
      &ci::195.83.14.1
      &ck::130.195.5.12
      &ck::130.195.6.10
      &ck::202.65.32.127
      &ck::202.65.32.128
      &cl::137.39.1.3
      &cl::146.83.4.11
      &cl::192.16.202.11
      &cl::200.27.2.2
      &cm::156.106.192.121
      &cm::193.0.0.193
      &cm::195.24.192.17
      &cm::195.24.192.34
      &cm::195.24.192.35
      &cm::198.6.1.82
      &cn::159.226.1.1
      &cn::202.112.0.44
      &cn::202.97.16.196
      &co::128.122.253.92
      &co::128.59.35.142
      &co::157.253.1.13
      &co::157.253.50.30
      &com::192.36.144.133
      &com::198.17.208.67
      &com::198.41.0.4
      &com::198.41.3.101
      &com::198.41.3.38
      &com::202.153.114.101
      &com::203.181.106.5
      &com::205.188.185.18
      &com::207.200.81.69
      &com::208.206.240.5
      &com::210.132.100.101
      &com::213.177.194.5
      &cool::204.80.101.90
      &cool::204.80.101.94
      &cool::204.80.125.130
      &cool::204.80.125.145
      &corp::12.28.140.20
      &corp::204.107.129.10
      &corp::204.107.129.2
      &corp::204.107.129.3
      &corp::208.179.112.2
      &corp::209.166.167.208
      &corp::63.160.181.10
      &corp::63.160.181.11
      &costarica::12.28.140.20
      &costarica::204.107.129.10
      &costarica::204.107.129.2
      &costarica::204.107.129.3
      &costarica::208.179.112.2
      &costarica::209.166.167.208
      &costarica::63.160.181.10
      &costarica::63.160.181.11
      &coupons::204.80.101.90
      &coupons::204.80.101.94
      &coupons::204.80.125.130
      &coupons::204.80.125.145
      &cr::144.228.254.10
      &cr::144.228.255.10
      &cr::163.178.8.2
      &cr::163.178.88.2
      &cr::206.228.179.10
      &cu::147.28.0.39
      &cu::169.158.128.136
      &cu::193.0.0.193
      &cu::204.59.1.222
      &cu::204.59.144.222
      &cu::204.59.64.222
      &cube::212.162.54.243
      &cube::212.162.54.34
      &cv::192.16.202.11
      &cv::192.36.125.2
      &cv::193.136.192.10
      &cv::193.136.7.17
      &cv::198.6.1.82
      &cx::195.222.235.216
      &cx::195.40.6.20
      &cx::203.132.96.2
      &cx::206.253.214.73
      &cx::209.237.73.73
      &cx::212.49.219.164
      &cx::212.49.219.190
      &cy::192.16.202.11
      &cy::192.35.82.50
      &cy::194.177.210.210
      &cy::194.177.210.211
      &cy::194.42.1.1
      &cy::194.42.6.97
      &cz::137.39.1.3
      &cz::192.16.202.11
      &cz::192.36.125.2
      &cz::192.93.0.4
      &cz::193.85.3.130
      &cz::204.152.184.64
      &dds::192.147.236.1
      &dds::199.166.24.1
      &dds::204.57.55.100
      &dds::204.80.125.130
      &dds::205.189.73.102
      &dds::209.104.33.252
      &dds::209.104.63.252
      &dds::216.13.76.2
      &de::192.36.125.2
      &de::192.76.144.16
      &de::193.0.0.237
      &de::193.141.40.42
      &de::193.171.255.34
      &de::194.246.96.79
      &dir::199.166.24.1
      &dir::216.13.126.116
      &dir::216.13.76.2
      &dj::193.251.143.253
      &dj::194.51.3.49
      &dk::130.225.16.40
      &dk::130.226.1.4
      &dk::192.16.202.11
      &dk::193.163.102.2
      &dk::193.88.44.42
      &dk::194.239.134.84
      &dm::128.8.10.14
      &dm::136.145.1.4
      &dns::199.166.24.1
      &dns::205.189.73.102
      &dns::216.13.76.2
      &do::128.223.32.35
      &do::136.145.1.4
      &do::207.176.16.50
      &doc::212.162.54.243
      &doc::212.162.54.34
      &dot::130.88.146.3
      &dot::209.152.193.4
      &duh::192.147.236.1
      &duh::199.166.24.1
      &duh::207.87.121.66
      &duh::216.13.76.2
      &dz::192.134.0.49
      &dz::193.0.0.193
      &dz::193.194.64.11
      &dz::193.194.81.45
      &earth::199.5.157.2
      &earth::199.5.157.3
      &ec::157.100.1.2
      &ec::157.100.45.2
      &ec::208.184.174.7
      &ec::208.184.25.199
      &ec::210.189.254.50
      &ec::211.169.245.170
      &ec::216.200.119.128
      &edu::128.63.2.53
      &edu::128.8.10.90
      &edu::128.9.0.107
      &edu::192.112.36.4
      &edu::192.203.230.10
      &edu::192.33.4.12
      &edu::192.36.148.17
      &edu::192.5.5.241
      &edu::198.41.0.4
      &edv::212.162.54.243
      &edv::212.162.54.34
      &ee::137.39.1.3
      &ee::192.121.251.13
      &ee::192.16.202.11
      &ee::192.36.125.2
      &ee::193.40.56.245
      &eg::147.28.0.39
      &eg::193.171.255.2
      &eg::193.227.1.1
      &email::165.251.1.2
      &email::165.251.1.239
      &email::165.251.1.3
      &er::140.174.131.100
      &er::204.177.156.38
      &es::128.250.1.21
      &es::130.206.1.2
      &es::137.39.1.3
      &es::192.134.0.49
      &es::192.16.202.11
      &es::192.36.125.2
      &es::192.94.163.152
      &es::193.127.1.11
      &es::194.69.254.1
      &es::194.69.254.2
      &et::196.27.22.43
      &et::204.59.1.222
      &et::204.59.144.222
      &et::204.59.64.222
      &etc::12.28.140.20
      &etc::204.107.129.10
      &etc::204.107.129.2
      &etc::204.107.129.3
      &etc::208.179.112.2
      &etc::209.166.167.208
      &etc::63.160.181.10
      &etc::63.160.181.11
      &event::199.166.31.250
      &event::199.166.31.3
      &ewe::192.147.236.1
      &ewe::192.203.17.71
      &ewe::199.166.24.1
      &ewe::199.184.128.35
      &ewe::205.189.73.102
      &ewe::216.13.76.2
      &family::12.28.140.20
      &family::204.107.129.10
      &family::204.107.129.2
      &family::204.107.129.3
      &family::208.179.112.2
      &family::209.166.167.208
      &family::63.160.181.10
      &family::63.160.181.11
      &faq::192.147.236.1
      &faq::199.166.24.1
      &faq::204.57.55.100
      &faq::204.80.125.130
      &faq::205.189.73.102
      &faq::209.104.33.252
      &faq::209.104.63.252
      &faq::216.13.76.2
      &fi::128.214.4.29
      &fi::137.39.1.3
      &fi::192.16.202.11
      &fi::192.67.14.16
      &fi::193.210.19.19
      &fi::193.66.1.146
      &film::199.166.24.1
      &film::216.13.126.116
      &film::216.13.76.2
      &film::216.86.199.114
      &film::216.86.199.115
      &fj::128.250.1.21
      &fj::128.32.136.12
      &fj::128.32.136.9
      &fj::128.32.206.12
      &fj::128.32.206.9
      &fj::144.120.8.1
      &fj::147.28.0.39
      &fj::198.6.1.65
      &fk::194.119.128.65
      &fk::194.119.128.66
      &florida::199.166.31.250
      &florida::199.166.31.3
      &fm::198.6.1.114
      &fm::204.59.1.222
      &fm::204.59.144.222
      &fm::204.59.64.222
      &fm::206.49.89.2
      &fm::206.49.89.4
      &fo::129.142.7.99
      &fo::195.82.195.99
      &food::12.28.140.20
      &food::204.107.129.10
      &food::204.107.129.2
      &food::204.107.129.3
      &food::208.179.112.2
      &food::209.166.167.208
      &food::63.160.181.10
      &food::63.160.181.11
      &fr::128.105.2.10
      &fr::128.112.129.15
      &fr::192.134.0.49
      &fr::192.16.202.11
      &fr::192.93.0.1
      &fr::192.93.0.4
      &fr::193.51.208.13
      &fr::204.152.184.64
      &fund::199.166.24.1
      &fund::216.13.126.116
      &fund::216.13.76.2
      &funds::199.166.24.1
      &funds::205.189.73.102
      &funds::216.13.76.2
      &ga::193.0.0.193
      &ga::208.148.44.1
      &gallery::192.147.236.1
      &gallery::199.166.24.1
      &gallery::204.57.55.100
      &gallery::204.80.125.130
      &gallery::205.189.73.102
      &gallery::209.104.33.252
      &gallery::209.104.63.252
      &gallery::216.13.76.2
      &games::165.251.1.2
      &games::165.251.1.239
      &games::165.251.1.3
      &gay::207.208.112.3
      &gay::207.208.112.4
      &gb::128.16.5.32
      &gb::128.63.58.18
      &gb::128.86.8.25
      &gb::137.39.1.3
      &gb::192.16.202.11
      &gbr::212.162.54.243
      &gbr::212.162.54.34
      &gd::128.8.10.14
      &gd::136.145.1.4
      &ge::137.39.1.3
      &ge::192.16.202.11
      &ge::192.36.125.2
      &ge::192.93.0.4
      &gf::128.112.129.15
      &gf::193.121.64.5
      &gf::195.6.144.3
      &gg::128.86.1.20
      &gg::154.32.105.34
      &gg::16.1.0.18
      &gg::16.1.0.19
      &gg::193.63.94.20
      &gg::195.226.128.3
      &gg::204.123.2.18
      &gg::212.100.224.90
      &gg::216.110.45.224
      &gh::158.43.128.8
      &gh::158.43.192.7
      &gh::196.3.64.1
      &gh::198.6.1.82
      &gi::194.88.77.1
      &gi::212.78.64.10
      &gl::130.226.1.4
      &gl::137.39.1.3
      &gl::193.0.0.193
      &gl::194.177.224.7
      &gl::194.177.232.3
      &global::205.189.73.10
      &global::216.196.51.4
      &globe::165.251.1.2
      &globe::165.251.1.239
      &globe::165.251.1.3
      &gm::195.225.2.10
      &gm::212.60.69.1
      &gm::63.77.152.177
      &gmbh::192.147.236.1
      &gmbh::199.166.24.1
      &gmbh::204.57.55.100
      &gmbh::204.80.125.130
      &gmbh::205.189.73.102
      &gmbh::209.104.33.252
      &gmbh::209.104.63.252
      &gmbh::216.13.76.2
      &gn::146.231.128.1
      &gn::147.28.0.39
      &gn::192.16.202.11
      &god::205.189.71.10
      &god::205.189.73.123
      &gov::128.63.2.53
      &gov::128.8.10.90
      &gov::128.9.0.107
      &gov::192.112.36.4
      &gov::192.203.230.10
      &gov::192.33.4.12
      &gov::192.36.148.17
      &gov::192.5.5.241
      &gov::198.41.0.4
      &gp::130.59.211.10
      &gp::194.143.196.3
      &gp::194.143.202.202
      &gp::194.179.87.1
      &gp::195.76.178.5
      &gp::213.16.1.106
      &gq::194.51.3.49
      &gq::195.101.152.253
      &gr::137.39.1.3
      &gr::139.91.1.1
      &gr::139.91.151.70
      &gr::139.91.191.3
      &gr::192.16.202.11
      &gr::192.36.125.2
      &gr::195.130.89.210
      &gs::154.32.105.34
      &gs::192.16.202.11
      &gs::193.0.0.193
      &gs::195.153.6.2
      &gs::198.6.1.82
      &gt::168.234.106.2
      &gt::168.234.68.2
      &gt::193.0.0.193
      &gt::205.161.188.3
      &gu::168.123.2.50
      &gu::168.123.4.10
      &gu::193.0.0.193
      &gw::194.65.3.20
      &gw::194.65.3.21
      &gw::194.65.87.2
      &gy::136.145.1.4
      &gy::137.39.1.3
      &gy::193.0.0.193
      &ham::199.166.24.1
      &ham::205.189.73.10
      &ham::216.13.76.2
      &ham::216.196.51.4
      &help::199.166.24.1
      &help::216.13.126.116
      &help::216.13.76.2
      &here::199.166.31.250
      &here::199.166.31.3
      &higgs::204.80.101.90
      &higgs::204.80.101.94
      &higgs::204.80.125.130
      &higgs::204.80.125.145
      &hk::128.103.1.1
      &hk::128.32.136.12
      &hk::128.32.136.9
      &hk::128.32.206.12
      &hk::128.32.206.9
      &hk::137.189.6.1
      &hk::137.189.6.21
      &hm::202.169.102.24
      &hm::204.144.183.78
      &hm::209.54.168.55
      &hn::137.39.1.3
      &hn::192.16.202.11
      &hn::192.36.125.2
      &hn::204.59.144.222
      &hn::206.48.104.142
      &home::199.166.24.1
      &home::205.189.73.10
      &home::216.13.76.2
      &home::216.196.51.4
      &hosts::199.166.31.250
      &hosts::199.166.31.3
      &hotel::199.166.24.1
      &hotel::216.13.126.116
      &hotel::216.13.76.2
      &hr::137.39.1.3
      &hr::161.53.3.7
      &hr::192.16.202.11
      &hr::192.36.125.2
      &hr::193.171.255.2
      &ht::206.152.15.33
      &ht::206.152.15.34
      &hu::137.39.1.3
      &hu::192.36.125.2
      &hu::192.93.0.4
      &hu::193.225.86.1
      &hu::193.6.27.62
      &i::206.25.132.30
      &id::130.179.16.143
      &id::202.12.28.131
      &id::202.152.12.227
      &id::202.155.30.227
      &id::202.159.124.34
      &id::202.46.1.2
      &ie::16.1.0.18
      &ie::16.1.0.19
      &ie::192.111.39.100
      &ie::192.16.202.11
      &ie::192.93.0.4
      &ie::193.1.142.2
      &ie::204.123.2.18
      &ie::212.17.32.2
      &il::128.139.6.1
      &il::132.66.32.10
      &il::147.28.0.39
      &il::193.0.0.193
      &il::206.54.224.1
      &im::193.63.94.25
      &im::194.72.124.1
      &im::194.72.124.2
      &im::194.72.6.51
      &immo::212.162.54.243
      &immo::212.162.54.34
      &in::137.39.1.3
      &in::16.1.0.18
      &in::16.1.0.19
      &in::192.16.202.11
      &in::198.6.1.182
      &in::198.6.1.65
      &in::202.141.150.18
      &in::202.41.110.66
      &in::204.123.2.18
      &inc::165.251.1.2
      &inc::165.251.1.239
      &inc::165.251.1.3
      &ind::12.28.140.20
      &ind::204.107.129.10
      &ind::204.107.129.2
      &ind::204.107.129.3
      &ind::208.179.112.2
      &ind::209.166.167.208
      &ind::63.160.181.10
      &ind::63.160.181.11
      &inmode::212.162.54.243
      &inmode::212.162.54.34
      &int::128.16.5.32
      &int::128.86.1.20
      &int::128.9.128.127
      &int::137.39.1.3
      &int::193.63.94.20
      &intern::212.162.54.243
      &intern::212.162.54.34
      &io::128.250.1.21
      &io::192.16.202.11
      &io::193.0.0.193
      &io::194.205.62.100
      &io::198.6.1.82
      &io::210.141.111.69
      &iq::204.70.128.1
      &iq::207.13.11.2
      &ir::193.171.255.2
      &ir::194.225.70.83
      &ir::198.6.1.82
      &irc::199.166.24.1
      &irc::204.57.55.100
      &irc::216.13.76.2
      &ircd::24.4.49.117
      &ircd::24.4.49.246
      &is::128.121.50.7
      &is::192.16.202.11
      &is::192.36.125.2
      &is::193.4.58.51
      &isp::199.166.24.1
      &isp::216.13.126.116
      &isp::216.13.76.2
      &iss::212.162.54.243
      &iss::212.162.54.34
      &it::131.154.1.3
      &it::151.1.2.1
      &it::192.106.1.31
      &it::192.16.202.11
      &it::193.0.0.193
      &it::193.205.245.5
      &it::194.119.192.34
      &it::38.8.50.2
      &itv::194.6.96.218
      &itv::195.172.127.72
      &java::199.166.31.250
      &java::199.166.31.3
      &je::128.86.1.20
      &je::154.32.105.34
      &je::16.1.0.18
      &je::16.1.0.19
      &je::193.63.94.20
      &je::195.226.128.3
      &je::204.123.2.18
      &je::212.100.224.90
      &je::216.110.45.224
      &jm::144.228.254.10
      &jm::144.228.255.10
      &jm::196.2.1.6
      &jm::200.9.115.2
      &jm::206.228.179.10
      &jo::130.11.48.2
      &jo::130.118.4.2
      &jo::193.0.0.193
      &jo::193.188.66.103
      &jo::193.188.66.2
      &jp::150.100.2.3
      &jp::165.76.0.98
      &jp::202.12.30.131
      &jp::202.232.2.34
      &jp::203.178.136.63
      &jp::61.120.151.100
      &jur::212.162.54.243
      &jur::212.162.54.34
      &k12::12.28.140.20
      &k12::204.107.129.10
      &k12::204.107.129.2
      &k12::204.107.129.3
      &k12::208.179.112.2
      &k12::209.166.167.208
      &k12::63.160.181.10
      &k12::63.160.181.11
      &ke::146.231.128.1
      &ke::147.28.0.39
      &ke::193.0.0.193
      &kg::194.226.128.1
      &kg::195.38.160.36
      &kh::192.82.108.38
      &kh::193.0.0.193
      &kh::199.75.208.10
      &kh::202.12.28.129
      &kh::203.127.100.21
      &ki::147.28.0.39
      &ki::192.189.54.17
      &ki::192.41.192.2
      &kid::212.162.54.243
      &kid::212.162.54.34
      &kids::165.251.1.2
      &kids::165.251.1.239
      &kids::165.251.1.3
      &king::199.166.24.1
      &king::205.189.73.102
      &king::216.13.76.2
      &km::194.51.3.49
      &km::195.101.19.253
      &kn::128.8.10.14
      &kn::136.145.1.4
      &kosher::204.80.101.90
      &kosher::204.80.101.94
      &kosher::204.80.125.130
      &kosher::204.80.125.145
      &kr::134.75.30.1
      &kr::147.47.1.1
      &kr::168.126.63.1
      &kr::193.0.0.193
      &kr::198.41.0.11
      &kr::202.30.50.50
      &kw::161.252.48.140
      &kw::161.252.48.150
      &kw::196.1.69.98
      &ky::209.26.120.2
      &ky::209.26.120.3
      &ky::209.26.120.5
      &ky::216.142.252.199
      &ky::216.142.252.201
      &ky::216.143.27.199
      &kz::193.0.0.193
      &kz::193.124.22.65
      &kz::193.124.83.69
      &kz::194.226.128.1
      &kz::194.87.112.4
      &kz::198.6.1.65
      &kz::212.110.240.65
      &kz::212.13.167.1
      &la::202.160.253.152
      &la::208.184.174.7
      &la::208.184.25.199
      &la::210.189.254.50
      &la::211.169.245.170
      &la::216.200.119.128
      &lab::212.162.54.243
      &lab::212.162.54.34
      &law::165.251.1.2
      &law::165.251.1.239
      &law::165.251.1.3
      &lb::128.196.128.233
      &lb::128.250.1.21
      &lb::146.230.192.18
      &lb::147.28.0.39
      &lb::193.0.0.193
      &lc::128.8.10.14
      &lc::136.145.1.4
      &learn::165.251.1.2
      &learn::165.251.1.239
      &learn::165.251.1.3
      &li::128.112.129.15
      &li::130.59.1.80
      &li::130.59.211.10
      &li::147.28.0.39
      &li::164.128.36.34
      &li::200.16.97.77
      &li::203.37.255.97
      &lib::12.28.140.20
      &lib::204.107.129.10
      &lib::204.107.129.2
      &lib::204.107.129.3
      &lib::208.179.112.2
      &lib::209.166.167.208
      &lib::63.160.181.10
      &lib::63.160.181.11
      &linux::209.136.161.192
      &linux::63.119.253.254
      &list::192.147.236.1
      &list::199.166.24.1
      &list::204.57.55.100
      &list::204.80.125.130
      &list::205.189.73.102
      &list::209.104.33.252
      &list::209.104.63.252
      &list::216.13.76.2
      &lk::128.10.2.5
      &lk::192.16.202.11
      &lk::192.248.1.65
      &llb::192.147.236.1
      &llb::199.166.24.1
      &llb::204.57.55.100
      &llb::204.80.125.130
      &llb::205.189.73.102
      &llb::209.104.33.252
      &llb::209.104.63.252
      &llb::216.13.76.2
      &log::212.162.54.243
      &log::212.162.54.34
      &lr::146.231.128.1
      &lr::147.28.0.39
      &lr::193.0.0.193
      &ls::146.230.192.18
      &ls::146.231.128.1
      &ls::147.28.0.34
      &lt::128.214.4.29
      &lt::137.39.1.3
      &lt::158.38.0.181
      &lt::192.16.202.11
      &lt::192.36.125.2
      &lt::193.219.32.13
      &lu::128.112.129.15
      &lu::130.59.211.10
      &lu::158.64.229.2
      &lu::158.64.229.3
      &lu::192.16.202.11
      &lu::192.36.125.2
      &lu::194.246.96.193
      &lu::204.152.184.64
      &lux::195.206.104.1
      &lux::195.206.104.201
      &lux::195.206.104.211
      &lux::195.206.105.1
      &lux::195.206.105.101
      &lux::195.206.105.102
      &lv::137.39.1.3
      &lv::159.148.108.1
      &lv::159.148.60.2
      &lv::192.36.125.2
      &lv::193.0.0.193
      &ly::195.224.53.80
      &ly::198.6.1.82
      &ma::192.93.0.4
      &ma::193.0.0.193
      &ma::193.51.208.13
      &ma::206.103.26.1
      &ma::212.217.0.1
      &ma::212.217.0.12
      &ma::212.217.1.1
      &mad::209.136.161.192
      &mad::63.119.253.254
      &mag::204.80.101.90
      &mag::204.80.101.94
      &mag::204.80.125.130
      &mag::204.80.125.145
      &mart::199.166.31.250
      &mart::199.166.31.3
      &mbx::199.166.31.250
      &mbx::199.166.31.3
      &mc::193.0.0.193
      &mc::194.51.3.49
      &mc::195.78.6.131
      &md::207.211.220.90
      &md::209.26.120.2
      &md::209.26.120.3
      &md::209.26.120.5
      &md::212.0.205.5
      &med::199.166.24.1
      &med::216.13.126.116
      &med::216.13.76.2
      &medic::12.28.140.20
      &medic::204.107.129.10
      &medic::204.107.129.2
      &medic::204.107.129.3
      &medic::208.179.112.2
      &medic::209.166.167.208
      &medic::63.160.181.10
      &medic::63.160.181.11
      &men::12.28.140.20
      &men::204.107.129.10
      &men::204.107.129.2
      &men::204.107.129.3
      &men::208.179.112.2
      &men::209.166.167.208
      &men::63.160.181.10
      &men::63.160.181.11
      &mg::193.0.0.193
      &mg::194.214.107.1
      &mg::194.214.107.253
      &mg::195.83.14.1
      &mh::204.95.160.2
      &mh::204.95.160.4
      &mib::216.86.199.114
      &mib::216.86.199.115
      &mil::128.63.2.53
      &mil::128.9.0.107
      &mil::192.112.36.4
      &mil::192.203.230.10
      &mil::198.41.0.4
      &mil::199.252.143.234
      &mil::199.252.154.234
      &mil::199.252.155.234
      &mil::199.252.173.234
      &mil::199.252.175.234
      &mil::199.252.180.234
      &mk::130.130.64.1
      &mk::147.28.0.39
      &mk::193.171.255.2
      &mk::193.2.1.66
      &mk::194.149.131.2
      &ml::165.231.1.2
      &ml::165.231.1.3
      &ml::205.177.10.10
      &ml::208.144.230.1
      &ml::208.144.230.2
      &ml::208.144.230.3
      &mm::151.196.69.5
      &mm::204.91.84.216
      &mn::147.28.0.39
      &mn::192.82.108.38
      &mn::193.0.0.193
      &mn::202.131.0.10
      &mnet::208.109.83.110
      &mnet::216.61.39.172
      &mo::137.39.1.3
      &mo::147.8.16.15
      &mo::161.64.3.1
      &mo::161.64.3.2
      &mo::161.64.7.1
      &mo::161.64.7.2
      &mode::212.162.54

    5. Re:A Geek's challenge: by Zeinfeld · · Score: 2
      Thats ~3150 queries per second. I imagine a good chunk of that 8 gigs is ram used to create sockets and threads that do the lookups - I also suspect that is's a heavy SMP machine, each processor with it's own ram. If there were, say, 32 processors, each with 256 megs of ram, and each processor ran (X) threads to handle requests...

      Err no, none of the memory is used for sockets and none for threads.

      DNS is a UDP protocol and there is no good reason to talk TCP to a root name server so those requests would be firewalled off to a different node.

      As a UDP protocol DNS is stateless and there is not a good reason to use threads. Ungranted requests can be cached in the network interface drivers. At least that is the way the servers running BIND function. I have not read the Nominet code but I doubt it is different.

      I don't know why Paul would have so much RAM on his box. The dotcom zone is many gigabytes but the root zone only has 200 records.

      --
      Looking for an Information Security student project suggestion?
      Try http://dotcrimeManifesto.com/
  18. references, bits, and pieces. by Eneff · · Score: 2, Informative

    http://www.cisco.com/public/sw-center/sw_download_ guide/dnsfaq.html gives a list of root servers and their IP Addresses, as well as some good information about the basics of DNS.

    http://www.isi.edu/in-notes/rfc2870.txt talks about the requirements for a root server. From this:

    1.1 The Internet Corporation for Assigned Names and Numbers (ICANN)has become responsible for the operation of the root servers. The ICANN has appointed a Root Server System Advisory Committee (RSSAC) to give technical and operational advice to the ICANN board. The ICANN and the RSSAC look to the IETF to provide engineering standards.

    As such, it looks like ICANN is the only organization that can take responsibility of the system.

    section 2.3 estimates that 2/3rds of the servers could be taken out and functionality would be maintained.

    The Internet Software Consortium runs F on BIND 8.2.3 (Hrmmn... their latest release is 8.3.0 and they've noted that 8.2.5 has a security bug, and the 9 series *is* out and at the 9.2 series, does anyone else find it disconcerting that they run 8.2.3?) Does anyone know of a list of who takes care of these root servers?

    1. Re:references, bits, and pieces. by Eneff · · Score: 1

      I forgot to mention in there... The reason I found F running 8.2.3 disconcerting is that

      A) The group that keeps F is responsible for developing BIND.
      B) this group released 8.3.0 because 8.2.5 had a security bug. F runs 8.2.3

      Does that make more sense?

    2. Re:references, bits, and pieces. by dissy · · Score: 1

      8.2.5 has the bug. The only remote exploits I know of myself were introduced after 8.2.3

      Actually, both 8.1.2 and 8.2.3 are Very stable and secure in the 8 series.

      I personally run 8.1.2 on half of my servers (Slaves) as i dont need the newer features of 8.2 on them.

      8.1.2 is also not effected by the holes introduced in the 8.2.2 series that existed up until i believe 8.2.2p5 (But dont quote me on that patch level)
      8.2.3 was basicly a pollished version of this.

      Any 8.2 released after optentially has bugs still, adn they did not fix them in the 8.2 tree as 9.x was pending so close.

      I have no paid anymind or attention to the 9.x tree at all myself, and wont until it gets a tad more stable.

      Additionally, there are still 4.x versions that are extreamly stable and secure and running over the internets backbones.

      Just because the version is older doesnt mean it automaticly has bugs.
      Some people either know/feel more comfortable with the 4.x zone files than they do with 8.x.
      They should not be forced to upgrade if they dont want to.
      Its the same with 8.x to 9.x.

      Most of the changes are not security or stability anyways, only new features.

      --Jon

    3. Re:references, bits, and pieces. by Anonymous Coward · · Score: 0
      No, this is so wrong...


      Look at http://www.isc.org/products/BIND/bind-security.htm l, especially the table at the bottom of the page. There are plenty of exploits for BIND 8.1.2, various versions of BIND 4 and none for 8.2.3 or later. In particular, no new security problems are known for 8.2.5, in direct contradiction to what you said.


      As for your comment about zone files, BIND 4 zonefiles are compatible with BIND 8, so what's your point? BIND 9, on the other hand, requires a $TTL directive, but other than that is downwards compatible to BIND 8 or BIND 4 zonefiles.

    4. Re:references, bits, and pieces. by Anonymous Coward · · Score: 0
      8.2.5 did not have a security hole.


      f.root-servers.net runs BIND 8.3.0.


      Are you still disconcerted? If so, why?

    5. Re:references, bits, and pieces. by Zeinfeld · · Score: 2
      BIND 9 is nowhere near ready for release on the root server. It is not unusual for production systems to use older, more stable versions of the code.

      It is very likely that the root node would run a stripped version of BIND. This is certainly done on some of the nodes.

      --
      Looking for an Information Security student project suggestion?
      Try http://dotcrimeManifesto.com/
  19. Centralization is *not* the answer. by tshoppa · · Score: 3, Insightful
    My take on the EU's beef:
    The EU believes that because the root servers are not controlled and administered by one central authority, they are unreliable.

    This is true, to an extent. Different and widely spread organizations run the root name servers, using different OS's, hardware configurations, and network connectivity.

    And this is a Good Thing
    Concentrating and centralizing the root name servers would defeat the diversity that now exists. If one goes down, the others pick up the load. If there's a fatal hardware bug in one, it probably won't affect the servers running on different hardware. And, most of all, A single business or management failure will not disrupt root nameservice.

    Whoever in the EU (I suspect it's some ex-communist beaurocrat who loves centralized authority) thinks that things are bad now should read the RFC 2870, Root Name Server Operational Requirements and get a clue.

  20. Sigh.... by madenosine · · Score: 1
    Yet another reason to support OpenNIC

    For those who do not know what OpenNIC is, here is their description:

    The OpenNIC is a user owned and controlled Network Information Center offering a democratic, non-national, alternative to the traditional Top-Level Domain registries.

    Users of the OpenNIC DNS servers, in addition to resolving host names in the Legacy U.S. Government DNS, can resolve host names in the OpenNIC operated namespaces as well as in the namespaces with which we have peering agreements (at this time those are AlterNIC and The Pacific Root).

    Membership in the OpenNIC is open to every user of the Internet. All decisions are made either by a democratically elected administrator or through a direct ballot of the interested members and all decisions, regardless of how they are made, within OpenNIC are appealable to a vote of the general membership.
  21. It has already happened! by Anonymous Coward · · Score: 0

    One employee made a mistake on one hard disk, this got propagated to all the others... oops! The DNS was hurt for several hours.

  22. Bring back IANA... by Codifex+Maximus · · Score: 2

    Joh Postel was the man. Why not vote for another pontificate?

    --
    Codifex Maximus ~ In search of... a shorter sig.
  23. What a joke... by Rev.LoveJoy · · Score: 3, Interesting
    So a couple years ago Jon Postel (RIP) can rediredct all authoritative root server queries to his lab PC and the internet is no worse for the ware, but ICANN, with substantially more resources, redundant locations and dozens of authoritative root server, cannot guarantee that some subset of them will always been online?

    Huh?

    What did I miss? We all have to meet requirements, whether your a 5 nines shop (god help you) or not with respect to uptime and service availability. Why should ICANN be any different?

    Cheers,
    -- RLJ

  24. Dummy by Anonymous Coward · · Score: 0

    If you were serious about the challenge, you would have included a link to the F server. Nobody is going to go to the trouble of looking up the address themselves.

    1. Re:Dummy by SevenTowers · · Score: 2

      very well, the address is F.root-servers.net and I'm serious, check it!

      --
      Imperium et libertas
      Autocracy and freedom
  25. Do you understand what root means? by MemeRot · · Score: 3

    The root servers are what makes a sea of unconnected networks into the apparently seamless internet. What you are suggesting would fragment the internet back into separate networks. Typing slashdot.org in europe could go to their 'root' servers and be directed to whoever their root says owns that domain. While typing the same address elsewhere in the world would take you to a different site.

    Pretty big change. There have been companies that set up new top level extensions (impatient with ICANN and who can blame them) and sell those addresses, but for visitors to get to those sites the visitors need to have the dns settings in their computer modified. And if ICANN eventually rolls out the new extension (and I think there is one extension that this applies to, can anyone remember? biz maybe?) you could then have two company.biz sites, and which one the browser goes to depends on which root it's querying. Man, what a mess.

    1. Re:Do you understand what root means? by hogsback · · Score: 1

      The root nameservers mirror between each other, right?

      What does it matter if some DNS servers think there are 13 root nameservers and some think there are 14? This isn't fragmenting anything - just that some of the servers the next level down have more choices than others.

      company.biz will always be the same, because all 14 root nameservers have the same information.

    2. Re:Do you understand what root means? by RedHat+Rocky · · Score: 1

      All DNS does is translate human friendly names to IP addresses. If the root servers died tomorrow, hitting slashdot's IP address would still work.

      Granted, you'd have a tough time finding the IP if the roots were really done, but the failure of DNS has nothing to do with how the "networks" talk to each other.

      What you're really talking about is the unified domain name space, having most of the users of the Net being able to resolve names certainly does keep the Net moving.

      However, the ICANN roots (and their name space) are not the only ones in town. There are currently several different groups of alternate Network Information Centers (NICs) such as OpenNIC. Using them is fairly trival for any admin; if enough of us start using them, ICANN no longer has power.

      Individual users don't need to modify their DNS setups, they should be pointing to their ISP's name servers anyway; saves both bandwidth and lookups.

      --
      Anything is possible given time and money.
    3. Re:Do you understand what root means? by huskymo · · Score: 2, Informative

      The problem is that 13 is a magic number in DNS. The maximum size of a DNS message when carried over UDP is 512 bytes. And guess how many NS records and associated A records you can fit in 512 bytes, assuming domain name compression is working as efficiently as possible? Thirteen.

      If you add more root name servers, when name servers look up the list of root name servers (via something called a system query) you truncate the DNS message, and then those name servers retry over TCP and all hell breaks loose.

      That said, two of the existing roots (j and l) are temporarily housed at ISI and VeriSign, which already have roots. Those two really need to be deployed to parts of the Internet that need them.

  26. This seems like a mute point by Geekboy(Wizard) · · Score: 1

    ICANN has already specified this, in RFC-2870. [http://www.isi.edu/in-notes/rfc2870.txt]

    /quote/
    2.3 At any time, each server MUST be able to handle a load of requests for root data which is three times the measured peak of such requests on the most loaded server in then current normal conditions. This is usually expressed in requests per second. This is intended to ensure continued operation of root services should two thirds of the servers be taken out of whether by intent, accident, or malice.
    /quote/


    I think that is the guarentee.

  27. Some points to think about by cluge · · Score: 3, Interesting
    Most people realize that the root servers can be taken down. There have been several articles about this very concept (see http://www.theregister.co.uk/content/archive/22851 .html for example).


    Given the nature of how DNS works, and how the root servers are run, how can ICANN guarantee anything? (it can't) If they do provide some sort of guarantee then haven't they added a financial incentive for someone to DOS the root servers?


    The Europeans are asking for something that cannot be delivered (currently), and if they get it the chances increase that someone will DOS the servers for some financial gain. (i.e. your server went down, I now don't have to pay you x dollars). If I was ICANN I wouldn't want to sign an agreement. It may be time for ICANN to change the way it does business, and the "ad hoc" nature that the root servers are maintained may have to change. DNS the protocol itself needs to be very carefully looked at as well.

    --
    "Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
    1. Re:Some points to think about by Anonymous Coward · · Score: 0

      I think it's time for ICANN to quietly pack its bags and get out of the Internet control business. It hasn't done a damn thing right yet. It's just a bunch of corporate assholes trying to exercise control over the net in favor of big business. They don't have a clue what they're talking about most of the time, and when they do, they lie through their teeth anyway. We don't need another big unaccountable organization in this world. ICANN needs to go away.

  28. maybe ... by Rev.LoveJoy · · Score: 2
    The next IIS worm can just be coded to update everybody's root.hints file?

    Kidding ... sorry. :-)
    -- RLJ

  29. The root servers should be a co-op by Animats · · Score: 2

    The root servers should be owned by a formal co-op, owned collectively by everyone who has a domain name registered, and run by an elected board with a hired staff. This would be a "producer co-op", like Agway, the giant co-op for farmers, rather than the more common consumer co-op. This would bring together the interests of the people who need the root servers to stay up, the domain owners, and the ownership of them.

    1. Re:The root servers should be a co-op by Anonymous Coward · · Score: 0

      Interesting a producer co-op - I think that be a co-op of the registry operators.

      every one with a domain name would be more akin to a consumer co-op

  30. Re:I'm an alcoholic oh yes i am by Anonymous Coward · · Score: 0
    Oh, I forgot one thing.

    Beautiful Mind wasn't boring.

  31. Socialised root servers? by Anonymous Coward · · Score: 0
    I know the Americans will run away screaming when socialism is mentioned, but why not let the users own the root servers (=means of production)?

    No governments and most definitely not corporations. Just users.

    1. Re:Socialised root servers? by ghurtado · · Score: 1

      That would definetly be a way to go.

      Add 'no corporations nor governments' to your statement, and you have me %50 sold, just dont call them 'socialist' servers, there are people whose support would be needed in this idea, who, like you mention, think that socialism = comunism = red = bad, long bearded dude who smokes stinking cigars

      Snap out of it people, its time to wake up

    2. Re:Socialised root servers? by freeweed · · Score: 2
      Add 'no corporations nor governments' to your statement, and you have me %50 sold

      Ah, so you want to exclude this new system from controlling .com and .gov? :)

      --
      Endless arguments over trivial contradictions in books written by ignorant savages to explain thunder in the dark.
  32. RFC on Root Servers by Emugamer · · Score: 1
  33. Future world government by Anonymous Coward · · Score: 0
    I wonder why the world conspiracy lunatics always blame UN for having ambitions for a world government.

    It's pretty clear to me that if there's going to be a world government (dictatorship) after the fall of the Soviet Union it's going to be a financial entity. It's either the IMF (just look what they did to Argentina who refused their "advice") or WTO.

    I guess it's too hard to see that unlimited private ownership is just as bad as unlimited public ownership when you've been conditioned to believe that anything non-capitalistic is evil.

  34. So... by 3Suns · · Score: 1

    Are ICANN and ICAAN interchangable now?

    ICANN do no wrong.

    --

    -3Suns

    ~~~~
    The Revolution will be Slashdotted
  35. Potential profit here ... by zangdesign · · Score: 2, Insightful

    Charge for a subscription to a root DNS server. One can make money off both ends: charge the domain name holder for the reservation on your server, AND charge the end user a yearly or a per use fee for DNS resolution. The latter requires some form of micropayment, but it's probably quite workable.

    The benefit to the end user is that one could subscribe to a completely Disne-fied root that would have only family-friendly sites, whereas another server would have all those wacky pr0n sites you could ask for. Somebody would probably even have a free root server out there based on his/her special interest groups.

    Heck, you could even charge for translating addresses to other systems. No need to worry about foreign DNS servers - if they don't pay up, they don't get access to your root.

    Some people would still get around the whole thing by just typing in the octet directly, but that would be such a small percentage that it wouldn't even matter.

    --
    To celebrate the occasion of my 1000th post, I will post no more forever on Slashdot. Goodbye.
  36. Once every 3 hours, I think by horza · · Score: 2

    Looking at my DNS config files, it looks like each domain can set it's own TTL (Time To Live) duration for its current settings before it needs refreshing. The default setting is 3 hours, which is what I presume everyone normally leaves it at.

    Phillip.

    1. Re:Once every 3 hours, I think by PapaZit · · Score: 3, Interesting

      At the few places I've worked, the policy's always been that TTL = expected worst-case response time from the networking group plus a fudge factor.

      So, if DNS goes down at 10:00pm on a Friday, people (who have the addresses cached) can still get to the machines until the hung-over networking crew logs in to check things out the next morning.

      They'd bump the TTL way down, on the other hand, when major machine moves were planned.

      --
      Forward, retransmit, or republish anything I say here. Just don't misquote me.
  37. Too close for comfort by Orange+Amphibian · · Score: 1

    Does anyone else see a striking similarity between the ICANN and Windows logos? Also the name, "I can", after Gates was supposedly denied the ability to buy the internet just works my paranoia nerve.

  38. Bah. by KupekKupoppo · · Score: 1

    ICAAN is unABEL to guarantee server stability.

    When asked for comment, a representative stated, "What? Am I my server's keeper?"

    (note misspelling of ICANN in the article)

  39. Always puzzled me. by haplo21112 · · Score: 2

    Thats one that has always puzzled me? root.hints contains the list of root servers. and it doesn't have through Z in the current naming convention, so why can't be have more root servers. I mean esspecially with the price of hardware, and such being what it is, it shouldn't be that hard to set up additonal root servers. I mean if the DNS howtos of the world just included a line like, "Your root.hints now includes the ICANN servers, add these additional listings for the other servers"? I partially agree that there does need to be a central authority for all this, but I do think ICANN is handling it in the best way. There is a need for some control so that two people don't try to register the same name with different authorities, and create a conflict. However, I also think its should be a case of first come first serve on getting the names, and the trademark game should not be a consideration.
    But I could be completely wrong because I so think, that DNS records should also include rudimentry routing info that helps the rest of the world find that last hop to my network since my ISP will not route for me. And I also think that DNS should have the ability to have a PORT record so when doing a DNS lookup the person looking me up can be directed to service ports within my IP so www.foo.com can live on port 8090 for instance because cable modem companies sometimes block port 80. That way when www.foo.com gets looked up the client not only gets the IP, but the port on the server to connect too, so users don't have to have stupid IPs like http://www.foo.com:8090, DNS takes care of passing the 8090 as part of the lookup reply.
    I am working on the RFC for this since there doesn't seem to be one.

    --
    Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
    1. Re:Always puzzled me. by arkanes · · Score: 2

      Uh, your post shows that you don't know the difference between the internet and the WWW. Not everything runs on port 80. Domain names have nothing to do with ports. Your domain name points you to an IP, which identifies your machine. You then connect to a port on that machine. The port you connect to is either a) identified by convention, such as port 80 = http. If the server is running a server on non-standard ports, it is the responsibility of the server to redirect clients to the correct port.

    2. Re:Always puzzled me. by Anonymous Coward · · Score: 0

      DNS queries are usually done on UDP port 53. Being USP is connectionless there is only so much room avaliable in a packet, i.e. only 13 names and their IPs can fit.

    3. Re:Always puzzled me. by dissy · · Score: 1

      Actually there are bind records to do everything you say you cant find RFCs on.

      Check out O'Reillys DNS and BIND 2nd addition under the 'Misc' chapter on Additional Resource Records.

      As i dont have a copy of the book in front of me to quote from.

      I believe the first (of many) RFCs on the additional resource records is RFC 1183

      There is an ISDN record i believed designed for (as they call it ISDN networks) but contains ISDN numbers for peer to peer routing.
      IE, the route ends at ISDN number xxxxxxx so if you cant reach that node over the internet, dial it up yourself!
      It has other info in it but i cant remember how things worked.

      There is also an X25 record for that type of network too (which i know nothing about)

      There is an RT record that is similar to MX
      Where MX routes mail to a host, RT routes packets to a host.

      RT lets you not only route packets on a per packet data level, but lets you assign priortiys like MX uses so you can have a packet go to say a different tftp server if the main is down!

      This way you can do priority routing 100% in DNS over static IP routes.

      RT and ISDN (and X25) all were suppost to work together to do what you are desiring.

      Bind 8 as far as i know fully supports these records (Atleast from 8.1.2)

      The problem is most clients dont honour them at all.

      The DNS and BIND book is a Great read on this subject, and I would highly suggest reading that chapter fully before you start work on an already thought-of,completed,and implimented RFC :)

      --Jon

      --Jon

    4. Re:Always puzzled me. by haplo21112 · · Score: 2

      Actually I do, I was using port 80 as an example of what i was talking about....

      Perhaps a closer read the next time, instead of just skimming for flamebait.

      To reiterate and expand...If a user such as one on a cable modem wants to have to have a WEB site, and the ISP blocks the Port 80, if DNS had the ability to pass port information with the DNS reply then the user could have www.foo.com, as the URL leading to the site instead of having www.foo.com:8090.

      Another example, I have one IP I want two sites, but they live on different boxes. The same rational applies, one could live directly on 80, and with DNS carrying the Port # the the other could live on 8090, and they can both have simple names www.foo.com, www.bar.com,(I am actually running into this problem now, as I have a domain already, and my girlfriend would like to have one as well)

      I am the DNS admin more several Internet domains, and have been for 5+ years in a professional capacity. I have been on the internet in one cpacity or another for 10+ years. I remember a time before the web didn't even exist.

      --
      Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
    5. Re:Always puzzled me. by haplo21112 · · Score: 2

      Thanks I will check into that, I think i looked into those before, but that was a while back when i was first learning the DNS admin job, and lets face it for the ordinary everyday tasks the zone file doesn't get that complicated, so those sorts of things slip your mind...but at least it was a rational response, with useful information rare around here.

      --
      Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
    6. Re:Always puzzled me. by karl.auerbach · · Score: 2, Informative

      The reason why there are only 12 or 13 root servers is based on several factors.

      The most basic factor is that the DNS specification imposes an obsolete 512 byte limit on the size of UDP DNS packets. (DNS can run on TCP but the overhead is much higher than with UDP.

      Since reply packets often contain many resource records, and DNS names can be up to 255 bytes each, you can see that one can brew up server names that would strongly press that 512 byte limit even with two servers. Fortunately, server names are usually not all that long.

      DNS name compression comes into play to help, and that situation has improved since most root servers now support root-servers.net as the right hand part of their names.

      Internationalization of domain names under the ACE rules coming out of the IETF will work the other way - internationalized server names will tend to be longer than than the a.root-servers.net form that we see today.

      Now, just because we see one NS record in a list of servers doesn't mean that there is only one computer there - or even that it is in one place. Many servers are actually clusters that are hiding behind load balancers.

      And with IP "anycast" technology (essentially a way of establishing multiple instances of the same address block by using localized more specific route announcements) we can have as many servers as we want at the same apparent address but located in widely scattered locations around the world. The .biz servers are, I believe, handled this way.

      Oh, by-the-way, don't fall into the belief that the names/addresses listed in the "hints" file are the root - those addresses merely serve as a way to find a single root server. That server, in turn, will provide the actual set of root servers. That's why the hints file is called "hints" - it's just there to get the ball rolling.

    7. Re:Always puzzled me. by dissy · · Score: 2, Informative

      Just got ahold of my copy of the book.
      I was half mistaken.

      RT is not the record of interest for ports, SRV is.
      This is from chapter 15.7.6

      Quoting the book (and all credits due)
      ~~~~~

      The experimental SRV record, introduced in RFC 2052, is a general mechanism for locating services. SRV also provides powerful features that allow domain administrators to distribute load and provide backup services, similar to the MX record.

      A unique aspect of the SRV record is the format of the domain name it's attached to. Like service-specific aliases, the domain name to which an SRV record is attached gives the name of the service sought, as well as the protocol it runs over, concatenated with a domain name. So, for example:
      ftp.tcp.movie.edu
      would represent the SRV records someone ftping to movie.edu should retrieve in order to find the movie.edu FTP servers, while:
      http.tcp.www.movie.edu
      represents the SRV records someone accessing the URL http://www.movie.edu/ should look up in order to find the www.movie.edu web servers.
      ~~~~~~~~~~~

      Hope this helps

    8. Re:Always puzzled me. by Eristone · · Score: 1

      Umm.. why would you do this when you could let your web server figure out which website the person is trying to reach via host header? You sure you aren't trolling?

      -- Eristone

    9. Re:Always puzzled me. by arkanes · · Score: 2
      I agree with Eristone, I'm afraid. If you can't figure out how to do port forwarding for subdomains and virtual hosting...

      I'm still wondering what ports have to do with DNS, and why you'd want port information attached to your DNS if you're running more than one service. Even assuming that this wasn't doable in other ways that didn't require major changes to DNS, 99% of the time services will be running on thier standard ports on legit servers any. (BTW, your ISP blocks port 80 cause running servers is against the AUP. That means it's not a legit server)

    10. Re:Always puzzled me. by Zeinfeld · · Score: 2
      And I also think that DNS should have the ability to have a PORT record so when doing a DNS lookup the person looking me up can be directed to service ports within my IP so www.foo.com can live on port 8090 for instance because cable modem companies sometimes block port 80.

      Been there, done that. It is called the SRV record and it works in the same way as the email MX record.

      Not supported inany of the browsers yet, but is used extensively in W2K for other purposes.

      --
      Looking for an Information Security student project suggestion?
      Try http://dotcrimeManifesto.com/
    11. Re:Always puzzled me. by huskymo · · Score: 2, Informative

      There's no reason we have to use whichever ACE becomes the standard in the domain names of root name servers. We sacrificed the old domain names of the root name servers (e.g., ns.nasa.gov) to the greater good of better domain name compression years ago.

      The countervailing force is EDNS0, which will allow 4096 byte UDP-based DNS messages. And BIND 8.3.0, recently released, supports EDNS0. f's already running it. Once 8.3.0 is fully deployed on the roots, I think additional root name servers are just a quick hack away:

      - System query without EDNS0: You get 13 root name servers
      - System query with EDNS0: You get more

    12. Re:Always puzzled me. by Anonymous Coward · · Score: 0

      Ok, I admit my complete ignorance of the full DNS protocal, but if the UDP packet size of 512 octets limits DNS to returning 13 root servers, why does it have to give out the *SAME* 13 on every reply. Create 26 and choose at ramdom 13 of those 26 for each reply packet. As long as the 26 have the same information it shouldn't matter.

    13. Re:Always puzzled me. by haplo21112 · · Score: 1

      Once again...1 IP at the router, multipule boxes behind the router which both want to provide Web services...its a classic problem with DSL and Cable lines.
      I don't want to have either box dependant on the other. The Router doing the NAT is say a Linksys Box....it doesn't know from host headers, it can't read host headers and redirect, so the only way to send traffic to the box not on 80 is to know the right port, which make for ugly URL's. Of course I know there are other better ways, if you used a real box as the router and had apache proxy the connections read the host headers and redirect, but I am trying to solve the problem for some of my customers, who don't want this level of complication.

      Why is it people always have to look at the complicated side of the problem and try to make things fit the complicated solution...its a simple answer...that most people are searching for, I can certainly give them the complicated answer, but generally with that level of complication and upkeep they will walk on the whole project.

      I am a geek who is actually trying to give non geeks easy answers.

      --
      Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
    14. Re:Always puzzled me. by haplo21112 · · Score: 2

      OK, I CAN do all that, but I am trying to solve problems for average users...I know geeks trying to help non-geeks is generally frowned upon, but sue me I have a big heart and want to help them get solutions. See the answer above for yet another expanded description of what I am attempting to do for these people.

      BTW, I don't believe that ISP's should be able to limit what you do with the Bandwidth, call my desire to help people who have their port 80 blocked civil disobidiance...

      I am with this conversation because obviously you people have so limited a view of things that you can't open your minds enough to understand what it is that I am trying to accomplish.

      --
      Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
    15. Re:Always puzzled me. by haplo21112 · · Score: 2

      Which is sort of the point I was trying to make origially, because SRV records aren't fully supported. There needs to be an agreement on making something of this sort happen that will allow all clients and servers to respect the information coming back....

      --
      Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
    16. Re:Always puzzled me. by arkanes · · Score: 2

      Call me wacky, but I just don't think that DNS (a way of identifying a machine) is the proper place to be showing ports (a way of identifying a process). For what it's worth, theres at least one company that provides everything you want to do in an easy-to-use solution for home users, without needing changes to the DNS system (yeah, watch that happen).

  40. I can't wait! by Mustang+Matt · · Score: 2

    If China sets up it's own root servers, I'll be the first to have my mail server do a lookup to see if the root server of the sender exists in China to block access.

    That will give me about 95% more bandwidth.

    --
    The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
  41. ICANN's problem is... by HardCase · · Score: 2
    ...that it's a bureaucracy looking for a purpose.


    I know, I know, what a troll...but sometimes I get so fed up...


    -h-

  42. here's a thought... by Anonymous Coward · · Score: 0
  43. Wildly inaccurate by Farce+Pest · · Score: 2, Informative
    The computer of someone searching for www.bbc.co.uk for the first time would consult the closest root server and would find out that Nominet handles the database of net domains ending .uk.

    The root server then would pass on the net address of Nominet to allow the searching machine to find the exact web address of the BBC website.

    This is totally inaccurate. If you are searching for www.bbc.co.uk, your computer asks the local DNS cache (listed in /etc/resolv.conf, unless you have some retard OS). That cache then asks a root server for www.bbc.co.uk (if that information has not already been cached). This produces a referral to the .uk nameservers. The process continues for co.uk and bbc.co.uk as necessary. Note that it does not ask the closest root server, because the cache has no way to know what this is. BIND uses the "fastest" server (until it overloads from all the other BIND servers using this strategy); djbdns's dnscache picks one at random.

    One way to avoid delays at the root servers is to run your own local root server, and periodically download the root zone. This shows you how to do it using the ORSC root zone, but you can do it with the standard root as well. You can AXFR it from one of the root servers. Then you tell your local cache to use your local root as the root server.

    --
    This message has been scanned for memes and dangerous content by MindScanner, and is believed to be unclean.
    1. Re:Wildly inaccurate by Anonymous Coward · · Score: 0
      BIND uses the "fastest" server (until it overloads from all the other BIND servers using this strategy)

      In which case, the load is balanced fairly equally across all of the root servers. Is this a problem?
      djbdns's dnscache picks one at random

      Now, that is a problem! It can lead to heavy "spiking" of one root server or another. Yet again, djbdns implements a "feature" that looks good on paper but doesn't work out very well in practice. Thank goodness the vast majority of sane DNS admins still run BIND...
  44. No, things have changed. by Erris · · Score: 2
    A couple of years ago certian destabilizing influences were not on the net. Today, the net is littered with cracked coppies of win2k on cable modems, not to mention serving "the enterprise" whatever that is. The venerability demonstrated by all those crippled machines did start to desabilize routers all around the world. You did not miss all the fun, did you?

    Unless people get smart and dump M$, it's hard for anyone to gaurantee any service. It's kind of like planning to meet someone on Burbon Street for Mardi Grass, your voice will be lost in the noise. All the resources in the world won't protect you from irresponsible net usage.

    By the way, 13 is 1.08333... dozen.

    --
    DMCA, Hollings, Palladium. What might have sounded like paranoia is now common sense.
    1. Re:No, things have changed. by Anonymous Coward · · Score: 0
      The venerability demonstrated by all those crippled machines did start to desabilize routers all around the world.

      Maybe you mean 'vulnerbility'? 'Venerability' means something totally different, look it up.

  45. My suggestions regarding DNS stability/security... by karl.auerbach · · Score: 2, Interesting

    I wrote a document about some simple steps that could be taken to improve DNS security before ICANN's meeting last November.


    http://www.cavebear.com/rw/steps-to-protect-dns. ht m

    Don't let the fact of 12 or 13 servers lul one into a sense of security - they are all fed data from the same source, and if that source is corrupted, then all the root servers will be corrupted. And that's not a hypothetical - the entire .com top level domain disappeared for a few hours in 2000. (Most people didn't notice this because of the damping provided by DNS caching, but it would have become really bad had the situation continued for a few more hours.)

    Also, because all of the root servers run a nearly common code base, they are potentially vulnerable to a common weakness.

    In addition, one need not bring down a server to take it off-line, an attacker need merely saturate the network in the vicinity of a target server so that no good traffic can get through. An even scarier notion is that of corruption of Internet routing so that packets flowing to DNS server addresses are forwarded out router interface null0.

  46. Hit em where it hurts by fire-eyes · · Score: 1

    If ICANN won't listen to those its servicing, then hit em where it hurts. Hit em in the wallet. They'll suddenly find solutions, and FAST.

    GO FOR IT.

    --
    -- Note: If you don't agree with me, don't bother replying. I won't read it.
  47. Nominet, DENIC et.al. shouldn't complain by new500 · · Score: 3, Informative

    . .

    If I read this correctly, the reason why the EU local registries don't have their own root servers, and hence control over service levels is a historical issue.



    Excerpting from the Internet Software Consortium's page, linked above - and please allow me to state that such a reference is anecdotal rather than given fact,

    We then discussed potential candidates and found no volunteers in the AsiaPacific region, none in Africa and only one in Europe.


    The "one in Europe" btw was NOT Nominet or another registrar, it was a guy working for LINX, the London INternet eXchange.

    There's good reason for this, as late as the early 1990s, Europe was still thinking that X.500 was the way forward, and a large amount of resources from universities, telcos and local standards agencies was devoted to "interoperability" testing of X.500 directory services. What really happened was the standards lagged the implementations so badly that vendors and implementors went ahead and did their own thing, creating, as anyone who has dealt with X.500, a nightmare for inter -vendor interoperability. That created the space in which the InterNet and DNS / BIND could flourish. FWIW, LDAP is a (nor precisely, so please don't flame me, too large a subject for absolute accuracy here) derivative of X.400, itself a cut down form of X.500. Novell's eDirectory, which runs some of the largest sites (CNN.com, AOL messenger services) is itself a souped up LDAP implementation.


    You can find a brief overview of X.500 and what the "authorities" in Europe were up to as late as 1990 and beyond in this history of X.500


    I'm British born myself, but this all seems to me to be Euro - Whining. Particularly the UK's Nominet making an issue of this is absolutely BS. Nominet has, IMO, very sharp practises. If you "buy" a domain in the UK (domain.co.uk) via an ISP, Nominet maintains a "tag" linking your domain to the "provding" ISP, until another ISP takes it over. Domains _never_ go back into circulation when they expire. Nominet refuses, on the whole, unless you threaten or cajoule them with considerable effort, to "release" your domain because it states it will not get involved in contractual disputes between you and your ISP. Most UK ISPs make contracts which lock you in to your services and charge a considerable and hefty severance fee, usually buried in the small print. You _can_ get a "Neutral Tag" applied to a UK domain, if you pay GBP £80 for two years, which fee goes back to the ISPs who are members of Nominet, which is a for profit company, limited by guarantee, a rare form of UK company which offers very lax statutory reporting. Even though you _can_ do all this, I've had several clients now who've complained to Nominet, e.g. when their ISP is TU and no longer provides service, and Nominet tells them anyway that they can only deal with an ISP who is a member of Nominet. Obviously that's BS. But you can't register a domain in the UK for .co.uk and run your own DNS and maintain it under your own authority without a *lot* of expensive hassle, and possibly an attoney. You could hire me, of course, but this kind of work sucks, so I wouldn't offer it generally.


    Sorry for that rant against Nominet, but it's Crocodile Tears time again and minus several million points for the Brits, as per usual.

    Please follow the links above, investigate yourself . . .

    1. Re:Nominet, DENIC et.al. shouldn't complain by Anonymous Coward · · Score: 0


      na

      ist just ICAN'T getting hoist by its own petard, they force other people to have contracts (and spend a lot of cash with lawyers) with them.

      They dont like having to do the same them seleves

    2. Re:Nominet, DENIC et.al. shouldn't complain by Simon+Brooke · · Score: 2
      Nominet has, IMO, very sharp practises. If you "buy" a domain in the UK (domain.co.uk) via an ISP, Nominet maintains a "tag" linking your domain to the "provding" ISP, until another ISP takes it over.

      Oh, for heaven's sake!

      Anyone can be a Nominet tag holder. I'm a tag holder myself. You don't have to be an ISP. You don't have to run your own DNS. If you want complete control over your domain, just register your own tag.

      --
      I'm old enough to remember when discussions on Slashdot were well informed.
  48. To Put This In Context by Anonymous Coward · · Score: 0

    Hey folks, as much as we might deplore ICANN's anti-majoritarian ways, remember that any attempt to homogenize the root servers ultimately works against the cause of Open Source -- ISC, which gives so much to Open Source, has limited resources to run f.root-servers.net and probably wouldn't be able to meet the uptime standards of Nominet or whoever is whining about this. So show some solidarity and tell Nominet to go to hell. We can fix ICANN later, hopefully...

  49. Nerds of all the planet-please shut up a sec. by ThufirHawat · · Score: 1

    Nope, the issue is not a technical one, it's political-rather ethnocentrical. Why should a silly corporation, incorporated in the State of California, and reporting essentially only to the US Department of Commerce, run alone the root servers for the whole planet Earth? I understand that many Americans find difficult to believe that there are those who, without being terrorists, believe the US has no valid claim to being the world's policeman (quite the contrary, the USA violate systematically international law, treaties they have signed, elementary rules, and now even the Geneva convention). So please get ICANN out of the US DoC claws, that's what this is all about. And stop stonewalling (one of the standard US foreign policy techniques, besides the subtle tanks and warplanes...)

    --
    Thufir Hawat
    Part-time Mentat
    1. Re:Nerds of all the planet-please shut up a sec. by NDPTAL85 · · Score: 0

      Shut up Mentat :P

      --
      Mac OS X and Windows XP working side by side to fight back the night.
  50. Some issues by Zeinfeld · · Score: 4, Insightful
    The point that folk seem to miss is that the root name server IP addresses are hard coded into the infrastructure. To change the root servers you have to either wait for everyone to redeploy BIND or get an address reassigned somehow. There is a hard limit of 13 servers that is set by the length of an ethernet packet, the size of the records and the need to guarantee that the packets don't fragment.

    Reassigning a root server address is hard because the operator likely has other machines in the address block whose numbers would also have to change.

    The EU concern is not irrational, it is pretty wierd that the root zone is essentially a volunteer effort given that the costs are not negligible and the responsibility immense.

    Against this however there is a major political issue at stake. The root operators are in effect the arbiters of the DNS. If ICANN gets too big for its boots they are a check on it.

    The other issue is that there are very few companies that could credibly manage the root zone on a contractual basis. It is one thing to run a server on a volunteer basis, quite another to provide a service guarantee.

    One thing that is in the pipe that may well change some of the concerns, in particular anycast addressing which allows multiple servers to sit on the same IP address. The packets are routed to the 'nearest' machine. That will allow the deploment of additional root servers. It will also address some of the denial of service concerns.

    --
    Looking for an Information Security student project suggestion?
    Try http://dotcrimeManifesto.com/
    1. Re:Some issues by Fastolfe · · Score: 1

      The IP's of the root servers are usually only "hard-coded" as "hints" for the resolver. All it needs is 1 hit on any of those hints and it will be able to obtain an "authoritative" list of those servers responsible for the root zone. Generally, those hints are then updated with that information. So unless all of the root servers get renumbered in a short period of time, there isn't much to worry about here.

      You have some valid points, but renumbering a root server isn't so bad. You just don't want to do it too often.

    2. Re:Some issues by ebonkyre · · Score: 1
      >The point that folk seem to miss is that the root name server IP addresses are hard coded into the infrastructure.

      WTF? The root server addresses are in a config (or "hints") file every time I've set up BIND... and seeing as how the last time was about a week ago, I feel pretty safe in saying that is the current state of things.

      Maybe you have a different definition of "hard-coded"?

      Also, every set of docs I've ever seen recommend updating your servers root hints file periodically, for precisely this reason (keeping aware of changes in the root servers).

      --
      "Time is an abstract concept devised by carbon-based lifeforms to monitor their ongoing decay." - Thundercleese
  51. Re:Let's riot! by CuCullin · · Score: 1

    Well, think of this.... when did Jesus say that we had to go to church, or drinking in moderation is bad, or any of the other crap that gets thrown around? I'm not one of those who lives blindly by faith, but I do believe, and I don't need to go to church to do it. I don't need to listen to Christian rock or hymns to be a good christian... that might make me a good catholic, but sort of like the pants and jeans thing, I can still be a good Christian. So, in short, don't get upset over the stupid. Do what we all should be doing.... point and laugh! ;)

  52. Didn't we have what it is they seek? by xski · · Score: 0

    He said many people wanted an overseer for the root servers and a technical co-ordination body that could drive the development of the net, not a global net policeman.


    My memory may be a bit foggy, but did we not have these things -- an overseer for the root servers and a technical coordination body to drive net development -- with IANA, IETF & ISOC and all that?