aos101 writes "The Renesys blog has an interesting story about networks advertising the old address space of the L root name server after ICANN changed the IP address last November. These networks were also running root name servers on the old IP address of the L root name server up until last week, so any DNS servers still using the old IP address might have been getting their answers from these bogus name servers. A very cursory examination by Renesys of one of these bogus servers found that it appeared to be providing correct responses, which might be why no one noticed the problem. As Renesys points out, the volume of traffic to a root server is staggering, so the people running these bogus root servers must have had a reason. What did they get out of it?"
Or possibly some attempt at stopping arbitrarily many of their customers setups from breaking... If you've got enough poorly configured machines, it might be easier to ensure that the servers they are looking for remain available, rather than trying to fix _all_ of them immediately... Especially if they're mission-critical systems...
Then wouldn't need to advertise routes/ip space for their own customers... The very word advertise, in the context, means to third parties, as in BGP advertisement.
You guys are awefully optimistic; those who pulled that off had an enormous power for a short time. Quoting TFA:
In general, they could engage in all sorts of mischief, ranging from very targeted ("let's get this one individual or organization") to very wide-ranging ("let's blow away.com today").
all the while completly undetected. I don't understand all the details, but from what I got the whole name resolving is a trust based system; so advertising a false youtube domain would temporarly work, but then you'd be busted and left with no karma. Except that these "root servers" are free of those constraint.
The fact that those who did this had huge resources do not make it less scary, neither does the fact that nobody detected anything. Remeber how that guy operated a tor exit node to get a whole lot of interesting datas; the idea here is the same.
(A concrete example would be to send your wikipedia request to a bogus wikipedia website. It would forward all your queries to the real wikipedia, so you couldn't tell the difference (man in the middle), but on some pages it would serve you an altered page; it could also make you feel like you wrote an article, but the article would actually only show up on your copy of the bogus website, not the real one. Encryption twarts this, otherwise it's really the worst case scenario.)
And apparently, there is nothing to prevent it from happening again. Since people seem so little concerend, I must have missed some detail which makes everything fine; or at least I really hope so.
I upgraded a corporate DNS once and left the old system in place, just changed the CNAME to point to the new server. The new server (windows) ate itself later, and since the guy whose baby it was had been canned, I just switched the name back to the old servers.
Later, my new boss wanted to switch to a Linux based system, instead of the windows system which I'd already repurposed. I quoted him a modest server, set it up as a secure proxy for some of our internal web applications, and let the original linux system keep chugging along.
I figure I can get at least two more servers out of this, before I actually have to upgrade the system.
Maybe the guys at root-servers just left some hardware running at the old address?;)
They should never have relinquished the address so damn quickly. Turn off the equipment for a few weeks first and let people see that that address no longer works...Don't just let someone move in seamlessly and hijack your junk.
Here's my question: Isn't there some sort of authentication for DNS a la SSL certificates? If not, would this take a major overhaul of the DNS system to support it?
As I understand it, there's also a man-in-the-middle type of attack with DNS where a local router (possibly a Hacked By Chinese(tm) "Cisco" router) will substitute its own DNS replies instead of passing the query to the real DNS server.
Couldn't both of these issues be resolved by having a field on the DNS record where the reply is signed by the DN
According to l.root-servers.org linked above, the IP change happened on the first of November last year, and only a couple weeks ago was taken offline at the old address. Is six months not enough?
Not if it still works. You need to take the old address offline for a while.
Most people don't pay much attention to their DNS infrastructure. The stuff doesn't need much maintenance. If it breaks, they'll notice that something is wrong, but if it continues working seamlessly, they'll ignore it.
Most modern DNS servers will automatically update their hints file each time they're restarted, by making a request to whichever root they connected to for the current list.
From my reading of the article they didn 't "relinquish" the ip at all. Basically some new groups claimed that they owned the ip address (when they didn't) and the sections of the internet just accepted that claim and started routing data to that IP to those groups. If you follow the article the actual change of IP address doesn't even matter. The server change merely provided a situation where they weren't paying as much attention to the old DNS.
It sounds like the attack could be pulled off at any time vs
Except that apparently ICANN switched their machine off on May 2nd. However, anticipating such a switch off, three other organisations around the world stepped in over the past 6 months to fill the void, and mostly went undetected for the last 6 months...
For the owner of the original IP address now being vacated by ICANN, there is also maybe a self-interest motive of identifying the servers who hadn't updated so as to notify them and kill the unwanted traffic.
Given how visible this is, it's hard to imagine anyone doing it for criminal purposes and thinking they could get away with it.
nonsense. the article is very clear: here's what happened:
icann hosted L-root on ip addresses they didn't have an exclusive right to use.
they decided to stop doing that and moved L-root to somewhere else.
shortly thereafter someone else decided to operate a name server on the very same IP addresses.
that's *what* happened. perhaps you meant to say that the article doesn't say *why* it happened. that would be a fair criticism.
you're missing something here. It wasn't just that "someone" else decided to operate a bogus L root server on that IP address, it's that several someones were doing this. The article states there were FOUR of these running on the OLD ip address. so you had the newly IP'd correct L server, and 4 bogus L servers (one of which was being run by ICANN itself), all using the same old IP address.
How could this happen you ask? because 3 entities not authorized to announce they host that IP block did so anyway, so there were 4 different routes to that IP block on the Internet, resulting in 4 possible places you could end up at when sending DNS queries to the old address, 198.32.64.12.
So basically there are 2 concerns here, one is that a couple of Internet entities were advertising routes for an IP block they were not authorized to advertise, and that they were running a bogus L root server from that IP block on it's old address. Bill Manning owned the IP block so his ISP was authorized to advertise that route, and it might be obvious why ICANN was also advertising a route for it as well (to try to get that traffic going to the old IP address for root lookups), but why were Community DNS and Diyixian.com advertising that route and running a bogus L root server?
nope. as the article points out, the fake L-root that is still running right now appears to be returning correct data for existing domains and NX records for non existing domains.
they may be gathering data from NX hits, though. who could say. well, community dns could say. perhaps they will.
Right. Still returning correct data but collecting logs of names that don't exist so they can sell them to all those wacky people who register everything udner the sun and park adverts on it (I hate that).
A story about this was/.'ed back in October but it was Verisign selling the data to third parties.
http://www.domainnamenews.com/editorial/verisign-to-profit-from-rootserver-data/889 [domainnamenews.com]
Actually, "attack" isn't really an appropriate term. It was not really an attack or a hijack or even identity theft. For one thing, these terms imply the existence of both a victim and a villain. In this story, the villains are not obvious and there might not have been any victims.
How do we go from this to a headline reading Identity Theft Hits the Root Servers?
There is no reason to believe that it was malicious at all. We all are familiar with that black hat turned grey or white that wants to help out by demonstrating vulnerabilities in the system. That is just as plausible as anything else. Maybe it's the free-masons!! The Illumanati, maybe!!! The only certain thing about this is the need to secure name service. We should be glad even though it was compromised, there is no apparent damage done.
Evil marketing firms are always looking for ways to improve typo-squatting. Popping a root server's address space is the ultimate in NXDOMAIN (failed to match) lookups as every DNS server on the net that cannot resolve a domain (such as unregistered typo-domains) will go further and further back until it hits a root server. Hence having a root server's NXDOMAIN data is the ultimate in typo-squatting.
I honestly doubt that typo-squatters care about the millions of requests for com, net, org, and all the other TLDs and ccTLDs, which is all you'll get if you have control of a root server. If someone makes a typo on some com domain, it won't make it any further than com's servers, so having control of the root is rather moot unless someone also makes a typo in the TLD.
On the other hand, the person in control of the root could give bogus records for the name servers for something like com. This is unlikely to be a major problems since the TTL on all the records served by the root is 120 days. Most people are going to be querying a caching name server of some sort, so it's statistically unlikely to affect much of the population before it is detected and dealt with.
Not to plug my own work too much, but as a part of my research, I work with a team that monitors DNSSEC deployment. This is something we would in theory be able to see from our distributed polling framework, and our datasets going back to 2005 don't show anything like a rogue TLD server being published. Kind of unfortunate in a way, being that DNS isn't exactly the most interesting research topic at face value.
Since they seem to be providing valid responses (as suggested in the article), it must be some traffic data that they are collecting. They now have a long list of valid IP addresses with data, consider it a list of targets. They also have some first-hand data on the most popular websites which they could sell to advertisers ("Are you sure you're getting the right billing from your advertising agents?"). It could also have been a set-up - benign now but gearing up to start attacking later. I hate to ment
If they did not answer the name requests then the client would go on retriying and retrying, being a more effective DOS on thier network. So the only correct action was to put a DNS server on the announced DNS adresses.
As Renesys points out, the volume of traffic to a root server is staggering, so the people running these bogus root servers must have had a reason. What did they get out of it?
A few reasons spring immediately to mind.
1. Preliminary move with the intent of actual subversion of results at a later date. This gives you an idea of what the traffic looks like, the volume you're going to have to manage, and the technical requirements of managing the subversion on top of recording important information about the systems you just subverted for later exploitation, plus any statistical information you need/want to improve your subversion process.
2. Preliminary move by a government, corporate entity, or some grouping with the intent of either wresting control of some portion of the DNS infrastructure from ICANN, or setting up a country-specific DNS infrastructure that is legally mandated. Again, you get valuable information about the kind of stuff you need to be dealing with, depending on exactly what you have in mind.
3. Same as above, but more of an idealistic style intervention, fearing malicious intent from the US government which still controls the DNS system, and trying to prepare for a time when an ICANN-free DNS system may need to be put in place.
Depending on where this stuff is actually going (and if it's the actual owner of the IP space that is doing this) of course...
If only 5% of DNS servers hadn't updated their root servers list, and this server is listed as 1 of the 13 root servers, then these people will have.38% of the entire internet's DNS requests coming through them.
With "control" of a root server (or at least what a DNS client believed was a root server. They would be free to insert whatever records for anything they want. Think banking, finance, email, etc.
So really, the title of this article should have been if you were in organized crime, what would you do if you could transparent MITM (man in the middle) attack.38% of all web traffic on the internet.
I guess I don't see what the big deal is. The ICANN article stated that the old root DNS server would run for 6 more months, and that appears to be all that has happened. What am I missing?
"It is expected that the old address will continue to work for at least six months after the transition, but will ultimately be retired from service."
The problem is, if you do grab the hints file from there, you have to make sure you keep refreshing it to stay up to date... Otherwise you're just setting yourself up for the same attack the next time this happens...
That said, I don't know if trusting your upstream provider is any better...
The file doesn't change all that often, so checking it once a month should keep you up to date. If you needed a more immediate update schedule, I'd subscribe to the ICANN newsletter at:
Oh, yeah, I realise that. In fact, given that the article states that the transition time is around 6 months, you could probably just update every 3 months, even. The point is, you have to have some system in place, either manual or automatic, to perform the update... Because it's easy to copy the file the first time, insert it into your configuration master image, and then forget about it as you roll out machines, and leave them in production for years with out-of-date hints files.
Maybe whoever set up the "fake" RNS was trying to hide and appear to be safe until some time when it could collaborate some DDOS. We won't know since they aren't up and running, but having such a highly used server would have been beneficial for whatever the purpose was in the first place, to everyone if it were a positive one or to them if it were negative. But what do I know, I'm purely speculating.
As Renesys points out, the volume of traffic to a root server is staggering, so the people running these bogus root servers must have had a reason. What did they get out of it?
So how long has the submitter had this habit of answering his/her own questions before he/she asked them? Staggering amounts of traffic. That IS your answer. Victim machines whose upstream DNS servers didn't update the root server file could be redirected to ad-wrapped versions of "real" websites. If there was far more malicious intent involved, they can redirect, say, baking sites to whatever site they want. Plain and simple.
/me quickly darts off to make sure his root file is up-to-date
Bear in mind that BIND for one doesn't use the root nameserver hints file directly under normal conditions. One of the first things it does is contact one of the servers listed in the hints file and download the real root nameserver list. After that it uses the downloaded list and ignores the hints file. So unless you contacted the L server for that initial download, you'll get the correct root server list and won't ever contact the bogus ones. I'd have to check whether BIND picks a hints entry at random or cycles through starting from the first. If it picks at random the window of vulnerability is small, but if it starts at the first it's virtually nonexistent (most hints files list A, B, C and so on in sequence, and the chance of getting no answer at all from the A-K servers is close to zero).
why traffic goes to "retired" address space is a difficult question to answer. http://www.caida.org/workshops/wide/0611/ [caida.org] has a pointer to some early work done on the "B" renumbering. There was agreement by the operators of "B","L","J", and "M" to collect data during the DITL-2008 collection to see if any correlation btwn querying nodes. That said, ICANN should have renumbered the node when they took it over. They did not. They have not had permission to use the prefix since 2004 - but for stability sake, I did not make a big fuss.
Maybe the reason that the nameserver is providing correct responses is due to something like port-knocking for domain names?
If a phisher wanted to use this, they would only supply a bogus dns pointer to a query if the query was preceded by some 'primer' query. E.g. first someone tries to resolve alpha.com, then beta.com within a few seconds, only then will the root server give the incorrect response for beta.com. This would be pretty easy to do with some cross-site scripting magic.
The Internet was originally designed to be a "self-healing" system, able to route around damage like (no joke) a nuclear war.
However, the system as it currently exists has one SERIOUS flaw: the reliance on root servers.
We need to switch to a system that does not rely on root servers. There are at least several such systems that are workable. Yes, the U.S. government would lose control over the whole thing. Does ANYBODY in their right mind think that is a bad thing? As long as nobody else can gain root control either, and there are various schemes that can ensure that.
Umm, also, you seem to have the whole operation of DNS upside down; you start at the root servers, which delegate you to the.com servers, which delegate you to the google.com servers, which can then tell you the address of www.google.com. Hopefully you also cache the results along the way, so that when you want to find news.google.com later you don't have to go to the root or.com servers, and when you want to find yahoo.com you don't have to go all the way back to the root and can start at.com.
Good Samaritans? (Score:3, Insightful)
Re:Good Samaritans? (Score:4, Insightful)
Parent
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
And, for that matter, if Bill Manning authorized the use of the address space, then it's not even an attack!
Re:Good Samaritans? (Score:5, Insightful)
The fact that those who did this had huge resources do not make it less scary, neither does the fact that nobody detected anything. Remeber how that guy operated a tor exit node to get a whole lot of interesting datas; the idea here is the same.
(A concrete example would be to send your wikipedia request to a bogus wikipedia website. It would forward all your queries to the real wikipedia, so you couldn't tell the difference (man in the middle), but on some pages it would serve you an altered page; it could also make you feel like you wrote an article, but the article would actually only show up on your copy of the bogus website, not the real one. Encryption twarts this, otherwise it's really the worst case scenario.)
And apparently, there is nothing to prevent it from happening again. Since people seem so little concerend, I must have missed some detail which makes everything fine; or at least I really hope so.
Parent
Re:Good Samaritans? (Score:5, Interesting)
Later, my new boss wanted to switch to a Linux based system, instead of the windows system which I'd already repurposed. I quoted him a modest server, set it up as a secure proxy for some of our internal web applications, and let the original linux system keep chugging along.
I figure I can get at least two more servers out of this, before I actually have to upgrade the system.
Maybe the guys at root-servers just left some hardware running at the old address?
They should never have relinquished the address so damn quickly. Turn off the equipment for a few weeks first and let people see that that address no longer works...Don't just let someone move in seamlessly and hijack your junk.
Parent
Re:Good Samaritans? (Score:5, Insightful)
Parent
Re: (Score:3, Interesting)
Isn't there some sort of authentication for DNS a la SSL certificates? If not, would this take a major overhaul of the DNS system to support it?
As I understand it, there's also a man-in-the-middle type of attack with DNS where a local router (possibly a Hacked By Chinese(tm) "Cisco" router) will substitute its own DNS replies instead of passing the query to the real DNS server.
Couldn't both of these issues be resolved by having a field on the DNS record where the reply is signed by the DN
Re:Good Samaritans? (Score:5, Insightful)
Parent
Re:Good Samaritans? (Score:5, Interesting)
Parent
Re:Good Samaritans? (Score:5, Insightful)
Most people don't pay much attention to their DNS infrastructure. The stuff doesn't need much maintenance. If it breaks, they'll notice that something is wrong, but if it continues working seamlessly, they'll ignore it.
Parent
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
If you follow the article the actual change of IP address doesn't even matter. The server change merely provided a situation where they weren't paying as much attention to the old DNS.
It sounds like the attack could be pulled off at any time vs
Re:Good Samaritans? (Score:5, Informative)
http://blog.icann.org/?p=227 [icann.org]
It is expected that the old address will continue to work for at least six months after the transition, but will ultimately be retired from service.
1st November 2007 -> 1st May 2008 is 6 months. So they left it a few days over 6 months
Tim.
Parent
Re: (Score:3, Informative)
Re:Good Samaritans? (Score:4, Insightful)
For the owner of the original IP address now being vacated by ICANN, there is also maybe a self-interest motive of identifying the servers who hadn't updated so as to notify them and kill the unwanted traffic.
Given how visible this is, it's hard to imagine anyone doing it for criminal purposes and thinking they could get away with it.
Parent
Re: (Score:2)
Extremely vague article (Score:2, Informative)
"Hey, something happened. No, we don't know who, what, when, or why. We do know where, but that's it. You got any ideas?"
Should have been submitted as "Ask Slashdot"... Then maybe we might find out what happened, if anything. As is, it is a non-news item.
Re:Extremely vague article (Score:5, Informative)
icann hosted L-root on ip addresses they didn't have an exclusive right to use.
they decided to stop doing that and moved L-root to somewhere else.
shortly thereafter someone else decided to operate a name server on the very same IP addresses.
that's *what* happened. perhaps you meant to say that the article doesn't say *why* it happened. that would be a fair criticism.
Parent
Re:Extremely vague article (Score:4, Interesting)
you're missing something here. It wasn't just that "someone" else decided to operate a bogus L root server on that IP address, it's that several someones were doing this. The article states there were FOUR of these running on the OLD ip address. so you had the newly IP'd correct L server, and 4 bogus L servers (one of which was being run by ICANN itself), all using the same old IP address.
How could this happen you ask? because 3 entities not authorized to announce they host that IP block did so anyway, so there were 4 different routes to that IP block on the Internet, resulting in 4 possible places you could end up at when sending DNS queries to the old address, 198.32.64.12.
So basically there are 2 concerns here, one is that a couple of Internet entities were advertising routes for an IP block they were not authorized to advertise, and that they were running a bogus L root server from that IP block on it's old address. Bill Manning owned the IP block so his ISP was authorized to advertise that route, and it might be obvious why ICANN was also advertising a route for it as well (to try to get that traffic going to the old IP address for root lookups), but why were Community DNS and Diyixian.com advertising that route and running a bogus L root server?
Parent
Cashing In (Score:2, Insightful)
Re: (Score:3, Informative)
they may be gathering data from NX hits, though. who could say. well, community dns could say. perhaps they will.
Re: (Score:3, Informative)
statistics? profiling? (Score:3, Insightful)
that data would be worth something to ad men surely...
Re: (Score:2)
Re:statistics? profiling? (Score:5, Funny)
(flem, 'a', 'n'...)
Parent
What? (Score:5, Insightful)
How do we go from this to a headline reading Identity Theft Hits the Root Servers?
There is no reason to believe that it was malicious at all. We all are familiar with that black hat turned grey or white that wants to help out by demonstrating vulnerabilities in the system. That is just as plausible as anything else. Maybe it's the free-masons!! The Illumanati, maybe!!! The only certain thing about this is the need to secure name service. We should be glad even though it was compromised, there is no apparent damage done.
Harvesting NXDOMAIN hits (Score:5, Interesting)
Re:Harvesting NXDOMAIN hits (Score:5, Informative)
On the other hand, the person in control of the root could give bogus records for the name servers for something like com. This is unlikely to be a major problems since the TTL on all the records served by the root is 120 days. Most people are going to be querying a caching name server of some sort, so it's statistically unlikely to affect much of the population before it is detected and dealt with.
Not to plug my own work too much, but as a part of my research, I work with a team that monitors DNSSEC deployment. This is something we would in theory be able to see from our distributed polling framework, and our datasets going back to 2005 don't show anything like a rogue TLD server being published. Kind of unfortunate in a way, being that DNS isn't exactly the most interesting research topic at face value.
Parent
Collecting valid IP addresses, reference data (Score:2, Interesting)
What they got (Score:2)
Re:What they got (Score:5, Insightful)
Parent
Could be several reasons (Score:5, Interesting)
A few reasons spring immediately to mind.
1. Preliminary move with the intent of actual subversion of results at a later date. This gives you an idea of what the traffic looks like, the volume you're going to have to manage, and the technical requirements of managing the subversion on top of recording important information about the systems you just subverted for later exploitation, plus any statistical information you need/want to improve your subversion process.
2. Preliminary move by a government, corporate entity, or some grouping with the intent of either wresting control of some portion of the DNS infrastructure from ICANN, or setting up a country-specific DNS infrastructure that is legally mandated. Again, you get valuable information about the kind of stuff you need to be dealing with, depending on exactly what you have in mind.
3. Same as above, but more of an idealistic style intervention, fearing malicious intent from the US government which still controls the DNS system, and trying to prepare for a time when an ICANN-free DNS system may need to be put in place.
Depending on where this stuff is actually going (and if it's the actual owner of the IP space that is doing this) of course...
This is the perfect Man In The Middle attack (Score:5, Insightful)
If only 5% of DNS servers hadn't updated their root servers list, and this server is listed as 1 of the 13 root servers, then these people will have .38% of the entire internet's DNS requests coming through them.
With "control" of a root server (or at least what a DNS client believed was a root server. They would be free to insert whatever records for anything they want. Think banking, finance, email, etc.
So really, the title of this article should have been if you were in organized crime, what would you do if you could transparent MITM (man in the middle) attack .38% of all web traffic on the internet.
My guess is all your accounts belong to us.....
Re: (Score:3, Informative)
What did they get out of it? Easy....root access! (Score:2, Funny)
What am I missing? (Score:2)
What am I missing?
"It is expected that the old address will continue to work for at least six months after the transition, but will ultimately be retired from service."
Make sure you are up to date! (Score:4, Informative)
ftp://ftp.internic.net/domain/named.cache [internic.net]
Slashdot's junk filter won't allow a cut and paste of the file's contents into a post.
Re: (Score:3, Insightful)
That said, I don't know if trusting your upstream provider is any better...
Re: (Score:2, Informative)
http://www.icann.org/newsletter/ [icann.org]
Re: (Score:2)
The point is, you have to have some system in place, either manual or automatic, to perform the update... Because it's easy to copy the file the first time, insert it into your configuration master image, and then forget about it as you roll out machines, and leave them in production for years with out-of-date hints files.
I know - I've probably don
Re: (Score:3, Funny)
Gain trust (Score:2)
Obvious answer already given (Score:2)
As Renesys points out, the volume of traffic to a root server is staggering, so the people running these bogus root servers must have had a reason. What did they get out of it?
So how long has the submitter had this habit of answering his/her own questions before he/she asked them? Staggering amounts of traffic. That IS your answer. Victim machines whose upstream DNS servers didn't update the root server file could be redirected to ad-wrapped versions of "real" websites. If there was far more malicious intent involved, they can redirect, say, baking sites to whatever site they want. Plain and simple.
/me quickly darts off to make sure his root file is up-to-date
Not horribly major (Score:3, Informative)
Bear in mind that BIND for one doesn't use the root nameserver hints file directly under normal conditions. One of the first things it does is contact one of the servers listed in the hints file and download the real root nameserver list. After that it uses the downloaded list and ignores the hints file. So unless you contacted the L server for that initial download, you'll get the correct root server list and won't ever contact the bogus ones. I'd have to check whether BIND picks a hints entry at random or cycles through starting from the first. If it picks at random the window of vulnerability is small, but if it starts at the first it's virtually nonexistent (most hints files list A, B, C and so on in sequence, and the chance of getting no answer at all from the A-K servers is close to zero).
Why indeed... (Score:4, Insightful)
bill manning
Domain-Name Knocking (Score:3, Insightful)
If a phisher wanted to use this, they would only supply a bogus dns pointer to a query if the query was preceded by some 'primer' query. E.g. first someone tries to resolve alpha.com, then beta.com within a few seconds, only then will the root server give the incorrect response for beta.com. This would be pretty easy to do with some cross-site scripting magic.
You can never disprove a conspiracy, after all...
This needs to be fixed. (Score:3, Insightful)
However, the system as it currently exists has one SERIOUS flaw: the reliance on root servers.
We need to switch to a system that does not rely on root servers. There are at least several such systems that are workable. Yes, the U.S. government would lose control over the whole thing. Does ANYBODY in their right mind think that is a bad thing? As long as nobody else can gain root control either, and there are various schemes that can ensure that.
Re: (Score:3, Informative)
ICANN's server was switched off on May 2.
Re: (Score:3, Informative)
Hopefully you also cache the results along the way, so that when you want to find news.google.com later you don't have to go to the root or
However, wh