Slashdot Mirror

← Back to Stories (view on slashdot.org)

Root Zone Changed

Posted by ryuzaki0 on from the verisign-causing-instability-as-usual dept.

An anonymous reader writes "The day before yesterday the root zone was silently changed for the first time in 5 years. The change was to J.ROOT-SERVERS.NET that is now managed by Verisign. The usual sites don't breathe a word about this change however as one would expect for such a change to be properly announced. An interesing sidenote is this thread on the IETF discussion list." the_proton writes "The server j.root-servers.net has changed IP address to 192.58.128.30. The new root zone hints can be grabbed from ftp://rs.internic.net/domain/named.root or ftp://ftp.internic.net/domain/named.root. The new zone serial number is 2002110501."

298 comments

  1. Will one need by bplipschitz · · Score: 0, Troll

    a root canal to get there?

  2. FP changed by Anonymous Coward · · Score: -1, Troll

    This is the new location of the FP!

  3. Why should we care? by Disoriented · · Score: 4, Interesting

    Maybe someone could explain to us newbies how this affects the operation of the Internet.

    1. Re:Why should we care? by LinuxOnHal · · Score: 3, Informative

      Without getting extremely technical with it, this mostly affects your ISP. If your ISP does not update their root zone files, when you attempt to resolve a website, your ISP has one less server for it to resolve the root server for and CC top level domains, as well as .com, .org, .net, etc.

      --
      Trying is the First Step to Failing --Homer Simpson
    2. Re:Why should we care? by nelsonal · · Score: 5, Informative

      The root servers are the master list of domain names for the Internet. The computers still use IP addresses to talk, but us Humans prefer remembering slashdot.org to 66.35.250.150. In meatspace terms, I think this is along the lines of a construction company changing the composition of their concrete for use on the Highway system, you might not notice the change as a user, but it could be a bad decision.
      All I want to know is if Sun is back to being the . in .com? :)

      --
      Degaussing scares the bad magnetism out of the monitor and fills it with good karma.
    3. Re:Why should we care? by Anonymous Coward · · Score: 0

      Basically the Root Zone has now changed from behind the McDonald's carpark, to the concreted area behind the abandoned rural supplies warehouse.

      Anyone caught in the McDonalds carpark from now on will be laughed at, and their mullet cut off.

    4. Re:Why should we care? by a+(+h+3+r+0+n · · Score: 5, Informative
      The root zones are where are all top-level DNS queries start. Think of the internet domain system as one giant honkin' tree. The root servers at the top manage domain information for the top level zones, and they pass off queries down the tree until the query hits an authoritative DNS server for the domain in question.

      This affects administrators of DNS servers, because in the DNS config is a list of the IP addresses where these root servers can be found.

      Why should you care? You probably don't. It doesn't affect you directly. That is, unless all the root servers mysteriously die one day. That would make surfing for your pr0n a thing of near impossibility. :)

    5. Re:Why should we care? by sporty · · Score: 2

      You forgot to mention domain name servers and the ip's to find out what their IP's are. All the root servers know about slashdot are what its ip's are and what the ip's of the dns servers are along with the fact that the name is slashdot.org.

      All the root servers are gigantic signs with posts pointing general directions to find out more specific information.

      --

      -
      ping -f 255.255.255.255 # if only

    6. Re:Why should we care? by KieranElby · · Score: 5, Informative

      > Maybe someone could explain to us newbies how this affects the operation of the Internet.

      Ok.

      Here's the usual (much simplified) explanation for how DNS (that is, maping hostnames to IP addresses) works:

      Let's assume we want to connect to www.slashdot.org. We need to know it's IP address in order to do this.

      What we do is:

      1) Ask one of the 13 root servers which server handles .org domains.

      2) Ask that server which server handles the slashdot.org domain.

      3)Ask that server which server handles the www.slashdot.org zone.

      However, this begs the question:

      "Where do the root servers get their info. from?"

      Well, as of yesterday they're getting it from 192.58.128.30.

      To some extent, 192.58.128.30 is now the most important address on the internet since it is the highest authority for the rather important business of looking up addresses.

    7. Re:Why should we care? by spinlocked · · Score: 3, Funny

      All I want to know is if Sun is back to being the . in .com

      I think Sun's marketing department finally realised that's not a good thing to be :)

      --
      # init 5
      Connection closed.

      Oh... ...bugger.
    8. Re:Why should we care? by MentlFlos · · Score: 1
      That would make surfing for your pr0n a thing of near impossibility

      just start at 69.69.69.69 and go from there!

      (Hmmm, I wonder who has that block.... I think I'll go check)

    9. Re:Why should we care? by BigGar' · · Score: 1, Funny

      That would make surfing for your pr0n a thing of near impossibility. :)

      This is exactly why I keep a notebook, with the ip address, of all the porn sites I visit regularly in it. Never can be to cautious when it comes to your porn.

      --


      Shop smart, Shop S-Mart.
    10. Re:Why should we care? by Anonymous Coward · · Score: 1, Informative

      No, it doesn't "beg the question." It inspires the question, it raises or prompts the question, but it does not beg the question. HTH.

    11. Re:Why should we care? by raindrop#1 · · Score: 1

      "Think of the internet domain system as one giant honkin' tree. The root servers at the top...pass off queries down the tree"

      So this is a tree with the roots at top and the branches at the bottom?? Where I live the roots normally go in the ground, that is, at the bottom of the tree. Still, it's a strange old world out there, maybe things are different round your way?

    12. Re:Why should we care? by timothy_m_smith · · Score: 2
      Still, it's a strange old world out there, maybe things are different round your way?

      Maybe the author of the parent post lives in Australia...
    13. Re:Why should we care? by Anonymous Coward · · Score: 5, Informative

      Not exactly. The question is actually "how do we find the root servers to ask them who handles .org" aka, "how do we find out who handles '.'".

      The answer is to keep a list of the 13 root servers' IPs on disk, in a file called (appropriately enough) "root.hints".

      J is *one* of the root servers, and it has changed its IP. Therefore at some point people should update their root.hints files to reflect this change.

      There's no hurry, because the other 12 haven't moved, and over time the update will tend to happen without any special help as you upgrade your DNS install, etc.

    14. Re:Why should we care? by Anonymous Coward · · Score: 1, Funny
      ...you might not notice the change as a user, but it could be a bad decision.
      All I want to know is if Sun is back to being the . in .com?
      If this turns out to be a bad decision, Sun could end up as the "stroke dot" (\., as opposed to slash dot, /.) in
      [[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:] ]{1,3}\.[[:digit:]]{1,3}

      I'd hate to be on the marketing team that tries to figure out how to sell that one to consumers.
    15. Re:Why should we care? by 4of12 · · Score: 1

      remembering slashdot.org to 66.35.250.150

      What?

      You mean 66.35.250.150 is Slashdot and not Pee Wee's Playhouse?

      --
      "Provided by the management for your protection."
    16. Re:Why should we care? by raindrop#1 · · Score: 0

      in which case I'd like to say that Nasser Hussain is merely biding his time (i hope).

      ps. [for the Americans out there] I'm talking about Cricket.

    17. Re:Why should we care? by Shagg · · Score: 4, Insightful

      Think of it like this:

      If you are looking for the phone number for a company you've never called before, you want to look in the Yellow Pages to find it. Now if your wife has moved the Yellow Pages to a different room in the house, you need to know where she put it. However, in this case it's more like there are 13 copies of the Yellow Pages in your home, and she's only moved one of them... so it's not too big of a deal. It's also not something you need to know unless you run a DNS server.

      --
      Unix is user friendly, it's just selective about who its friends are.
    18. Re:Why should we care? by dfn5 · · Score: 1

      But in this specific case j.root-servers.net doesn't really seem to do anything important other than serve up "." so I would say that nobody should really care. At least the other root servers [a-i].root-servers.net serve up other things like .mil and .arpa. Opennic doesn't even have a mention of it in its root zone file because it is soooo unimportant.

      --
      -- Thou hast strayed far from the path of the Avatar.
    19. Re:Why should we care? by Anonymous Coward · · Score: 0

      This is funny!!!! Dipshit moderators....

    20. Re:Why should we care? by SacredNaCl · · Score: 5, Insightful

      I wonder if this has anything to do with the recent denial of service attacks against the root servers?

      Just speculating that maybe the attackers used a worm/trojan that was preset to attack them at the previous IP on certain dates? Similar to some things we have seen in the past...

      --
      Freedom is merely privilege extended unless enjoyed by one and all.
    21. Re:Why should we care? by Strog · · Score: 5, Informative

      A.ROOT-SERVERS.NET is considered the ultimate authority in DNS. It is also called "dot" and used to be a healthy Sun box. So they really were the "dot" in .com in a sense and that's what made it so funny. That box was replaced with an IBM box and now IBM could say they are the "dot" in .com.

      Link here

    22. Re:Why should we care? by paranoos · · Score: 1
      Sun is now actually the "m" in ".com" ... meaning that it is the butt of all jokes. Including this one.

      heh Couldn't resist, sorry :>

    23. Re:Why should we care? by Anonymous Coward · · Score: 0

      That would make surfing for your pr0n a thing of near impossibility.

      What? You don't index your pr0n sites by IP? It's much less suspicious to see 210.214.xx.xx on your history list, instead of www.daddysfistisinsideme.com

    24. Re:Why should we care? by Anonymous Coward · · Score: 0

      Thank you. Misuse of that phrase drives me right out of my tree.

      At some point, I'm hoping the school system reintroduces literacy to the curriculum.

    25. Re:Why should we care? by MindStalker · · Score: 2

      Competly wrong.
      Here is how it actually works.

      Your computer contacts your ISPs DNS server asking where www.slashdot.org is. That computer if it knows the answer (which it often does as it keeps stores request for a few hours) Tells you the answer, if it doesn't or it only knows the partial answer (it might know the DNS server for slashdot.org in which it would go straight there and ask where www.slashdot.org is. Anyways your ISPs DNs server will assuming it didn't know the answer and immediently tell you, do one of two things, depending upon how its programmed, very small isps or most company intranet DNS servers, will ask its ISPs DNS server. Or assuming its a normal ISP with randomly pick one of X number of servers. (by my list, (not updated sence 1997) 14 different servers A.ROOT-SERVERS.NET to M.ROOT-SERVERS.NET) Of course the IP address of these servers are more important than the names. This server tells me that slashdot.org's domain name records are stored at ns1.osdn.com (and ns2 and ns3 as backups) and gives these ip addresses of ns1.osdn.org and the backups, then tells my local dns to keep this info on hand for just short of 2 days. My DNs server then asks ns1.osdn.org just where I can find www.slashdot.org, this server will answer me.

    26. Re:Why should we care? by br0ck · · Score: 5, Informative

      I think your suspicion has been confirmed by a this recent New Scientist article. It says one of the Versign root servers was actually moved to a new location so that two servers wouldn't be relying on the same infrastructure. It does not mention the IP change, but it seems to make sense.

    27. Re:Why should we care? by Alsee · · Score: 3, Funny

      Now if your wife has moved the Yellow Pages to a different room in the house, you need to know where she put it. However, in this case it's more like there are 13 copies of the Yellow Pages in your home, and she's only moved one of them... so it's not too big of a deal.

      I don't give a damn about the Yellow Pages, I just wish she'd stop leaving the frigg'n cordless phone burried in a pile of freshly folded laundry.

      -

      --
      - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
    28. Re:Why should we care? by miltimj · · Score: 1

      Unless you've visited the sites recently. DNS info should be cached up (down?) the tree.

      You make it seem as though the root servers get every DNS lookups, which is definitely not the case (for obviously good reason!)

      --
      "Truth is not decided by majority vote" consensus gentium -- Norman Geisler
    29. Re:Why should we care? by sv0f · · Score: 1, Offtopic

      heh Couldn't resist, sorry :>

      No need to apologize. You're not funny.

    30. Re:Why should we care? by douglas+jeffries · · Score: 1

      in computer science, that's how tree's always grow.

      weird, i know, and probably makes planting a pain. then again, most of computer science makes more sense standing on your head, if only for the rush of blood.

    31. Re:Why should we care? by TheOnlyCoolTim · · Score: 2

      I remember when my ISPs DNS server would go down a lot, I ended up putting in one of the root servers for the tertiary alternative DNS or something like that...

      Tim

      --
      Omnia vestra castrorum habetur nobis.
    32. Re:Why should we care? by NateTech · · Score: 1

      Actually you missed a step or twenty. "Much simplified" is the understatement of the year.

      You said:

      1) Ask one of the 13 root servers which server handles .org domains.

      2) Ask that server which server handles the slashdot.org domain.

      3)Ask that server which server handles the www.slashdot.org zone.

      And of course that last step is a bit wrong, even in a simple analogy.

      Should have been:

      3) Ask that server which server handles the slashdot.org zone.

      ***4) Ask that server for the A record for the www.slashdot.org name.

      And of course, it's a lot more complex than this, as at each point you're really asking "do you have records for this zone?...

      If not, do you have an NS record for the nameserver to ask for it?"... "Oh! Your timout values on those zones are X, Y, and Z? Okay... I'll cache those. Thanks."

      And of course, like many big sites, you may get more than one answer for the A-record for www.slashdot.org and have to hand all of those back to the client resolver which will randomize (hopefully) which one it uses...

      And at each stop, you might have to resolve something ELSE to get here... for example when it finds out that the slashdot.org zone is hosted on ns1-ns3.osdn.net, it has to start all over at the top and see if it has cached information for those and if not, ask from the root down where that name lives...

      Etc etc etc...

      It's quite amazing that it works as well as it does as fast as it does.

      --
      +++OK ATH
    33. Re:Why should we care? by Zeinfeld · · Score: 2
      It is also called "dot" and used to be a healthy Sun box. So they really were the "dot" in .com in a sense and that's what made it so funny. That box was replaced with an IBM box and now IBM could say they are the "dot" in .com.

      Actually the change happened mid way through the Sun marketing campaign. Didn't seem to stop Sun however...

      Most folk would think that the folk who run the .com Registry are the dot in dot com.

      --
      Looking for an Information Security student project suggestion?
      Try http://dotcrimeManifesto.com/
    34. Re:Why should we care? by evilviper · · Score: 2
      It says one of the Versign root servers was actually moved to a new location so that two servers wouldn't be relying on the same infrastructure. It does not mention the IP change, but it seems to make sense.

      Haha... When was the last time you moved a computer from one network to another, but kept the same IP address? Come on, were you confused just because they didn't use the magic phrase 'IP address'?
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    35. Re:Why should we care? by evilviper · · Score: 2
      Think of the internet domain system as one giant honkin' tree. The root servers at the top

      Okay, so the DNS servers are the top of the tree. That must mean that they are nte most protruded, and support nothing but themselves.

      I'd say the DNS 'tree' is better described as a sort of upside down pyramid.
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    36. Re:Why should we care? by numark · · Score: 1

      According to ARIN, no one does...

      --
      Want Slashdot headlines on your site? Try SlashHead
    37. Re:Why should we care? by JWSmythe · · Score: 1


      You know, that domain is available.. :)

      --
      Serious? Seriousness is well above my pay grade.
    38. Re:Why should we care? by lostchicken · · Score: 2

      You bad man. You very bad man.

      Don't do this. The root servers would end up in a smoldering heap of goo if end users started using them.

      --
      -twb
    39. Re:Why should we care? by Blkdeath · · Score: 2
      Don't do this. The root servers would end up in a smoldering heap of goo if end users started using them.
      ... you mean "tried to use them". Much like any good authoritative nameserver, they're not recursive.
      --
      BD Phone Home!

      Shameless plug. Like you weren't expecting it.

    40. Re:Why should we care? by dreamword · · Score: 2
      now IBM could say they are the "dot" in .com.


      IBM, perhaps unfortunately, would be promptly sued for trademark infringement if they did that, since Sun still holds a trademark on the phrase. I liked it better when, for once, relatively obscure bits of technical reality were lined up with marketing hype. Alas, no longer; the marketing hype lives on.

    41. Re:Why should we care? by ShavenYak · · Score: 1

      I can tell that most Slashdot readers are single by the fact that this post isn't +5, Funny (not that I didn't know beforehand, mind you).

      BTW, you forgot to mention the remote control for the TV in the living room being left on the kitchen table.

      --

      Hey kids, there's only 5 days left 'til Yak Shaving Day!
    42. Re:Why should we care? by jez9999 · · Score: 1

      Don't quite get what you mean by 'recursive' here?

      --
      == Jez ==
      Do you miss Firefox? Try Pale Moon.
    43. Re:Why should we care? by cperciva · · Score: 2

      When was the last time you moved a computer from one network to another, but kept the same IP address?

      Given that ARIN makes "micro-allocations" available to root servers (and other "critical infrastructure providers"), it would be quite possible for Verisign to move a root server while keeping the same IP address.

      --
      Tarsnap: Online backups for the truly paranoid
    44. Re:Why should we care? by Strog · · Score: 1

      Why should facts bother a good marketing campaign?

      They had pretty good steam and most people didn't know about the change anyway. Most of the ones that did had already made their mind up one way other about Sun and their products.

      We should talk about F root server too. It changed from DEC to Compaq to now HP but the specs stay the same. Actually it's the same 2 node cluster of Alpha boxes and they update the manufacturer name on the webpage and nothing else. It is one of the busiest of the root servers.

    45. Re:Why should we care? by extremely · · Score: 2
      Recursive in this case means they don't walk the tree. You ask a non-recursive server "blah.zone.com." and unless it handles "zone.com.", it says "I dunno"!

      A recursive server would lookup ".", then ask one of the answers to that question "com." and then ask one of the answers to that questions "zone.com.", and then finally ask the real DNS server for "blah.zone.com."

      The authoritative servers aren't recursive to keep bozos from adding them to their DNS lists and beating them to death.

      --

      $you = new YOU;
      honk() if $you->love(perl)

    46. Re:Why should we care? by delta407 · · Score: 2
      That is, unless all the root servers mysteriously die one day. That would make surfing for your pr0n a thing of near impossibility.
      Actually, some systems (most notably Freenet ) are designed to withstand massive amounts of infrastructure failure. Freenet does not require DNS to work; if IP routing is still happening, Freenet will continue to function. There have been experiments with FNP (Freenet Native Protocol) over private fiber, point-to-point serial links, and even amateur radio, allowing worldwide communication despite all of the Tier 1 ISPs closing their doors.

      In short, Freenet would let you get your pr0n -- electronically and anonymously -- even if the entire Internet imploded.
    47. Re:Why should we care? by Anonymous Coward · · Score: 0

      Nothing to do with ARIN, everything to do with routing. Routing a single IP is kinda wasteful, so usually when you move a machine to a different network, you change its IP address.

    48. Re:Why should we care? by bpmd · · Score: 1

      But there is darker side: the place where the Yellow Pages used to be is currently empty.

      And the wife has a possibility to fill it with something else. Which may look like Yellow Pages and smell like Yellow Pages, but this may not be Yellow Pages!

      And if I make 13 calls per day and pick a new Yellow Pages each time that means that once per day I may be slightly surprised.

  4. Thanks Micheal, you're gonna /. by Hairy_Potter · · Score: 5, Funny

    the internet. Don't every one go J.ROOT-NET.NET now.

    1. Re:Thanks Micheal, you're gonna /. by br0ck · · Score: 4, Informative

      Oddly, the reply to the NANOG post about the change encourages people to hold off on downloding the hints file to prevent Slashdotting internic.net since. The reply claims that the update is not at all critical.

    2. Re:Thanks Micheal, you're gonna /. by Grape+Smuggler · · Score: -1

      Yeah, hilarity.

      Good job you fucking karma whore.

    3. Re:Thanks Micheal, you're gonna /. by eastbam · · Score: 1

      too late...

      eastbam@Dagger:~$ ping J.ROOT-NET.NET
      ping: unknown host J.ROOT-NET.NET

    4. Re:Thanks Micheal, you're gonna /. by Mitchell+Mebane · · Score: 1

      Um, it's actually j.root-servers.net .

      --

      The roots of education are bitter, but the fruit is sweet.
      --Aristotle
    5. Re:Thanks Micheal, you're gonna /. by thogard · · Score: 2, Interesting

      Its not at all critical and there is a reason its called a "hint" file.

      When you start up bind, it will loads the hints file. when you do a dns query where it has to go to the root, it grabs one out of the hints and does a lookup while timimg how long that server took. Its then continues through the list using the one with the lowest time and it increments a running average so that it will retry all the roots over time. At some point during this process it will find out the serail number of the root zone isn't quite what it expected and then will ask the a root server for the list of root servers. If your bind has been running for weeks, months or years, it already has the new data. Its just the startup data that has one wrong entry -- if you've been running a recent zone file, I've seen servers that runing hint files that are close to a decade old.

      If you don't want to /. the ftp server,
      $ dig @a.ROOT-SERVERS.NET. . ns > root.hints

      This would only be an urgent issue if they address of one of the root servers was assigned to a different group.

    6. Re:Thanks Micheal, you're gonna /. by 216pi · · Score: 1

      OMG I can't reach it!

      oh wait. it's a problem with my proxy.

    7. Re:Thanks Micheal, you're gonna /. by ibennetch · · Score: 1

      No, seriously - what happens if someone launches a large scale DoS or DDoS attack on a few of the root name servers? People's querys start timing out and no one can go anywhere?

    8. Re:Thanks Micheal, you're gonna /. by TheOnlyCoolTim · · Score: 2

      Someone did recently, I believe. They knocked out all but three or four. No one noticed until they read it on slashdot.

      Tim

      --
      Omnia vestra castrorum habetur nobis.
    9. Re:Thanks Micheal, you're gonna /. by l1_wulf · · Score: 1

      Exactly, it has been done, and frankly, will probably happen again. The system is designed to keep the internet running, in theory, as long as one is still up and active. The servers are located virtually and geographically seperate to keep the possibility of a disaster (massive hardware failures, natural disasters, etc.) from keeping the internet from grinding to a halt.

    10. Re:Thanks Micheal, you're gonna /. by NanoGator · · Score: 2

      "Oddly, the reply [cctec.com] to the NANOG post [cctec.com] about the change encourages..."

      Heh, wanna know what's funny? When you said "NANOG", I thought you were referring to me!

      --
      "Derp de derp."
  5. why tell anyone? by chef_raekwon · · Score: 0, Redundant

    its not like anyone uses that thing called the internet anyway....

    --
    We're like rats, in some experiment! -- George Costanza
  6. bah. by grub · · Score: 5, Funny


    Whenever I go near a "root zone" I end up getting pepper sprayed and charged with sexual assault.

    --
    Trolling is a art,
    1. Re:bah. by Anonymous Coward · · Score: -1, Offtopic

      What an idiot. You have to put them to sleep first.

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

      Good sig. However, it'd be much funnier if you left off the "not as in beer" part. Kinda breaks up the rhythm.

  7. Frist psot!!! by Anonymous Coward · · Score: -1, Troll

    'Cause I rule and you dr00l

  8. For owning the whole interenet..... by Anonymous Coward · · Score: -1, Troll



    Their webiste fucking sucks some big asss

    if I had Inventedd the interenet i woulc have made a much beter page!

    I could rite better HTML in notped

    1. Re:For owning the whole interenet..... by Anonymous Coward · · Score: -1, Flamebait

      Yes, if you could only spell.

  9. FP for the AC! by Anonymous Coward · · Score: -1, Troll

    Frist tops 0wnage!

  10. wow by Anonymous Coward · · Score: -1, Offtopic

    imagine a beowulf cluster of these!

  11. Michael is a trolling cunt (proof inside) by Anonymous Coward · · Score: -1, Offtopic


    Michael is a trolling cunt

    It's a diatribe about a dork. Read up.

  12. It was announced on NANOG..... by dannyp · · Score: 5, Informative

    ....the day before. See the message. Granted not much warning, but it wasn't silent.

    1. Re:It was announced on NANOG..... by Jucius+Maximus · · Score: 2
      " ....the day before. See the message [cctec.com]. Granted not much warning, but it wasn't silent."

      I see the message but the PGP key fingerprint does not match his key on the server for some reason. (Not that the meassage isn't accurate.)

      crain@icann.]org
      fingerprint: 1AF4 F638 4B2D 3EF2 F9BA 99E4 8D85 69A7

    2. Re:It was announced on NANOG..... by l1_wulf · · Score: 5, Informative
      As it has been pointed out further down (for those of us that sort by score), this is truly a non-event and makes no significant impact on the typical /. reader. I will not take credit for the following information, but will quote someone that I think summed up the situation enough to hopefully keep the average Joe from /.ing any of the links posted in the article above. ccandreva posted
      This is not a change that needs to be done immediately. For one thing, there are 13 (A - M) root servers. As long as your name server can contact one of them, it will download the latest list at start-up, so your root file can be fairly out of date, and still be fine when running. Also, the announcement says that the server will respond on both IP addresses "for the forseeable future".
      Essentially, unless you know specifically that you are directly affected by this change, and can explain in detail why exactly you need this information right now, there is no need to /. any of the links above. If you run a linux box and keep your builds rather current, then I can assure you that there is no need to update. Think about it, the last change was 5 years ago, there should not be a major rush to update for the majority of us.
    3. Re:It was announced on NANOG..... by gfilion · · Score: 1

      I see the message but the PGP key fingerprint does not match his key on the server for some reason. (Not that the meassage isn't accurate.)

      It does match key 0xD48A5892 on keyserver.pgp.com.

    4. Re:It was announced on NANOG..... by hoeferbe · · Score: 1
      The fingerprint given in John Crain's ICANN/IANA announcement,
      1AF4 F638 4B2D 3EF2 F9BA 99E4 8D85 69A7
      has 32 hexidecimal bits. This is what the MD5 hash algorithm puts out. When I looked up the key that was used to sign John Crain's annoucemnt, it reports this fingerprint:
      9A49 B5AF 8C39 83B9 369C 2512 D1B1 A795 D48A 5892
      Notice that my PGP Freeware 6.5.8 displays the fingerprint in 40 hexidecimal bits. This is an output of the SHA-1 hash algorithm.

      John Crain's PGP signature reports the version of PGP he is using is "PGP Personal Security 7.0.3". Perhaps key fingerprints are displayed in MD5 instead of SHA-1 in this version of PGP? I doubt that, since I think PGP originally used MD5 sum and moved to SHA-1.

      I do not now how to compute the MD5 fingerprint of a PGP key either in PGP Freeware 6.5.8 or GnuPG 1.0.6.

    5. Re:It was announced on NANOG..... by l1_wulf · · Score: 1

      Heh, it figures. 10 minutes after I post this, it gets bumped waaaaay lower due to a handful of funny posts and their replies. Oh well, I tried :P.

    6. Re:It was announced on NANOG..... by TomViolin · · Score: 1


      Check out the immediate reply to the original announcement. The guy says "There's no need to slashdot internic.net tomorrow morning." :-)

    7. Re:It was announced on NANOG..... by MikeBabcock · · Score: 2

      Could you please consider getting your GPG key signed by as many people as possible? Please? Perhaps anyone else on NANOG who knows you? Perhaps even by Verisign's Key?

      (GPG/PGP Activism ...)

      --
      - Michael T. Babcock (Yes, I blog)
    8. Re:It was announced on NANOG..... by Jouster · · Score: 2

      No such thing as a hexadecimal bit. Only hexadecimal characters, or, if you're adventurous and know your old-fashioned 'puter terminology, hexadecimal nibbles.

      Jouster

  13. Verisign? Does that mean by myowntrueself · · Score: 5, Funny

    that we are going to need Microsoft passport to make changes to DNS now?

    --
    In the free world the media isn't government run; the government is media run.
    1. Re:Verisign? Does that mean by TheCeltic · · Score: 5, Funny

      Not unless at least one of the Root servers changes from being UNIX based... Come now.. can you imagine the size of the windows cluster needed to offer a stable Root server? It would fill a warehouse!

      --
      =-=-=-=-=-=-=-= - The Celtic - =-=-=-=-=-=-=-=
    2. Re:Verisign? Does that mean by Mage+Powers · · Score: 1

      >that we are going to need Microsoft passport to make changes to DNS now?
      Is that a joke? a troll? is it a geniune thought? or are you using the "ask-a-question" shell script? Just curious ;)

    3. Re:Verisign? Does that mean by Anonymous Coward · · Score: 0

      are you joking or just an idiot?? the .net domain does not belong to microsoft you moron

    4. Re:Verisign? Does that mean by rizzo · · Score: 3, Funny

      For whatever subliminal reason I thought you typed "whorehouse" instead of "warehouse". Offtopic, but I thought I'd share. ;)

      --

      "More organs means more human." - Zim

    5. Re:Verisign? Does that mean by Anonymous Coward · · Score: 0

      "Whorehouse" would have been a lot more accurate.

    6. Re:Verisign? Does that mean by Alsee · · Score: 2

      can you imagine the size of the windows cluster needed to offer a stable Root server?

      Isn't that kind of like asking how many lawyers it takes to find the truth?

      -

      --
      - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
    7. Re:Verisign? Does that mean by AndroidCat · · Score: 1
      And why do you think that adding more nodes to a Windows cluster would make it stable??

      --
      One line blog. I hear that they're called Twitters now.
    8. Re:Verisign? Does that mean by zarqman · · Score: 1

      yeah, but considered the state of the tech job market, that wouldn't be so bad. verisign could then put out a press release about creating tons of [windows admin] jobs.

      --
      geek friendly VPS's and free API enabled DNS : zerigo.com
    9. Re:Verisign? Does that mean by myowntrueself · · Score: 1

      I suspect that it was a troll.

      --
      In the free world the media isn't government run; the government is media run.
    10. Re:Verisign? Does that mean by jonbrewer · · Score: 2

      Not unless at least one of the Root servers changes from being UNIX based... Come now.. can you imagine the size of the windows cluster needed to offer a stable Root server? It would fill a warehouse!

      Really I fail to see why you would say this. The IBM workstation sitting below my desk running Windows 2000 has several times the horsepower of the last root server I heard about. (IIRC they're a mishmash of six or seven unix variants running on five different hardware platforms.)

      RFC 2870 specifies "2.3 At any time, each (root) 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"

      I believe that normal load is around 280 million requests per day, or 3300 requests per second.

      These are not complex transactions. There isn't any writing going on to slow things down. The space requirements for a root server running Win2k would likely be 5U. Smaller than an e450, I do believe. And with 2-4 2GHz Xeon processors, a hell of a lot faster too.

    11. Re:Verisign? Does that mean by kasperd · · Score: 2

      IIRC they're a mishmash of six or seven unix variants running on five different hardware platforms.

      That sounds like a good choice. Running different hardware and software combinations should make them less prone to a single bug allowing a DoS attack.

      three times the measured peak of such requests on the most loaded server

      Does that actually mean, that the root servers are not designed such that a single can serve the entire net if needed?

      --

      Do you care about the security of your wireless mouse?
    12. Re:Verisign? Does that mean by TheCeltic · · Score: 1

      >Really I fail to see why you would say this.

      It's about stability, security and the fact that we don't have to reboot our systems everytime we apply a patch. (not to mention the ability to communicate well with others, standards...DNS/Bind etc..). BTW, many of the root servers are 32+ CPU systems.. last I checked, it was impossible to get 32 CPU's in any wintel system without clustering 4 - 8-cpu systems and calling it 32 cpu's.

      >And with 2-4 2GHz Xeon processors, a hell of a lot faster too.

      Hrmm.. a 32 Bit bus faster than a 64 bit one? The whole concept of multi-processor hasn't yet been fully grasped by ms. (of course the mhz is higher.. but do we include bus speed, downtime,viruses, DOS vulnerability, patch time/etc??)

      --
      =-=-=-=-=-=-=-= - The Celtic - =-=-=-=-=-=-=-=
    13. Re:Verisign? Does that mean by myowntrueself · · Score: 1

      was that an exclusive or inclusive 'or'?

      --
      In the free world the media isn't government run; the government is media run.
  14. Guess what, gang? Michael is... by Anonymous Coward · · Score: -1, Troll


    Michael is a trolling cunt

    It's like the facts just hit me 'bout the face!

  15. Wha? by Anonymous Coward · · Score: 0



    matt@wproxy03:~$ ping j.root-net.net
    ping: unknown host j.root-net.net
    matt@wproxy03:~$

    dammit!

  16. See, it's like this... by Anonymous Coward · · Score: -1, Troll


    Michael is a trolling cunt

    And that's all I've got to say about that. (In this post).

    1. Re:See, it's like this... by Anonymous Coward · · Score: 0

      Self flagelation will send you blind....

  17. protocols? by ftide · · Score: 2, Flamebait

    are there written protocols & procedures for this activity agreed upon by the community?

    where's the oversight? who made the decision that changed the root zone? A *.int (intl. exchange) entity should mandate or govern root zone oversight, not some U$ corporate shill.

    1. Re:protocols? by Anonymous Coward · · Score: 3, Informative

      IANA made the decision and they are the appropriate authority to do such things.

    2. Re:protocols? by DAldredge · · Score: 0, Flamebait

      Why? It's not like the international community every does anything. All the ever do is talk about doing it...

    3. Re:protocols? by pyros · · Score: 3, Funny

      IANA made the

      Did anyone else read that and ask "You are not a what? And who made the decision? Finish your damn sentence!"

    4. Re:protocols? by Morth · · Score: 1

      Did anyone else read that and ask "You are not a what? And who made the decision? Finish your damn sentence!"

      No, but perhaps that's because i visit IANA's homepage around once a week. I mean, who can live without the assigned numbers of the Internet?

    5. Re:protocols? by gughunter · · Score: 1
      are there written protocols & procedures for this activity agreed upon by the community?

      Of course there are -- that's why it took five years to get it done!

    6. Re:protocols? by neitzsche · · Score: 1

      The parent post here was originally modd'ed as "insightful." It was a great pleasure to meta-moderate that "Unfair."

      --
      "God is dead." - Frederik Nietzsche
  18. He's already doing his job. by Anonymous Coward · · Score: -1, Troll


    Michael is a trolling cunt

    Now he's trolling ROOOOOOOT. 'cause he's a NEEEEEGRROOOOOOO

    1. Re:He's already doing his job. by buswolley · · Score: 1

      fucking racist. You are bringing us down.

      --

      A Good Troll is better than a Bad Human.

  19. Crapflood! by Anonymous Coward · · Score: -1, Troll

    ping 192.58.128.30
    PING 192.58.128.30 (192.58.128.30) from 192.168.2.7 : 56(84) bytes of data.
    64 bytes from 192.58.128.30: icmp_seq=1 ttl=234 time=94.8 ms
    64 bytes from 192.58.128.30: icmp_seq=2 ttl=234 time=96.4 ms
    64 bytes from 192.58.128.30: icmp_seq=3 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=4 ttl=234 time=91.9 ms
    64 bytes from 192.58.128.30: icmp_seq=5 ttl=234 time=92.5 ms
    64 bytes from 192.58.128.30: icmp_seq=6 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=7 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=8 ttl=234 time=95.4 ms
    64 bytes from 192.58.128.30: icmp_seq=9 ttl=234 time=93.7 ms
    64 bytes from 192.58.128.30: icmp_seq=10 ttl=234 time=93.4 ms
    64 bytes from 192.58.128.30: icmp_seq=11 ttl=234 time=92.5 ms
    64 bytes from 192.58.128.30: icmp_seq=12 ttl=234 time=91.6 ms
    64 bytes from 192.58.128.30: icmp_seq=13 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=14 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=15 ttl=234 time=92.4 ms
    64 bytes from 192.58.128.30: icmp_seq=16 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=17 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=18 ttl=234 time=94.3 ms
    64 bytes from 192.58.128.30: icmp_seq=19 ttl=234 time=93.1 ms
    64 bytes from 192.58.128.30: icmp_seq=20 ttl=234 time=95.8 ms
    64 bytes from 192.58.128.30: icmp_seq=21 ttl=234 time=95.4 ms
    64 bytes from 192.58.128.30: icmp_seq=22 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=23 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=24 ttl=234 time=91.9 ms
    64 bytes from 192.58.128.30: icmp_seq=25 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=26 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=27 ttl=234 time=92.4 ms
    64 bytes from 192.58.128.30: icmp_seq=28 ttl=234 time=153 ms
    64 bytes from 192.58.128.30: icmp_seq=29 ttl=234 time=93.4 ms
    64 bytes from 192.58.128.30: icmp_seq=30 ttl=234 time=92.6 ms
    64 bytes from 192.58.128.30: icmp_seq=31 ttl=234 time=92.0 ms
    64 bytes from 192.58.128.30: icmp_seq=32 ttl=234 time=91.3 ms
    64 bytes from 192.58.128.30: icmp_seq=33 ttl=234 time=91.0 ms
    64 bytes from 192.58.128.30: icmp_seq=34 ttl=234 time=94.3 ms
    64 bytes from 192.58.128.30: icmp_seq=35 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=36 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=37 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=38 ttl=234 time=97.2 ms
    64 bytes from 192.58.128.30: icmp_seq=39 ttl=234 time=135 ms
    64 bytes from 192.58.128.30: icmp_seq=40 ttl=234 time=92.5 ms
    64 bytes from 192.58.128.30: icmp_seq=41 ttl=234 time=97.9 ms
    64 bytes from 192.58.128.30: icmp_seq=42 ttl=234 time=92.4 ms
    64 bytes from 192.58.128.30: icmp_seq=43 ttl=234 time=91.8 ms
    64 bytes from 192.58.128.30: icmp_seq=44 ttl=234 time=134 ms
    64 bytes from 192.58.128.30: icmp_seq=45 ttl=234 time=93.6 ms
    64 bytes from 192.58.128.30: icmp_seq=46 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=47 ttl=234 time=92.6 ms
    64 bytes from 192.58.128.30: icmp_seq=48 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=49 ttl=234 time=91.8 ms
    64 bytes from 192.58.128.30: icmp_seq=50 ttl=234 time=92.0 ms
    64 bytes from 192.58.128.30: icmp_seq=51 ttl=234 time=110 ms
    64 bytes from 192.58.128.30: icmp_seq=52 ttl=234 time=91.5 ms
    64 bytes from 192.58.128.30: icmp_seq=53 ttl=234 time=91.0 ms
    64 bytes from 192.58.128.30: icmp_seq=54 ttl=234 time=95.6 ms
    64 bytes from 192.58.128.30: icmp_seq=55 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=56 ttl=234 time=92.7 ms
    64 bytes from 192.58.128.30: icmp_seq=57 ttl=234 time=91.6 ms
    64 bytes from 192.58.128.30: icmp_seq=58 ttl=234 time=94.5 ms
    64 bytes from 192.58.128.30: icmp_seq=59 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=60 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=61 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=62 ttl=234 time=93.2 ms
    64 bytes from 192.58.128.30: icmp_seq=63 ttl=234 time=95.5 ms
    64 bytes from 192.58.128.30: icmp_seq=64 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=65 ttl=234 time=92.3 ms
    64 bytes from 192.58.128.30: icmp_seq=66 ttl=234 time=94.8 ms
    64 bytes from 192.58.128.30: icmp_seq=67 ttl=234 time=92.9 ms
    64 bytes from 192.58.128.30: icmp_seq=68 ttl=234 time=98.4 ms
    64 bytes from 192.58.128.30: icmp_seq=69 ttl=234 time=90.9 ms
    64 bytes from 192.58.128.30: icmp_seq=70 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=71 ttl=234 time=93.1 ms
    64 bytes from 192.58.128.30: icmp_seq=72 ttl=234 time=91.5 ms
    64 bytes from 192.58.128.30: icmp_seq=73 ttl=234 time=98.8 ms
    64 bytes from 192.58.128.30: icmp_seq=74 ttl=234 time=99.5 ms
    64 bytes from 192.58.128.30: icmp_seq=75 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=76 ttl=234 time=92.5 ms
    64 bytes from 192.58.128.30: icmp_seq=77 ttl=234 time=91.4 ms
    64 bytes from 192.58.128.30: icmp_seq=78 ttl=234 time=97.6 ms
    64 bytes from 192.58.128.30: icmp_seq=79 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=80 ttl=234 time=94.7 ms
    64 bytes from 192.58.128.30: icmp_seq=81 ttl=234 time=91.3 ms
    64 bytes from 192.58.128.30: icmp_seq=82 ttl=234 time=92.0 ms
    64 bytes from 192.58.128.30: icmp_seq=83 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=84 ttl=234 time=93.6 ms
    64 bytes from 192.58.128.30: icmp_seq=85 ttl=234 time=91.9 ms
    64 bytes from 192.58.128.30: icmp_seq=86 ttl=234 time=93.9 ms
    64 bytes from 192.58.128.30: icmp_seq=87 ttl=234 time=94.5 ms
    64 bytes from 192.58.128.30: icmp_seq=88 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=89 ttl=234 time=91.2 ms
    64 bytes from 192.58.128.30: icmp_seq=90 ttl=234 time=97.5 ms
    64 bytes from 192.58.128.30: icmp_seq=91 ttl=234 time=93.2 ms
    64 bytes from 192.58.128.30: icmp_seq=92 ttl=234 time=95.5 ms
    64 bytes from 192.58.128.30: icmp_seq=93 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=94 ttl=234 time=94.2 ms
    64 bytes from 192.58.128.30: icmp_seq=95 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=96 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=97 ttl=234 time=91.4 ms
    64 bytes from 192.58.128.30: icmp_seq=98 ttl=234 time=97.6 ms
    64 bytes from 192.58.128.30: icmp_seq=99 ttl=234 time=92.9 ms
    64 bytes from 192.58.128.30: icmp_seq=100 ttl=234 time=92.0 ms
    64 bytes from 192.58.128.30: icmp_seq=101 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=102 ttl=234 time=92.4 ms
    64 bytes from 192.58.128.30: icmp_seq=103 ttl=234 time=92.9 ms
    64 bytes from 192.58.128.30: icmp_seq=104 ttl=234 time=92.4 ms
    64 bytes from 192.58.128.30: icmp_seq=105 ttl=234 time=91.5 ms
    64 bytes from 192.58.128.30: icmp_seq=106 ttl=234 time=91.7 ms
    64 bytes from 192.58.128.30: icmp_seq=107 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=108 ttl=234 time=92.5 ms
    64 bytes from 192.58.128.30: icmp_seq=109 ttl=234 time=92.0 ms
    64 bytes from 192.58.128.30: icmp_seq=110 ttl=234 time=92.3 ms
    64 bytes from 192.58.128.30: icmp_seq=111 ttl=234 time=92.3 ms
    64 bytes from 192.58.128.30: icmp_seq=112 ttl=234 time=91.9 ms
    64 bytes from 192.58.128.30: icmp_seq=113 ttl=234 time=94.5 ms
    64 bytes from 192.58.128.30: icmp_seq=114 ttl=234 time=93.6 ms
    64 bytes from 192.58.128.30: icmp_seq=115 ttl=234 time=97.8 ms
    64 bytes from 192.58.128.30: icmp_seq=116 ttl=234 time=93.6 ms
    64 bytes from 192.58.128.30: icmp_seq=117 ttl=234 time=97.3 ms
    64 bytes from 192.58.128.30: icmp_seq=118 ttl=234 time=92.3 ms
    64 bytes from 192.58.128.30: icmp_seq=119 ttl=234 time=92.7 ms
    64 bytes from 192.58.128.30: icmp_seq=120 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=121 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=122 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=123 ttl=234 time=152 ms
    64 bytes from 192.58.128.30: icmp_seq=124 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=125 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=126 ttl=234 time=96.0 ms
    64 bytes from 192.58.128.30: icmp_seq=127 ttl=234 time=93.6 ms
    64 bytes from 192.58.128.30: icmp_seq=128 ttl=234 time=96.1 ms
    64 bytes from 192.58.128.30: icmp_seq=129 ttl=234 time=91.9 ms
    64 bytes from 192.58.128.30: icmp_seq=130 ttl=234 time=94.1 ms
    64 bytes from 192.58.128.30: icmp_seq=131 ttl=234 time=110 ms
    64 bytes from 192.58.128.30: icmp_seq=132 ttl=234 time=91.9 ms
    64 bytes from 192.58.128.30: icmp_seq=133 ttl=234 time=96.0 ms
    64 bytes from 192.58.128.30: icmp_seq=134 ttl=234 time=96.6 ms
    64 bytes from 192.58.128.30: icmp_seq=135 ttl=234 time=92.7 ms
    64 bytes from 192.58.128.30: icmp_seq=136 ttl=234 time=93.2 ms
    64 bytes from 192.58.128.30: icmp_seq=137 ttl=234 time=92.7 ms
    64 bytes from 192.58.128.30: icmp_seq=138 ttl=234 time=92.3 ms
    64 bytes from 192.58.128.30: icmp_seq=139 ttl=234 time=93.4 ms
    64 bytes from 192.58.128.30: icmp_seq=140 ttl=234 time=92.6 ms
    64 bytes from 192.58.128.30: icmp_seq=141 ttl=234 time=94.5 ms
    64 bytes from 192.58.128.30: icmp_seq=142 ttl=234 time=91.5 ms
    64 bytes from 192.58.128.30: icmp_seq=143 ttl=234 time=97.6 ms
    64 bytes from 192.58.128.30: icmp_seq=144 ttl=234 time=94.3 ms
    64 bytes from 192.58.128.30: icmp_seq=145 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=146 ttl=234 time=93.2 ms
    64 bytes from 192.58.128.30: icmp_seq=147 ttl=234 time=99.7 ms
    64 bytes from 192.58.128.30: icmp_seq=148 ttl=234 time=94.4 ms
    64 bytes from 192.58.128.30: icmp_seq=149 ttl=234 time=93.6 ms
    64 bytes from 192.58.128.30: icmp_seq=150 ttl=234 time=113 ms
    64 bytes from 192.58.128.30: icmp_seq=151 ttl=234 time=91.0 ms
    64 bytes from 192.58.128.30: icmp_seq=152 ttl=234 time=93.5 ms
    64 bytes from 192.58.128.30: icmp_seq=153 ttl=234 time=92.9 ms
    64 bytes from 192.58.128.30: icmp_seq=154 ttl=234 time=93.5 ms
    64 bytes from 192.58.128.30: icmp_seq=155 ttl=234 time=92.6 ms
    64 bytes from 192.58.128.30: icmp_seq=156 ttl=234 time=93.4 ms
    64 bytes from 192.58.128.30: icmp_seq=157 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=158 ttl=234 time=91.9 ms
    64 bytes from 192.58.128.30: icmp_seq=159 ttl=234 time=91.9 ms
    64 bytes from 192.58.128.30: icmp_seq=160 ttl=234 time=96.6 ms
    64 bytes from 192.58.128.30: icmp_seq=161 ttl=234 time=161 ms
    64 bytes from 192.58.128.30: icmp_seq=162 ttl=234 time=92.5 ms
    64 bytes from 192.58.128.30: icmp_seq=163 ttl=234 time=92.0 ms
    64 bytes from 192.58.128.30: icmp_seq=164 ttl=234 time=113 ms
    64 bytes from 192.58.128.30: icmp_seq=165 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=166 ttl=234 time=97.7 ms
    64 bytes from 192.58.128.30: icmp_seq=167 ttl=234 time=91.3 ms
    64 bytes from 192.58.128.30: icmp_seq=168 ttl=234 time=93.5 ms
    64 bytes from 192.58.128.30: icmp_seq=169 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=170 ttl=234 time=95.4 ms
    64 bytes from 192.58.128.30: icmp_seq=171 ttl=234 time=93.5 ms
    64 bytes from 192.58.128.30: icmp_seq=172 ttl=234 time=93.6 ms
    64 bytes from 192.58.128.30: icmp_seq=173 ttl=234 time=93.1 ms
    64 bytes from 192.58.128.30: icmp_seq=174 ttl=234 time=92.6 ms
    64 bytes from 192.58.128.30: icmp_seq=175 ttl=234 time=93.1 ms
    64 bytes from 192.58.128.30: icmp_seq=176 ttl=234 time=93.4 ms
    64 bytes from 192.58.128.30: icmp_seq=177 ttl=234 time=92.9 ms
    64 bytes from 192.58.128.30: icmp_seq=178 ttl=234 time=92.6 ms
    64 bytes from 192.58.128.30: icmp_seq=179 ttl=234 time=91.8 ms
    64 bytes from 192.58.128.30: icmp_seq=180 ttl=234 time=94.0 ms
    64 bytes from 192.58.128.30: icmp_seq=181 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=182 ttl=234 time=92.3 ms
    64 bytes from 192.58.128.30: icmp_seq=183 ttl=234 time=94.1 ms
    64 bytes from 192.58.128.30: icmp_seq=184 ttl=234 time=91.6 ms
    64 bytes from 192.58.128.30: icmp_seq=185 ttl=234 time=93.4 ms
    64 bytes from 192.58.128.30: icmp_seq=186 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=187 ttl=234 time=94.3 ms
    64 bytes from 192.58.128.30: icmp_seq=188 ttl=234 time=97.7 ms
    64 bytes from 192.58.128.30: icmp_seq=189 ttl=234 time=93.2 ms
    64 bytes from 192.58.128.30: icmp_seq=190 ttl=234 time=116 ms
    64 bytes from 192.58.128.30: icmp_seq=191 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=192 ttl=234 time=93.7 ms
    64 bytes from 192.58.128.30: icmp_seq=193 ttl=234 time=93.4 ms
    64 bytes from 192.58.128.30: icmp_seq=194 ttl=234 time=92.9 ms
    64 bytes from 192.58.128.30: icmp_seq=195 ttl=234 time=92.4 ms
    64 bytes from 192.58.128.30: icmp_seq=196 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=197 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=198 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=199 ttl=234 time=92.5 ms
    64 bytes from 192.58.128.30: icmp_seq=200 ttl=234 time=91.1 ms
    64 bytes from 192.58.128.30: icmp_seq=201 ttl=234 time=96.4 ms
    64 bytes from 192.58.128.30: icmp_seq=202 ttl=234 time=93.5 ms
    64 bytes from 192.58.128.30: icmp_seq=203 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=204 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=205 ttl=234 time=93.5 ms
    64 bytes from 192.58.128.30: icmp_seq=206 ttl=234 time=95.5 ms
    64 bytes from 192.58.128.30: icmp_seq=207 ttl=234 time=99.7 ms
    64 bytes from 192.58.128.30: icmp_seq=208 ttl=234 time=92.5 ms
    64 bytes from 192.58.128.30: icmp_seq=209 ttl=234 time=100 ms
    64 bytes from 192.58.128.30: icmp_seq=210 ttl=234 time=92.6 ms
    64 bytes from 192.58.128.30: icmp_seq=211 ttl=234 time=95.4 ms
    64 bytes from 192.58.128.30: icmp_seq=212 ttl=234 time=93.6 ms
    64 bytes from 192.58.128.30: icmp_seq=213 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=214 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=215 ttl=234 time=92.4 ms
    64 bytes from 192.58.128.30: icmp_seq=216 ttl=234 time=91.9 ms
    64 bytes from 192.58.128.30: icmp_seq=217 ttl=234 time=107 ms
    64 bytes from 192.58.128.30: icmp_seq=218 ttl=234 time=92.3 ms
    64 bytes from 192.58.128.30: icmp_seq=219 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=220 ttl=234 time=95.9 ms
    64 bytes from 192.58.128.30: icmp_seq=221 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=222 ttl=234 time=97.5 ms
    64 bytes from 192.58.128.30: icmp_seq=223 ttl=234 time=91.8 ms
    64 bytes from 192.58.128.30: icmp_seq=224 ttl=234 time=94.8 ms
    64 bytes from 192.58.128.30: icmp_seq=225 ttl=234 time=92.7 ms
    64 bytes from 192.58.128.30: icmp_seq=226 ttl=234 time=99.4 ms
    64 bytes from 192.58.128.30: icmp_seq=227 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=228 ttl=234 time=98.1 ms
    64 bytes from 192.58.128.30: icmp_seq=229 ttl=234 time=93.5 ms
    64 bytes from 192.58.128.30: icmp_seq=230 ttl=234 time=93.1 ms
    64 bytes from 192.58.128.30: icmp_seq=231 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=232 ttl=234 time=91.5 ms
    64 bytes from 192.58.128.30: icmp_seq=233 ttl=234 time=94.0 ms
    64 bytes from 192.58.128.30: icmp_seq=234 ttl=234 time=92.6 ms

  20. In case you were wondering... by Anonymous Coward · · Score: -1, Troll



    Michael is a trolling cunt

    BTW, Cmdr Taco licks dog balls!

    Spread the word! Spread the god damn word!!

  21. a quick theory by cr@ckwhore · · Score: 5, Insightful

    Following the recent DOS attacks against the root servers, it wouldn't surprise me if this move is only a small part of a bigger story. I'm willing to bet that modifications are being made to the networking and security of the root servers that will better prepare the entire root system for future attacks. The move of J. is probably just the tip of the clandestine "ice berg".

    --
    Skiers and Riders -- http://www.snowjournal.com
    1. Re:a quick theory by bugpit · · Score: 3, Informative

      See the CNET article, Key Internet server moved for security, tho Verisign claims that the timing was coincidental.

      --
      We have found the enemy and he is us. - Pogo
    2. Re:a quick theory by TeddyR · · Score: 2

      RFC 2010 has the guidelines on what is needed for a root nameserver operations. Those guidelines had not been followed as closely as they should have. My feeling is that even as a result of the recent DOS attacks that they are trying to bring everything to ATLEAST rfc2010 standards and then maybe improve some more... esp. since that RFC was written in 1996, WAY before any of the "new" DOS attacks {like the ones that got Yahoo....) were so easy to do...

      http://www.ietf.org/rfc/rfc2010.txt?number=2010

      --

      --
      Time is on my side
    3. Re:a quick theory by Dog+and+Pony · · Score: 2

      Following the recent DOS attacks against the root servers

      You mean like posting the IP on slashdot for all previously unknowing script kiddies to see? :)

    4. Re:a quick theory by l1_wulf · · Score: 1

      Heh, technically an address getting /.ed is a form of DOS...

    5. Re:a quick theory by BrunoC · · Score: 1

      I find this theory pretty good. As far as my named.cache knows, J was "temporarily hosted at NSI" and since root server A survived the DDoS and J did not, moving J to Verisign seems a pretty good thing to do. I truly believe that's why J is moving.

  22. This doesn't matter. Really. by toastyman · · Score: 5, Informative
    To quote Sean Donelan's post on NANOG:

    Since its been 5 years since the hints/cache boot file has changed,
    it may be useful to remind people an immediate change to your
    local configuration files is not required. You don't need to
    slashdot internic.net tomorrow morning trying to download the file.

    As long as 1 listed IP address responds with the current list of root
    servers, the server doesn't even need to be a root server itself, your
    name server should figure out who are the current roots. In the 1980's
    and 1990's when the hints/cache file changed regularly, some people when
    years without updating it. Or only updated it when they upgraded their
    name server code.

    Don't Panic.


    To sum up: You don't need to change anything. As long as one of the 13 servers in your hints/cache file responds, your name server will download the updated list on startup. You only have to worry if you've put off updating it so long that all 13 servers have changed IP's. Pretty unlikely, since that would be a hints file that's more than 10 years old at least. (You're not running Linux, anyway...)

    And no, this isn't verisign-causing-instability-as-usual. They're actually trying to help it. Before this change, both a.root-servers.net and j.root-servers.net were in the same /24 and in the same BGP annoucement. They're moving things around a bit(presumably) to increase reliability and redundancy.
    1. Re:This doesn't matter. Really. by Anonymous Coward · · Score: 2, Insightful

      My job involves looking at naked chicks all day. Why doesn't yours?
      Screw the IP change, anyone got more information on how to get a job like this?
    2. Re:This doesn't matter. Really. by maw · · Score: 2
      That's great, until one of the deprecated root servers starts serving stale or even deliberately information.

      They say it won't happen, but I'd rather place as little as possible faith in people not screwing up.

      --
      You're a suburbanite.
    3. Re:This doesn't matter. Really. by Alsee · · Score: 2

      To quote Sean Donelan's post on NANOG:
      [yada yada yada]
      Don't Panic.

      Would that be Sean Donelan, head of Vogon Internet Industries?

      -

      --
      - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
    4. Re:This doesn't matter. Really. by JWSmythe · · Score: 1

      You gotta luck out..

      BTW, I admin voyeurweb.com :) Been here about 5 years, and am not leaving soon.. hehe

      --
      Serious? Seriousness is well above my pay grade.
    5. Re:This doesn't matter. Really. by kasperd · · Score: 1

      Screw the IP change

      No, screw those chicks. This is ./

      --

      Do you care about the security of your wireless mouse?
    6. Re:This doesn't matter. Really. by jez9999 · · Score: 1

      Hmm. If the effect they want is for no one to update their hosts file until their server restarts, in order not to overload the root servers, surely the best method would be to 'silently' change the root IP and not tell anyone?

      --
      == Jez ==
      Do you miss Firefox? Try Pale Moon.
  23. Anyone that cares... by pirodude · · Score: 5, Informative

    Anyone that cares and needs to know about it was properly notified. There was a post to NANOG 3 days ago about it:

    *****PLEASE NOTE*****
    This is an important Informational Message to the internet community:

    November 5, 2002, the IP address for J.root-servers.net will
    change in the authoritative NS set for "dot". The change will
    be reflected in zone serial # 2002110501.

    The new set of servers authoritative for "dot" will be:
    A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4
    H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53
    C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12
    G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4
    F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241
    B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107
    J.ROOT-SERVERS.NET. 5w6d16h IN A 192.58.128.30
    K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129
    L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12
    M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33
    I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17
    E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10
    D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90

    This WILL require a change to your root hints file. The new
    file will be available via anonymous ftp from
    rs.internic.net:/domain/named.root as well as
    ftp.internic.net:/doamin/named.root starting 11/5/02 1700UTC (12pm
    EST/9am PST).

    Both the new and old j.root-servers.net IP space will provide
    answers in parallel for the foreseeable future.

    _________________________________________

    John Crain
    Manager of Technical Operations
    ICANN/IANA

    crain@icann.org
    1AF4 F638 4B2D 3EF2 F9BA 99E4 8D85 69A7

    1. Re:Anyone that cares... by Tony+Hoyle · · Score: 1

      No need to slashdot internic, just:

      $ dig @a.root-servers.net . >/etc/bind/db.root

    2. Re:Anyone that cares... by Tony+Hoyle · · Score: 4, Informative

      Oops (don't try that at home kids...)

      # dig @a.root-servers.net . ns >/etc/bind/db.root

  24. Please Be Advised: +1 Patriotic by Anonymous Coward · · Score: 2, Funny


    that DDOS attacks are covered under the U.S.A.
    "Patriot" Act.

    Very truly yours,

    J. Ashcroft

    _)*&^%$$

    Be Patriotic: Smoke Amerikan Grown Marijuana

  25. I'm sorry the mods are stupid. by Anonymous Coward · · Score: -1, Offtopic

    They're inspired my Michael, and Michael is a trolling cunt.

    Your joke was funny. Please don't stop.

  26. You can't have it both ways.... by Anonymous Coward · · Score: -1, Offtopic

    You can't have the internet an uncontrolled, free society, and have "oversight".

    Also, Michael is a trolling cunt.

    Both are true. Q. E. D.

  27. Don't panic - and there is no conspiricy by karl.auerbach · · Score: 5, Interesting

    This move is "a good thing".

    The J server shared a broadcast domain (i.e. it was on the same Ethernet) as the A root server. That's was clearly sub-optimal.

    So this move is good in that it creates a small bit of physical separation and a bit larger amount of net-topological separation between the J and A root servers.

    I hear that the old server will continue in operation for an indefinite period - so there is no need to rush out and update your "hints" file for your DNS resolvers - you can do it at your leasure and you probably won't notice even if you forget to do it.

    (Even if the old server is turned off - as long as a bogus server doesn't replace it, when DNS resolvers that are using the old hints file come up and look for a root zone definition, they will simply bypass the non-responsive absent server and try the other hints.)

    But there is another issue - A change in the "hints" is always a nuisance. And since we are incurring this nuisance, I wonder why we did not use this as an opportunity to redress the imbalance of root server placement - there are few root servers in Europe and Asia, and rather than simply moving the J server from one side of Herndon, Virginia to another, why wasn't it moved to Europe of Asia?

    1. Re:Don't panic - and there is no conspiricy by Anonymous Coward · · Score: 0

      You really should have used the word "paradigum" in your post.

    2. Re:Don't panic - and there is no conspiricy by sam_handelman · · Score: 5, Funny

      If there's no conspiracy, why are we all crouching around a table in a smoke filled room going over printed transcripts of your VoIP conversations for the past week, huh, smart guy?

      Just because we at Verisign have no sinister motives in moving a god damned computer does NOT mean that we're not involved in any conspiracies!

      As another example, our co-conspirators at the NSA just closed a loophole that let members of their alien autopsy division take extra paid sickdays even if they've never been exposed to any alien tissue (and thus, to the space virus). This was a totally inoccuous cost cutting measure, and not part of their conspiracy to conceal the existence the aliens. Does this mean the conspiracy doesn't exist? Absolutely not!

      --
      The good and new comes from no quarter where it is looked for, and is always something different from what is expected.
  28. stupid tagline by GigsVT · · Score: 5, Informative

    "Causing instability as usual"?

    You only need one root server, there are 12 others. In fact, it safe to just wait until the next time you upgrade BIND or your operating system... running an out of date file won't hurt anything.

    There was no reason to announce anything here. This is really a non-event.

    --
    I've had enough abrasive sigs. Kittens are cute and fuzzy.
    1. Re:stupid tagline by ep32g79 · · Score: 1

      "Move along, there's nothing to see here...."

  29. Come get some karma... by Metallic+Matty · · Score: 1, Interesting

    What exactly is a root zone?

    1. Re:Come get some karma... by fawadhalim · · Score: 3, Informative

      The root zone corresponds to the '.' at the very end of the domain names. The root name servers have records for .com,.org, and the national (.uk,.dk etc.) etc. DNS servers. If you ping cr.yp.to (DJB's domain), for example, and your DNS server has never seen a .to domain before, it'll query one of the root name servers for a name server authoritative for .to.

    2. Re:Come get some karma... by Daniel_Staal · · Score: 3, Informative

      Simple: You know there is a nameserver for slashdot.org, right? You find that nameserver by asking the org nameserver where it is. And how do you find the org nameserver? You ask the root nameservers. The zoot zone is the base zone of the Internet (just like / is the base of the file system in Unix).

      --
      'Sensible' is a curse word.
    3. Re:Come get some karma... by Bluecoat93 · · Score: 1

      Actually, .com, .org, and .net servers aren't on the roots. They're on the gtld-server.net servers, which are completely separate.

    4. Re:Come get some karma... by jroysdon · · Score: 1

      The statement "The root name servers have records for .com,.org, and the national (.uk,.dk etc.) etc. DNS servers." is correct. He was stating that the root name servers have the NS records for the DNS servers of .com, etc., which they do. If the root nameservers didn't know the NS records for the .com DNS servers, you'd never know how to get there. These records are AKA "glue" records. The actual SOA are the .com, etc. DNS servers, but the root still has the glue to get you to that NS.

      What you should have clarified is that the actual records in the .com, etc. zones are not in the root servers, other than the NS records glue.

  30. No. There are no black helicopters here. by Anonymous Coward · · Score: 1, Insightful

    My 'non-expert' understanding of this:

    1. This was discussed in multiple (appropriate) forums significantly before the change.

    2. This will be seemless to properly configured DNS.

    3. This was to move the server to a different subnet from it's 'mirror' for significantly improved reliability.

    Best!

    1. Re:No. There are no black helicopters here. by swfranklin · · Score: 2, Funny
      1. This was discussed in multiple (appropriate) forums significantly before the change.

      2. This will be seemless to properly configured DNS.

      3. This was to move the server to a different subnet from it's 'mirror' for significantly improved reliability.

      4. Profit!!!

    2. Re:No. There are no black helicopters here. by Anonymous Coward · · Score: 0

      What profit? Noone is paid for running root servers. See the article at:
      http://www.cnn.com/2002/TECH/internet/11/07/i ntern et.attacks.ap/index.html

      It's amazing the even a non-tech organization like CNN has better reporting on this than the 'geeks' at slashdot. How sad.

      Best!

  31. "Michael" is greek for "gets no female attention" by Anonymous Coward · · Score: -1, Troll

    Also, Michael is a trolling cunt

    Say it, don't spray it!

  32. Michael is a TROLLING CUNT by Anonymous Coward · · Score: -1, Troll


    It's time to ask yourselfs, HOW DO THEY get this past the Lameass filtar?!

    ping 192.58.128.30
    PING 192.58.128.30 (192.58.128.30) from 192.168.2.7 : 56(84) bytes of data.
    64 bytes from 192.58.128.30: icmp_seq=1 ttl=234 time=94.8 ms
    64 bytes from 192.58.128.30: icmp_seq=2 ttl=234 time=96.4 ms
    64 bytes from 192.58.128.30: icmp_seq=3 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=4 ttl=234 time=91.9 ms
    64 bytes from 192.58.128.30: icmp_seq=5 ttl=234 time=92.5 ms
    64 bytes from 192.58.128.30: icmp_seq=6 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=7 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=8 ttl=234 time=95.4 ms
    64 bytes from 192.58.128.30: icmp_seq=9 ttl=234 time=93.7 ms
    64 bytes from 192.58.128.30: icmp_seq=10 ttl=234 time=93.4 ms
    64 bytes from 192.58.128.30: icmp_seq=11 ttl=234 time=92.5 ms
    64 bytes from 192.58.128.30: icmp_seq=12 ttl=234 time=91.6 ms
    64 bytes from 192.58.128.30: icmp_seq=13 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=14 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=15 ttl=234 time=92.4 ms
    64 bytes from 192.58.128.30: icmp_seq=16 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=17 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=18 ttl=234 time=94.3 ms
    64 bytes from 192.58.128.30: icmp_seq=19 ttl=234 time=93.1 ms
    64 bytes from 192.58.128.30: icmp_seq=20 ttl=234 time=95.8 ms
    64 bytes from 192.58.128.30: icmp_seq=21 ttl=234 time=95.4 ms
    64 bytes from 192.58.128.30: icmp_seq=22 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=23 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=24 ttl=234 time=91.9 ms
    64 bytes from 192.58.128.30: icmp_seq=25 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=26 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=27 ttl=234 time=92.4 ms
    64 bytes from 192.58.128.30: icmp_seq=28 ttl=234 time=153 ms
    64 bytes from 192.58.128.30: icmp_seq=29 ttl=234 time=93.4 ms
    64 bytes from 192.58.128.30: icmp_seq=30 ttl=234 time=92.6 ms
    64 bytes from 192.58.128.30: icmp_seq=31 ttl=234 time=92.0 ms
    64 bytes from 192.58.128.30: icmp_seq=32 ttl=234 time=91.3 ms
    64 bytes from 192.58.128.30: icmp_seq=33 ttl=234 time=91.0 ms
    64 bytes from 192.58.128.30: icmp_seq=34 ttl=234 time=94.3 ms
    64 bytes from 192.58.128.30: icmp_seq=35 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=36 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=37 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=38 ttl=234 time=97.2 ms
    64 bytes from 192.58.128.30: icmp_seq=39 ttl=234 time=135 ms
    64 bytes from 192.58.128.30: icmp_seq=40 ttl=234 time=92.5 ms
    64 bytes from 192.58.128.30: icmp_seq=41 ttl=234 time=97.9 ms
    64 bytes from 192.58.128.30: icmp_seq=42 ttl=234 time=92.4 ms
    64 bytes from 192.58.128.30: icmp_seq=43 ttl=234 time=91.8 ms
    64 bytes from 192.58.128.30: icmp_seq=44 ttl=234 time=134 ms
    64 bytes from 192.58.128.30: icmp_seq=45 ttl=234 time=93.6 ms
    64 bytes from 192.58.128.30: icmp_seq=46 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=47 ttl=234 time=92.6 ms
    64 bytes from 192.58.128.30: icmp_seq=48 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=49 ttl=234 time=91.8 ms
    64 bytes from 192.58.128.30: icmp_seq=50 ttl=234 time=92.0 ms
    64 bytes from 192.58.128.30: icmp_seq=51 ttl=234 time=110 ms
    64 bytes from 192.58.128.30: icmp_seq=52 ttl=234 time=91.5 ms
    64 bytes from 192.58.128.30: icmp_seq=53 ttl=234 time=91.0 ms
    64 bytes from 192.58.128.30: icmp_seq=54 ttl=234 time=95.6 ms
    64 bytes from 192.58.128.30: icmp_seq=55 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=56 ttl=234 time=92.7 ms
    64 bytes from 192.58.128.30: icmp_seq=57 ttl=234 time=91.6 ms
    64 bytes from 192.58.128.30: icmp_seq=58 ttl=234 time=94.5 ms
    64 bytes from 192.58.128.30: icmp_seq=59 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=60 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=61 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=62 ttl=234 time=93.2 ms
    64 bytes from 192.58.128.30: icmp_seq=63 ttl=234 time=95.5 ms
    64 bytes from 192.58.128.30: icmp_seq=64 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=65 ttl=234 time=92.3 ms
    64 bytes from 192.58.128.30: icmp_seq=66 ttl=234 time=94.8 ms
    64 bytes from 192.58.128.30: icmp_seq=67 ttl=234 time=92.9 ms
    64 bytes from 192.58.128.30: icmp_seq=68 ttl=234 time=98.4 ms
    64 bytes from 192.58.128.30: icmp_seq=69 ttl=234 time=90.9 ms
    64 bytes from 192.58.128.30: icmp_seq=70 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=71 ttl=234 time=93.1 ms
    64 bytes from 192.58.128.30: icmp_seq=72 ttl=234 time=91.5 ms
    64 bytes from 192.58.128.30: icmp_seq=73 ttl=234 time=98.8 ms
    64 bytes from 192.58.128.30: icmp_seq=74 ttl=234 time=99.5 ms
    64 bytes from 192.58.128.30: icmp_seq=75 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=76 ttl=234 time=92.5 ms
    64 bytes from 192.58.128.30: icmp_seq=77 ttl=234 time=91.4 ms
    64 bytes from 192.58.128.30: icmp_seq=78 ttl=234 time=97.6 ms
    64 bytes from 192.58.128.30: icmp_seq=79 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=80 ttl=234 time=94.7 ms
    64 bytes from 192.58.128.30: icmp_seq=81 ttl=234 time=91.3 ms
    64 bytes from 192.58.128.30: icmp_seq=82 ttl=234 time=92.0 ms
    64 bytes from 192.58.128.30: icmp_seq=83 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=84 ttl=234 time=93.6 ms
    64 bytes from 192.58.128.30: icmp_seq=85 ttl=234 time=91.9 ms
    64 bytes from 192.58.128.30: icmp_seq=86 ttl=234 time=93.9 ms
    64 bytes from 192.58.128.30: icmp_seq=87 ttl=234 time=94.5 ms
    64 bytes from 192.58.128.30: icmp_seq=88 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=89 ttl=234 time=91.2 ms
    64 bytes from 192.58.128.30: icmp_seq=90 ttl=234 time=97.5 ms
    64 bytes from 192.58.128.30: icmp_seq=91 ttl=234 time=93.2 ms
    64 bytes from 192.58.128.30: icmp_seq=92 ttl=234 time=95.5 ms
    64 bytes from 192.58.128.30: icmp_seq=93 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=94 ttl=234 time=94.2 ms
    64 bytes from 192.58.128.30: icmp_seq=95 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=96 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=97 ttl=234 time=91.4 ms
    64 bytes from 192.58.128.30: icmp_seq=98 ttl=234 time=97.6 ms
    64 bytes from 192.58.128.30: icmp_seq=99 ttl=234 time=92.9 ms
    64 bytes from 192.58.128.30: icmp_seq=100 ttl=234 time=92.0 ms
    64 bytes from 192.58.128.30: icmp_seq=101 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=102 ttl=234 time=92.4 ms
    64 bytes from 192.58.128.30: icmp_seq=103 ttl=234 time=92.9 ms
    64 bytes from 192.58.128.30: icmp_seq=104 ttl=234 time=92.4 ms
    64 bytes from 192.58.128.30: icmp_seq=105 ttl=234 time=91.5 ms
    64 bytes from 192.58.128.30: icmp_seq=106 ttl=234 time=91.7 ms
    64 bytes from 192.58.128.30: icmp_seq=107 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=108 ttl=234 time=92.5 ms
    64 bytes from 192.58.128.30: icmp_seq=109 ttl=234 time=92.0 ms
    64 bytes from 192.58.128.30: icmp_seq=110 ttl=234 time=92.3 ms
    64 bytes from 192.58.128.30: icmp_seq=111 ttl=234 time=92.3 ms
    64 bytes from 192.58.128.30: icmp_seq=112 ttl=234 time=91.9 ms
    64 bytes from 192.58.128.30: icmp_seq=113 ttl=234 time=94.5 ms
    64 bytes from 192.58.128.30: icmp_seq=114 ttl=234 time=93.6 ms
    64 bytes from 192.58.128.30: icmp_seq=115 ttl=234 time=97.8 ms
    64 bytes from 192.58.128.30: icmp_seq=116 ttl=234 time=93.6 ms
    64 bytes from 192.58.128.30: icmp_seq=117 ttl=234 time=97.3 ms
    64 bytes from 192.58.128.30: icmp_seq=118 ttl=234 time=92.3 ms
    64 bytes from 192.58.128.30: icmp_seq=119 ttl=234 time=92.7 ms
    64 bytes from 192.58.128.30: icmp_seq=120 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=121 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=122 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=123 ttl=234 time=152 ms
    64 bytes from 192.58.128.30: icmp_seq=124 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=125 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=126 ttl=234 time=96.0 ms
    64 bytes from 192.58.128.30: icmp_seq=127 ttl=234 time=93.6 ms
    64 bytes from 192.58.128.30: icmp_seq=128 ttl=234 time=96.1 ms
    64 bytes from 192.58.128.30: icmp_seq=129 ttl=234 time=91.9 ms
    64 bytes from 192.58.128.30: icmp_seq=130 ttl=234 time=94.1 ms
    64 bytes from 192.58.128.30: icmp_seq=131 ttl=234 time=110 ms
    64 bytes from 192.58.128.30: icmp_seq=132 ttl=234 time=91.9 ms
    64 bytes from 192.58.128.30: icmp_seq=133 ttl=234 time=96.0 ms
    64 bytes from 192.58.128.30: icmp_seq=134 ttl=234 time=96.6 ms
    64 bytes from 192.58.128.30: icmp_seq=135 ttl=234 time=92.7 ms
    64 bytes from 192.58.128.30: icmp_seq=136 ttl=234 time=93.2 ms
    64 bytes from 192.58.128.30: icmp_seq=137 ttl=234 time=92.7 ms
    64 bytes from 192.58.128.30: icmp_seq=138 ttl=234 time=92.3 ms
    64 bytes from 192.58.128.30: icmp_seq=139 ttl=234 time=93.4 ms
    64 bytes from 192.58.128.30: icmp_seq=140 ttl=234 time=92.6 ms
    64 bytes from 192.58.128.30: icmp_seq=141 ttl=234 time=94.5 ms
    64 bytes from 192.58.128.30: icmp_seq=142 ttl=234 time=91.5 ms
    64 bytes from 192.58.128.30: icmp_seq=143 ttl=234 time=97.6 ms
    64 bytes from 192.58.128.30: icmp_seq=144 ttl=234 time=94.3 ms
    64 bytes from 192.58.128.30: icmp_seq=145 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=146 ttl=234 time=93.2 ms
    64 bytes from 192.58.128.30: icmp_seq=147 ttl=234 time=99.7 ms
    64 bytes from 192.58.128.30: icmp_seq=148 ttl=234 time=94.4 ms
    64 bytes from 192.58.128.30: icmp_seq=149 ttl=234 time=93.6 ms
    64 bytes from 192.58.128.30: icmp_seq=150 ttl=234 time=113 ms
    64 bytes from 192.58.128.30: icmp_seq=151 ttl=234 time=91.0 ms
    64 bytes from 192.58.128.30: icmp_seq=152 ttl=234 time=93.5 ms
    64 bytes from 192.58.128.30: icmp_seq=153 ttl=234 time=92.9 ms
    64 bytes from 192.58.128.30: icmp_seq=154 ttl=234 time=93.5 ms
    64 bytes from 192.58.128.30: icmp_seq=155 ttl=234 time=92.6 ms
    64 bytes from 192.58.128.30: icmp_seq=156 ttl=234 time=93.4 ms
    64 bytes from 192.58.128.30: icmp_seq=157 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=158 ttl=234 time=91.9 ms
    64 bytes from 192.58.128.30: icmp_seq=159 ttl=234 time=91.9 ms
    64 bytes from 192.58.128.30: icmp_seq=160 ttl=234 time=96.6 ms
    64 bytes from 192.58.128.30: icmp_seq=161 ttl=234 time=161 ms
    64 bytes from 192.58.128.30: icmp_seq=162 ttl=234 time=92.5 ms
    64 bytes from 192.58.128.30: icmp_seq=163 ttl=234 time=92.0 ms
    64 bytes from 192.58.128.30: icmp_seq=164 ttl=234 time=113 ms
    64 bytes from 192.58.128.30: icmp_seq=165 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=166 ttl=234 time=97.7 ms
    64 bytes from 192.58.128.30: icmp_seq=167 ttl=234 time=91.3 ms
    64 bytes from 192.58.128.30: icmp_seq=168 ttl=234 time=93.5 ms
    64 bytes from 192.58.128.30: icmp_seq=169 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=170 ttl=234 time=95.4 ms
    64 bytes from 192.58.128.30: icmp_seq=171 ttl=234 time=93.5 ms
    64 bytes from 192.58.128.30: icmp_seq=172 ttl=234 time=93.6 ms
    64 bytes from 192.58.128.30: icmp_seq=173 ttl=234 time=93.1 ms
    64 bytes from 192.58.128.30: icmp_seq=174 ttl=234 time=92.6 ms
    64 bytes from 192.58.128.30: icmp_seq=175 ttl=234 time=93.1 ms
    64 bytes from 192.58.128.30: icmp_seq=176 ttl=234 time=93.4 ms
    64 bytes from 192.58.128.30: icmp_seq=177 ttl=234 time=92.9 ms
    64 bytes from 192.58.128.30: icmp_seq=178 ttl=234 time=92.6 ms
    64 bytes from 192.58.128.30: icmp_seq=179 ttl=234 time=91.8 ms
    64 bytes from 192.58.128.30: icmp_seq=180 ttl=234 time=94.0 ms
    64 bytes from 192.58.128.30: icmp_seq=181 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=182 ttl=234 time=92.3 ms
    64 bytes from 192.58.128.30: icmp_seq=183 ttl=234 time=94.1 ms
    64 bytes from 192.58.128.30: icmp_seq=184 ttl=234 time=91.6 ms
    64 bytes from 192.58.128.30: icmp_seq=185 ttl=234 time=93.4 ms
    64 bytes from 192.58.128.30: icmp_seq=186 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=187 ttl=234 time=94.3 ms
    64 bytes from 192.58.128.30: icmp_seq=188 ttl=234 time=97.7 ms
    64 bytes from 192.58.128.30: icmp_seq=189 ttl=234 time=93.2 ms
    64 bytes from 192.58.128.30: icmp_seq=190 ttl=234 time=116 ms
    64 bytes from 192.58.128.30: icmp_seq=191 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=192 ttl=234 time=93.7 ms
    64 bytes from 192.58.128.30: icmp_seq=193 ttl=234 time=93.4 ms
    64 bytes from 192.58.128.30: icmp_seq=194 ttl=234 time=92.9 ms
    64 bytes from 192.58.128.30: icmp_seq=195 ttl=234 time=92.4 ms
    64 bytes from 192.58.128.30: icmp_seq=196 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=197 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=198 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=199 ttl=234 time=92.5 ms
    64 bytes from 192.58.128.30: icmp_seq=200 ttl=234 time=91.1 ms
    64 bytes from 192.58.128.30: icmp_seq=201 ttl=234 time=96.4 ms
    64 bytes from 192.58.128.30: icmp_seq=202 ttl=234 time=93.5 ms
    64 bytes from 192.58.128.30: icmp_seq=203 ttl=234 time=92.2 ms
    64 bytes from 192.58.128.30: icmp_seq=204 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=205 ttl=234 time=93.5 ms
    64 bytes from 192.58.128.30: icmp_seq=206 ttl=234 time=95.5 ms
    64 bytes from 192.58.128.30: icmp_seq=207 ttl=234 time=99.7 ms
    64 bytes from 192.58.128.30: icmp_seq=208 ttl=234 time=92.5 ms
    64 bytes from 192.58.128.30: icmp_seq=209 ttl=234 time=100 ms
    64 bytes from 192.58.128.30: icmp_seq=210 ttl=234 time=92.6 ms
    64 bytes from 192.58.128.30: icmp_seq=211 ttl=234 time=95.4 ms
    64 bytes from 192.58.128.30: icmp_seq=212 ttl=234 time=93.6 ms
    64 bytes from 192.58.128.30: icmp_seq=213 ttl=234 time=93.3 ms
    64 bytes from 192.58.128.30: icmp_seq=214 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=215 ttl=234 time=92.4 ms
    64 bytes from 192.58.128.30: icmp_seq=216 ttl=234 time=91.9 ms
    64 bytes from 192.58.128.30: icmp_seq=217 ttl=234 time=107 ms
    64 bytes from 192.58.128.30: icmp_seq=218 ttl=234 time=92.3 ms
    64 bytes from 192.58.128.30: icmp_seq=219 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=220 ttl=234 time=95.9 ms
    64 bytes from 192.58.128.30: icmp_seq=221 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=222 ttl=234 time=97.5 ms
    64 bytes from 192.58.128.30: icmp_seq=223 ttl=234 time=91.8 ms
    64 bytes from 192.58.128.30: icmp_seq=224 ttl=234 time=94.8 ms
    64 bytes from 192.58.128.30: icmp_seq=225 ttl=234 time=92.7 ms
    64 bytes from 192.58.128.30: icmp_seq=226 ttl=234 time=99.4 ms
    64 bytes from 192.58.128.30: icmp_seq=227 ttl=234 time=92.1 ms
    64 bytes from 192.58.128.30: icmp_seq=228 ttl=234 time=98.1 ms
    64 bytes from 192.58.128.30: icmp_seq=229 ttl=234 time=93.5 ms
    64 bytes from 192.58.128.30: icmp_seq=230 ttl=234 time=93.1 ms
    64 bytes from 192.58.128.30: icmp_seq=231 ttl=234 time=92.8 ms
    64 bytes from 192.58.128.30: icmp_seq=232 ttl=234 time=91.5 ms
    64 bytes from 192.58.128.30: icmp_seq=233 ttl=234 time=94.0 ms
    64 bytes from 192.58.128.30: icmp_seq=234 ttl=234 time=92.6 ms

    1. Re:Michael is a TROLLING CUNT by Anonymous Coward · · Score: -1, Offtopic

      It's time to ask yourselfs, HOW DO THEY get this past the Lameass filtar?!

      With their b0rken computars, obviously.

  33. Don't forget... by Anonymous Coward · · Score: -1

    ...to #dig

  34. umm... by Triv · · Score: 5, Funny

    An anonymous reader writes

    Ok. I got that. Next.

    "The day before yesterday the root zone was silently changed for the first time in 5 years.

    That's english at least. Something changed. Hopefully the rest will tell me what.

    The change was to J.ROOT-SERVERS.NET that is now managed by Verisign.

    Verisign's evil, right?

    The usual sites don't breathe a word about this change however as one would expect for such a change to be properly announced.

    Conspiracies are bad, right?

    An interesing sidenote is this thread on the IETF discussion list." the_proton writes "The server j.root-servers.net has changed IP address to 192.58.128.30. The new root zone hints can be grabbed from ftp://rs.internic.net/domain/named.root or ftp://ftp.internic.net/domain/named.root. The new zone serial number is 2002110501."

    [Brain explodes]

    (Isn't it amazing when you read something written in your own language and don't understand a word of what's being said?) ;)

    Triv

    1. Re:umm... by FauxPasIII · · Score: 2

      >> Isn't it amazing when you read something written in your own language and don't understand a word of what's being said?

      This should have come with a warning similar to the ones on a lot of linux kernel options: If you don't have any idea what this is talking about, then it doesn't affect you.
      This is only important to those of us who run our own DNS servers; the root servers are basically the "upstream" source from which all other DNS servers get their information.

      --
      25% Funny, 25% Insightful, 25% Informative, 25% Troll
    2. Re:umm... by Nintendork · · Score: 2

      The biased opinions are required material to get your submission posted by Michael.

    3. Re:umm... by Zwack · · Score: 1

      An interesing sidenote is this thread on the IETF discussion list." the_proton writes "The server j.root-servers.net has changed IP address to 192.58.128.30. The new root zone hints can be grabbed from ftp://rs.internic.net/domain/named.root or ftp://ftp.internic.net/domain/named.root. The new zone serial number is 2002110501."

      [Brain explodes]

      (Isn't it amazing when you read something written in your own language and don't understand a word of what's being said?) ;)

      Perhaps it doesn't make sense to you because you don't need to know about it... I'm sure that you say things in English that I wouldn't understand at times...

      However, here is the "simple" explanation...

      An interesing sidenote is this thread on the IETF discussion list." the_proton writes "

      That's just preamble... forget it.

      The server j.root-servers.net has changed IP address to 192.58.128.30.

      A server called j.root-servers.net has had its IP address changed. The root-servers.net servers (a, b, c,...) are spread out all over the world and tell everyobody where to start looking for IP addresses given a domain name. They can point you to the root server for a particular tld (.org) or a country (.za)... They are important.

      The new root zone hints can be grabbed from ftp://rs.internic.net/domain/named.root or ftp://ftp.internic.net/domain/named.root.

      The file which you use to tell your name server where to start looking for an IP address/Domain name has been updated and a new copy is available at one of these two ftp sites. Unless you are running your own DNS server (and even then you can safely ignore this) then you don't need to worry about updating this file.

      The new zone serial number is 2002110501."

      DNS Zone files have serial numbers. These numbers always increase. It helps you tell if you have got the right version of the DNS information... Your server should cache DNS lookups. The standard serial number is based on the date... in fact it is YYYYMMDDXX where YYYY is the year, MM is the month, DD is the day and XX is an index (multiple updates can be performed in the same day, this allows up to one hundred changes to a zone in a day).

      Does this help?

      Z.

      --
      -- Under/Overrated is meta-moderation, and therefore is Redundant.
  35. Thanks. by Anonymous Coward · · Score: -1, Troll

    Did you know that Michael is a trolling cunt? It's too bad.

    I think he works for Microsoft.

  36. Whew! by Anonymous Coward · · Score: -1, Troll

    Thanks for the heads-up. Did you also know that Michael is a trolling cunt? So much reading to do today!

    --peterpuffer

  37. Getting root.hints by image · · Score: 5, Informative

    > The new root zone hints can be grabbed from ftp://rs.internic.net/domain/named.root or ftp://ftp.internic.net/domain/named.root.

    For those running bind, you may want to try this instead:

    dig @e.root-servers.net . ns > root.hints

    It will generate the root list automatically, ready for you to drop into /var/named/ (or wherever you installed it).

    1. Re:Getting root.hints by Phroggy · · Score: 2

      For those running bind, you may want to try this instead:

      dig @e.root-servers.net . ns > root.hints

      Or, even simpler:

      dig @a.root-servers.net > root.hints

      (pick any letter from a-m to use in place of a; they should all work, even j)

      --
      $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
      $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
    2. Re:Getting root.hints by belloc · · Score: 2

      For those running bind, you may want to try this instead:

      Yeah, because "wget ftp://ftp.internic.net/domain/named.root ; cp named.root /var/named/named.ca" is WAY more complicated.

      Belloc

      --
      I got more rhymes than Jamaica got Mangoes.
    3. Re:Getting root.hints by mamahuhu · · Score: 1

      I just updated my DNS and re-read the DNS howto on LinuxDoc. In the Keeping it working section there is information about keeping your root.hints up-to-date.... though if this is the first change in 5 years perhpas not so vital.

      I'll post the page below.... but the pertinent point here is this: -

      Some of you might have picked up that the root.hints file is also available by ftp from Internic. Please don't use ftp to update root.hints, the above method is much more friendly to the net, and Internic.

      If though this is a little out of date (BIND 8) it is still valid in principle. Try the script included....

      Keeping it working.

      There is one maintenance task you have to do on nameds, other than keeping them running. That's keeping the root.hints file updated. The easiest way is using dig. First run dig with no arguments you will get the root.hints according to your own server. Then ask one of the listed root servers with dig @rootserver. You will note that the output looks terribly like a root.hints file. Save it to a file (dig @e.root-servers.net . ns >root.hints.new) and replace the old root.hints with it.

      Remember to reload named after replacing the cache file.

      Al Longyear sent me this script that can be run automatically to update root.hints. Install a crontab entry to run it once a month and forget it. The script assumes you have mail working and that the mail-alias `hostmaster' is defined. You must hack it to suit your setup.

      Note - go to LinuxDocs to get the script

      Some of you might have picked up that the root.hints file is also available by ftp from Internic. Please don't use ftp to update root.hints, the above method is much more friendly to the net, and Internic.

    4. Re:Getting root.hints by feronti · · Score: 1

      even, even simpler:

      $ dig > root.hints
      dig without options pulls the hints by default.
    5. Re:Getting root.hints by Phroggy · · Score: 2

      dig without options pulls the hints by default.

      But doesn't that pull from your own nameserver's configuration, which may not match what the root servers have to say? That would mean "dig>root.hints" would be completely useless.

      I could be wrong...

      --
      $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
      $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
    6. Re:Getting root.hints by feronti · · Score: 1

      Hadn't thought of that. D'oh... I stand corrected.

  38. Re:protocols? Yeah - RFCs by Anonymous Coward · · Score: 1, Informative

    It's all in the RFCs. Might want to spend less time doing Chicken Little and a bit more time on research/learning.

  39. Not that big a deal by ccandreva · · Score: 5, Informative

    This post is leaving out some details that were brought up on the NANOG mailing list.

    This is not a change that needs to be done immediately. For one thing, there are 13 (A - M) root servers. As long as your name server can contact one of them, it will download the latest list at start-up, so your root file can be fairly out of date, and still be fine when running.

    Also, the announcement says that the server will respond on both IP addresses "for the forseeable future".

    This isn't a question of flipping a switch and everyone having to update their servers at once. A big public announcement would probably just have confused most users for no good reason.

  40. Alert! Alert! by wahay · · Score: 0, Troll

    Make sure you point your network settings in windows to the new root server!

  41. Doesn't seem to be working yet by Anonymous Coward · · Score: 0

    I wait a few days before switching. 192.158.128.30 doesn't seem to be answering nslookups yet. The old address still works though.

    Somehow I find that not surprising considering its Verisign.

  42. Apparently there was also a change today by Kj0n · · Score: 3, Interesting

    Since when I look up the SOA record for the root domain, it gives a serial number of 2002110700 instead of 2002220501.

    1. Re:Apparently there was also a change today by jroysdon · · Score: 1

      The root zone SOA is incremented EVERY day. The zone itself is rather stable (how often do new CC or domains come into existance or need to get removed?). It was the root.hints file that was updated on the 5th as the actual J root server IP changed, and this is the rare occurance.

    2. Re:Apparently there was also a change today by bill_mcgonigle · · Score: 2

      2002220501

      That serial doesn't make sense. Did you just typo or was that really the serial for a while (they typo'd)? If that was the serial, the 'net is going to be horked until Jan 1, at least in theory (major simultaneous root server catastrophies).

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    3. Re:Apparently there was also a change today by scottj · · Score: 1

      That's funny. The serial I get now is 2002111001. I wonder if they change it often.

      --
      .-.--
  43. Just a heads-up to all you out there by Anonymous Coward · · Score: -1, Troll

    Psst! Michael is a trolling cunt! Pass it on.

    I'm running out of proxies! Oh, hold on... there's thousands of them!

    How can you bypass the lameness filter?

  44. DON'T /. THE NAMED.ROOT FILES!!!! by PacketMaster · · Score: 3, Insightful

    Please don't /. the named.root files Don't click on it just because you're curious to see what they look like. People need to legitimately access those files to update their DNS servers and flooding the FTP with meaningless requests is highly counterproductive.

    Also, Slashdot editors, why even let those links get posted? Every person with a browser is clicking on those to see what they look like and making them inaccessable to people who need them. People who need to see them or access them know where they're at already and people who are that curious should exercise a little personal initiative and go find out where to get them. It's irresponsible on the part of /. to let this happen. Slashdotting a news site is one thing, but Slashdotting internic is a very different can.

    --

    Some people take their .sig way too seriously

    1. Re:DON'T /. THE NAMED.ROOT FILES!!!! by Anonymous Coward · · Score: -1, Flamebait

      what did you expect from leenux lemmings who can't even pick a real free OS? leenux losers are just plain stupid.

    2. Re:DON'T /. THE NAMED.ROOT FILES!!!! by Anonymous Coward · · Score: -1, Offtopic

      don't be critical, it will just get you modded down

    3. Re:DON'T /. THE NAMED.ROOT FILES!!!! by Anonymous Coward · · Score: 2, Funny

      I don't know, I clicked on the link 100 times and it worked ok for me.

    4. Re:DON'T /. THE NAMED.ROOT FILES!!!! by sys$manager · · Score: 3, Insightful

      Nobody needs to legitimately access those files to update their DNS servers. Everything will continue to work fine even if nobody could access those files. Even if you NEEDED to update your root hints file (which you don't), you can always lookup the NS records on another root server and output it to your hints file.

      Nice troll though, it went totally unnoticed until now.

    5. Re:DON'T /. THE NAMED.ROOT FILES!!!! by Anonymous Coward · · Score: 0

      Why are you even posting if the inevitable is bound to happen? Do you really think you'll see a drop off in attempts via this post? Work on the source of the problem, which is poor communication and supposed traffic management, than whining. If you're that concerned about traffic then perhaps an infrastructure/architecture change for how these statements are announced should be under review.

    6. Re:DON'T /. THE NAMED.ROOT FILES!!!! by edA-qa · · Score: 3, Insightful

      Why shouldn't somebody look if they are curious? I often hear about problems resulting from people not knowing enough about computers and the internet, perhaps looking at these root files is a good thing -- certainly some people will just be confused, but others might actually be even more curious and try to figure out what they mean.

      Any extra bit of knowledge anybody has about the internet probably helps everybody in the long run.

      And in any case, since nobody needs this root file immediately, and since the /. effect disappears in a few days, there shouldn't be any concern. At very least, consider this a fair test of the system, we wouldn't want our root name servers running on anything not-up-to-the-job, would we?

    7. Re:DON'T /. THE NAMED.ROOT FILES!!!! by Anonymous Coward · · Score: 0

      Oh yeah, that little text file being downloaded is just going to kill the server.

      Apparently some people are so taken by this mythical "Slashdot effect" that all reason begins to fail them. Those servers survived a massive DoS attack. The "Slashdot effect" only kills servers which are hosting large pages.

      Get a grip. Those servers probably get bombarded by requests more often than any Slashdot viewer could possibly imagine. They are not fragile little flowers and Slashdot isn't nearly popular enough to come close to DoSing it.

      Next you're going to be telling us the sky is falling.

      Ben

    8. Re:DON'T /. THE NAMED.ROOT FILES!!!! by Phroggy · · Score: 3, Insightful

      People need to legitimately access those files to update their DNS servers and flooding the FTP with meaningless requests is highly counterproductive.

      No they don't. People need to type:
      dig @a.root-servers.net > root.hints
      and they'll get exactly the same thing. Much faster and easier, and you can't tell me we're going to slashdot a root nameserver by sending it a bunch of DNS queries like this - that's what root nameservers handle all day.

      --
      $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
      $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
    9. Re:DON'T /. THE NAMED.ROOT FILES!!!! by maw · · Score: 1
      Nobody needs to legitimately access those files to update their DNS servers.

      Wrong. Well-written dns servers will not accept out-of-bailiwick information, since that leaves them susceptable to cache poisoning.

      Even if you NEEDED to update your root hints file (which you don't)....

      You do need to update them. It isn't likely that the rest of the root servers will change tomorrow or next week or next month, but it will happen eventually. Keeping your site's list of root servers current is essential for reliability. Otherwise, the (caveated) guarantees of reliability in the dns are lost.

      Nice troll though, it went totally unnoticed until now.

      Not a troll, just naive.

      --
      You're a suburbanite.
    10. Re:DON'T /. THE NAMED.ROOT FILES!!!! by Anonymous Coward · · Score: -1, Offtopic

      see, tried to tell you

      Moderation Totals: Flamebait=1, Troll=1, Redundant=1, Insightful=4, Interesting=1, Informative=1, Overrated=1, Total=10.

      10 mod points and 4 were negative!

    11. Re:DON'T /. THE NAMED.ROOT FILES!!!! by ryanvm · · Score: 3, Informative

      Please don't /. the named.root files.

      Oh get serious.

      1) Slashdot is not that big. I think the Internet's root servers just might be able to handle a bigger load than you think.

      2) There are 12 (?) other root servers out there to get your root hints from. If any sysadmins out there give up on downloading the root hints because one freakin' server doesn't respond - well, they've got bigger problems.

    12. Re:DON'T /. THE NAMED.ROOT FILES!!!! by MikeBabcock · · Score: 2

      The root servers only have to serve relatively small UDP results for the most part; you can compare the size of the UDP results to a DNS query with the size of the roots file and determine if there's a load difference or not ...

      --
      - Michael T. Babcock (Yes, I blog)
    13. Re:DON'T /. THE NAMED.ROOT FILES!!!! by MikeBabcock · · Score: 2

      Download the tools from cr.yp.to for doing DNS queries (if you're running a *nix variant) and do a

      dnstrace a www.slashdot.org a.root-servers.net | dnstracesort | less
      and watch the results.

      The results are available on my website as a text file; take a look if you don't have the tools above.

      dnstrace is a great program for seeing how DNS resolvers resolve names to IP addresses. To see a visual diagram try dnsbajaj. It gives a graph of how it got to a domain from a root server, and which nameservers are qualified to answer for those queries.

      --
      - Michael T. Babcock (Yes, I blog)
  45. Poor trees by Anonymous Coward · · Score: 0

    The trees should be really upset by this. They have used the same zone for millions of years.

  46. Try Flowers netx time by RatBastard · · Score: 4, Funny

    I hear flowers and or chocolates will reduce the number of macings a geek will suffer in his lifetime.

    You could also ask before you go rooting around the garden.

    --
    Boobies never hurt anyone. - Sherry Glaser.
    1. Re:Try Flowers netx time by grub · · Score: 3, Funny


      You could also ask before..

      Ask? Generally the first exchange of words is "Hey! You in the bushes!"

      --
      Trolling is a art,
    2. Re:Try Flowers netx time by Anonymous Coward · · Score: 1, Funny

      Dating advice for geeks:

      Don't bring a girl chocolates. None of them like it and it can only get you in trouble. If they're in a heart shaped box, girls will think it's retarded and cliche.

      Flowers are another story. Flowers can help you out early on in the relationship and get you out of jams later on. There are a few rules thought. Roses are cliche, but still nice. They show effort but not imagination. Carnations scream that you're broke or cheap. And rule three, make sure you don't buy a funeral boquet. Beyond that, it's pretty hard to go wrong. If the woman at the flower shop is under 65, your best bet is to give her a price range and let her do her thing.

      Yeah, it's off topic. But most geeks really need to know this stuff and almost none of them do.

    3. Re:Try Flowers netx time by Anonymous Coward · · Score: 0

      Girls don't like chocolate? Now that's a funny one. The only thing they don't like about it is what it does to their waist line.

      If you want to be a relly clever male, invent calorie free chocolate that tastes just like the real stuff, with no side effects, and you will have all the women (and money) that you could ever hope to have.

    4. Re:Try Flowers netx time by HiredMan · · Score: 2

      While we're wildly off-topic...

      "Just once I'd like somebody to call me 'Sir' without adding 'you're making a scene!'".
      -Homer Simpson

      "In college I was shy. Now they call it stalking - but I was shy..."
      -Comic whose name escapes me.

      =tkk

      --
      Bill Gates - Creationist?!?
    5. Re:Try Flowers netx time by Anonymous Coward · · Score: 0

      Oh girls like chocolate. The just don't want you to buy them chocolate.

    6. Re:Try Flowers netx time by Anonymous Coward · · Score: 0
      "In college I was shy. Now they call it stalking - but I was shy..."


      Sounds like redmeat

  47. Something broke my BIND by Anonymous Coward · · Score: -1, Troll

    I think it might be due to Michael being a trolling cunt. Is there an impossible-to-understand Lunix howto that covers this in condescending detail?

    I'm sure there is. I'll have to find one.

  48. So why is MIchael still working here by Anonymous Coward · · Score: -1, Troll

    if he's a cunt like all the mods?

  49. The Change is not reflected at WHOIS by Anonymous Coward · · Score: 2, Informative

    [OS/390]$ whois root-servers.net
    [whois.crsnic.net]

    Whois Server Version 1.3

    Domain names in the .com, .net, and .org domains can now be registered
    with many different competing registrars. Go to http://www.internic.net
    for detailed information.

    Domain Name: ROOT-SERVERS.NET
    Registrar: NETWORK SOLUTIONS, INC.
    Whois Server: whois.networksolutions.com
    Referral URL: http://www.networksolutions.com
    Name Server: A.ROOT-SERVERS.NET
    Name Server: F.ROOT-SERVERS.NET
    Name Server: J.ROOT-SERVERS.NET
    Name Server: K.ROOT-SERVERS.NET
    Updated Date: 23-aug-2002

    >>> Last update of whois database: Thu, 7 Nov 2002 05:05:26 EST <<<
    The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and
    Registrars.

    [whois.networksolutions.com]
    The Data in the VeriSign Registrar WHOIS database is provided by VeriSign for
    information purposes only, and to assist persons in obtaining information about
    or related to a domain name registration record. VeriSign does not guarantee
    its accuracy. Additionally, the data may not reflect updates to billing contact
    information. By submitting a WHOIS query, you agree to use this Data only
    for lawful purposes and that under no circumstances will you use this Data to:
    (1) allow, enable, or otherwise support the transmission of mass unsolicited,
    commercial advertising or solicitations via e-mail, telephone, or facsimile; or
    (2) enable high volume, automated, electronic processes that apply to VeriSign
    (or its computer systems). The compilation, repackaging, dissemination or
    other use of this Data is expressly prohibited without the prior written
    consent of VeriSign. VeriSign reserves the right to terminate your access to
    the VeriSign Registrar WHOIS database in its sole discretion, including
    without limitation, for excessive querying of the WHOIS database or for failure
    to otherwise abide by this policy. VeriSign reserves the right to modify these
    terms at any time. By submitting this query, you agree to abide by this policy.

    Registrant:
    VERISIGN GLOBAL REGISTRY SERVICES (ROOT-SERVERS-DOM)
    21345 Ridgetop Circle
    Dulles, VA 20166
    US

    Domain Name: ROOT-SERVERS.NET

    Administrative Contact:
    Internet Assigned Numbers Authority (IANA) iana@IANA.ORG
    4676 Admiralty Way, Suite 330
    Marina del Rey, CA 90292
    US
    310-823-9358
    Fax- 310-823-8649
    Technical Contact:
    VeriSign Global Registry Services (REGISTRY) nocnoc@VERISIGN.COM
    21345 Ridgetop Circle
    Dulles, VA 20166
    US
    703-948-7064
    Fax-703-421-6703

    Record expires on 05-Jul-2005.
    Record created on 04-Jul-1995.
    Database last updated on 7-Nov-2002 15:25:52 EST.

    Domain servers in listed order:

    A.ROOT-SERVERS.NET 198.41.0.4
    F.ROOT-SERVERS.NET 192.5.5.241
    J.ROOT-SERVERS.NET 198.41.0.10
    K.ROOT-SERVERS.NET 193.0.14.129

    1. Re:The Change is not reflected at WHOIS by jroysdon · · Score: 1


      I'm sure they'll get to it eventually. But as you may know, WHOIS data isn't what matters and is solely for informational reference.

  50. Where are the mods? by Anonymous Coward · · Score: -1, Offtopic

    All typing away at their win98 boxen preaching the good word about open sores and buttfucking Michael to make him so crabby

  51. Pulled up by the roots by Gizzmonic · · Score: 1, Offtopic
    You know, this reminds me a lot of the C.S Lewis classic, The Silver Chair. The enchanted Prince Rilian is only sane for one hour, when he is tied to his enchanted silver chair.

    It makes me wonder-is DNS only sane when the world root servers are switching. Is this the time for the Puddleglums and Poles of the world to sally forth and cut the cords of DNS for good?

    --
    (-1, Raw and Uncut is the only way to read)
    1. Re:Pulled up by the roots by ethereal · · Score: 1

      Favorite line from the book:

      "Resh-PECK-O-Biggle!" -- a very drunk Puddlegum

      --

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

  52. newspaper had it by jeavis · · Score: 3, Informative

    A short blurb on this appeared in my local paper today (they don't have it online, sorry). The gist of it is Verisign physically relocated the server to another building on their campus. The stated intent was (1) to move it to an undisclosed location in the interest of physical security, and (2) to get it off a network segment that another root server (a.root-servers.net) was already on.

  53. Too many moves, too many critical paths by 1984 · · Score: 2
    "I wonder why we did not use this as an opportunity to redress the imbalance of root server placement"

    I'm guessing (and yes, guessing) that it was just to be conservative. There's probably a lot less to do, far fewer people to involve to move a machine across town, that to implement a geographically distributed bunch of servers. Setting up a DNS server and plugging it in might be easy, but coordinating different teams, new locations, procedures, languages for administration etc. isn't trivial.

    In fact it's probably a little fiddly procedurally, and a lot fiddly politically. Probably one of those things that gets mired for years.

    1. Re:Too many moves, too many critical paths by valdis · · Score: 4, Informative

      Quite correct - there's only a little bit of procedurally/technically fiddly about it.

      Your average root nameserver gets hit for about 100M queries per day (or on the order of 1,500 per second). See http://www.caida.org/~kkeys/dns/ for details. A root nameserver is expected to get pounded on by *mostly* invalid queries (see http://www.nanog.org/mtg-0210/wessels.html). The Wessels data was *normal production* workload, not during a DDoS.

      All the usual considerations regarding BGP multihoming and hardware redundancy apply. There's reasons why the servers are Sun E10K or large IBM boxes or similar big iron, and why people who have just a T-1 from Barney's ISP, Bait, and Tackle Shop need not apply.

      Of course, there's nothing in the above that can't be solved by applying clue and dollars. However...

      Ever priced a E10K? And noticed that most of the root nameservers are basically donated by their hosts? That's where the politically fiddly comes in - the number of places that are clued enough to run a root DNS, network connected well enough to be worth it, and willing to donate the resources to do it, is a lot smaller than you might expect...

  54. michael is a pathetic coward by Anonymous Coward · · Score: -1, Offtopic

    see? its all right here

  55. DDOS by dirvish · · Score: 3, Interesting

    Does this have to do with the DDOS attacks that happened a couple weeks ago? Why else would they not make an announcement? OTOH, the perpetrators of the attacks wouldn't be fooled for long by a name change.

    --
    FoundNews.com - get paid to blog.,
    1. Re:DDOS by winnetou · · Score: 2, Informative
      Does this have to do with the DDOS attacks that happened a couple weeks ago?
      Possibly, a and j.root-servers.net are now in different netblocks, making a DDoS a bit more difficult.

      Why else would they not make an announcement?
      Because nameservers use the "hints" zone as a hints zone, i.e. they will fetch the authoritative nameservers using the IP addresses in the "hints" zone to find an answering nameserver.
      Since j.root-servers.net will continue to answer at the old address, no one will notice the change.

    2. Re:DDOS by TheSHAD0W · · Score: 2

      > Since j.root-servers.net will continue to answer at
      > the old address, no one will notice the change.

      Wouldn't that mean you could STILL DDoS both A and J at the same time?

    3. Re:DDOS by puetzk · · Score: 1

      there is a new J, in a different block.

      There is also the machine & IP which used to be J, which is still present, will be kept up-to-date, and will still answer you (for some period of time), though it is no longer the official J root nameserver.

      --
      The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
  56. Imagine the excitement this news will cause... by slipgun · · Score: 2

    The server j.root-servers.net has changed IP address to 192.58.128.30.

    Wow, that's pretty close to my home network address!

    --
    SpamNet - a spam blocker that really works
    1. Re:Imagine the excitement this news will cause... by Nintendork · · Score: 4, Funny
      Same here. Although my main IP address is 127.0.0.1

      I dare you all to hack me!

    2. Re:Imagine the excitement this news will cause... by jemoody · · Score: 1

      "Hello? You want a what resolved? Who are you looking for? No no no, this is one-nine-*one* dot five-eight dot one-two-eight dot thirty. No problem. Good luck. Bye."

    3. Re:Imagine the excitement this news will cause... by isorox · · Score: 2

      my main IP address is 127.0.0.1
      I dare you all to hack me!

      Dude, you're computer is as wide open as the goatse man - and you've got at least 3 trojans installed!

    4. Re:Imagine the excitement this news will cause... by AndroidCat · · Score: 2

      And he's got all the sekret scientology stuff on it: 127.0.0.1

      --
      One line blog. I hear that they're called Twitters now.
  57. How about query response times? by whovian · · Score: 1, Flamebait

    http://www.cymru.com/DNS/dns.html

    --
    To-do List: Receive telemarketing call during a tornado warning. Check.
  58. where did all my posts go? by Anonymous Coward · · Score: -1, Troll

    Oh they're gone because of the dickcheese

  59. j.root-servers.net did not change hands. by winnetou · · Score: 4, Informative

    j.root-servers.net was 198.41.0.10 in 198.41.0.0/22, owned by VeriSign Global Registry Services.
    j.root-servers.net is 192.58.128.30 now, in 192.58.128.0/24, owned by VeriSign Global Registry Services.
    Having both a and j in the same netblock was not a good idea (remember what happened to Microsoft when they had all nameservers in the same netblock?).
    See ARIN and ARIN again.

  60. Michael and CmdrTaco are Cock Faggots by Anonymous Coward · · Score: -1, Offtopic

    8 gigabitethernet5-1-136.ipcolo2.Washington1.Level3. net (63.215.136.209) 99.174 ms 105.168 ms 100.807 ms
    9 gigabitethernet8-0.core1.Washington1.Level3.net (64.159.18.37) 85.336 ms 91.505 ms 90.106 ms
    10 cw-level3-oc12.Washington1.Level3.net (209.244.219.150) 111.822 ms 76.502 ms 116.993 ms
    11 agr4-loopback.SantaClara.cw.net (208.172.146.104) 132.439 ms 139.183 ms 177.950 ms
    12 dcr2-so-1-3-0.SantaClara.cw.net (208.172.156.157) 174.585 ms 125.559 ms 159.337 ms
    13 cable-and-wireless-internal-isp.SantaClara.cw.net (208.172.156.198) 177.333 ms 180.029 ms 150.413 ms
    14 dcr02-g10-1.sntc08.exodus.net (66.35.194.196) 177.042 ms 137.144 ms 142.823 ms
    15 csr01-ve242.sntc08.exodus.net (66.35.194.58) 125.246 ms 143.368 ms 273.901 ms
    16 66.35.212.174 (66.35.212.174) 140.565 ms 186.003 ms 131.296 ms
    8 gigabitethernet5-1-136.ipcolo2.Washington1.Level3. net (63.215.136.209) 79.281 ms 124.104 ms 107.286 ms
    9 ae0-53.gar1.Washington1.Level3.net (64.159.18.77) 80.211 ms 83.066 ms 99.858 ms
    10 so-6-0-0.edge1.Washington1.Level3.net (209.244.11.10) 93.622 ms 76.178 ms 75.466 ms
    11 sl-st20-ash.sprintlink.net (209.244.219.170) 116.826 ms 88.640 ms 85.984 ms
    12 sl-bb25-rly-15-3.sprintlink.net (144.232.20.4) 86.744 ms 79.198 ms 73.650 ms
    13 sl-bb21-sj-5-3.sprintlink.net (144.232.20.91) 126.422 ms 150.122 ms 125.562 ms
    14 sl-bb20-sj-14-0.sprintlink.net (144.232.3.157) 119.726 ms 131.540 ms 124.452 ms
    15 sl-gw11-sj-9-0.sprintlink.net (144.232.3.138) 140.652 ms 133.844 ms 148.016 ms
    16 sl-ciscopsn2-11-0-0.sprintlink.net (144.228.44.14) 141.471 ms 127.684 ms 138.909 ms
    17 sjck-dirty-gw1.cisco.com (128.107.239.5) 118.757 ms 126.444 ms 164.723 ms
    18 sjck-sdf-ciod-gw1.cisco.com (128.107.239.106) 131.568 ms 119.764 ms 130.583 ms
    8 gigabitethernet5-1-136.ipcolo2.Washington1.Level3. net (63.215.136.209) 101.909 ms 93.442 ms 122.531 ms
    9 gigabitethernet8-0.core1.Washington1.Level3.net (64.159.18.37) 99.632 ms 75.954 ms 76.329 ms
    10 cw-level3-oc12.Washington1.Level3.net (209.244.219.150) 90.947 ms 77.652 ms 79.919 ms
    11 agr3-loopback.SantaClara.cw.net (208.172.146.103) 126.223 ms 123.470 ms 125.940 ms
    12 dcr1-so-1-2-0.SantaClara.cw.net (208.172.156.25) 135.329 ms 122.395 ms 122.421 ms
    13 ibr01-p5-0.sntc05.exodus.net (208.172.156.74) 126.563 ms 120.868 ms 148.296 ms
    14 dcr01-g6-1.sntc05.exodus.net (64.56.192.195) 128.222 ms 138.695 ms 145.097 ms
    15 csr11-ve240.sntc05.exodus.net (64.56.192.82) 128.091 ms 150.121 ms 153.368 ms
    16 sourceforge.net (216.136.171.196) 138.061 ms 128.780 ms 166.523 ms
    ping -s 1 -i .1 192.58.128.30
    PING 192.58.128.30 (192.58.128.30): 1 data bytes
    9 bytes from 192.58.128.30: icmp_seq=0 ttl=236
    9 bytes from 192.58.128.30: icmp_seq=1 ttl=236
    9 bytes from 192.58.128.30: icmp_seq=2 ttl=236
    9 bytes from 192.58.128.30: icmp_seq=3 ttl=236
    9 bytes from 192.58.128.30: icmp_seq=4 ttl=236
    9 bytes from 192.58.128.30: icmp_seq=5 ttl=236
    9 bytes from 192.58.128.30: icmp_seq=6 ttl=236
    9 bytes from 192.58.128.30: icmp_seq=7 ttl=236
    9 bytes from 192.58.128.30: icmp_seq=8 ttl=236

  61. icmp_seq=2000! by Anonymous Coward · · Score: -1, Offtopic

    64 bytes from 192.58.128.30: icmp_seq=1876 ttl=234 time=196 ms
    64 bytes from 192.58.128.30: icmp_seq=1877 ttl=234 time=183 ms
    64 bytes from 192.58.128.30: icmp_seq=1878 ttl=234 time=174 ms
    64 bytes from 192.58.128.30: icmp_seq=1879 ttl=234 time=183 ms
    64 bytes from 192.58.128.30: icmp_seq=1880 ttl=234 time=193 ms
    64 bytes from 192.58.128.30: icmp_seq=1881 ttl=234 time=206 ms
    64 bytes from 192.58.128.30: icmp_seq=1882 ttl=234 time=172 ms
    64 bytes from 192.58.128.30: icmp_seq=1883 ttl=234 time=180 ms
    64 bytes from 192.58.128.30: icmp_seq=1884 ttl=234 time=216 ms
    64 bytes from 192.58.128.30: icmp_seq=1885 ttl=234 time=97.1 ms
    64 bytes from 192.58.128.30: icmp_seq=1886 ttl=234 time=103 ms
    64 bytes from 192.58.128.30: icmp_seq=1887 ttl=234 time=216 ms
    64 bytes from 192.58.128.30: icmp_seq=1888 ttl=234 time=198 ms
    64 bytes from 192.58.128.30: icmp_seq=1889 ttl=234 time=116 ms
    64 bytes from 192.58.128.30: icmp_seq=1890 ttl=234 time=92.6 ms
    64 bytes from 192.58.128.30: icmp_seq=1891 ttl=234 time=92.9 ms
    64 bytes from 192.58.128.30: icmp_seq=1892 ttl=234 time=93.0 ms
    64 bytes from 192.58.128.30: icmp_seq=1893 ttl=234 time=96.4 ms
    64 bytes from 192.58.128.30: icmp_seq=1894 ttl=234 time=94.1 ms
    64 bytes from 192.58.128.30: icmp_seq=1895 ttl=234 time=131 ms
    64 bytes from 192.58.128.30: icmp_seq=1896 ttl=234 time=111 ms
    64 bytes from 192.58.128.30: icmp_seq=1897 ttl=234 time=147 ms
    64 bytes from 192.58.128.30: icmp_seq=1898 ttl=234 time=186 ms
    64 bytes from 192.58.128.30: icmp_seq=1899 ttl=234 time=143 ms
    64 bytes from 192.58.128.30: icmp_seq=1900 ttl=234 time=180 ms
    64 bytes from 192.58.128.30: icmp_seq=1901 ttl=234 time=186 ms
    64 bytes from 192.58.128.30: icmp_seq=1902 ttl=234 time=129 ms
    64 bytes from 192.58.128.30: icmp_seq=1903 ttl=234 time=200 ms
    64 bytes from 192.58.128.30: icmp_seq=1904 ttl=234 time=185 ms
    64 bytes from 192.58.128.30: icmp_seq=1905 ttl=234 time=189 ms
    64 bytes from 192.58.128.30: icmp_seq=1906 ttl=234 time=203 ms
    64 bytes from 192.58.128.30: icmp_seq=1907 ttl=234 time=186 ms
    64 bytes from 192.58.128.30: icmp_seq=1908 ttl=234 time=174 ms
    64 bytes from 192.58.128.30: icmp_seq=1910 ttl=234 time=167 ms
    64 bytes from 192.58.128.30: icmp_seq=1911 ttl=234 time=205 ms
    64 bytes from 192.58.128.30: icmp_seq=1912 ttl=234 time=115 ms
    64 bytes from 192.58.128.30: icmp_seq=1913 ttl=234 time=99.0 ms
    64 bytes from 192.58.128.30: icmp_seq=1914 ttl=234 time=92.5 ms
    64 bytes from 192.58.128.30: icmp_seq=1915 ttl=234 time=110 ms
    64 bytes from 192.58.128.30: icmp_seq=1916 ttl=234 time=219 ms
    64 bytes from 192.58.128.30: icmp_seq=1917 ttl=234 time=154 ms
    64 bytes from 192.58.128.30: icmp_seq=1918 ttl=234 time=183 ms
    64 bytes from 192.58.128.30: icmp_seq=1919 ttl=234 time=93.5 ms
    64 bytes from 192.58.128.30: icmp_seq=1920 ttl=234 time=113 ms
    64 bytes from 192.58.128.30: icmp_seq=1921 ttl=234 time=115 ms
    64 bytes from 192.58.128.30: icmp_seq=1922 ttl=234 time=122 ms
    64 bytes from 192.58.128.30: icmp_seq=1923 ttl=234 time=96.2 ms
    64 bytes from 192.58.128.30: icmp_seq=1924 ttl=234 time=211 ms
    64 bytes from 192.58.128.30: icmp_seq=1925 ttl=234 time=161 ms
    64 bytes from 192.58.128.30: icmp_seq=1926 ttl=234 time=146 ms
    64 bytes from 192.58.128.30: icmp_seq=1927 ttl=234 time=182 ms
    64 bytes from 192.58.128.30: icmp_seq=1928 ttl=234 time=179 ms
    64 bytes from 192.58.128.30: icmp_seq=1929 ttl=234 time=230 ms
    64 bytes from 192.58.128.30: icmp_seq=1930 ttl=234 time=195 ms
    64 bytes from 192.58.128.30: icmp_seq=1931 ttl=234 time=189 ms
    64 bytes from 192.58.128.30: icmp_seq=1932 ttl=234 time=210 ms
    64 bytes from 192.58.128.30: icmp_seq=1933 ttl=234 time=181 ms
    64 bytes from 192.58.128.30: icmp_seq=1934 ttl=234 time=191 ms
    64 bytes from 192.58.128.30: icmp_seq=1935 ttl=234 time=131 ms
    64 bytes from 192.58.128.30: icmp_seq=1936 ttl=234 time=189 ms
    64 bytes from 192.58.128.30: icmp_seq=1937 ttl=234 time=201 ms
    64 bytes from 192.58.128.30: icmp_seq=1938 ttl=234 time=234 ms
    64 bytes from 192.58.128.30: icmp_seq=1939 ttl=234 time=200 ms
    64 bytes from 192.58.128.30: icmp_seq=1940 ttl=234 time=193 ms
    64 bytes from 192.58.128.30: icmp_seq=1941 ttl=234 time=132 ms
    64 bytes from 192.58.128.30: icmp_seq=1942 ttl=234 time=199 ms
    64 bytes from 192.58.128.30: icmp_seq=1943 ttl=234 time=208 ms
    64 bytes from 192.58.128.30: icmp_seq=1944 ttl=234 time=190 ms
    64 bytes from 192.58.128.30: icmp_seq=1945 ttl=234 time=196 ms
    64 bytes from 192.58.128.30: icmp_seq=1946 ttl=234 time=210 ms
    64 bytes from 192.58.128.30: icmp_seq=1947 ttl=234 time=171 ms
    64 bytes from 192.58.128.30: icmp_seq=1948 ttl=234 time=208 ms
    64 bytes from 192.58.128.30: icmp_seq=1949 ttl=234 time=204 ms
    64 bytes from 192.58.128.30: icmp_seq=1950 ttl=234 time=189 ms
    64 bytes from 192.58.128.30: icmp_seq=1951 ttl=234 time=225 ms
    64 bytes from 192.58.128.30: icmp_seq=1952 ttl=234 time=162 ms
    64 bytes from 192.58.128.30: icmp_seq=1953 ttl=234 time=159 ms
    64 bytes from 192.58.128.30: icmp_seq=1954 ttl=234 time=177 ms
    64 bytes from 192.58.128.30: icmp_seq=1955 ttl=234 time=150 ms
    64 bytes from 192.58.128.30: icmp_seq=1956 ttl=234 time=175 ms
    64 bytes from 192.58.128.30: icmp_seq=1957 ttl=234 time=229 ms
    64 bytes from 192.58.128.30: icmp_seq=1958 ttl=234 time=131 ms
    64 bytes from 192.58.128.30: icmp_seq=1959 ttl=234 time=164 ms
    64 bytes from 192.58.128.30: icmp_seq=1960 ttl=234 time=182 ms
    64 bytes from 192.58.128.30: icmp_seq=1961 ttl=234 time=190 ms
    64 bytes from 192.58.128.30: icmp_seq=1962 ttl=234 time=247 ms
    64 bytes from 192.58.128.30: icmp_seq=1963 ttl=234 time=188 ms
    64 bytes from 192.58.128.30: icmp_seq=1964 ttl=234 time=117 ms
    64 bytes from 192.58.128.30: icmp_seq=1965 ttl=234 time=154 ms
    64 bytes from 192.58.128.30: icmp_seq=1966 ttl=234 time=141 ms
    64 bytes from 192.58.128.30: icmp_seq=1967 ttl=234 time=126 ms
    64 bytes from 192.58.128.30: icmp_seq=1968 ttl=234 time=161 ms
    64 bytes from 192.58.128.30: icmp_seq=1969 ttl=234 time=199 ms
    64 bytes from 192.58.128.30: icmp_seq=1970 ttl=234 time=207 ms
    64 bytes from 192.58.128.30: icmp_seq=1971 ttl=234 time=219 ms
    64 bytes from 192.58.128.30: icmp_seq=1972 ttl=234 time=208 ms
    64 bytes from 192.58.128.30: icmp_seq=1973 ttl=234 time=170 ms
    64 bytes from 192.58.128.30: icmp_seq=1974 ttl=234 time=187 ms
    64 bytes from 192.58.128.30: icmp_seq=1975 ttl=234 time=195 ms
    64 bytes from 192.58.128.30: icmp_seq=1976 ttl=234 time=182 ms
    64 bytes from 192.58.128.30: icmp_seq=1977 ttl=234 time=193 ms
    64 bytes from 192.58.128.30: icmp_seq=1978 ttl=234 time=203 ms
    64 bytes from 192.58.128.30: icmp_seq=1979 ttl=234 time=193 ms
    64 bytes from 192.58.128.30: icmp_seq=1980 ttl=234 time=203 ms
    64 bytes from 192.58.128.30: icmp_seq=1981 ttl=234 time=145 ms
    64 bytes from 192.58.128.30: icmp_seq=1982 ttl=234 time=131 ms
    64 bytes from 192.58.128.30: icmp_seq=1983 ttl=234 time=142 ms
    64 bytes from 192.58.128.30: icmp_seq=1984 ttl=234 time=203 ms
    64 bytes from 192.58.128.30: icmp_seq=1985 ttl=234 time=189 ms
    64 bytes from 192.58.128.30: icmp_seq=1986 ttl=234 time=203 ms
    64 bytes from 192.58.128.30: icmp_seq=1987 ttl=234 time=213 ms
    64 bytes from 192.58.128.30: icmp_seq=1988 ttl=234 time=203 ms
    64 bytes from 192.58.128.30: icmp_seq=1989 ttl=234 time=190 ms
    64 bytes from 192.58.128.30: icmp_seq=1990 ttl=234 time=200 ms
    64 bytes from 192.58.128.30: icmp_seq=1991 ttl=234 time=165 ms
    64 bytes from 192.58.128.30: icmp_seq=1992 ttl=234 time=173 ms
    64 bytes from 192.58.128.30: icmp_seq=1993 ttl=234 time=189 ms
    64 bytes from 192.58.128.30: icmp_seq=1994 ttl=234 time=175 ms
    64 bytes from 192.58.128.30: icmp_seq=1995 ttl=234 time=165 ms
    64 bytes from 192.58.128.30: icmp_seq=1996 ttl=234 time=151 ms
    64 bytes from 192.58.128.30: icmp_seq=1997 ttl=234 time=161 ms
    64 bytes from 192.58.128.30: icmp_seq=1998 ttl=234 time=199 ms
    64 bytes from 192.58.128.30: icmp_seq=1999 ttl=234 time=164 ms
    64 bytes from 192.58.128.30: icmp_seq=2000 ttl=234 time=197 ms

    Yes, 2000 pings and couting! j.root-servers.net is going to feel da pain!

  62. Paid to look at porn by IIEFreeMan · · Score: 0, Offtopic

    Yup see this article on k5 : Get Paid To Look At Porn !

  63. Wow.. by NicolaiBSD · · Score: 1

    My God. A DNS change. Life is great.

    If only everyone was as easily excited as a geek, i'd actually have a sexlife.

  64. "Verisign causing instability as usual" by Anonymous Coward · · Score: 0

    Nice trolling line there, michael, you fucking twat.

    In case ol' mikey gets it into his head to delete cetan's educational journal entry, here it is:

    I'm writing this entry to point my new sig to effectively. This link will take you to a thread in a seemingly small article. What's important to understand is that the /. editor, michael, decided to yet again abuse the moderation system by modding every single one of my posts to -1. He removed 30 karma points in one article because I did not like his extra "comment" at the end of the article he posted. It's sad how pathetic michael is.

    Here's the link: http://slashdot.org/comments.pl?sid=40037&threshol d=-1&commentsort=0&tid=134&mode=nested&cid=4267381

    1. Re:"Verisign causing instability as usual" by arctuniol · · Score: 1

      13 root servers maintain the records that every other DNS server looks at. They synchronize depending on your TTL settings. If a root servers is moved it will update the rest of the world in about 72 hours,without having to make any changes to your DNS settings or local files.

      That is one of the benefits of using the DNS system rather then every machine keep a record of data locally in your .host file or whatever.

  65. Whoa. by StupidKatz · · Score: 3, Funny

    $ ftp rs.internic.net
    Connected to rs.internic.net (198.41.0.6).
    in.ftpd: error in loading shared libraries: libdl.so.2: cannot open shared object file: Error 23
    ftp>

    Slashdotted an FTP server. On some sort of *nix. Ouch.

  66. Bind Root Zone Migration HOWTO by nsushkin · · Score: 2, Informative

    [root@localhost named]# perl -pi.orig -e "s'198.41.0.10'192.58.128.30'" /var/named/named.ca

    [root@localhost named]# diff /var/named/named.ca /var/named/named.ca.orig
    67c67
    < J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30
    ---
    > J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10

  67. Michael's Anal Leakage is CmdrTaco's Wet Dream! by Anonymous Coward · · Score: -1, Offtopic

    9 bytes from 192.58.128.30: icmp_seq=4013 ttl=236
    9 bytes from 192.58.128.30: icmp_seq=4014 ttl=236
    9 bytes from 192.58.128.30: icmp_seq=4015 ttl=236
    9 bytes from 192.58.128.30: icmp_seq=4016 ttl=236
    9 bytes from 192.58.128.30: icmp_seq=4017 ttl=236
    9 bytes from 192.58.128.30: icmp_seq=4018 ttl=236 8 vva-paix.hotmail.net (198.32.190.23) 49.508 ms 93.407 ms 53.023 ms
    9 gig1-0.core1.was1.us.msn.net (207.46.33.148) 62.823 ms 48.501 ms 36.167 ms
    10 pos3-0.core2.sea1.us.msn.net (207.46.33.134) 162.074 ms 138.344 ms 121.251 ms
    11 pos3-0.core1.pao1.us.msn.net (207.46.33.41) 130.916 ms 184.295 ms 143.110 ms
    12 pos15-0.core1.sea1.us.msn.net (207.46.33.29) 140.379 ms 142.792 ms 191.110 ms
    13 207.46.36.66 (207.46.36.66) 153.262 ms 142.775 ms 186.384 ms
    14 207.46.155.10 (207.46.155.10) 142.913 ms 208.285 ms 149.122 ms
    9 bytes from 198.133.219.25: icmp_seq=24 ttl=236
    9 bytes from 198.133.219.25: icmp_seq=25 ttl=236
    9 bytes from 198.133.219.25: icmp_seq=26 ttl=236
    9 bytes from 198.133.219.25: icmp_seq=38 ttl=236
    9 bytes from 198.133.219.25: icmp_seq=39 ttl=236
    9 bytes from 198.133.219.25: icmp_seq=40 ttl=236
    15:52:16.529136 192.168.2.2 > 192.168.2.55: (frag 16901:928@7400)
    15:52:16.897717 192.168.2.55.546110688 > 192.168.2.2.2049: 112 read [|nfs]
    15:52:16.898433 192.168.2.2.2049 > 192.168.2.55.546110688: reply ok 1472 read (frag 58987:1480@0+)
    15:52:16.898550 192.168.2.2 > 192.168.2.55: (frag 58987:1480@1480+)
    15:52:16.898674 192.168.2.2 > 192.168.2.55: (frag 58987:1480@2960+)
    15:52:16.898797 192.168.2.2 > 192.168.2.55: (frag 58987:1480@4440+)
    15:52:16.898921 192.168.2.2 > 192.168.2.55: (frag 58987:1480@5920+)
    15:52:16.899006 192.168.2.2 > 192.168.2.55: (frag 58987:928@7400)
    15:52:17.068094 192.168.2.55.22 > 192.168.2.98.1592: P 4820:5152(332) ack 1 win 65535 (DF) [tos 0x10]
    15:52:17.068303 192.168.2.55.22 > 192.168.2.98.1592: P 5152:5484(332) ack 1 win 65535 (DF) [tos 0x10]
    15:52:17.068506 192.168.2.55.22 > 192.168.2.98.1592: P 5484:5792(308) ack 1 win 65535 (DF) [tos 0x10]
    15:52:17.068728 192.168.2.55.22 > 192.168.2.98.1592: P 5792:6156(364) ack 1 win 65535 (DF) [tos 0x10]
    15:52:17.068962 192.168.2.55.22 > 192.168.2.98.1592: P 6156:6488(332) ack 1 win 65535 (DF) [tos 0x10]
    15:52:17.069171 192.168.2.55.22 > 192.168.2.98.1592: P 6488:6788(300) ack 1 win 65535 (DF) [tos 0x10]
    15:52:17.069375 192.168.2.55.22 > 192.168.2.98.1592: P 6788:7112(324) ack 1 win 65535 (DF) [tos 0x10]
    15:52:17.069589 192.168.2.55.22 > 192.168.2.98.1592: P 7112:7404(292) ack 1 win 65535 (DF) [tos 0x10]
    15:52:17.069805 192.168.2.55.22 > 192.168.2.98.1592: P 7404:7736(332) ack 1 win 65535 (DF) [tos 0x10]
    15:52:17.070011 192.168.2.55.22 > 192.168.2.98.1592: P 7736:8028(292) ack 1 win 65535 (DF) [tos 0x10]
    15:52:17.074766 192.168.2.98.1592 > 192.168.2.55.22: . ack 5484 win 17520 (DF)
    15:52:17.076125 192.168.2.98.1592 > 192.168.2.55.22: . ack 6156 win 16848 (DF)
    15:52:17.076594 192.168.2.98.1592 > 192.168.2.55.22: . ack 6788 win 16216 (DF)
    15:52:17.079886 192.168.2.98.1592 > 192.168.2.55.22: . ack 7404 win 17520 (DF)
    15:52:17.080999 192.168.2.98.1592 > 192.168.2.55.22: . ack 8028 win 16896 (DF)
    15:52:17.247654 192.168.2.55.546110689 > 192.168.2.2.2049: 112 read [|nfs]
    15:52:17.248358 192.168.2.2.2049 > 192.168.2.55.546110689: reply ok 1472 read (frag 54124:1480@0+)
    15:52:17.248477 192.168.2.2 > 192.168.2.55: (frag 54124:1480@1480+)
    15:52:17.248599 192.168.2.2 > 192.168.2.55: (frag 54124:1480@2960+)
    15:52:17.248723 192.168.2.2 > 192.168.2.55: (frag 54124:1480@4440+)
    15:52:17.248846 192.168.2.2 > 192.168.2.55: (frag 54124:1480@5920+)
    15:52:17.248924 192.168.2.2 > 192.168.2.55: (frag 54124:928@7400)
    15:52:17.558552 192.168.2.55.546110690 > 192.168.2.2.2049: 112 read [|nfs]
    15:52:17.559258 192.168.2.2.2049 > 192.168.2.55.546110690: reply ok 1472 read (frag 40775:1480@0+)
    15:52:17.559377 192.168.2.2 > 192.168.2.55: (frag 40775:1480@1480+)
    15:52:17.559498 192.168.2.2 > 192.168.2.55: (frag 40775:1480@2960+)
    15:52:17.559622 192.168.2.2 > 192.168.2.55: (frag 40775:1480@4440+)
    15:52:17.559745 192.168.2.2 > 192.168.2.55: (frag 40775:1480@5920+)
    15:52:17.559824 192.168.2.2 > 192.168.2.55: (frag 40775:928@7400)
    15:52:17.917612 192.168.2.55.546110691 > 192.168.2.2.2049: 112 read [|nfs]
    15:52:17.918337 192.168.2.2.2049 > 192.168.2.55.546110691: reply ok 1472 read (frag 2839:1480@0+)
    15:52:17.918456 192.168.2.2 > 192.168.2.55: (frag 2839:1480@1480+)
    15:52:17.918577 192.168.2.2 > 192.168.2.55: (frag 2839:1480@2960+)
    15:52:17.918701 192.168.2.2 > 192.168.2.55: (frag 2839:1480@4440+)
    15:52:17.918835 192.168.2.2 > 192.168.2.55: (frag 2839:1480@5920+)
    15:52:17.918902 192.168.2.2 > 192.168.2.55: (frag 2839:928@7400)

  68. It doesn't matter anyways... by GLX · · Score: 4, Informative

    When the change was announced, they noted specifically that the current J.ROOT-SERVERS.NET will stay in existance with it's current IP (just no direct DNS entry) and the new one has been moved to a different IP block for DoS protection... The current one will exist for awhile to come.

    This isn't really news...

    --
    Sig (appended to the end of comments you post, 120 chars)
  69. Well now that you've made it sound naughty.... by NigelJohnstone · · Score: 2, Funny

    I wasn't going to click the link, but you make it sound soooooo naughty... ;)

  70. Related to Problems? by Mr+Bubble · · Score: 0, Troll

    OK, this will probably mark me as a clueless newbie, but could this be remotely responsible for three separate issues of clients unable to resolve perfectly healthy domain names today and yesterday?

    Pinging the sites from their machines returned an "unknown host".

    --
    "The world is a construct of forceful imagination. Those who don't know walk around in the reailties of those who do"
    1. Re:Related to Problems? by Mr+Bubble · · Score: 1

      Why is this a troll?

      We had multiple users with domain name issues yesterday on perfectly stable sites. I am asking is anyone can tell me if this could have anything to do with the subject of the story.

      --
      "The world is a construct of forceful imagination. Those who don't know walk around in the reailties of those who do"
    2. Re:Related to Problems? by Anonymous Coward · · Score: 0

      No, it didn't. There were other seriously broken things on the internet yesterday rendering lots of eurpoean sites unreachable for a while.

    3. Re:Related to Problems? by Christianfreak · · Score: 2

      Well there's not a 'clueless' moderation .. :) I'm kidding,

      to answer your question: No. As many other comments have stated there are 13 root servers, if one went down your client's request would simply go to another one. But even 'J' has not completely switched over yet as it will still respond to the old IP address, according to the article for hte "foreseeable future".

      So no your DNS problems are probably related to Windows or clueless users or a combination of the two.

      --
      The Anti-Blog
  71. just because I'm too lazy to search... by mblase · · Score: 2

    As long as one of the 13 servers in your hints/cache file responds, your name server will download the updated list on startup.

    Can someone tell me why thirteen is the magic number of servers? And why that number apparently hasn't changed in all these years?

    1. Re:just because I'm too lazy to search... by digitalsushi · · Score: 2

      Baker's Dozen.

      The Root Server RFC mandates a triple redundancy, so you have your 4 root servers triplicated.

      --
      slashdot: where everyone yells sarcastic metaphors to themselves to understand the issue
    2. Re:just because I'm too lazy to search... by longhairedgnome · · Score: 0

      its lucky

      --
      GENERATION O98346: The first time you see this, copy it into your sig and remove a random number from the generation. T
    3. Re:just because I'm too lazy to search... by huskymo · · Score: 1

      The maximum size of a DNS message over UDP is 512 bytes (unless you're using EDNS0, which is relatively new). 13 NS records and the 13 corresponding A records just fits into 512 bytes, assuming domain name compression is working as efficiently as possible. And to make compression work as efficiently as possible, the domain names in the NS records should be as similar as possible, as in [a-m].root-servers.net.

      If you've been around the Internet long enough, you might remember a time when the root name servers had names like ns.nasa.gov, and there were fewer of them. Changing the names to [a-m].root-servers.net bought us room for 13.

  72. Hoax! by First_In_Hell · · Score: 1, Funny
    192.58.128.30

    ? Everyone and their bastard child knows that is a NATTED IP address. Someone is playing you for a fool!

    1. Re:Hoax! by Tony+Hoyle · · Score: 2, Insightful

      Score -1: Clueless....

      (hint: Read RFC1918 before posting)

    2. Re:Hoax! by ohboy-sleep · · Score: 1, Flamebait

      I thought NAT IPs were all 192.168.x.x

      I could be very wrong, anyone know for sure?

    3. Re:Hoax! by Anonymous Coward · · Score: 1, Informative

      Idiot. Just because it starts with 192 doesn't mean its natted.

    4. Re:Hoax! by .smoke · · Score: 2, Insightful

      You are correct... The following are for private IP addresses (e.g. for NATing):

      10.0.0.0 - 10.255.255.255 (10/8 prefix)
      172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
      192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

      This is according to RFC 1918.

      B*B,
      -Smoke.

    5. Re:Hoax! by Junta · · Score: 3, Interesting

      If that was intended as a joke, it sucked.

      If not, it is stupid.

      The IP addresses that are reserved for private use are:

      10.0.0.0/8 (10.x.x.x)
      192.168.0.0/16 (192.*168*.x.x)
      172.16.0.0/12 (172.16-31.x.x)

      Quite frankly, I'm not sure why 99.9% of the network administrators gravitate towards 192.168.1.0/24 as their private network address... Even I chose 192.168.123.0/24 as my network, so I'm partially guilty....

      If it is going to always stay a private network, why not just use the full class B? If trying to plan for communications with other private networks in the class B range, why pick something so common?

      I personally have started using 10.(random).(random).0/24 when setting up class C networks. When *really* limited use, I constrict it to /26 or so. This way the chances are low that any private network I want to set up a tunnel with will conflict with my address space...

      Of course I have yet to see 172.16.0.0/12 used by anyone, it's just too damn weird. What's the point? Some routers can't even handle non class a/b/c addresses... But saying you used the class B and a half private network should earn points on some scale..

      --
      XML is like violence. If it doesn't solve the problem, use more.
    6. Re:Hoax! by Anonymous Coward · · Score: 0
      Quite frankly, I'm not sure why 99.9% of the network administrators gravitate towards 192.168.1.0/24 as their private network address... Even I chose 192.168.123.0/24 as my network, so I'm partially guilty....

      So why don't you just ask yourself you silly little fucktard?

    7. Re:Hoax! by cjpez · · Score: 2

      We're using part of the 172.16.0.0/12 where I am currently . . .

      --
      Al Qaeda has ninjas!
    8. Re:Hoax! by gaudior · · Score: 2

      A data center I worked in used all three classes for various functions. the 192 network was for all the desktops and small department servers in the corporate network. The big HP unix application and database servers in the ASP were on both the 172 and the 10 network. All the Linux and MS servers were on the 10 network.

    9. Re:Hoax! by ShavenYak · · Score: 2

      We use the 172.16.0.0/12 range where I work now. My last place of employment used 10.0.0.0/8, but with about 30 locations across the US, they had a good reason. The second byte was used to indicate which site a machine was at, so each site had two bytes of address space to assign numbers sensibly.

      --

      Hey kids, there's only 5 days left 'til Yak Shaving Day!
    10. Re:Hoax! by feronti · · Score: 1

      We use 172.16.x.x/31 (yeah, like I'd really give you any extra info) for a PtP link to one of our outside processors... we nat to them, they nat to us.

    11. Re:Hoax! by MikeBabcock · · Score: 2

      We use 172.x.y.0/24 here ... :)

      --
      - Michael T. Babcock (Yes, I blog)
  73. I changed the text a little. by Anonymous Coward · · Score: 0

    I was getting tired of "cunt".

    michael, is a flamebaiting twat.

    In case ol' mikey gets it into his head to delete cetan's educational journal entry, here it is:

    I'm writing this entry to point my new sig to effectively. This link will take you to a thread in a seemingly small article. What's important to understand is that the /. editor, michael, decided to yet again abuse the moderation system by modding every single one of my posts to -1. He removed 30 karma points in one article because I did not like his extra "comment" at the end of the article he posted. It's sad how pathetic michael is.

    Here's the link: http://slashdot.org/comments.pl?sid=40037&threshol d=-1&commentsort=0&tid=134&mode=nested&cid=4267381

  74. what it means? by Anonymous Coward · · Score: 0

    The internet gets a new nodelist

  75. Instability? WTF? by alexjohns · · Score: 4, Insightful
    "verisign-causing-instability-as-usual dept."
    Michael Sims, you're a fucking idiot. You know nothing about the way the internet works. In no way, shape, or form does this cause any instability whatsoever. It improves stability, however slightly.

    You might want to stick to articles about politics or censorship or something. Technical issues don't appear to be your forté.

    1. Re:Instability? WTF? by alexjohns · · Score: 3
      Wow. Score: 5. For calling someone an idiot. Perhaps there's too many mod points floating around. :)

      Has anyone noticed that Michael likes to post snide insider-like comments in articles he posts? The problem is that they're sometimes wrong. It's like he's the outsider kid trying to get into the in-clique, but he keeps screwing it up.

      Wonder how long it will be before he discovers this threads and super-mods me down to -1?

  76. For DjbDNS users by chrysalis · · Score: 4, Informative

    You must put this in your /etc/dnscache/root/servers/@ file :

    128.63.2.53
    128.8.10.90
    128.9.0.107
    192.112.3 6.4
    192.203.230.10
    192.33.4.12
    192.36.148.17
    1 92.5.5.241
    192.58.128.30
    193.0.14.129
    198.32.64 .12
    198.41.0.4
    202.12.27.33

    --
    {{.sig}}
    1. Re:For DjbDNS users by PerryMason · · Score: 2

      Alright fess up. Which of those is the goatse ip?

      I dont know what it is, but I just get nervous around IPs on slashdot.;)

      --
      "I'm tired of all this 'Aren't humanity great' bullshit. We're a virus with shoes" - Bill Hicks
    2. Re:For DjbDNS users by messju · · Score: 1

      hmm.

      xargs -n1 host < @ | sort -f -k 5
      4.0.41.198.IN-ADDR.ARPA domain name pointer a.root-servers.net
      107.0.9.128.IN-ADDR.ARPA domain name pointer b.root-servers.net
      12.4.33.192.IN-ADDR.ARPA domain name pointer c.root-servers.net
      90.10.8.128.IN-ADDR.ARPA domain name pointer d.root-servers.net
      10.230.203.192.IN-ADDR.ARPA domain name pointer E.ROOT-SERVERS.NET
      241.5.5.192.IN-ADDR.ARPA domain name pointer f.root-servers.net
      4.36.112.192.IN-ADDR.ARPA domain name pointer G.ROOT-SERVERS.NET
      53.2.63.128.IN-ADDR.ARPA domain name pointer h.root-servers.net
      17.148.36.192.IN-ADDR.ARPA domain name pointer i.root-servers.net
      30.128.58.192.IN-ADDR.ARPA domain name pointer j.root-servers.net
      129.14.0.193.IN-ADDR.ARPA domain name pointer k.root-servers.net
      12.64.32.198.IN-ADDR.ARPA domain name pointer l.root-servers.net
      33.27.12.202.IN-ADDR.ARPA domain name pointer m.root-servers.net
      53.2.63.128.IN-ADDR.ARPA domain name pointer rns.arl.army.mil

      looks okay to me :)

    3. Re:For DjbDNS users by MikeBabcock · · Score: 2

      /etc/dnsroots.global is also valuable.

      --
      - Michael T. Babcock (Yes, I blog)
  77. A message from America by Qrlx · · Score: 1

    Jiminy Cricket? The Cricket in Times Square? We still don't get it.

    1. Re:A message from America by raindrop#1 · · Score: 0

      um, it's a sport. With bats and balls, kind of like baseball except better and the games can last for up to five days and still end in a draw.

    2. Re:A message from America by Anonymous Coward · · Score: 0

      Sounds like a big letdown to me.

  78. hmmm..... by colnago · · Score: 1

    Freudian?

    1. Re:hmmm..... by TheCeltic · · Score: 1

      A whorehouse is much MUCH better than a warehouse full of MS! (hell, a dollhouse is more useful)

      --
      =-=-=-=-=-=-=-= - The Celtic - =-=-=-=-=-=-=-=
  79. While you're at it, move to OpenNIC by robbo · · Score: 2, Insightful

    If your DNS admin has some savvy, this link should work for you.
    If not, visit
    OpenNIC and then ask your DNS admin to support OpenNIC and erode ICANN's dictatorial regime.

    --
    So long, and thanks for all the Phish
    1. Re:While you're at it, move to OpenNIC by Blain · · Score: 1

      I went and checked out OpenNIC a week or two ago, and it looked pretty cool. I set it up on my machine, and I can now reach cool tlds that I used to couldn't (although it can take a couple reloads to do it).

      Slight downside -- there doesn't seem to be anything there right now.

      But it works just as well as using ICANN's system for my purposes, so I'll keep it this way, and hope that somebody somewhere puts something in all these new tlds that's worth looking at.

  80. Serial number? by Phroggy · · Score: 1

    The new zone serial number is 2002110501.

    What was the old serial number?

    --
    $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
    $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
    1. Re:Serial number? by rherbert · · Score: 2, Informative

      The previous serial number was 1997082200, updated on August 22, 1997.

    2. Re:Serial number? by Anonymous Coward · · Score: 0

      I would guess the serial number would be whatever the date was when it was last changed with a couple digits after it.

      Anyway, it doesn't matter. It is arbitrary. All that matters is that the number is higher than the last one. The date is used because it is easy to recognize and always goes up.

    3. Re:Serial number? by Jugalator · · Score: 3, Informative

      > > The new zone serial number is 2002110501.
      > What was the old serial number?

      1997082200

      --
      Beware: In C++, your friends can see your privates!
  81. They do now... by Anonymous Coward · · Score: 0

    ...now that it's on computers.

  82. O'Reilly DNS and Bind book by Skjellifetti · · Score: 3, Informative

    How is this [named.root/db.cache] kept up to date? As the network administrator [of your local network], that's your responsibility. Some old versions of BIND did update this file periodically. That feature was disabled, though; apparently it didn't work as well as the authors had hoped. Sometimes the db.cache file is mailed to the bind-users or namedroppers list mailing list. If you are on one of those lists, you are likely to hear about changes. (pg 68)

    Bottom line: If you run a nameserver it is your responsibility to keep it up to date. That includes knowing how changes are announced. BIND has also had several well known security problems. If you are running a version < 8.2.5 you should upgrade that as well.

    --
    FreeSpeech.org
  83. I haven't been informed neither! So what? by MavEtJu · · Score: 3, Insightful

    The usual sites don't breathe a word about this change however as one would expect for such a change to be properly announced.

    The impact of this change is close to zero. The announcement is only necessary for people who distribute name-server software. Why?

    - Only the hints-file needs to be changed. The hints file bootstraps the DNS software on where it can find the .-zone. After that has been found, this data is not needed anymore.

    - There are still 12 other perfectly reachable servers in the hints-file. They give you all the information needed.

    - On the old IP address, a server will keep running for a while.

    - Unless you're working for an ISP, you don't need this information. The majority of the internet (windows users) don't have to change anything, they just run use their ISPs nameservers. The majority of the minority of the internet also use the nameservers of the ISP. Only a relative small group run their own servers.

    So dear anonymous writer, don't be afraid, the internet is not going to break because of this. No reason for panic, all is fine.

    --
    bash$ :(){ :|:&};:
  84. So if I understand this correctly... by Anonymous Coward · · Score: 0
    the j-th rootserver changes its address, but the 12 other didn't. Those 12 presumably know where J started to live, but still people running DNS services need to manually set the new IP-address in the next few years or so.

    Why o why don't each of the 13 root-servers keep a small list with all the addresses of the other root servers? They bloody keep such lists for the entirety of the internet.

  85. This only affects OS maintainers, not DNS admins by Anonymous Coward · · Score: 3, Informative

    I'm surprised that only one poster has even noticed that Slashdotters are barking up the wrong tree, but even (s)he didn't quite make the connection.



    For the most part, root.hints files are maintained by OS/Distribution maintainers, not DNS admins. The hints file is only used to bootstrap a DNS server which will (well, should) retrieve an authoritative copy of the root zone shortly after startup and then rely on that instead. As long as just one of the 13 root server IP addresses listed in a DNS server's root.hints file is correct, the server will successfully retrieve the updated root zone. At the rate at which changes are made to the root zone (or at least, to its delegated servers), it is likely that this condition will hold true for the next 10-20 years.



    So, as long as DNS server admins perform an OS upgrade sometime between now and the year 2012, they need not touch their server configuration at all; the change will be handled automatically.

  86. Almost but not quite... by AndroidCat · · Score: 5, Informative
    In the same way that requests go down the tree to find the server, requests go up the tree to the root servers. (Up the tree to the roots, hmm!)

    If your immediate DNS handled a request for slashdot.org two seconds previously, it should still be cached -- no need to bother a root server over that. Any request would have go up several levels before a root server would be bothered with it. (Otherwise they'd be continually /.'ed :^)

    The root servers could all disappear without a lot of disruption, but only for a short time until the cache entries started timing out.

    My backup plan is to toss the entire name space into my local hosts file. I've already got DoubleClick in there for testing. :^)

    --
    One line blog. I hear that they're called Twitters now.
    1. Re:Almost but not quite... by jez9999 · · Score: 1

      My backup plan is to toss the entire name space into my local hosts file.

      Your backup plan for what? If there was a global nuclear and biological war?

      --
      == Jez ==
      Do you miss Firefox? Try Pale Moon.
    2. Re:Almost but not quite... by AndroidCat · · Score: 1
      Your backup plan for what? If there was a global nuclear and biological war?

      Was joke. DoubleClick is in my hosts file -- at IPA 127.0.0.1.

      --
      One line blog. I hear that they're called Twitters now.
  87. DNS Server Moved by Steve0987 · · Score: 3, Informative

    As the href="http://computerworld.com/newsletter/0%2C4902 %2C75711%2C0.html?nlid=AM"article in Computer World explains, the move of the DNS server was done for both physical seperation and to move it onto a different LAN segment.

  88. your wife has moved by Anonymous Coward · · Score: 0

    your wife has moved the Yellow Pages to a different room in the house

    A mover from the Yellow Pages roomed with my wife in a different house.

  89. Spelling does not seem to be your forte by jCaT · · Score: 1, Offtopic

    Oh the irony in that... you try to sound so smart by tacking on an accent, but end up sounding stupid in the process. There is and never has been an accent anywhere in that word, as it is not supposed to be pronounced with one. The mispronunciation of the word has become so widespread that it is now accepted, but it's still not proper usage. The correct pronunciation is FORT, and since you seem to be such a fan of accents, that would be fôrt.

    Go read this, and get off your high horse, jackass.

    1. Re:Spelling does not seem to be your forte by Anonymous Coward · · Score: 0

      The correct pronunciation is FORT

      not in Italiano.

      Of course, the guy who tacked on an accent still is an idiot.

    2. Re:Spelling does not seem to be your forte by Huge+Pi+Removal · · Score: 2

      Ummmm....

      1. Thanks for pointing that out, I never realised 'forte' meaning 'strong point' came from the French (my British-English etymological dictionary bears that out as well). Interesting.

      2. Did you have to be so damn rude about it? I very nearly modded you down as a troll...

      --
      - Oliver

      The right to bear arms is only slightly less stupid than the right to arm bears...
    3. Re:Spelling does not seem to be your forte by jCaT · · Score: 2

      1. I had a teacher in high school whose only gig was vocabulary. I absolutely hated it then, but I do know a lot of words now...

      2. No, but it sure was fun.. and he was being a jackass, so I was just speaking his language. I've been here long enough to not be afraid of the moderators (hell, I am one most of the time), otherwise I would have checked the "no +1 bonus" and "post anonymously" boxes.

    4. Re:Spelling does not seem to be your forte by Anonymous Coward · · Score: 0

      Despite this thread being totally off topic. Please notice, no accent.

      Source: Oxford English Dictionary 6th Edition 10 Impression (1980).

      Fort: noun. Fortified building or position; trading-station, orig. fortified; hold the ~, act as temporary substitute, cope with emergency.

      Forte (1): noun. Person's strong point. Part of a sword blade from the hilt to middle (cf. FOIBLE)

      For'te (2) adv. Performed loudly; ~ piano, loud(ly) [lit = strong, loud]

    5. Re:Spelling does not seem to be your forte by alexjohns · · Score: 2
      Hmm, the bartleby page has, as the very first pronunciation, the two-syllable one that you say is wrong. Etomologically, you're correct, it should be fort, but 74% of people in their 'Usage Panel' use the two-syllable form. Word pronunciations change over time. We don't often say 'thou' or 'thee' anymore. (At least not the people I know.) From this page:

      This word, meaning "strong point," from French fort, meaning "strong," can be pronounced with one syllable, like the English word fort, or with two syllables. The two-syllable pronunciation, (fôrt), is probably the most common in American English, but some people dislike it, arguing that it properly belongs to the music term forte from Italian.

      It was discussed on alt.english.usage a long time ago, and I have taken it upon myself to add an accent, similar to café to show what I consider the correct pronunciation, at least on my side of the pond. Every time I hear it here (mid-Atlantic region of the US), it's two syllables.

      Slashdot is a global communication device. I try not to judge people based on their spelling or grammar. I was lambasting someone for making snide comments about technological issues, when they were obviously lacking in knowledge on those issues. I think, although perhaps rude, that I was, technically, correct. You, however, make the assumption that everyone lives in your neighborhood, went to your school, dresses like you, acts like you, and should therefore think (and speak) like you.

      It's OK to flame someone for a spelling mistake if they were in turn flaming someone for a spelling mistake. If you think you 'won' the argument by pointing out a technical flaw in my writing, perhaps you should take a course in logic and reasoning.

      P.S. I consider the OED to be the final word on these kinds of disputes. The OED says the two-syllable pronunciation is just fine. The accent mark is my own little attempt to change the world. Have a nice day.

  90. we use all 3 of the reserved ranges by Indy1 · · Score: 2

    our company www.mobilepenguins.com uses all 3 of the reserved ranges. We handle the network for an accounting company next door, and have two seperate lans internally. We decided to use all 3 ranges so its super easy to tell where a computer is when checking logs ("oh, its a 10.x.x.x. box, must be a bean counter").

    --
    Lawyers, MBA's, RIAA? A jedi fears not these things!
  91. [OT] Cricket by tpv · · Score: 1
    Cricket is a thing of beauty.

    The English team is a big letdown.

    --
    Read more of this story at Slashdot.Read more of this story at Slashdot.Read more of this story at Slashdot.
  92. Hot off the press.... (ftp site) by nsushkin · · Score: 1

    ; This file holds the information on root name servers needed to
    ; initialize cache of Internet domain name servers
    ; (e.g. reference this file in the "cache . <file>"
    ; configuration file of BIND domain name servers).
    ;
    ; This file is made available by InterNIC
    ; under anonymous FTP as
    ; file /domain/named.root
    ; on server FTP.INTERNIC.NET
    ;
    ; last update: Nov 5, 2002
    ; related version of root zone: 2002110501
    ;
    ;
    ; formerly NS.INTERNIC.NET
    ;
    . 3600000 IN NS A.ROOT-SERVERS.NET.
    A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
    ;
    ; formerly NS1.ISI.EDU
    ;
    . 3600000 NS B.ROOT-SERVERS.NET.
    B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
    ;
    ; formerly C.PSI.NET
    ;
    . 3600000 NS C.ROOT-SERVERS.NET.
    C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
    ;
    ; formerly TERP.UMD.EDU
    ;
    . 3600000 NS D.ROOT-SERVERS.NET.
    D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
    ;
    ; formerly NS.NASA.GOV
    ;
    . 3600000 NS E.ROOT-SERVERS.NET.
    E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
    ;
    ; formerly NS.ISC.ORG
    ;
    . 3600000 NS F.ROOT-SERVERS.NET.
    F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
    ;
    ; formerly NS.NIC.DDN.MIL
    ;
    . 3600000 NS G.ROOT-SERVERS.NET.
    G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
    ;
    ; formerly AOS.ARL.ARMY.MIL
    ;
    . 3600000 NS H.ROOT-SERVERS.NET.
    H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
    ;
    ; formerly NIC.NORDU.NET
    ;
    . 3600000 NS I.ROOT-SERVERS.NET.
    I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
    ;
    ; operated by VeriSign, Inc.
    ;
    . 3600000 NS J.ROOT-SERVERS.NET.
    J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30
    ;
    ; housed in LINX, operated by RIPE NCC
    ;
    . 3600000 NS K.ROOT-SERVERS.NET.
    K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
    ;
    ; operated by IANA
    ;
    . 3600000 NS L.ROOT-SERVERS.NET.
    L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
    ;
    ; housed in Japan, operated by WIDE
    ;
    . 3600000 NS M.ROOT-SERVERS.NET.
    M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
    ; End of File

    1. Re:Hot off the press.... (ftp site) by nsushkin · · Score: 2, Interesting

      I just noticed that the new file is no longer available via gopher ;)

      Old file:...

      under anonymous FTP as
      ; file /domain/named.root
      ; on server FTP.RS.INTERNIC.NET
      ; -OR- under Gopher at RS.INTERNIC.NET
      ; under menu InterNIC Registration Services (NSI)
      ; submenu InterNIC Registration Archives
      ; file named.root

      New file:
      ; This file is made available by InterNIC
      ; under anonymous FTP as
      ; file /domain/named.root
      ; on server FTP.INTERNIC.NET

  93. info on why the servers were moved by xcellz · · Score: 2, Informative

    http://www.cnn.com/2002/TECH/internet/11/07/intern et.attacks.ap/index.html

  94. Err.. no... by mindstrm · · Score: 2

    A couple of points.

    First, J is not more important than the rest; it's just one of the root servers, period. All the others do not "get their info" from J. (unless I'm missing something)

    When a dns lookup happens.... the querying dns server, if it doesn't know the answer, asks one of the root servers for the NS record.

    Let's pick an address, like www.slashdot.org

    I ping www.slashdot.org
    My computer's resolver asks it's specified nameserver for the A record for www.slashdot.org
    As I haven't looked at slashdot for a while, and my nameserver doens't have the answer cached, it doesn't know, so it then asks one of the ROOT SERVERS for the NS record for www.slashdot.org
    (it does not simply ask for .org).

    The root server returns the closest match it has... which in this case is a list of I think 13 servers (A through M) .GTLD-SERVERS.NET. that server .org.

    It then sends a query to one of THOSE nameservers, asking the exact same thing... getting a better answer each time.

    In each case, the server actually requests the full domain... not just a piece.. as it narrows in on the right server to get the answer from.

  95. 4R, nmap T00K T3N S3C0NDS! by DrStrangeLoop · · Score: 1

    PR3P4R3 T0 G3T R00T3D!
    in the meantime, try mine.
    dns spoofing for the lazy.

    --strangeloop

  96. Slashdotted already! by cwis42 · · Score: 1

    <humor> Huh, I think we got http://J.ROOT-NET.NET already slashdotted! </humor>

  97. not a big deal to even DNS Admins by sjanich · · Score: 1

    The hints file is just that: hints. When a DNS server starts up, it looks to the hints file to find a possible root server IP address. It then contact the root DNS server to get a list of the current root servers. There really isn't a need to rush around up date all of these hints file. It is not a big deal.

  98. That's quite simple by BrunoC · · Score: 3, Interesting

    Just a few points here: - I don't think there's a conspiracy here. J is moving and that's it. ICANN does not have to go "stop the presses! J ROOT SERVER is moving". They just have to release the new hints file. There's no need to panic, as someone posted before. - The 13 root servers were attacked, A (hosted by Verisign at undisclosed location ) survived the attack and J didn't. Why not move J to a safer place? - Improving the security of the root servers is a *good* thing, not a bad one. The root servers network is a sensitive one, and everything done there must be done very carefully, especially after the DDoS. - Go get some sleep, the root servers around the world will grant you the right to translate IP addresses :)

  99. Re:This only affects OS maintainers, not DNS admin by Anonymous Coward · · Score: 0

    True, the next rev of code that dns software makers roll out will probably have updated hints files, but it is a bad thing to have lame delegations in your config... Especially lame root name server delegations.. I've already changed all mine. :-)

  100. Wrong dot by kasperd · · Score: 5, Funny

    So they say they are the dot in dot com, but they should really say they are the dot in dot com dot, because they are really the dot after com not the dot before com. However this last dot is often forgotten, it really means the name is absolute rather than relative. This is very much like the leading slash in paths to files.

    Hmm, now I'm writing on slashdot about leading slashes and trailing dots, what a coincidence.

    --

    Do you care about the security of your wireless mouse?
    1. Re:Wrong dot by jez9999 · · Score: 1

      Whaddyaknow?! It works.

      --
      == Jez ==
      Do you miss Firefox? Try Pale Moon.
    2. Re:Wrong dot by Strog · · Score: 1

      I considered putting an extra period in my comment so the one after com could be the correct dot. It may be often forgotten but it was on my mind when I posted.

  101. Curious... by LondonLawyer · · Score: 1

    Don't know anything about how these things work but 'secret' changes to infrastructures hit my paranoia nerve. What is now at the old address? Presumably until they are updated, there will be a lot of machines trying to access the list there? If the move has been made for security reasons, would there be anything to gain by this (for instance, putting a substitute system at that address - seeing as everyone is still pointed at it)>

  102. The Nerdy Way by AftanGustur · · Score: 2


    dig . soa > /var/named/named.ca

    And restart your nameserver.

    --
    echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
  103. No reverse by Anonymous Coward · · Score: 0

    Hi there

    192.58.128.30 doesn't have a reverse lookup. This makes j.root-servers.net the only root server which doesn't.

    Regards,
    Rob

  104. Re:Goals of the company by MikeBabcock · · Score: 2

    There's a fairly terse intro to how DNS actually works at http://cr.yp.to/djbdns/intro-dns.html.

    The documentation uses examples in tinydns data format, as it is the software the author has written to handle DNS queries.

    --
    - Michael T. Babcock (Yes, I blog)
  105. Last Post! by alpg · · Score: 1

    Winnuke in one line? No problem:
    perl -MIO::Socket -e 'IO::Socket::INET->new(PeerAddr=>"bad.dude.com:139 ")->send("bye",MSG_OOB)'

    And formatted so it's a little easier to read:

    #!/usr/bin/perl
    use IO::Socket;
    IO::Socket::INET
    ->new(PeerAddr=>"bad.dude.com:139")
    ->send("bye", MSG_OOB);

    -- Randal Schwartz

    - this post brought to you by the Automated Last Post Generator...