Taking control of all .io domains with a targeted registration(thehackerblog.com)
thehackerblog.com
Taking control of all .io domains with a targeted registration
https://thehackerblog.com/the-io-error-taking-control-of-all-io-domains-with-a-targeted-registration/
257 comments
Just so no one is misled: "original inhabitants" does not mean "indigenous peoples" with respect to the BIOT. The islands were not populated prior to late-18th Century European colonization. The depopulation was of post-colonial people.
> Just so no one is misled: "original inhabitants" does not mean "indigenous peoples" with respect to the BIOT. ... The depopulation was of post-colonial people.
Oh that's fine then. They only lived there for what 100 years, totally fine to do these things to those 1000 some people:
https://en.wikipedia.org/wiki/Diego_Garcia
---
first tactics were implemented to decrease the population of Diego Garcia. Those who left the island - either for vacation or medical purposes - were not allowed to return, and those who stayed could obtain only restricted food and medical supplies. This tactic was in hope that those that stayed would leave "willingly".[26] One of the tactics used was that of the killings of Chagossian pets. Dogs were carried into sheds where they were gassed in front of their owners.[26]
---
Oh that's fine then. They only lived there for what 100 years, totally fine to do these things to those 1000 some people:
https://en.wikipedia.org/wiki/Diego_Garcia
---
first tactics were implemented to decrease the population of Diego Garcia. Those who left the island - either for vacation or medical purposes - were not allowed to return, and those who stayed could obtain only restricted food and medical supplies. This tactic was in hope that those that stayed would leave "willingly".[26] One of the tactics used was that of the killings of Chagossian pets. Dogs were carried into sheds where they were gassed in front of their owners.[26]
---
Is there a country on Earth which does not have a forced removal of 1000+ people in it's history?
I mean, that doesn't justify the act, but I question the logic of claiming moral superiority or questioning authenticity over this.
I mean, that doesn't justify the act, but I question the logic of claiming moral superiority or questioning authenticity over this.
It isn't anywhere near the worst thing the UK has done (in this case for the US so, I think they share a bit of the blame). The key issue here is that it is ongoing - the UK still isn't allowing them back or properly compensating them. The UK government should recognise that what it did was wrong, establish that the land belongs to the Chagossians and, broker an agreement where the US tries to try to buy the land needed for the base from them. There will be a price that the US government is willing to pay to keep the base there, that the Chagossians will accept, I suspect. If there is not, the base should have to be moved over a period of five years. An alternative might be the construction of an artificial island nearby. It is also possible that the value to the Chagossians, and the cost of building an artificial island, are both greater than the value to the US of having the base, in which case they should just abandon it. This is the only fair solution IMHO.
Why is that an important distinction? Is forcible expulsion and dispropriration more acceptable if the people were brought to the island as slaves and laborers in the mid-1700s?
> an important distinction
That it is a distinction is important to me. Having difficult discussions is made more difficult if we obscure facts or conflate terms.
> more acceptable
I applied no normative judgement.
That it is a distinction is important to me. Having difficult discussions is made more difficult if we obscure facts or conflate terms.
> more acceptable
I applied no normative judgement.
> That it is a distinction is important to me.
Why ?
Why ?
Are you being deliberately obtuse? It's a pretty important distinction that these were not some native tribesmen with millennia of ancestral history tied up in the lands.
100s of years though, so from the perspective of an individual on the island it's exactly the same -- their entire life was on that island. So, the distinction is pointless and reeks of apologetics IMO.
"Sir Bruce Greatbatch, KCVO, CMG, MBE, governor of the Seychelles, ordered all the dogs on Diego Garcia to be killed. More than 1000 pets were gassed with exhaust fumes. "They put the dogs in a furnace where the people worked", Lisette Talatte, in her 60s, told me, "and when their dogs were taken away in front of them our children screamed and cried". Sir Bruce had been given responsibility for what the US called "cleansing" and "sanitising" the islands; and the killing of the pets was taken by the islanders as a warning."
"Sir Bruce Greatbatch, KCVO, CMG, MBE, governor of the Seychelles, ordered all the dogs on Diego Garcia to be killed. More than 1000 pets were gassed with exhaust fumes. "They put the dogs in a furnace where the people worked", Lisette Talatte, in her 60s, told me, "and when their dogs were taken away in front of them our children screamed and cried". Sir Bruce had been given responsibility for what the US called "cleansing" and "sanitising" the islands; and the killing of the pets was taken by the islanders as a warning."
By that logic, ethnic Europeans are the 'original inhabitants' of North America.
I'm also unclear on why you quoted what the British did in your post - how does it relate to whether or not calling those people 'original inhabitants' is misleading? Do you believe that, if the British did something sufficiently wrong to them, that calling them 'original inhabitants' will be less misleading?
I'm also unclear on why you quoted what the British did in your post - how does it relate to whether or not calling those people 'original inhabitants' is misleading? Do you believe that, if the British did something sufficiently wrong to them, that calling them 'original inhabitants' will be less misleading?
Not everything is a contest. It doesn't matter how "original" natives are if they're natives.
The reason "ethnic Europeans" aren't "the original inhabitants of North America" is that European settlers violently displaced (or killed) the previous inhabitants.
Heck, the "original" inhabitants of North America (as far as we know) actually originated in what is now mostly Russia if you go back a few dozen millenia. And if you go back further than that (according to mainstream scientific consensus) we all likely originated in Africa. Defining the term "original inhabitants" as an absolute is blatantly begging the question (specifically it only works if you're a creationist).
People were subjected to physical and psychological violence to be forcibly removed from their home and birthplace. That's bad enough, no matter how many generations lived in the same place before. This isn't about who's had it worse.
The reason "ethnic Europeans" aren't "the original inhabitants of North America" is that European settlers violently displaced (or killed) the previous inhabitants.
Heck, the "original" inhabitants of North America (as far as we know) actually originated in what is now mostly Russia if you go back a few dozen millenia. And if you go back further than that (according to mainstream scientific consensus) we all likely originated in Africa. Defining the term "original inhabitants" as an absolute is blatantly begging the question (specifically it only works if you're a creationist).
People were subjected to physical and psychological violence to be forcibly removed from their home and birthplace. That's bad enough, no matter how many generations lived in the same place before. This isn't about who's had it worse.
So why oppose clarifications on what 'original' means in this context?
They were expelled in 1965. The current year is 2017. If we wait a few more decades this discussion will be pointless either way.
I'm not opposing clarifications. I'm opposing quibbling over the semantics of "original" as if the distinction adds anything to the conversation.
Their parents lived there, they were born there, they were violently expelled and suffered emotional abuse. The number of dead ancestors (or lack thereof) in the ground does not invalidate the suffering these people were forced to endure.
I'm not opposing clarifications. I'm opposing quibbling over the semantics of "original" as if the distinction adds anything to the conversation.
Their parents lived there, they were born there, they were violently expelled and suffered emotional abuse. The number of dead ancestors (or lack thereof) in the ground does not invalidate the suffering these people were forced to endure.
What would you call the descendant of a Frenchman who settled in Quebec during the 1600s ?
Immigrant? No. Settler? Not really after so many years.
As an immigrant, I view them as natives Quebecers.
What would you call them?
Immigrant? No. Settler? Not really after so many years.
As an immigrant, I view them as natives Quebecers.
What would you call them?
By European standards the US is mostly inhabited by non-natives. So I guess it'd be okay to forcibly expel everyone but the Natives because they don't have millennia of ancestral history?
I'd hope the more important distinction is how people are removed, not how many generations of dead people there were before them.
I'd hope the more important distinction is how people are removed, not how many generations of dead people there were before them.
If a man shows up with a gun to run me off my land, it doesn't matter whether it was my father that bought it or my grandfather or my great-grandfather. What's important is the forcible dispropriation itself.
Cases like this just make a mockery of the Lockean natural rights theory of property.
Cases like this just make a mockery of the Lockean natural rights theory of property.
I made no comment on if it was right or not, I simply maintain that there is an important distinction there.
No its not.
it's
Rather than correcting grammar, why don't you respond to the numerous rebuttals of your point of view elsewhere in this thread ?
You says its important but don't explain why, and empathise that you place no "normative judgement" on it.
Normative judgment doesn't make sense btw, judgement adhering to the norm - eh wat ? I think you meant moral/ethical.
You says its important but don't explain why, and empathise that you place no "normative judgement" on it.
Normative judgment doesn't make sense btw, judgement adhering to the norm - eh wat ? I think you meant moral/ethical.
For a conversation to happen, everyone should be on the same page. Distinction for the sake of clarity should always be welcomed and not confused with endorsing a specific action or behavior.
It doesn't really matter at all. The land didn't come with a .io ccTLD. It's dervived from a name the British chose, so it's not like they stole the domain name from those people, right?
Displacing settlers is a different question.
Displacing settlers is a different question.
Still, why does the UK need a special TLD for a naval base?
IANA allows delegation of country-code TLDs for all countries and territories represented in the ISO 3166-1 standard.
The thing to bear in mind is this standard is used for a number of different purposes historically that has informed territories and other "non"-countries being added.
For example, it is used by postal services for routing physical mail. A lot of far flung island dependencies are coded individually because their mail wouldn't route through their mother country but through other ports.
The addition of "EU", while not a country, reflected the needs of the "EUR" currency code when the Euro was introduced (the first two letters of ISO 4217 currency codes are derived from the ISO 3166-1 standard).
The thing to bear in mind is this standard is used for a number of different purposes historically that has informed territories and other "non"-countries being added.
For example, it is used by postal services for routing physical mail. A lot of far flung island dependencies are coded individually because their mail wouldn't route through their mother country but through other ports.
The addition of "EU", while not a country, reflected the needs of the "EUR" currency code when the Euro was introduced (the first two letters of ISO 4217 currency codes are derived from the ISO 3166-1 standard).
Because the domain name system uses ISO-8859, which provides codes for "countries, territories and islands".
The standard provides codes for such places since different law often applies in territories and on islands.
(See also: UM, TW, EH, AQ, SH, SJ, and many others.)
The standard provides codes for such places since different law often applies in territories and on islands.
(See also: UM, TW, EH, AQ, SH, SJ, and many others.)
I think the morally questionable problem is this: I am highly doubtful that the original inhabitants of the islands are receiving any revenue whatsoever from the corporation which runs .IO. At least the small pacific island nation states that have hired third parties to run their ccTLD have contracts and agreements in place for a revenue share.
Why should they get any revenue from .io? The .io is an invention of the government and has nothing to do with the original inhabitants. The "original" people were removed well before .io even existed.
Might as well demand they get paid for any inventions the military makes while testing stuff out there.
And if the British hadn't done this and gave control over to the people living there 50 years ago, they wouldn't get .io either, because they wouldn't call themselves British Indian Ocean Territories. They'd have used something reflecting the name in their language.
So again, this is a "resource" purely created by the British government being there.
Maybe it's terribly unfair and bad what they've done to those peoples, but .io doesn't figure into that at all.
Edit: I suppose if they had their own nation state, they could make some money that they couldn't otherwise. But why stop at domain names (which, again, wouldn't be .io, it'd be .cx or something for Chagossians)? They can't issue passports, a potentially valuable resource, not being a sovereign nation. They can't run "tax haven" schemes, etc. Seems like getting upset over .io itself is pointless compared to all the other stuff they could do with an internationally recognized government.
Might as well demand they get paid for any inventions the military makes while testing stuff out there.
And if the British hadn't done this and gave control over to the people living there 50 years ago, they wouldn't get .io either, because they wouldn't call themselves British Indian Ocean Territories. They'd have used something reflecting the name in their language.
So again, this is a "resource" purely created by the British government being there.
Maybe it's terribly unfair and bad what they've done to those peoples, but .io doesn't figure into that at all.
Edit: I suppose if they had their own nation state, they could make some money that they couldn't otherwise. But why stop at domain names (which, again, wouldn't be .io, it'd be .cx or something for Chagossians)? They can't issue passports, a potentially valuable resource, not being a sovereign nation. They can't run "tax haven" schemes, etc. Seems like getting upset over .io itself is pointless compared to all the other stuff they could do with an internationally recognized government.
When Britain (and thus the US) decide they no longer require the island for a naval base, it will be given to Mauritius.
The .IO domain would eventually be deleted, and that territory represented under the existing .MU (Mauritius) domain.
Judging by https://en.wikipedia.org/wiki/.mu I don't think the Mauritian people have much benefit from the arrangements for .MU.
The .IO domain would eventually be deleted, and that territory represented under the existing .MU (Mauritius) domain.
Judging by https://en.wikipedia.org/wiki/.mu I don't think the Mauritian people have much benefit from the arrangements for .MU.
.SU - for the Soviet Union - still exists, I somewhat doubt that many TLDs will ever be deleted in general.
.SU is actually the only former country with a TLD still delegated, and quite a few have been removed. In recent years .AN, .TP, .YU, .ZR have been phased out representing former countries.
I am similarly outraged that I haven't had any cheques from Nominet come through the post recently and as a UK tax paying citizen I am outraged at this oversight.
I want my £10!
I want my £10!
Are the original inhabitants of these islands still alive?
The question is NOT about the morality of deportation, but about about the legitimacy of the UK's ownership.
The only two nations that have laid claim to the territory are France and the United Kingdom. (France lost it in the Napoleonic Wars.)
The only two nations that have laid claim to the territory are France and the United Kingdom. (France lost it in the Napoleonic Wars.)
Ha ha :)
Of course, the difference between the Indian Ocean Territory and India, is that people lived in India before. When the French showed up, the atolls were uninhabited.
Of course, the difference between the Indian Ocean Territory and India, is that people lived in India before. When the French showed up, the atolls were uninhabited.
I'd say that using the land of your own country - owned by people in your country - for military purposes, while sketchy, is definitely more acceptable than taking an island from its indigenous occupants by force. The UK ownership then seems at least to be legitimate.
How is that relevant to this discussion? They are original habitants, or are you contesting that?
I'm in the TLD space (we run a fair number of gTLDs). If a gTLD operator screwed up like this then there could be consequences. A ccTLD, however, runs with very few restrictions. I don't see much of consequence happening to it as a result of this.
I will, however, say that gTLDs are generally more secure and well-run than smaller ccTLDs, and are worth preferring for that reason. It's a weird historical quirk that .io randomly became popular in the developer community, but there are better options. And, as you point out, it's morally suspect, which is why we don't use it for new domain names.
I will, however, say that gTLDs are generally more secure and well-run than smaller ccTLDs, and are worth preferring for that reason. It's a weird historical quirk that .io randomly became popular in the developer community, but there are better options. And, as you point out, it's morally suspect, which is why we don't use it for new domain names.
There are a few ccTLDs that differ from that, though. DENIC and CZNIC are two that are generally very well-run, DENIC even offering better security and safety than many gTLDs (while also being a cooperative, not a commercial NIC, so prices are very low, too)
It is really nice, that the .de domain is seen more as infrastructure than some business. But there are a few downsides to DENIC as well.
1. you need to have a person (juridicial or natural) with an address in Germany to register and list that person as ADMIN-C
2. if you run a website that provide contents which COULD generate revenue, you have to have an Impressum [1] which includes the address, names, etc. of the website owner.
This is pretty annoying if you are sensitive about privacy and do not want your details out in the open.
[1] https://en.wikipedia.org/wiki/Impressum
1. you need to have a person (juridicial or natural) with an address in Germany to register and list that person as ADMIN-C
2. if you run a website that provide contents which COULD generate revenue, you have to have an Impressum [1] which includes the address, names, etc. of the website owner.
This is pretty annoying if you are sensitive about privacy and do not want your details out in the open.
[1] https://en.wikipedia.org/wiki/Impressum
Well, this is what every domain should have, though. A Ladungsfähige Anschrift of a person that is liable.
This is a major criticism I have with many other domains, I don’t know where to send a C&D, or whom to sue if they violate my rights.
And requiring only commercial entities to have these things also makes sense.
This is a major criticism I have with many other domains, I don’t know where to send a C&D, or whom to sue if they violate my rights.
And requiring only commercial entities to have these things also makes sense.
Agree to disagree. Of the top of my head I can think of several useful things where a public (private) address would be problematic:
1. you want to do something like wiki leaks
2. you want to publish your thoughts anonymously, let's say you are from the LGTB spectrum and want to engage with people by building a forum or blog to communicate with them -> this could lead to potential problems with family, friends and work
3. you have political views and publish them. Now say someone disagrees with your views and is potentially aggressive. Do you want them to know where your family lives?
4. you do not wan't annoying calls by people who crawl the DENIC records (happens to me regularly)
I agree with you that a person should be liable for the stuff they do, but should also be able to engage in open discussion while protecting their privacy. FWIW If someone does bad stuff on a .de domain there are several options:
a) take down the domain via DENIC, or b) take down the domain via ISP or c) take down the domain via Hosting provider
If you really did illegal stuff, I am with you and someone (DENIC, ISP or Host) probably should have the knowledge of the domain owner which could be subpoenaed to lawfully prosecute someone.
1. you want to do something like wiki leaks
2. you want to publish your thoughts anonymously, let's say you are from the LGTB spectrum and want to engage with people by building a forum or blog to communicate with them -> this could lead to potential problems with family, friends and work
3. you have political views and publish them. Now say someone disagrees with your views and is potentially aggressive. Do you want them to know where your family lives?
4. you do not wan't annoying calls by people who crawl the DENIC records (happens to me regularly)
I agree with you that a person should be liable for the stuff they do, but should also be able to engage in open discussion while protecting their privacy. FWIW If someone does bad stuff on a .de domain there are several options:
a) take down the domain via DENIC, or b) take down the domain via ISP or c) take down the domain via Hosting provider
If you really did illegal stuff, I am with you and someone (DENIC, ISP or Host) probably should have the knowledge of the domain owner which could be subpoenaed to lawfully prosecute someone.
making a single person personally liable for content that's hosted on a domain is problematic, to say the least. Go down that path and you eventually end up where the chinese government is now. Where you need a "license" from some ministry to operate an http daemon and you need to hire censors to police all user generated content that disagrees with an authoritarian regime's politics.
https://www.google.com/search?q=china+lgbt+web&ie=utf-8&oe=u...
https://www.google.com/search?q=china+lgbt+web&ie=utf-8&oe=u...
There's probably around a dozen ccTLDs that are really competently run and that are world-class. Beyond that I'd stick with competently run gTLDs.
I actually just met a bunch of the denic guys at a conference they hosted a month ago in Frankfurt. They're on point with their Internet stuff.
I actually just met a bunch of the denic guys at a conference they hosted a month ago in Frankfurt. They're on point with their Internet stuff.
I think it's more than a dozen. I would expect all wealthy, tech-savvy democracies to have fairly competently run ccTLDs. It's just that there's about 200 countries in the world, and quite a lot of those are a complete mess.
given the incredible importance to global internet infrastructure of things like the DE-CIX in frankfurt, I am not surprised that the Germans have their shit together when running critical back end systems.
.me and .ca "seem" competently run.
More so for .me, ran by the owners of .org
More so for .me, ran by the owners of .org
if .ca was not competently run, I'm pretty sure the federal government would step in and put it into the hands of people with real DNS/network engineering credibility.
Unlike the rarely used .us for the USA, it is used for the vast majority of canadian domestic corporations' web identities.
Unlike the rarely used .us for the USA, it is used for the vast majority of canadian domestic corporations' web identities.
And also the Canadian government for that matter
As an average user, how do I know which is which? How can I tell whether .ABCXYZ is competently run and trustworthy?
gTLDs & ccTLDs have to be some of the worst ideas in Internet history.
gTLDs & ccTLDs have to be some of the worst ideas in Internet history.
ccTLDs are pretty much the most sensible thing in DNS hierarchy. The "original" TLDs (.com, .net, .org etc) had mostly lost their meaning by late 90s (iirc), and were heavily biased towards the US anyways and as such would have made far more sense as second-level domains for .us, where enforcing the separation could have at least hypothetically worked in some reasonable way.
> gTLDs have to be some of the worst ideas in Internet history.
Not if you're an investor in Donuts, LLC, they're not...
Not if you're an investor in Donuts, LLC, they're not...
ccTLDs (Country Codes) are always two letters. gTLDs aren't.
The gTLDs have a pretty strict ICANN contract they have to follow; ccTLDs are looser.
The gTLDs have a pretty strict ICANN contract they have to follow; ccTLDs are looser.
_ASCII_ ccTLDs are always two letters. There are ccTLDs in other scripts that are of variable length (.ไทย, .ελ, .укр, .한국 etc.)
ccTLDs are loosers? Not according to their increasing registration figures.
Looser != loser
ccTLDs don't appear to be held to very high standards. For example the .AF top level domain (which is controlled by the government's ministry of communications) doesn't even have a working website, www.nic.af
They're not held to any standards, really. Some of the smaller ccTLDs are basically just run using hand-edited zone files and spreadsheets to track ownership and expiration thereof.
There are also issues like the .LY ccTLD being owned by whatever government claims to be in control of Libya this month, and occasionally revoking domains for things they don't agree with. If I recall correctly for a long time there were several commercial services reselling .LY, but its stability is questionable at best.
Like .ai, the new "hot" ccTLD.
We just used ai.google instead of google.ai as the canonical domain name for Google's AI initiative for precisely this reason. (We run .google and you can see the source code at https://nomulus.foo )
I just looked at the wikipedia page for the .ai ccTLD and registering something in Anguilla requires.... a fax machine?
It's like time traveling to 1987.
It's like time traveling to 1987.
If I'm reading https://whois.ai/cgi-bin/register.py? correctly, I'm not sure it's strictly required - it might just delay our account by a month (it's not 100% clear IMO):
> We will email you a password after which you need to login and pay the $100, unless you are resident in Anguilla.
> After this we will send you a letter, fax and short text message (SMS) with codes on them. Please, be sure your information is correct so you can receive verifiaction codes. When you get these you need to login and enter them.
> We will also wait 3 months to make sure there is no problem with your credit card. But each successfully verification will decrease this period by one month, so if you pass all of them you do not need to wait 3 month.
Shame it's so arcane/expensive ($100 for account, then $100/2 years per domain) - there's a couple of joke domains I might have picked up if they were cheap enough (gomennas.ai / ebihara.ai [character from Persona4]).
I do appreciate that the TLD alone resolves though: http://ai./
> We will email you a password after which you need to login and pay the $100, unless you are resident in Anguilla.
> After this we will send you a letter, fax and short text message (SMS) with codes on them. Please, be sure your information is correct so you can receive verifiaction codes. When you get these you need to login and enter them.
> We will also wait 3 months to make sure there is no problem with your credit card. But each successfully verification will decrease this period by one month, so if you pass all of them you do not need to wait 3 month.
Shame it's so arcane/expensive ($100 for account, then $100/2 years per domain) - there's a couple of joke domains I might have picked up if they were cheap enough (gomennas.ai / ebihara.ai [character from Persona4]).
I do appreciate that the TLD alone resolves though: http://ai./
FWIW, 101 Domains allows you to register a .ai domain (I registered zuse.ai there) and you don't have to do anything with a fax, etc. Now, maybe 101 has to fax something to somebody in Anguilla, but as the end user, you're isolated from that. Unless things have changed since I registered my domain.
Hey, when are you guys gonna open .meme? Asking for a friend :-)
I'd love to open it up tomorrow, but alas, I'm not the decision maker.
How about setting MX records for .google so you can have name@google emails
We also have .gmail, so you can imagine some clever possibilities with that.
God knows how widely a "ben@google" email address would work though. I'm going to guess not very.
God knows how widely a "ben@google" email address would work though. I'm going to guess not very.
True, I imagine a lot of software wouldn't know how to handle an email without a dot in the domain part
That and apparently ICANN would frown upon such an implementation [1]
[1] https://www.icann.org/news/announcement-2013-08-30-en
That and apparently ICANN would frown upon such an implementation [1]
[1] https://www.icann.org/news/announcement-2013-08-30-en
Wouldn't that work like the old Compuserve or Prodigy email addresses? And if it would, wouldn't most email clients have to have "back-compatibility" with it?
There's far too much software that won't accept that, sadly.
Any ETA on .app?
Shame: Afghanistan could really use a stream of teen marketing/hipster revenue for various domains that are x AF.
At least somebody grabbed the delightfully multilayered dope.af domain already...
At least somebody grabbed the delightfully multilayered dope.af domain already...
Why you assume that nic.$cctld must exist?
because that's the URL that the admins of .AF publish. It could be http://whatever.af if they wanted that, but if it had an httpd not showing any content, would be equally as suspect.
https://en.wikipedia.org/wiki/.af
http://www.wipo.int/amc/en/domains/cctld_db/codes/af.html
https://en.wikipedia.org/wiki/.af
http://www.wipo.int/amc/en/domains/cctld_db/codes/af.html
> "It's a weird historical quirk that .io randomly became popular in the developer community"
The reason for me is totally clear: Github Pages gives me a free subdomain for http://pingtype.github.io but not .com.
I registered http://peterburk.github.com before that policy changed.
The reason for me is totally clear: Github Pages gives me a free subdomain for http://pingtype.github.io but not .com.
I registered http://peterburk.github.com before that policy changed.
Besides the old .org, what better options are there for software projects?
Play around at domainr.com, a brainstorming tool some friends and I made a few years ago. It supports all the new generic TLDs.
.sh and .run come to mind in some cases.
what's wrong with the traditional .net ? software projects are pretty much all network related these days. or use the new gTLD .network which is pretty cheap to buy.
.build ?
> and their entire operation should be severely scrutinized by ICANN.
ICANN does not have 'control' in any substantive way over the ccTld's.
https://www.icann.org/resources/pages/cctlds-21-2012-02-25-e...
ICANN does not have 'control' in any substantive way over the ccTld's.
https://www.icann.org/resources/pages/cctlds-21-2012-02-25-e...
In the mid 90's I got to spend a quiet and frankly wonderful 60 days on Diego Garcia while I was enlisted in the USAF. It is a wonderful island, you can bike around the whole thing in a couple hours, the rec facilities were great, beer was incredibly cheap, and the Internet (on such a remote island, in 1995!) was the best/fastest I had seen at that point.
That all said, the forced expulsion thing (which I just caught up on) is news to me now. I guess bullies will always exist. It reminds me of forcibly relocating people in the US via eminent domain to build a highway. It's possible that an ethical argument can be made that if the security of the USA actually did depend on total control of that island, the cost in dollars and emotion of "strongly encouraging" people to move elsewhere might be justifiable (and I do believe they were compensated... the gassing of pets thing is shocking, though).
That all said, the forced expulsion thing (which I just caught up on) is news to me now. I guess bullies will always exist. It reminds me of forcibly relocating people in the US via eminent domain to build a highway. It's possible that an ethical argument can be made that if the security of the USA actually did depend on total control of that island, the cost in dollars and emotion of "strongly encouraging" people to move elsewhere might be justifiable (and I do believe they were compensated... the gassing of pets thing is shocking, though).
Bad actors are on those mailing lists too. What you describe would be the equivalent of mailing fulldisclosure with "Hi all, there might be more unregistered nameservers at .IO (or another 101domains-serviced TLD) that could be used to attack live traffic if anyone wants to grab those, kthx"
I'm fine with that happening, because the people who run .IO need to be spanked. If their customers are subsequently unhappy that their domain names have been hijacked, they can take it up with whatever corporate entity runs .IO. Same problem as publicly disclosing serious flaws with an SSL/TLS root CA.
I own an .IO domain. Do I deserve to have fake LetsEncrypt certs issued against me and my domain hijacked because some engineer forgot to remove some critical NS records or forgot to register some aliases?
Responsible disclosure cat is responsible!
Responsible disclosure cat is responsible!
"Responsible disclosure" is a coercive term. It implies that it's irresponsible to do anything else. "Coordinated disclosure" is far better.
That said, coordinated disclosure is the neighborly thing to do, but it's by no means a moral obligation. It would be perfectly fine for the author to tweet about it, for example.
That said, coordinated disclosure is the neighborly thing to do, but it's by no means a moral obligation. It would be perfectly fine for the author to tweet about it, for example.
No moral obligation? I don't think many people would agree with you on that.
If you are actively poking around at someone's home and you find an unlocked window, you don't think there is a moral obligation to inform the owner of the security issue? No moral issues if you then find a group of hoodlums down the street and announce that house 123 has an unlocked window?
I can see if you were just driving by and saw the window open, you don't really have any obligation (unless you plan to announce it publicly) but if you are actively seeking out security flaws in someone else's property, not disclosing it to the owner and then announcing it or worse, selling it to potentially bad actors seems morally reprehensible.
If you are actively poking around at someone's home and you find an unlocked window, you don't think there is a moral obligation to inform the owner of the security issue? No moral issues if you then find a group of hoodlums down the street and announce that house 123 has an unlocked window?
I can see if you were just driving by and saw the window open, you don't really have any obligation (unless you plan to announce it publicly) but if you are actively seeking out security flaws in someone else's property, not disclosing it to the owner and then announcing it or worse, selling it to potentially bad actors seems morally reprehensible.
This isn't equivalent to "If I leave my door unlocked..." scenarios. It's perfectly legal to register any .io name you want. You can't go poking around someone's house.
The situation is more analogous to discovering that a certain type of door offers no protection, even though it seems to lock. It's perfectly fine to tweet about that, regardless of how many people have that door. The blame lies on the company, not the messenger.
The situation is more analogous to discovering that a certain type of door offers no protection, even though it seems to lock. It's perfectly fine to tweet about that, regardless of how many people have that door. The blame lies on the company, not the messenger.
That would still be unethical. An ethical person would not commit acts which they know have the potential to cause harm to innocent people.
If you're a black hat and you don't give a shit about potential legal ramifications or any injury to anyone (partly because you fear no consequence), there's probably nothing unethical to you about fucking over a bunch of innocent people just so you can "spank" some douchebag management company into following best practices.
If you're a professional, or even a non-douchebag adult, who finds value in the ideal of protecting the innocent customers of a dangerously irresponsible corporation, you would want to work first toward protecting those individuals, and then focus on disciplining the corporation.
If you're a black hat and you don't give a shit about potential legal ramifications or any injury to anyone (partly because you fear no consequence), there's probably nothing unethical to you about fucking over a bunch of innocent people just so you can "spank" some douchebag management company into following best practices.
If you're a professional, or even a non-douchebag adult, who finds value in the ideal of protecting the innocent customers of a dangerously irresponsible corporation, you would want to work first toward protecting those individuals, and then focus on disciplining the corporation.
It represents a moral judgement that it is absolutely not okay (or perhaps: irresponsible) to screw over n+y people for the actions of n people.
This moral judgement is mistaken because its premise is false. The moral blame lies on the company that allowed the problem to happen, not the person calling attention to it. It's not at all the same as "if I leave my door unlocked..." type scenarios. It's perfectly legal to register .io's nameservers.
That's a cop out. If your actions reasonably cause harm to other people, regardless if those actions are "calling attention to" or actually pulling the trigger, that's a moral evil.
If someone goes around the town telling everyone that you leave your door unlocked, while they can't be legally held responsible, they're still morally responsible if someone goes in and steals your stuff armed with that knowledge.
Companies fixing their stuff before that happens is in everyone's best interests at the end of the day - hence responsible disclosure.
If someone goes around the town telling everyone that you leave your door unlocked, while they can't be legally held responsible, they're still morally responsible if someone goes in and steals your stuff armed with that knowledge.
Companies fixing their stuff before that happens is in everyone's best interests at the end of the day - hence responsible disclosure.
Frankly, yes, a little bit. You're choosing to run your website/infrastructure/etc with a dependency on a sketchy service with no oversight (the ccTLD system in general, but .io in particular). Unless you suffer for this choice, the market for provider competence will be broken.
That nobody had any idea was sketchy or un-oversighten until recently. It was not a choice to run their website/infrastructure/etc on sketchy services at all.
No. People who care about internet-scale infrastructural issues have known about these issues for a very long time. However, most people who utilize (and depend on) these services have not taken the time to understand how they work.
Because it's a simple transaction. I pay someone for a domain, I get said domain.
Jimmy Throwawaysite shouldn't have to take the time to understand how DNS works above knowing how to set DNS records, the oversight should come from above. If ICANN wants to let anyone with a couple hundred thou run a TLD they should be making sure that entity can technically manage the TLD.
Jimmy Throwawaysite shouldn't have to take the time to understand how DNS works above knowing how to set DNS records, the oversight should come from above. If ICANN wants to let anyone with a couple hundred thou run a TLD they should be making sure that entity can technically manage the TLD.
That will most likely cause widespread havoc without solving anything and even slow down the actual resolution of the problem.
Strategy is important.
Strategy is important.
> original inhabitants
Is a pretty misleading phrase: they were 1000 or so slaves brought by the French to otherwise unoccupied islands. They should have been compensated like any other group of people whose government wants to build a military base, or a dam, or a highway on their land - but it's not like it was some kind of genocide. Much worse things have happened in pretty much every country on the globe.
Is a pretty misleading phrase: they were 1000 or so slaves brought by the French to otherwise unoccupied islands. They should have been compensated like any other group of people whose government wants to build a military base, or a dam, or a highway on their land - but it's not like it was some kind of genocide. Much worse things have happened in pretty much every country on the globe.
The idea that there should be a breakdown of domains by country is a bad one. There's this situation. There are many other situations where countries don't have the resources or drive to maintain what they have been allocated. And then there's the fact that there are enough domains conflicting with this structure that it makes no intuitive sense.
The fact is that there is nothing that can be derived by an end user from most top level TLDs. EDU is one of the few, but then anybody can have a subdomain in an edu environment for any purpose.
Maybe the time isn't now, but somebody should be thinking about how to replace the current domain management system and with what.
The fact is that there is nothing that can be derived by an end user from most top level TLDs. EDU is one of the few, but then anybody can have a subdomain in an edu environment for any purpose.
Maybe the time isn't now, but somebody should be thinking about how to replace the current domain management system and with what.
People make mistakes. This seems like some manual configuration/technical debt issues. Don't get me wrong, mistakes for these big, highly used TLDs is pretty massive. The scale of this is could have been devastating.
Responsible disclosure to the company that runs the TLD seems like the right first step. This should probably posted on ICANN, ARIN, etc mailing lists even now, but I think the writer's original response is the right one.
Responsible disclosure to the company that runs the TLD seems like the right first step. This should probably posted on ICANN, ARIN, etc mailing lists even now, but I think the writer's original response is the right one.
The people that make this sort of mistake should not be responsible for a TLD. This is one of the worst possible blunders imaginable.
Considering they control the .io TLD these should have been registered and locked as reserved. That this wasn't the policy is but one of the many failings that lead to this outcome.
If I were ICANN I'd slap them with a huge fine to send a message.
Considering they control the .io TLD these should have been registered and locked as reserved. That this wasn't the policy is but one of the many failings that lead to this outcome.
If I were ICANN I'd slap them with a huge fine to send a message.
*coordinated disclosure. "Responsible disclosure" is coercive.
Just about every country has had some war with people removed or killed by an occupier. America, for instance.
yeah...yeah...and the UK seized ".UK" from the Ukraine and this means...
save your politics for politics, not for a technology discussion. We get it, you're moral.
save your politics for politics, not for a technology discussion. We get it, you're moral.
That's not the same thing?
If you're interested, the Ukraine TLD is .ua.
To say they stole it from Ukraine in the same way they stole the .io TLD would mean that they would have to take over the entire country of Ukraine. Maybe the Russian government will have control of the .ua TLD someday.
If you're interested, the Ukraine TLD is .ua.
To say they stole it from Ukraine in the same way they stole the .io TLD would mean that they would have to take over the entire country of Ukraine. Maybe the Russian government will have control of the .ua TLD someday.
Originally, .io, .sh and .tm were operated by ICB PLC, later ICB LLC (owned by Paul Kane[1]). Just a couple of weeks ago .io and .sh changed hands to Afilias which swapped out all turning parts over a weekend. They really screwed up a lot of things including losing my balance, manipulating domain information and extortion attemps:
I was a reseller with ICB and have a contract. Without a cancellation period (which as defined in the contract) they wanted to take over the contract, introduce new contract details and probably a new pricing scheme. Around 20 pages of legal stuff and a window of <10 days to "decide"/comply.
I'm done with them (Afilias). I'll never ever spend a dime and advise anyone not doing any business with them.
(But also the old technology backed (which still runs .tm) is far from secure and reliable. At least it supports IPv6 whereas the Afilias infrastructure still is not IPv6 ready…)
[1] https://en.wikipedia.org/wiki/Paul_Kane_(entrepreneur)
I was a reseller with ICB and have a contract. Without a cancellation period (which as defined in the contract) they wanted to take over the contract, introduce new contract details and probably a new pricing scheme. Around 20 pages of legal stuff and a window of <10 days to "decide"/comply.
I'm done with them (Afilias). I'll never ever spend a dime and advise anyone not doing any business with them.
(But also the old technology backed (which still runs .tm) is far from secure and reliable. At least it supports IPv6 whereas the Afilias infrastructure still is not IPv6 ready…)
[1] https://en.wikipedia.org/wiki/Paul_Kane_(entrepreneur)
Wow, I don't think I would've even considered such an attack...
DNSSEC, HSTS and Certificate Pinning would've made it more difficult to abuse this, but I guess it would've been pretty easy to get valid SSL certificates for all your favourite .io domains.
Let's try to play malicious party here:
Phase A: First set up a simple DNS forwarder playing by the rules and answering requests as we should (as to not get any unwanted attention). Gather usage statistics.
Phase B: Crawl the list of most-used domains to see if there are any valuable targets without HTTPS (port 443 is closed). Alternatively/additionally see if there are API subdomains used by software other than browsers (of which a few won't have annoying features like Cert Pinning - golang's DNS resolver for example afaik doesn't do DNSSEC). Pick some medium to high level targets where the attack might go undetected for at least some time.
Phase C: MitM time! Get certificates for the target domain(s) of your choice and get to work. Start with only a few percent of the requests to not draw too much attention (and to avoid the majority of their traffic coming from a single IP (range) all of a sudden) Obfuscate the attack by acting like a third party app or something simply doing requests for their users.
Congratulations on finding the vulnerability (and thanks for looking for that kinda stuff in the first place).
DNSSEC, HSTS and Certificate Pinning would've made it more difficult to abuse this, but I guess it would've been pretty easy to get valid SSL certificates for all your favourite .io domains.
Let's try to play malicious party here:
Phase A: First set up a simple DNS forwarder playing by the rules and answering requests as we should (as to not get any unwanted attention). Gather usage statistics.
Phase B: Crawl the list of most-used domains to see if there are any valuable targets without HTTPS (port 443 is closed). Alternatively/additionally see if there are API subdomains used by software other than browsers (of which a few won't have annoying features like Cert Pinning - golang's DNS resolver for example afaik doesn't do DNSSEC). Pick some medium to high level targets where the attack might go undetected for at least some time.
Phase C: MitM time! Get certificates for the target domain(s) of your choice and get to work. Start with only a few percent of the requests to not draw too much attention (and to avoid the majority of their traffic coming from a single IP (range) all of a sudden) Obfuscate the attack by acting like a third party app or something simply doing requests for their users.
Congratulations on finding the vulnerability (and thanks for looking for that kinda stuff in the first place).
If you control the root DNS servers for .io, you can simply not answer the DNSSEC queries. Many resolvers will fail open.
HSTS requires the site is HTTPS with a valid cert. If you own all .io, you can use LetsEncrypt to get that for free. They now even support Wildcard Certs! :-) That said, you would have to choose your targets carefully and/or load balance your requests to LetsEncrypt. There is a rate limit. There are browser plugins that can tell you if a cert just changed, assuming you have been to that site prior.
Then there is Public Key Pinning. This would be great, but I suspect the number of big companies implementing this are low. I don't have numbers, but you can test your favorite sites in Qualys[1] or using testssl.sh[2] that only depends on openssl and bash.
You could proxy all requests to the real root servers for .io and only become authoritative for the ones you wish to target.
Given the small number of zones, I think a modest server could keep up, or you could balance the load on a bunch of VM's. It may take a while for anyone to notice. I am curious actually, how many fellow geeks have nagios/sensu alerts that would tell them if the root server IP's changed.
All of this said, there are BGP attacks you can do that accomplish the same thing for any TLD and the IP's wouldn't even have to change. Only more advanced monitoring tools that keep an eye on route path might notice, but probably would not alert anyone.
[1] https://www.ssllabs.com/ssltest/index.html [2] https://github.com/drwetter/testssl.sh
HSTS requires the site is HTTPS with a valid cert. If you own all .io, you can use LetsEncrypt to get that for free. They now even support Wildcard Certs! :-) That said, you would have to choose your targets carefully and/or load balance your requests to LetsEncrypt. There is a rate limit. There are browser plugins that can tell you if a cert just changed, assuming you have been to that site prior.
Then there is Public Key Pinning. This would be great, but I suspect the number of big companies implementing this are low. I don't have numbers, but you can test your favorite sites in Qualys[1] or using testssl.sh[2] that only depends on openssl and bash.
You could proxy all requests to the real root servers for .io and only become authoritative for the ones you wish to target.
Given the small number of zones, I think a modest server could keep up, or you could balance the load on a bunch of VM's. It may take a while for anyone to notice. I am curious actually, how many fellow geeks have nagios/sensu alerts that would tell them if the root server IP's changed.
All of this said, there are BGP attacks you can do that accomplish the same thing for any TLD and the IP's wouldn't even have to change. Only more advanced monitoring tools that keep an eye on route path might notice, but probably would not alert anyone.
[1] https://www.ssllabs.com/ssltest/index.html [2] https://github.com/drwetter/testssl.sh
LetsEncrypt don't support wildcards yet. They will, starting January next year.
Ah, I was not aware it would be January. Then for now the targets would have to be specific DNS records.
So how does certificate transparency fit into all this?
https://www.certificate-transparency.org/what-is-ct
Let's assume an attacker who selectively hijacks .io traffic in such a magical* way that the owners of the relevant domain names do not notice the attack is happening. Assuming that, what exactly would the CT monitors notice? I assume there would be new LetsEncrypt certificates entered into the append-only log, but then what?
Edit: added word magical for clarity
https://www.certificate-transparency.org/what-is-ct
Let's assume an attacker who selectively hijacks .io traffic in such a magical* way that the owners of the relevant domain names do not notice the attack is happening. Assuming that, what exactly would the CT monitors notice? I assume there would be new LetsEncrypt certificates entered into the append-only log, but then what?
Edit: added word magical for clarity
That could certainly be useful in the follow-up investigation and forensics. Hopefully our attacker did not spin up those VM's using a burner card or stolen CC and proxies.
There isn't anything magical about selectively targeting domains. One simply creates multiple recursors and sets the upstream forwarder to the proper IP's of the original root servers. Then one adds zones for the domains or individual records they wish to modify. Unbound DNS is great for taking over individual records. I use it for this very purpose to block advertisements and trackers. In this case however, we are just acting as a root server, so there isn't much to take over. We just point the victims to ourselves for the domains we wish to hijack. We could then have a second level of recursors to perform the above selective attacks.
There isn't anything magical about selectively targeting domains. One simply creates multiple recursors and sets the upstream forwarder to the proper IP's of the original root servers. Then one adds zones for the domains or individual records they wish to modify. Unbound DNS is great for taking over individual records. I use it for this very purpose to block advertisements and trackers. In this case however, we are just acting as a root server, so there isn't much to take over. We just point the victims to ourselves for the domains we wish to hijack. We could then have a second level of recursors to perform the above selective attacks.
I think the problem with PKP is that there's such a big risk of temporarily unfixable breakage if things aren't done right.
Could you get a wildcard certificate for *.io this way?
I don't know if LetsEncrypt would issue that, even if you control it. That would be a good exercise to validate if there is an "easy mode" for state sponsored fun.
I've read that browsers are said to block such wildcards, but I don't know to what they are referring. I create wildcard TLD self signed certs all the time. I've never had one signed by a proper CA, so I can't tell you if the browsers have any logic to ignore them.
I've read that browsers are said to block such wildcards, but I don't know to what they are referring. I create wildcard TLD self signed certs all the time. I've never had one signed by a proper CA, so I can't tell you if the browsers have any logic to ignore them.
Your missing a ton of potential here by assuming that all DNS is good for is Web traffic. For one thing, taking over or intercepting email (remember, you now control the DNS, so you also control SPF and DKIM records) becomes trivial. you could even leverage that control of email to get SSL certificates for domains you really want to do https for (letsencrypt will even generate a wildcard cert using only dns based verification).
You could also be much more surgical, and target specific people/organizations using that .tld, ignoring dns requests for everyone that you don’t want to alert to your control. Hijack their email, and you control access to things like account recovery for domain users, and have a great method for phishing account credentials for the domains customers.
Honestly, the list of what you could do here is almost only limited by your imagination
You could also be much more surgical, and target specific people/organizations using that .tld, ignoring dns requests for everyone that you don’t want to alert to your control. Hijack their email, and you control access to things like account recovery for domain users, and have a great method for phishing account credentials for the domains customers.
Honestly, the list of what you could do here is almost only limited by your imagination
Or, in Phase C, an attacker could proxy traffic through a botnet to avoid the single-ip-range issue; they could even find botnet participants geographically close to each user, so they might not even trigger any red flags from a close look at IP logs. Setting aside DNS hijacking altogether, the idea that phishing sites could do something like this, perfectly proxy i.e. a bank's content and remain largely undetectable, makes me very concerned that we're only just seeing the beginning of sophisticated phishing attacks.
Author here, thanks - glad you liked the post! :)
Thanks for this; as very-much-not-a-security guy, the alarm sounded by the original post was surprisingly clear, but fleshing out a plausible attack scenario like this really helps drive the point home while also teaching me a bit.
I read this, but still don't fully understand the implications or impact for .IO TLD services and domain owners.
From the OP's "Impact" section.
> Given the fact that we were able to take over four of the seven authoritative nameservers for the .io TLD we would be able to poison/redirect the DNS for all .io domain names registered. Not only that, but since we have control over a majority of the nameservers it’s actually more likely that clients will randomly select our hijacked nameservers over any of the legitimate nameservers even before employing tricks like long TTL responses, etc to further tilt the odds in our favor.
What does this mean? Is the "poisoning" / "redirecting" of traffic for ALL .IO domains possible through this "hack" because of some flaw at the .IO registrar, or at 101domains.com or at Nameservers that .IO registrars are using, or something else?
How can this be mitigated? Or am I over-reacting since I don't fully understand this story?
From the OP's "Impact" section.
> Given the fact that we were able to take over four of the seven authoritative nameservers for the .io TLD we would be able to poison/redirect the DNS for all .io domain names registered. Not only that, but since we have control over a majority of the nameservers it’s actually more likely that clients will randomly select our hijacked nameservers over any of the legitimate nameservers even before employing tricks like long TTL responses, etc to further tilt the odds in our favor.
What does this mean? Is the "poisoning" / "redirecting" of traffic for ALL .IO domains possible through this "hack" because of some flaw at the .IO registrar, or at 101domains.com or at Nameservers that .IO registrars are using, or something else?
How can this be mitigated? Or am I over-reacting since I don't fully understand this story?
Yes. It does.
Someone noticed that the 4 of the 7 hostnames that were assigned for authoritative names servers for .IO were available for registration. They registered them, and started receiving DNS lookups for .IO hosts from what appears to be actual internet users. Since the user had 4 or the 7, its possible that the majority of DNS lookups for .IO hosts would be sent and answer by the author's systems.
The author could have started replying with malicious lookups. "Oh some-sexy-saas.io? yeah, that's [evil IP]." "oh, billing.otherapp.io? what a surprise that site is also available at the same [evil IP]!"
How could .io sites have avoiding getting spoofed? HTTPS + HSTS would prevent the author from spoofing the DNS of that those sites and sending them to a server over HTTP thus avoiding the certificate errors.
update: I overlooked that sites would also need to leverage Public Key Pinning to be protected, since getting a valid DV cert for a spoofed cite when you control DNS would be likely.
https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
Someone noticed that the 4 of the 7 hostnames that were assigned for authoritative names servers for .IO were available for registration. They registered them, and started receiving DNS lookups for .IO hosts from what appears to be actual internet users. Since the user had 4 or the 7, its possible that the majority of DNS lookups for .IO hosts would be sent and answer by the author's systems.
The author could have started replying with malicious lookups. "Oh some-sexy-saas.io? yeah, that's [evil IP]." "oh, billing.otherapp.io? what a surprise that site is also available at the same [evil IP]!"
How could .io sites have avoiding getting spoofed? HTTPS + HSTS would prevent the author from spoofing the DNS of that those sites and sending them to a server over HTTP thus avoiding the certificate errors.
update: I overlooked that sites would also need to leverage Public Key Pinning to be protected, since getting a valid DV cert for a spoofed cite when you control DNS would be likely.
https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
>HTTPS + HSTS would prevent the author from spoofing the DNS of that those sites and sending them to a server over HTTP thus avoiding the certificate errors.
Unless I'm missing something if you own the DNS it should be trivial to get a valid HTTPS certificate for any .io domain. Then the only thing that can save you is certificate pinning.
That makes me think: I wonder if you could "trick" a CA into giving you a wildcard *.io certificate when you own the TLD. Would that even be accepted by the browsers?
Unless I'm missing something if you own the DNS it should be trivial to get a valid HTTPS certificate for any .io domain. Then the only thing that can save you is certificate pinning.
That makes me think: I wonder if you could "trick" a CA into giving you a wildcard *.io certificate when you own the TLD. Would that even be accepted by the browsers?
I believe the major web browsers all reject wildcard certs for TLDs. For more discussion: https://security.stackexchange.com/questions/6873/can-a-wild...
>HTTPS + HSTS would prevent the author from spoofing the DNS of that those sites and sending them to a server over HTTP thus avoiding the certificate errors.
I'm confused, how would that help? Could the attacker (the author, in this case) not get a valid https certificate for these domains, returning spoofed DNS responses when the CA goes to validate it?
I'm confused, how would that help? Could the attacker (the author, in this case) not get a valid https certificate for these domains, returning spoofed DNS responses when the CA goes to validate it?
Depends, but for DV certificates, most likely. Certificate Transparency could/would help alert the original site if that was the case.
yes, but HTTPS + HSTS would not enforce a certain validation level, eg you can't enforce EV certs only in HSTS (as far as I know), so a DV cert would be sufficient
the attacker MITM TLS has to present a certificate for the spoofed domain that was signed by a Certificate Authority the victim's browser trusts
Very easy to do. You can even automate it with Let's Encrypt since you can serve whatever DNS records you want.
I feel any mention of HTTP Public Key Pinning should have the words "WARNING" surrounding it.
It can take down your site if you screw it up - https://www.smashingmagazine.com/be-afraid-of-public-key-pin...
I also believe it is one of the more difficult security features to implement & doesn't work well with Let's Encrypt https://community.letsencrypt.org/t/hpkp-best-practices-if-y...
I'm not against it and this case does seem to make me reconsider my prior risk balance assessment of implementing it.
It can take down your site if you screw it up - https://www.smashingmagazine.com/be-afraid-of-public-key-pin...
I also believe it is one of the more difficult security features to implement & doesn't work well with Let's Encrypt https://community.letsencrypt.org/t/hpkp-best-practices-if-y...
I'm not against it and this case does seem to make me reconsider my prior risk balance assessment of implementing it.
Couldn't you just use letsencrypt to create arbitrary SSL certs for the io domains you now own? Then https isn't going to help you much.
HSTS (correction: HPKP) preloading would help avoid that, and Certificate Transparency monitoring would help detect it, but yes, in general, if you control DNS for a domain, you can get a valid certificate for the domain.
HSTS preloading doesn't help if you can get a Domain Validated certificate. HPKP preloading helps, but only if you pin to a CA that won't issue a DV certificate to someone who controls 4 out of 7 of the nameservers for the TLD your domain is in. And also only helps if the incident is cleaned up before the browser preload process catches the malicious server when confirming the preload. It might be a good idea to require DV certificate issuance to respect DNSSEC -- in this case, the poison nameservers wouldn't be able to sign the responses properly, and .io is DNSSEC enabled.
Certificate transparency should help you know what's going on, but only if you're getting notifications through a method that's not compromised (email to your domain may not make it to you).
Certificate transparency should help you know what's going on, but only if you're getting notifications through a method that's not compromised (email to your domain may not make it to you).
Edited in a correction, thanks. But also: you can pin to a specific certificate, not just a CA.
> It might be a good idea to require DV certificate issuance to respect DNSSEC -- in this case, the poison nameservers wouldn't be able to sign the responses properly, and .io is DNSSEC enabled.
That seems like a good idea. DNSSEC isn't perfect, but for this purpose it's better than nothing.
(That said, I'd love to know where we stand on getting a better replacement for it.)
> Certificate transparency should help you know what's going on, but only if you're getting notifications through a method that's not compromised (email to your domain may not make it to you).
Definitely a good idea to point domain-related notifications of any kind to an email that doesn't go through that domain.
> It might be a good idea to require DV certificate issuance to respect DNSSEC -- in this case, the poison nameservers wouldn't be able to sign the responses properly, and .io is DNSSEC enabled.
That seems like a good idea. DNSSEC isn't perfect, but for this purpose it's better than nothing.
(That said, I'd love to know where we stand on getting a better replacement for it.)
> Certificate transparency should help you know what's going on, but only if you're getting notifications through a method that's not compromised (email to your domain may not make it to you).
Definitely a good idea to point domain-related notifications of any kind to an email that doesn't go through that domain.
> But also: you can pin to a specific certificate, not just a CA.
I think the general best practices for pinning are to pin a CA or two, and a backup key; in case your keys get compromised, you can reissue with your preferred CA; in case your CA gets delisted, you can get a cert issued with your backup key from a still trusted CA. You could have a series of keys and trust those, but it seems like that would be an easy way for you to shoot yourself in the foot.
I think the general best practices for pinning are to pin a CA or two, and a backup key; in case your keys get compromised, you can reissue with your preferred CA; in case your CA gets delisted, you can get a cert issued with your backup key from a still trusted CA. You could have a series of keys and trust those, but it seems like that would be an easy way for you to shoot yourself in the foot.
> HTTPS + HSTS would prevent the author from spoofing the DNS of that those sites and sending them to a server over HTTP thus avoiding the certificate errors
I'm not sure that's true. From a CA's perspective the attacker would own the redirected domain 4/7 tries, so they could probably convince at least one CA to issue them a valid certificate for it.
I'm not sure that's true. From a CA's perspective the attacker would own the redirected domain 4/7 tries, so they could probably convince at least one CA to issue them a valid certificate for it.
[deleted]
The best way to protect yourself against this kind of attack is DNSSEC. Plain and simple.
Only if your resolver fails closed. Otherwise, an attacker can just return non-signed responses. This is all client side, as a domain owner you simply need to trust your TLD.
As long as most clients don't run tight DNSSEC, you're screwed if the TLD fucks up.
As long as most clients don't run tight DNSSEC, you're screwed if the TLD fucks up.
.io is signed and it has a DS record in the root zone. If you're using a DNSSEC validating recursive resolver(e.g., Google, Comcast) they should replace their cached NS records from auth resolvers that don't return signed respones, with cache entries that do return signed responses. If a stub tells a recursive resolver to return a DNSSEC signed response(by setting the DO bit to 1 in the query) that recursive should keep trying to find a signed response until it has exhausted all possible NS records in the parent zone.
This assumes of course that the second-level zones are also signed. So it would only protect people going to example.io if example.io was signed. If you have a .io child zone then you should sign it.
This assumes of course that the second-level zones are also signed. So it would only protect people going to example.io if example.io was signed. If you have a .io child zone then you should sign it.
I dispute this, even though this seems like the one case where we're talking about an attack that actually lines up with what DNSSEC actually does.
The reason is, what we're talking about is a massive misconfiguration. It's not an elaborate technical spoofing attack that takes advantage of the weakness of the underlying DNS. The mistake the .IO team made is just as easy to make in DNSSEC as it is with vanilla DNS.
The reason is, what we're talking about is a massive misconfiguration. It's not an elaborate technical spoofing attack that takes advantage of the weakness of the underlying DNS. The mistake the .IO team made is just as easy to make in DNSSEC as it is with vanilla DNS.
But if the attacker is unable to sign DNS responses, and you're validating those responses, then you're not going to have a bad time.
I don't really understand your argument. I'm talking specifics and you seem to be talking about some hypothetical.
I don't really understand your argument. I'm talking specifics and you seem to be talking about some hypothetical.
The underlying "vulnerability" here is misconfiguration. DNSSEC doesn't defend against misconfiguration. That's the simple point I'm making.
[deleted]
When I skimmed your message, I read some-sexy-ass.io. I think that would be a more likely domain for people to look up ;)
EDIT: C'mon, you know I'm not wrong.
EDIT: C'mon, you know I'm not wrong.
Yes, your initial summary is my understanding as well. Basically, top-level domains use fairly arbitrary domains as authoritative nameservers (in this case ns-a[1-4].io), and the company that manages all the .io registrations (101Domain) was allowing any arbitrary user to register four of the seven nameserver domains. So a malicious user could have purchased all of them and pointed ALL .io domains to any arbitrary server (for at least 4 out of 7 DNS requests).
It can't really be mitigated at the user level but it's already been mitigated by the registrar. Still though, jfc.
It can't really be mitigated at the user level but it's already been mitigated by the registrar. Still though, jfc.
Nameservers have always been the premiere MITM attack vector for domains, that's been known for sometime. Sad we need to keep relearning these same basic security lessons.
It wasn't immediately clear to me, but here is my guess as someone having worked in a registry. DNS itself is decoupled from registration. It sounds like .io manually entered it's NS records and associated A/AAAA records, but never put those domains themselves into their registry. This would mean when a registrar(101domains) queries, they show as available and worse, allowed registration.
The impact, however, is likely implementation dependent. Glue records exist at the parent nameserver, and aren't typically checked again at the auth. So in short, I don't believe this could be used to legitimately steal traffic, but perhaps I haven't thought it through enough.
The impact, however, is likely implementation dependent. Glue records exist at the parent nameserver, and aren't typically checked again at the auth. So in short, I don't believe this could be used to legitimately steal traffic, but perhaps I haven't thought it through enough.
Treat this like:
> I was able to hack/gain control over the majority of the servers that serve up authoritative information about who owns what records on the .IO ccTLD.
A "poisoning" if DNS is serving up untrue information via DNS records. This could point your bank site to a phishing site, or it could just point your bank site to a blackhole (or just point it at Google.com or something).
> I was able to hack/gain control over the majority of the servers that serve up authoritative information about who owns what records on the .IO ccTLD.
A "poisoning" if DNS is serving up untrue information via DNS records. This could point your bank site to a phishing site, or it could just point your bank site to a blackhole (or just point it at Google.com or something).
The poisoning / redirecting was able to be done because the domains were available to be registered. Not sure why that was the case, but they no longer are, so it's no longer an issue.
> How can this be mitigated? Or am I over-reacting since I don't fully understand this story?
It's been mitigated already.
> How can this be mitigated? Or am I over-reacting since I don't fully understand this story?
It's been mitigated already.
Phew! Thanks.
Because he proved he could control the majority of name servers, that means that he could change what server his nameservers respond with and have a good chance of getting his bad DNS records used
So any site hosted on the io tld could be duplicated and hosted on a bad box that could steal credentials, install malware, without impunity and without much detection.
---
It can't be mitigated in the long-term as far as I know. There might be some short term solution but once your browser needs to look up the IP, he has got you.
The solution is not allowing nameservers to be registered as far as I know.
So any site hosted on the io tld could be duplicated and hosted on a bad box that could steal credentials, install malware, without impunity and without much detection.
---
It can't be mitigated in the long-term as far as I know. There might be some short term solution but once your browser needs to look up the IP, he has got you.
The solution is not allowing nameservers to be registered as far as I know.
[deleted]
Yes, it allowed redirecting DNS for any .io domain wherever they wanted, unless the resolver making the request used DNSSEC.
This can be mitigated primarily by the .io registry not giving the domain names registered for their nameservers to random people! And partially by DNSSEC, but I'm not sure about the exact guarantees that brings.
This can be mitigated primarily by the .io registry not giving the domain names registered for their nameservers to random people! And partially by DNSSEC, but I'm not sure about the exact guarantees that brings.
Just to add some color to this: There was an attack last Friday on a few geo TLDs that ended up hijacking a bunch of traffic for a few hours, including .la, .es, and .jp:
https://news.gandi.net/en/2017/07/report-on-july-7-2017-inci...
https://news.gandi.net/en/2017/07/report-on-july-7-2017-inci...
I'm one of the unlucky few that were affected by this (I own .ch).
One of my site user's reported that the website is inaccessible on Friday. I went to check and observed the DNS changing. Then went to check Route 53 status page[2] in which I learn that this is not specific to my site. The behavior is exactly the same as what is described in the SWITCH report[1]. Luckily that I have HSTS on my site, so the damage is limited (users not getting redirected), and Gandi seems to fixed this quick enough (I was in the middle of commuting back home by the time of the attack.)
[1]: https://securityblog.switch.ch/2017/07/07/94-ch-li-domain-na...
[2]: http://status.aws.amazon.com/ (The blue icon for Amazon Route 53 Domain Registration)
One of my site user's reported that the website is inaccessible on Friday. I went to check and observed the DNS changing. Then went to check Route 53 status page[2] in which I learn that this is not specific to my site. The behavior is exactly the same as what is described in the SWITCH report[1]. Luckily that I have HSTS on my site, so the damage is limited (users not getting redirected), and Gandi seems to fixed this quick enough (I was in the middle of commuting back home by the time of the attack.)
[1]: https://securityblog.switch.ch/2017/07/07/94-ch-li-domain-na...
[2]: http://status.aws.amazon.com/ (The blue icon for Amazon Route 53 Domain Registration)
We were also affected by this on a major e-commerce site. It was a .se domain.
Their post mortem isn't really convincing ( https://news.gandi.net/en/2017/07/report-on-july-7-2017-inci... ) since they do not state what really happened and how it can be prevented again.
I issued a support ticket to aws today to see what measures can be taken, otherwise we might need to change registrar.
I issued a support ticket to aws today to see what measures can be taken, otherwise we might need to change registrar.
There is a more detailed followup today: https://news.gandi.net/en/2017/07/detailed-incident-report/
> These credentials were likewise not obtained by a breach of our systems and we strongly suspect they were obtained from an insecure connection to our technical partner’s web portal (the web platform in question allows access via http).
This makes no sense - how did the attacker get between gandi.net and their technical partner in order to MITM them? MITMs aren't magic - simply sending an unencrypted password somewhere doesn't result in it becoming public knowledge unless a router or switch in the path is malicious.
This makes no sense - how did the attacker get between gandi.net and their technical partner in order to MITM them? MITMs aren't magic - simply sending an unencrypted password somewhere doesn't result in it becoming public knowledge unless a router or switch in the path is malicious.
> This makes no sense - how did the attacker get between gandi.net and their technical partner in order to MITM them?
On the top of my head, bgp hijacking perhaps?
> MITMs aren't magic
No. But do not trust the network. Ever.
On the top of my head, bgp hijacking perhaps?
> MITMs aren't magic
No. But do not trust the network. Ever.
If it's BGP hijacking, there'll be evidence somewhere.
And no, don't trust the network, but "the network isn't trustworthy" is not a diagnosis, only a potential risk factor. "X entity used BGP hijacking to situate their router between me and Y" is a diagnosis.
And no, don't trust the network, but "the network isn't trustworthy" is not a diagnosis, only a potential risk factor. "X entity used BGP hijacking to situate their router between me and Y" is a diagnosis.
I doubt changing the registra would change anything, as this seems more likely a problem on the TLD backend side than a problem on the registra itself, since it affect not only Gandi but also Route 53 Domain Registration. I'm under a serious consideration to switch from .ch to something else.
Route53 domain registration uses gandi as a partner.
So, the real question is: "How much should we freak out about this?"
If you scroll back a few months to Cloudbleed/Cloudflare we sort of collectively decided that because cache data containing sensitive info (passwords, tokens, whatever) might be accessible for your site using Cloudflare that everything should be revoked, force password resets, etc.
Now we have this vuln, which I'll dub "IOgate" because it's the cool thing to name these. We don't know if this has ever happened before, there clearly were not adequate safeguards in place, etc.
Should anyone operating a service using a ".io" TLD consider everything potentially compromised?
If you scroll back a few months to Cloudbleed/Cloudflare we sort of collectively decided that because cache data containing sensitive info (passwords, tokens, whatever) might be accessible for your site using Cloudflare that everything should be revoked, force password resets, etc.
Now we have this vuln, which I'll dub "IOgate" because it's the cool thing to name these. We don't know if this has ever happened before, there clearly were not adequate safeguards in place, etc.
Should anyone operating a service using a ".io" TLD consider everything potentially compromised?
Cloudbleed was different in a lot of ways, not least of which because it could have been passively exploited by an unknowable number of attackers even after the bug was fixed. Here, this is an active attack that leaves a trail. The question is more like "do you trust the author?"
You make a really good point about the post patch exploitation from Cloudbleed putting that in a different category. I guess my thinking was: Is this guy the first? Are the authoritative IO domain servers compromised some other way? Are the other servers legit?
>I'll dub "IOgate" because it's the cool thing to name these.
FWIW, I've found that whenever major news outlets use the "gate" postfix for anything other than Watergate, it's an indicator that they're being manipulative (it's tabloid bullshit). The certainly didn't call it Snowdengate or Trump/Russiagate.
Keep an eye out and see if you don't agree.
I deem this Clubber's Law!
FWIW, I've found that whenever major news outlets use the "gate" postfix for anything other than Watergate, it's an indicator that they're being manipulative (it's tabloid bullshit). The certainly didn't call it Snowdengate or Trump/Russiagate.
Keep an eye out and see if you don't agree.
I deem this Clubber's Law!
Clubbergate is well underway, I see.
Well, if it's any consolation.. the domains weren't registered..
Per the article, he got them registered and pointing at his own DNS test server and received actual .io resolution requests to it.
Yes but [per the article] they weren't registered before he bought them. Obviously somebody could have done this before and stopped, or could control some of the other servers.
The post states that they were registered, used, then revoked.
Registered by the author. What lwansbrough means is that they weren't already registered, which means it's unlikely this was previously exploited unless the previous registrant let those domains expire afterwards.
The registry (and many other people who have downloaded zone files and such) would have records of these having previously been registered. If it was exploited then it would easily be possible to find that out.
[deleted]
> Now we have this vuln, which I'll dub "IOgate" because it's the cool thing to name these
No
No
I would have gone for "ih oh" rather than iogate!
As the article mention, this is a nice example where DNSSEC would had prevented malicious activity for users which has DNSSEC validation enabled. There are also countries like Sweden were almost all ISP has this, so a rather large group of people in the world would likely have noticed if a majority of .io nameservers was responding with unsigned data.
I am really super happy that the root domain serving the largest IOT population on the planet wasn't co-opted by the MIRAI bot writers.
That could have been a net killing event.
That could have been a net killing event.
There's an IOT population? I thought it was just a dumb trend everyone hates?
I'm not trying to diss anyone, I just thought the whole "IoT" concept was dead in the water?
I'm not trying to diss anyone, I just thought the whole "IoT" concept was dead in the water?
Side note: Please don’t use such gray and thin fonts. I had to modify the CSS to use black instead of #555 for the text color.
#555 is still quite dark and should be easy to read. The real culprit is the 300 font weight - when set to 400 it's quite another matter.
I don't mean this pejoratively, but how old are you? I'm just curious as I had no problems with the color / font weight. For my sites I usually use something like #232323 instead of pure black.
I’m 25. I agree with other commenters that the issue is more with the font-weight than the color; I don’t have issues reading e.g. text in #666 or even #999.
I'm 25 and had to zoom to read and even then it wasn't comfortable. (not the OP)
Ah I see, upping the font-weight to 400 helped when viewing it on my laptop screen. I didn't really have that issue on mobile, though.
I had to use the "Reader" feature of my browser to read the text, for maybe the first time ever.
Not the first time .io TLD messes things pretty bad. A few months ago they had a couple of name servers poisoning internet with false negatives, that made a few hours very "interesting"
NIC.io are a terrible, terrible registrar. I reported an account takeover security vulnerability to them 6 years ago that they only fixed after 4ish years.
> After sending the email I immediately received a bounce message indicating that the [email protected] was not an email address that existed at all
> This was not a strong vote of confidence that someone was going to see this notice.
Honestly though, this seems like common practice to me.
> This was not a strong vote of confidence that someone was going to see this notice.
Honestly though, this seems like common practice to me.
I though ICANN was supposed to be getting serious against fake contact data on domain registrations? The fact that even a TLD's NIC admin info is fake is pretty spectacular.
This sounds an awful lot like what happened to the .sr ccTLD on 06/23/17. Part of my business runs on a .sr and we were down several days.
Any way to look up a history of such an event?
Any way to look up a history of such an event?
Good grief! I've always found using vanity domains for your project/company to be tasteless at best. Now .io is even associated with deportation, dispute of territory, and security screwups. Using an .io domain only serves to demonstrate that you care about pretending to be a 2010-ish startup at the expense of everything else at this point.
I had a similar issue with the .IM domain three months ago. One of the four NS for the domain was not responding.
Two of the guys at Cloudflare diagnosed it for me: https://twitter.com/xxdesmus/status/855858441289572353
Two of the guys at Cloudflare diagnosed it for me: https://twitter.com/xxdesmus/status/855858441289572353
At least that name is not at risk of subversion.
JA.NET is the Joint Academic Network, the university / academic Internet infrastructure for the UK.
JA.NET is the Joint Academic Network, the university / academic Internet infrastructure for the UK.
One Cofounder of cloudflare, pretty impressed they picked up tweets directly.
Many people at Cloudflare (including myself, Matthew, Justin and others) monitor Twitter, HN and other forums carefully and reply quickly to folks.
Personally, I run a script that emails me for every HN comment that mentions Cloudflare and use Tweetdeck to monitor @cloudflare/cloudflare mentions.
Personally, I run a script that emails me for every HN comment that mentions Cloudflare and use Tweetdeck to monitor @cloudflare/cloudflare mentions.
They really are great guys, it's not the first time they've tweeted me either!
The CEO is active on HN too. Great customer service.
The CEO is active on HN too. Great customer service.
Not even a "thank you" message from the TLD managers ? That is the most shameful behavior.
Wow this is quite shocking. A very nice find, this is all the more concerning considering many high profile startups including financial ones are using .io domains (I'm using one too).
Wow! That is one scary vulnerability. Glad we have smart people like this to find such problems before the bad guys do. Well done!
While it's definitely an error on the part of the backend registry operator for .io, this is not the major security issue the author describes. He couldn't have hijacked any DNS traffic this way.
I've written in detail about why this is the case at https://mpounsett.blogspot.ca/2017/07/the-io-error-problem-w...
I've written in detail about why this is the case at https://mpounsett.blogspot.ca/2017/07/the-io-error-problem-w...
Author here, responding here like I did on Twitter. DNS resolver implementations matter here greatly. I received so many DNS queries (without me actually responding to any of them) that I quickly filled up my VPS with gigabytes of data from IP addresses of DNS resolvers across the Internet.
Saying "this is not the major security issue the author describes. He couldn't have hijacked any DNS traffic this way." seems a bit dishonest. You're saying that you have personally vetting all the DNS implementations of various DNS resolvers and have verified all of them take the resolution steps you've described exactly? If this is the case why did I receive so many queries (such as A, AAAA for the NS hostnames - which I assumed/assume was to cached these IP addresses for future resolution of the TLD's IPs). The way dig resolves things is different from how many production resolvers would do so, etc.
I can certainly see that some resolvers may take different steps for resolution which would make them unaffected by this issue (I'd have to think on it some more). A big issue here is of course that I didn't actually attempt to poison a bunch of the DNS resolvers which were hitting my server because I didn't want to affect any actual users. "Proving the point" in this case would've been dangerous and probably illegal as well.
That being said, mapping out how various DNS resolvers would perform their full resolution is an interesting side project and I've added it to my TODO list :)
Saying "this is not the major security issue the author describes. He couldn't have hijacked any DNS traffic this way." seems a bit dishonest. You're saying that you have personally vetting all the DNS implementations of various DNS resolvers and have verified all of them take the resolution steps you've described exactly? If this is the case why did I receive so many queries (such as A, AAAA for the NS hostnames - which I assumed/assume was to cached these IP addresses for future resolution of the TLD's IPs). The way dig resolves things is different from how many production resolvers would do so, etc.
I can certainly see that some resolvers may take different steps for resolution which would make them unaffected by this issue (I'd have to think on it some more). A big issue here is of course that I didn't actually attempt to poison a bunch of the DNS resolvers which were hitting my server because I didn't want to affect any actual users. "Proving the point" in this case would've been dangerous and probably illegal as well.
That being said, mapping out how various DNS resolvers would perform their full resolution is an interesting side project and I've added it to my TODO list :)
>The author assumes that because he's able to register a domain name that matches several of the authoritative name server names for the .io TLD that it is "likely that clients will randomly select our hijacked nameservers over any of the legitimate nameservers..." This is wrong.
It is definitely not wrong for a large number of resolvers. This bears out in his traffic.
It is very common for a resolver to take the list of nameservers from the root and resolve them rather than using the A records provided by the root. Quite wrong, but common. If they didn't, he would have received zero traffic.
Thus it would have been quite easy to redirect traffic for bit.io by also supplying a different set of NS records for it.
It is definitely not wrong for a large number of resolvers. This bears out in his traffic.
It is very common for a resolver to take the list of nameservers from the root and resolve them rather than using the A records provided by the root. Quite wrong, but common. If they didn't, he would have received zero traffic.
Thus it would have been quite easy to redirect traffic for bit.io by also supplying a different set of NS records for it.
"He couldn't have hijacked any DNS traffic this way."
That is entirely untrue. If I have control of the majority of DNS server routes/domains, I can hijack plenty of traffic. This is basic N+ certification-level stuff, not even advanced networking.
That is entirely untrue. If I have control of the majority of DNS server routes/domains, I can hijack plenty of traffic. This is basic N+ certification-level stuff, not even advanced networking.
[deleted]
I need like a dumbed-down version of what went wrong here.
seems to be a bad idea to get domains from strange small countries just because they look cool.
mrkrab(6)
Complicated by the fact that the .io domain has recently become popular for startups
That's amazing! Nice find, man!
Trying to figure out why you were downvoted. Was it the positivity?
The exclamation marks? The lack of pretending to contribute to the conversation?
The exclamation marks? The lack of pretending to contribute to the conversation?
I downvoted because it doesn't raise any questions or add any information to the discussion.
BTW, neither does commenting about votes ;)
As per https://news.ycombinator.com/newsguidelines.html
"Please resist commenting about being downvoted. It never does any good, and it makes boring reading."
BTW, neither does commenting about votes ;)
As per https://news.ycombinator.com/newsguidelines.html
"Please resist commenting about being downvoted. It never does any good, and it makes boring reading."
I was merely puzzled that my favorite comment was downvoted to the bottom of the thread!
I am sure the author (who appeared in the discussion here) would have appreciated the positive feedback. Are you suggesting it would have been better to contact the author directly?
I am sure the author (who appeared in the discussion here) would have appreciated the positive feedback. Are you suggesting it would have been better to contact the author directly?
Who would have thought that [email protected] registered in a small overseas territory in the middle of the Indian Ocean might not be entirely reliable?
Considering there are a grand total of 2500 people in the BIOT, all of whom are British or American military personnel, it might not be a great idea to route a good chunk of the world's tech traffic through them. The disparity between how important the .io TLD is for the Internet and how few resources must go to running it is pretty appalling.
In my opinion almost all of the 'weird' TLDs which are country codes that are actually operated by a third party commercial service are 95% spam and junk registrations. .TV is a good example.
Technical screwups aside, the existence of .IO and the fact that it "belongs" to the UK government is morally questionable, since the entire country code only exists because the British and American militaries forcibly removed the original inhabitants of islands such as Diego Garcia so that they could use the area as naval and air force bases.
https://en.wikipedia.org/wiki/British_Indian_Ocean_Territory
https://en.wikipedia.org/wiki/Diego_Garcia
If I had been able to successfully register these names and get live traffic going to a BIND9 instance, my first instinct would not be to alert the company through its first tier customer support levels, but to immediately post a summary of the problem to ARIN, RIPE, APNIC and ICANN mailing lists. This would get the issue in front of people who immediately understand how serious the problem is, and hopefully one of them would be able to contact the principals of .IO directly.