Entire .SE TLD Drops Off the Internet
207
Icemaann writes "Pingdom and Network World are reporting that the SE tld dropped off the internet yesterday due to a bug in the script that generates the SE zone file. The SE tld has close to one million domains that all went down due to missing the trailing dot in the SE zone file. Some caching nameservers may still be returning invalid DNS responses for 24 hours."
No big deal (Score:2, Informative)
The downtime lasted 30 minutes, and most domains were probably cached by nameservers anyway.
Re:No big deal (Score:4, Informative)
Yeah, been there done that. *My* fumble only brought 10,000 domains down for about 10 minutes, and no one noticed. (I think all the domains hosted only cat pictures anyway.)
Sorry, that's as big a responsibility as any employer has ever deemed suitable for my incompetent ass.
Re: (Score:3, Interesting)
My biggest bug resulted in about a dozen tigers getting tranquilized.
Re:No big deal (Score:4, Funny)
Are you my motherboard?
Re:No big deal (Score:5, Funny)
The downtime lasted 30 minutes, and most domains were probably cached by nameservers anyway.
I once viddied an animated documentary about a small town in Colorado that lost the internet for 22 minutes [wikipedia.org]. It was not pretty. Our hearts and minds go out to you, people of Sweden. I cannot even fathom what that would be like ... I hope the looting and rioting has died down with the restoration of the internet.
Re: (Score:2)
Nah. In Sweden, when you want to see hot chicks, you just have to go outside. Even looking out the window might suffice. ^^
Re: (Score:2)
Re: (Score:2)
For the pool souls in the .se domain, it was the end of the universe.
Re: (Score:2)
It was not the whole internet, it was only .se tld ...
Can I riot anyway?
Re: (Score:2)
Depends. Do you live in Sweden? Do you have Swedish relatives? Are there any Swedish meatballs in your refrigerator?
Re: (Score:2)
"For those who love Adam Smith, in Argentina we have only two ISP providers, Telecom and Telefonica. Telefonica has bougth Telecom, so now we have a BIG monopoly on cell phones, wired phones, and internet services."
Ahhh... but that's prue free market in action, señor mío, so you must be grateful.
Re: (Score:3, Insightful)
While the impact of this is no big deal, it's still kind of scary that the people running a decently-sized ccTLD would make such a novice mistake on their zonefile.
Re: (Score:3, Insightful)
You expect them to be absolutely perfect all the time no matter what, forever and ever? /That's/ unrealistic.
Re: (Score:3, Informative)
Incorrect. The zone file is hosted by Autonomica AB (who own the servers that are authoritative for the "se" domain according to the root servers).
If you were talking about a change to the NS records, you'd - I assume - be correct - Verisign operates a.root-servers.net (which I assume is the root)
Re:No big deal (Score:5, Funny)
The downtime lasted 30 minutes, and most domains were probably cached by nameservers anyway.
I didn't notice the DNS freak out, but I did notice the internet's smug meter had dropped about 30%.
Re:No big deal (Score:5, Funny)
but I did notice the internet's smug meter had dropped about 30%.
Norwegian detected.
Re:No big deal (Score:5, Insightful)
DNS is very simple, but it's just as prone to human error as anything else. If you're responsible for the records of a large number of domains (like, say, an entire country), you probably ought to take some time to develop proper testing and change control procedures before you fiddle with it. It sounds like these guys didn't take it seriously enough and got burned. I hope they'll learn their lesson from this and change their procedures.
Re:No big deal (Score:5, Funny)
DNS is very simple, but it's just as prone to human error as anything else.
Are you kidding? I've been programming DNS for a long time, and if theirs one thing I learned, its that programmers like me don't make errors.
Re: (Score:2, Redundant)
Are you kidding? I've been programming DNS for a long time, and if theirs one thing I learned, its that programmers like me don't make errors.
If one doesn't count spelling errors, apparently.
Re: (Score:2)
"When I worked for a major telecomm here in the US, one of our partner companies submitted a text file generated on a *nix machine [...] I found it more interesting that the reason why the partner company didn't want to muck with it was because the file would be 'validated' with their servers. The inclusion of two CRs threw off the checksum value and nothing would work."
So, the partner company sent you some files. You inserted them on your system which sudden and misteriosuly failed. You blame your partne
Re: (Score:2)
Incorrect. Notepad does not interpret LF or CR on their own as a line break, so you'd find it pretty obvious that the file is malformed when the whole damn thing shows up on a single line. Wordpad will transparently fix it though.
Re: (Score:2)
No big deal? No big deal??? Where the hell else am I supposed to go to look at pictures of hot Swedish women hitting the nightclub scene (in a way that's at least a little SFW) if I can't get to http://www.thelocal.se/ [thelocal.se]?
Re: (Score:3, Insightful)
I wish browsers would store the IP address of the page as well as the domain name in bookmarks. That way if the DNS server goes down you could still get to the site. Of course, the primary lookup should still be the domain name, since a site can have its address changed; the browser would only look at the IP if the DNS lookup failed.
Re: (Score:2)
That feature would be very handy.
The main reason one can't simply record host/ip pairs right now, is due to named-based virtual web servers.
Even if you put in the IP manually, without sending the correct domain in the http request, you won't get the proper page.
Having the IP as a separate field in the bookmarks would let the browser connect to any IP you put there (be it cached, or manually changed when a server is renumbered), but it would still have the needed data to send in the http request to make the
Re:unless you are swedish (Score:4, Insightful)
its "no big deal" until you need to know something off the internet right now, high stakes
I need to know what a fourteen year old thinks about copyright law and I need to know it NOW [smbc-comics.com] !
Re:unless you are swedish (Score:4, Insightful)
Anything sufficiently "high stakes" shouldn't rely on an unreliable medium.
Re: (Score:3, Funny)
If a packet gets through, great. If not, well, it's not the end of the world.
Sounds like a lot of cities' approaches to freeway systems/traffic control.
Re: (Score:3, Funny)
Cache your porn, folks. Just sayin'.
Re: (Score:2)
Re: (Score:2)
Tell that to the "Operation SpoilSport" computers running the missle silos.
Re: (Score:2)
There goes my favorite web site ! (Score:3, Funny)
Goat.se
Re: (Score:3, Funny)
Goat.se
Huh... that's interesting. I've never heard of that one before... I think, though, that based on your recommendation I'll share the link with the rest of the office. I've seen a lot of your posts here in Slashdot, Anonymous Coward, and all the ones I've seen have been pretty highly rated, so I'm guessing you wouldn't link me to a website that wasn't interesting.
Re: (Score:2)
(humor)
The satellite Microsoft Retro Fan Site Windows98.se also went down.
And look. My sig this month is all about your joke.
(No Closing tag. The humor never ends.)
Re:There goes my favorite web site ! [Goat...] (Score:2, Funny)
Don't worry, there's plenty of mirrors......unfortunately.
Re: (Score:3, Funny)
Goat.se
Arrgh... the horror... http://goat.se/cx [goat.se] You'll want to claw your eyes out!
change control / management, anyone? (Score:5, Insightful)
I seriously hope someone is fired or loses a contract over this. Where was the validation, change control, etc? I would expect that at the TLD level, a change to a configuration file would have to be inspected by someone AND run through some syntax-checking scripts...
As for the person who was modded up for saying "hey, no big deal, fixed in 30 minutes!", not quite. DNS servers (and individual computers!) cache negative results. Anything anyone did a query on during those 30 minutes will be negatively cached by their system and their local DNS server. Granted, a whole lot of local Swedish ISPs and network providers have probably flushed their DNS server caches, but it's still going to seriously impact traffic to many, many sites, especially for everyone outside Sweden.
Re: (Score:2)
It really isn't a big deal. The mistake was made, the world has the opportunity to learn from it and the economic impact was probably small but scalable enough to take seriously.
Now if it happened again I'd hope action were taken... don't be so vengeful, SuperBanana!
Re: (Score:3, Insightful)
I'll go one better and say we should try him in a military tribunal and sentenced to hard time in ADX. That will send the world a message - NO MISTAKES OR ELSE.
Get real man, this is a human error. Your struggle for perfection baffles my monkey brain.
Re:change control / management, anyone? (Score:4, Funny)
I seriously hope someone is fired or loses a contract over this.
You'll be happy to know that the person responsible have been found. The person in question was described as having unusual bushy eyebrows and speaking in a thick Swedish accent. His last comment about the incident, before being dragged away, was "bork bork bork".
Re: (Score:2)
I seriously hope someone is fired or loses a contract over this.
It seems a silly idea to fire somebody just after having invested $(whatever_this_snafu_is_supposed_to_have_cost) into his education.
Re: (Score:2)
I seriously hope someone is fired or loses a contract over this.
It seems a silly idea to fire somebody just after having invested $(whatever_this_snafu_is_supposed_to_have_cost) into his education.
Disagree... Obviously that file was being maintained by hand, BS press releases about scripts to the contrary. So the failure was at the management level for allowing such a crazy working procedure with no testing infrastructure at all. The only "education" the peon got was "typos cause problems", not exactly a Nobel prize winning contribution to human knowledge (although in comparison to a recent winner...) Since management doesn't make mistakes, and someone has to be the fall guy... the excuse will pro
Re:change control / management, anyone? (Score:5, Insightful)
As a DNS admin myself, touching high value zones, let me tell you, missing a stupid dot happens all the time. All the change control in the world doesn't help when you just don't type one little period. Even more helpfully, most tools won't notice and the zone will pass a configuration check because missing the trailing "." is syntactically correct.
Let me add as well that "change management" that you want is just fantastic .. no making changes during core hours. When you run a 24/7 business, non-core hours means something like 2am. at 2am, I, and most mammals, are not at their mental best, so missing a single dot isn't horribly hard.
The only thing I'd suggest they do is use an offline test box for zones, then promote that change to prod. Then, you can load all the mistakes you want, do your digs, and if stuff works, THEN you move it to prod. I never ever make changes on production servers, they are done offline, tested, then put into prod with scripts. It makes it a lot harder for missing periods to make it into production.
Finally, this is a good reason why negative caching should have low TTLs. If you run a DNS server that can't handle low neg-caching TTLs, it's time to upgrade from a 386.
Cheers.
Re: (Score:2)
I think the big failure here is that anyone is ever editing the file by hand. It should be created programatically and edited only with a tool so that an error like this can never happen. (Of course, other errors are possible; now you have to vet your code. But the tool need not be complex, and in fact should be small enough to be provable if you so desire.)
Re: (Score:2)
I think the big failure here is that anyone is ever editing the file by hand. It should be created programatically and edited only with a tool so that an error like this can never happen. (Of course, other errors are possible; now you have to vet your code. But the tool need not be complex, and in fact should be small enough to be provable if you so desire.)
I agree, but I'll also be a monkey's uncle when free software is designed this way.
What does this failure have to do with free software? If anything, it should be easy.
Even if you have an open source DNS server that uses text files, a major DNS registrar should be automating the hell out of it. I'm struggling to think of a reason why you wouldn't generate all your DNS records from a database. The files aren't that complicated, and they're essentially tabular data anyway.
I once saw an admin go on about how much 'better' Linux DNS servers were, then spend 5 hours hunting typos in the DNS co
Re: (Score:3, Insightful)
Not if the configuration check you wrote checks for the trailing "." anyways. And if it doesn't, you need to rewrite it.
Re: (Score:2)
It's not "a" dot, it's "every" dot. A bad script adn DNSSEC are to blame. Note that this is version 4 (5?) of dnssec. The earlier ones just didn't work.
And there's a real bad gotcha in the current one they haven't found yet that has still to raise it's ugly head. In time.
Re: (Score:2)
at 2am, I, and most mammals, are not at their mental best,
I'm a black-footed ferret, you insensitive clod!
Re: (Score:2)
I'm no DNS expert, but I can't fathom why negative responses are cached at all. You have many, many more requests for valid domains than you do for invalid ones and the vast majority of the invalid ones are one-off typos. I just don't see what the benefit is. We could do away with an entire class of sysadmin headaches if all resolver software configuration and network policies defaulted to not caching negative responses.
Re: (Score:2)
Obviously, it passed syntax-checking, or the server wouldn't have loaded it. What you are looking for is semantic-checking, which is much more difficult. I expect that the generation scripts will be expanded to check for more things; that's generally what happens (you check for what you can think of, and expand the checking when someone thinks of a better way to break things).
Negative caching (in BIND anyway) tops out at 3 hours (it looks like .se has it set to 2 hours). The NS record TTL is 2 days, so o
Re: (Score:2)
And if you get so emotional for 30min of Internet downtime you will probably die out of stress too soon.
Re: (Score:2)
"I would expect that at the TLD level, a change to a configuration file would have to be inspected by someone AND run through some syntax-checking scripts..."
Expect price and time-to-activation increase for second level domains way beyond current status then.
"DNS servers (and individual computers!) cache negative results."
Yeah, but in practice only for individual resources, not whole domains, since negative answers from authoritative sources must include SOA references as per RFC2308.
"Anything anyone did a
Re:change control / management, anyone? (Score:4, Funny)
Sweden porn?
IKEA instruction manuals?
Re: (Score:2)
Don't you mean "I wrong code" in this context?
Re: (Score:2)
20 GOTO 10
Re:change control / management, anyone? (Score:4, Insightful)
Excessive paperwork like 30 min to fill out a change request form to do something like make a 30 second edit to a config file and sighup a daemon is stupid and you'll hear no argument from me on that. Change control per se however, is essential, particularly in a large enterprise. Running part of that kind of infrastructure without change control would be like trying to manage the kernel source tree without cvs (or svn or $REPOS_OF_CHOICE, analogy holds either way.)
The problem is not change control, its the way it is implemented. Change control methodology is designed by PHBs who haven't actually done the tech work in years, if they ever did. It's then scribbled all over by a "business analyst" who thinks a sigpipe is a plumbing problem and by the time guys actually doing the work get hold of it it has become a nightmare of procedural BS when all you really needed was a way to make sure everything you do to a live production system is documented and that anything other than emergency break-fix at least got basic testing and a second pair of eyes looking at it before rolling it out.
Re: (Score:2)
Running part of that kind of infrastructure without change control would be like trying to manage the kernel source tree without cvs (or svn or $REPOS_OF_CHOICE, analogy holds either way.)
I hate to break it to you, but until 2002 the Linux kernel was managed without automated version control. It worked quite well, actually.
Re: (Score:2)
Then why did they stop doing it?
Actually, I'll tell *you* why they stopped doing it: because Linus realized he was doing by hand a job that could be done much better by machine.
Re: (Score:2)
"Then why did they stop doing it?"
Because it didn't scalate not because Linus thought his previous procedure made kernel quality lacking.
Re: (Score:2)
Running part of that kind of infrastructure without change control would be like trying to manage the kernel source tree with cvs.
FTFY ;-)
Re: (Score:2)
Yes, that's why we have testbeds. The problem is not the missing character or whatever, is testing stuff before making a change in a system which affects thousands of websites.
So I guess it's... (Score:5, Funny)
Re: (Score:2)
I'm chopping up the zone files if that's ok with you (tosses random shyte over shoulder)
We'll scoop up all the trailing dots and put them in the stew
BORKBORKBORK!
Re: (Score:2)
Re: (Score:2)
Iceland? That would be BjorkBjorkBjork surely?
This is a Muppets' Swedish Chef reference.
Ah, the joy of automated oopsies. (Score:2)
Comment removed (Score:3, Funny)
DNS is the problem (Score:5, Interesting)
Re: (Score:2)
And your robust solution to a scalable global directory of name-to-ip address mapping is... ?
Re:DNS is the problem (Score:5, Funny)
Regedit32.exe
Upgrade .com to .exe (Score:2)
Regedit32.exe
I agree. It's long past time for the .com domain to be upgraded to .exe.
Re: (Score:2)
I agree. It's long past time for the .com domain to be upgraded to .exe.
No, .exe is the new domain for malware and trojan distribution websites. Did you miss the recent ICANN memo?
Re: (Score:2)
DHT. Thanks for asking. Efforts are already underway, quietly, so ICANN doesn't notice and cannot co-opt it. Oh, and name and address shortages? Thing of the past.
The end of an era where artificial scarcity to promote a monopoly to make the insiders very wealthy is nearly at an end. http://forum.icann.org/lists/bc-gnso/msg00134.html [icann.org]
I'm shocked nobody is asking "what have all those poeple done for 10 years and many many millions of dollars".
Re:DNS is the problem (Score:4, Insightful)
Except the Pakistan affair was about the BGP routing protocol. I agree the file format is nutty, though.
I can't think of a better alternative to the hierarchical system, perhaps you have a suggestion. A flat namespace would be an administrative impossiblity, not to mention the stress it would put on name servers. Increasing the number of TLDs would lessen the impact of a single failure, though.
Re: (Score:3, Insightful)
Pakistan taking out Youtube had absolutely nothing to do with DNS, they wrongly propagated a BGP announcement for the youtube IPs outside of Pakistan, so about 1/3 of the internet routed traffic into their black hole instead of to Youtube. Pretty effective blocking had they kept it internal, but they didn't.
Re: (Score:3, Informative)
Well in the 1980's when the RFC was written for zone files (1034/1035) it probably sounded like a perfectly sound way to configure this sort of thing, same with DNS in general (RFC's for which were also written in the 1980's).
If it were invented from scratch today I'm sure it would resemble something like LDAP.
The fact we haven't had more mass DNS failures like this is actually surprising.
Re: (Score:2)
It still boggles my mind that anyone thought zone files are a good idea. The file format is so damn brittle, that a single byte can spell disaster. On top of that, the hierarchical naming structure presents an inherent systemic risk for all sub-domains as exhibited by this .se fiasco. Nevermind the injection attacks, Pakistan taking out Youtube, and the rest, you have organizations like Verisign which profit immensely off of keeping the system broken. And don't even bother mentioning DNSSEC, as it still doesn't resolve this fundamental issue. The next systemic fuckup will simply be a signed fuckup.
Yes, it's a shame you were still in diapers when this solution was developed. They could have benefited from your vast wisdom. Or maybe not, if you think the problem with YouTube in Pakistan was due to DNS rather than BGP.
Re: (Score:2, Insightful)
Besides, if we redesigned it now, it would be insanely complex and bloated, not to mention never fully implemented (CSS? ha!), as there would be too many parties "contributing".
Re:DNS is the problem (Score:5, Informative)
Part of the problem with DNS these days, which your post exemplifies, is that from very early on "BIND's implementation of DNS", and "DNS The Protocol" have been mashed together and confused by the RFC authors (who were involved with the BIND implementation and had motive to encourage the world to think only in BIND terms) and basically everyone who ever used DNS in any capacity. Zonefiles are not implicit in DNS address resolution (neither for authoritative servers or recursive caches). They really aren't any part of the wire DNS protocol for resolving names. They *are* part of a wire protocol for secondary servers that slave zonefiles from primary servers, but even in that case it's really more a "BIND convention" than a necessity. Ultimately how you transfer a zone's records from a master server to a slave server is up to however those two servers and their administrators agree to do so. You can skip the AXFR protocol that uses zonefiles and instead do something else that works for both of you. Inventing a new method of slaving zone data is easy and doesn't involved much complicated rollout. Some people just rsync zonefiles for instance instead of using AXFR today.
It's really frustrating (believe me, I've done it) when you try to implement a new DNS server daemon from scratch from the RFCs, and you have to wade through this mess of "what's a BIND convention that doesn't matter and what's important to the actual DNS protocol for resolving names on the wire".
Re: (Score:2)
BIND was the spec for DNS for a while. But recently Vixie has washed his hands of that mess by saying "Don't use BIND as a spec".
Like that helps Paul.
Re: (Score:3, Interesting)
From this overview, it is possible to conclude that DNS is a poorly specified protocol, but that would be unfair and untrue. DNS was specified loosely, on purpose. This protocol design is a fine example of what M.A. Padlipsky meant by “descriptive rather than prescriptive” in his 1984 thriller, The Elements of Networking Style (Prentice Hall). Functional interoperability and ease of implementation were the goals of the DNS protocol specification, and from the relative ease with which DNS has grown from its petri dish into a world-devouring monster, it’s clear to me that those goals were met. A stronger document set would have eliminated some of the “gotchas” that DNS implementers face, but the essential and intentional looseness of the specification has to be seen as a strength rather than a weakness.
Re: (Score:2)
It gets worse. In 2007, Paul Vixie wrote an article in ACM Queue [acm.org] basically praising the vagueness of the DNS protocol specifications:
From this overview, it is possible to conclude that DNS is a poorly specified protocol, but that would be unfair and untrue. DNS was specified loosely, on purpose. This protocol design is a fine example of what M.A. Padlipsky meant by “descriptive rather than prescriptive” in his 1984 thriller, The Elements of Networking Style (Prentice Hall). Functional interoperability and ease of implementation were the goals of the DNS protocol specification, and from the relative ease with which DNS has grown from its petri dish into a world-devouring monster, it’s clear to me that those goals were met. A stronger document set would have eliminated some of the “gotchas” that DNS implementers face, but the essential and intentional looseness of the specification has to be seen as a strength rather than a weakness.
Correlation does not imply causation.
DNS didn't grow to be huge because it was designed loosely, it happened to grow big because coincidentally the Internet took off and become huge, and the Internet happened to use DNS. It would be a bit of a stretch to say that the Internet become the size it is today because one of the many underpinning protocols and standards was loosely specified.
The Internet could have used any number of alternate name lookup systems, and it would have grown to its current size just f
Re: (Score:3, Interesting)
The file format is so damn brittle, that a single byte can spell disaster.
You know what, so is ELF. Who said you should write zonefiles by hand let alone without any kind of syntax verification.
Input syntax is never really an issue. You only ever lack the necessary tools or you are unable to use them properly. It can always be hidden behind a precompiler or whatever necessary.
Hmmm... wait, termcap. I stand corrected.
Why MaraDNS uses a special zone file format (Score:2, Interesting)
This is why MaraDNS [maradns.org] (my open-source DNS server) uses a special zone file format.
MaraDNS uses a zone file format that, for the most part, resembles BIND zone files. However, the zone file format has some minor differences so the common "Forgot to put a dot at the end of a hostname" and the "forgot to update the SOA serial number" problems do not happen; a domain name without a dot at the end in a syntax error in MaraDNS' zone file parser; if you want to end a hostname with the name of the zone in questio
Re: (Score:3, Insightful)
Can MaraDNS handle IPv6 now? Last time I used it I had to ditch it in end as IPv6 support was lacking.
There's møre to Sweden than .se (Score:5, Funny)
Wi nøt trei a høliday in Sweden this yer?
See the løveli lakes
The wonderful telephøne system
And mani interesting furry animals
Re:There's møre to Sweden than .se (Score:5, Funny)
We apologise for the fault in the previous post. Those responsible have been sacked.
Nö There's Nöt! (Score:2)
The Swedish alphabet does not have the letter "ø", it's written "ö" in Swedish. The letter "ø" is found in Danish and Norwegian.
The letter is NOT a ligature or a diacritical variant of the letter o! The vowel it sounds most like is the vowel in "bird" or "hurt".
Re:No There's Not! (Score:2)
Hand in your geek card: http://www.youtube.com/watch?v=4I2qWq9L6rw#t=1m00 [youtube.com]
A moose once bit my DNS... (Score:2)
What's a " .SE TLD"? (Score:2)
That's how it looked like in Thunderbird's RSS reader.
It happens (Score:2)
Because Unix admins never test-run their code.
Simple solution (Score:2)
Re: (Score:3, Interesting)
Uh, it would make no difference.
DNS is hierarchical, and has teh caching.
2 independent groups running DNS would strive to make sure they sync with each other quickly - thus all failures would sync quickly too.
The difference between
- the delay of a correct change propagating across the two firms running DNS
- the delay of an incorrect change propagating within a single DNS
would essentially be zero.
No good things could come from what you propose unless it was specifically designed to have a 24
Re: (Score:2)
You can't protect against a single point of failure when you're talking about a person updating a system. Redundancy protects against computer error, not human error.
See, ultimately, somebody, somewhere has to be responsible for the name updating. Having it in two places just means that an incorrect update gets pushed to both places by the person making the change.
In this case, the effects were minimized by the nature of DNS itself, and the caching mechanisms involved. Most servers probably never saw the ch
Re: (Score:2)
Re: (Score:2)
"In this case, the effects were minimized by the nature of DNS itself"
Well, at least somebody shows some common sense.
Of course, losing a whole TLD even if only for half an hour is a shame probably the one that did it won't include in his resume, but the fact is that nobody will expend more on secure a resource than it's very value. DNS is basically distributed, cached information described on plain text files; if an update works (which is vastly most of the time), it works; if it isn't you detect the fail
Re: (Score:3, Funny)
It looks like someone messed up the summary. I'm pretty sure it should be:
Peengdum und Netvurk Vurld ere-a repurteeng thet zee SE tld drupped ooffff zee internet yesterdey dooe-a tu a boog in zee screept thet generetes zee SE zune-a feele-a. Zee SE tld hes cluse-a tu oone-a meelliun dumeeens thet ell vent doon dooe-a tu meessing zee treeeling dut in zee SE zune-a feele-a. Sume-a cecheeng nemeserfers mey steell be-a retoorneeng infeleed DNS respunses fur 24 huoors.
Re: (Score:2)
Re: (Score:2)