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 :)
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.
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.