The Domain Name System
Published:
As I posted yesterday, we released PATHspider 1.0.0. What I didn’t talk about in that post was an event that occured only a few hours before the release.
Everything was going fine, proofreading of the documentation was in progress,
a quick git push with the documentation updates and… CI FAILED!?! Our
CI doesn’t build the documentation, only tests the core code. I’m planning to
release real soon and something has broken.
Starting to panic.
irl@orbiter# ./tests.sh
................
----------------------------------------------------------------------
Ran 16 tests in 0.984s
OK
This makes no sense. Maybe I forgot to add a dependency and it’s been broken for a while? I scrutinise the dependencies list and it all looks fine.
In fairness, probably the first thing I should have done is look at the build log in Jenkins, but I’ve never had a failure that I couldn’t reproduce locally before.
It was at this point that I realised there was something screwy going on. A sigh of relief as I realise that there’s not a catastrophic test failure but now it looks like maybe there’s a problem with the University research group network, which is arguably worse.
Being focussed on getting the release ready, I didn’t realise that the Internet
was
falling
apart.
Unknown to me, a massive DDoS attack against Dyn, a major DNS host, was in
progress. After a few attempts to debug the problem, I hardcoded a line into
/etc/hosts, still believing it to be a localised issue.
192.30.253.112 github.com
I’ve just removed this line as the problem seems to have resolved itself for now. There are two main points I’ve taken away from this:
- CI failure doesn’t necessarily mean that your code is broken, it can also indicate that your CI infrastructure is broken.
- Decentralised internetwork routing is pretty worthless when the centralised name system goes down.
This afternoon I read a post by [tj] on the 57North Planet, and this is where I learnt what had really happened. He mentions multicast DNS and Namecoin as distributed name system alternatives. I’d like to add some more to that list:
Only the first of these is really a distributed solution.
My idea with ICMP Domain Name Messages is that you send an ICMP message to a webserver. Somewhere along the path, you’ll hit either a surveillance or censorship middlebox. These middleboxes can provide value by caching any DNS replies that are seen so that an ICMP DNS request message will cause the message to not be forwarded but a reply is generated to provide the answer to the query. If the middlebox cannot generate a reply, it can still forward it to other surveillance and censorship boxes.
I think this would be a great secondary use for the NSA and GCHQ boxen on the Internet, clearly fits within the scope of “defending national security” as if DNS is down the Internet is kinda dead, plus it’d make it nice and easy to find the boxes with PATHspider.