Taking control of all .io domains with a targeted registration
thehackerblog.com
thehackerblog.com
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.
Responsible disclosure cat is responsible!
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 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.
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 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.
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.
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.
Strategy is important.
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.
Why ?
"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."
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?
Immigrant? No. Settler? Not really after so many years.
As an immigrant, I view them as natives Quebecers.
What would you call them?
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.
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.
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.
I'd hope the more important distinction is how people are removed, not how many generations of dead people there were before them.
Cases like this just make a mockery of the Lockean natural rights theory of property.
The only two nations that have laid claim to the territory are France and the United Kingdom. (France lost it in the Napoleonic Wars.)
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.
Displacing settlers is a different question.
I want my £10!
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.
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 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 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).
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]
---
I mean, that doesn't justify the act, but I question the logic of claiming moral superiority or questioning authenticity over this.
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.
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.
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 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.
More so for .me, ran by the owners of .org
Unlike the rarely used .us for the USA, it is used for the vast majority of canadian domestic corporations' web identities.
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.
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.
https://www.google.com/search?q=china+lgbt+web&ie=utf-8&oe=u...
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.
It's like time traveling to 1987.
> 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./
God knows how widely a "ben@google" email address would work though. I'm going to guess not very.
That and apparently ICANN would frown upon such an implementation [1]
At least somebody grabbed the delightfully multilayered dope.af domain already...
gTLDs & ccTLDs have to be some of the worst ideas in Internet history.
Not if you're an investor in Donuts, LLC, they're not...
The gTLDs have a pretty strict ICANN contract they have to follow; ccTLDs are looser.
I really hope that one never becomes available..
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.
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...
save your politics for politics, not for a technology discussion. We get it, you're moral.
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.
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.
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).
They have great network engineers (I personally know one), maybe the best in the world.
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.
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…)
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).
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
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
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
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'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.
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?
> How can this be mitigated? Or am I over-reacting since I don't fully understand this story?
It's been mitigated already.
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.
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.
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.
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.
EDIT: C'mon, you know I'm not wrong.
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).
> 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.
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'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?
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'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.
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.
As long as most clients don't run tight DNSSEC, you're screwed if the TLD fucks up.
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.
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.
I don't really understand your argument. I'm talking specifics and you seem to be talking about some hypothetical.
It can't really be mitigated at the user level but it's already been mitigated by the registrar. Still though, jfc.
> 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).
https://news.gandi.net/en/2017/07/report-on-july-7-2017-inci...
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)
I issued a support ticket to aws today to see what measures can be taken, otherwise we might need to change registrar.
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.
On the top of my head, bgp hijacking perhaps?
> MITMs aren't magic
No. But do not trust the network. Ever.
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.
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?
No
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!
That could have been a net killing event.
I'm not trying to diss anyone, I just thought the whole "IoT" concept was dead in the water?
> 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.
Any way to look up a history of such an event?
Two of the guys at Cloudflare diagnosed it for me: https://twitter.com/xxdesmus/status/855858441289572353
The CEO is active on HN too. Great customer service.
Personally, I run a script that emails me for every HN comment that mentions Cloudflare and use Tweetdeck to monitor @cloudflare/cloudflare mentions.
JA.NET is the Joint Academic Network, the university / academic Internet infrastructure for the UK.
I've written in detail about why this is the case at https://mpounsett.blogspot.ca/2017/07/the-io-error-problem-w...
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 :)
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.
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.
The exclamation marks? The lack of pretending to contribute to the conversation?
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 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?