Browse Source

Remove unfinished blog post

drone-ci
Silke 5 months ago
parent
commit
6e193dacfd
  1. 102
      content/blog/How this site almost broke the internet.md

102
content/blog/How this site almost broke the internet.md

@ -1,102 +0,0 @@
---
date: 2016-11-02 09:48:32.106880653 +0100
title: How this site almost broke the internet
draft: true
---
When someone says *I broke the internet*, this usually one of two things:
- This person broke his or her internet connection
- This person is greatly exaggerating
I would like to say that this was one of those situations.
Unfortunately, it isn't.
Apparently this domain was setup in such a way that it had the potential to actually break the internet.
The setup
---------
I own two domains [slxh.nl] and [slxh.eu].
Both point to this website, but in the case of [slxh.nl],
something special is going on.
When asking the records for [www.slxh.eu], you get something like the following:
www.slxh.eu. 3600 IN AAAA 2001:470:7830:0:216:3eff:fef5:2ead
However, when doing the same with `www.slxh.nl`, a bit of magic is going on:
slxh.nl. 3600 IN DNAME slxh.eu.
www.slxh.nl. 3600 IN CNAME www.slxh.eu.
www.slxh.eu. 3600 IN AAAA 2001:470:7830:0:216:3eff:fef5:2ead
Now, this quickly gets [a bit more complicated][dnsviz] because of [DNSSEC],
but it tends to work fairly well.
Also, because both domains use the same authoritative DNS servers,
when a resolver asks for [slxh.nl] it receives all those records in the answer immediately. Very convenient.
The bug
-------
So, what happens if something does not exist in the zone?
The expected answer is an NXDOMAIN and no answer.
With DNSSEC one actually receives some signatures to prove that the record does not exist, but not much more.
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;nx.slxh.eu. IN AAAA
However, with the DNAME something else happens:
Because the server is authoritative for both the zones,
it returns the DNAME, CNAME and an NXDOMAIN:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;nx.slxh.eu. IN AAAA
;; ANSWER SECTION:
slxh.nl. 3600 IN DNAME scintilla.utwente.nl.
nx.slxh.nl. 0 IN CNAME nx.slxh.nl.
This does actually make sense, and is (as far as I know) correct behavior.
The developers of Bind, however, did not take this into account.
This meant that when asking the Bind recursor to resolve *nx.slxh.nl*,
[Bind would crash][cve]. Such a vulnerability warrants a CVE[[1]][cve].
Impact
------
What is the impact of this?
According to [the Bind website][bind] it is *"The most widely used Name Server Software"*. It seems to have a market share of about 55% of recursive resolvers[[2]][bindshare].
Assuming all are running a fairly up to date version of Bind,
this means that it is possible to kill the majority of DNS recursive resolvers using a DNS lookup.
How that lookup is to be spread, I leave up to the reader.
Conclusion
----------
So, did this site almost break the internet?
Well, it could have.
But, when I learned of this vulnerability the DNAME was disabled *almost* immediately.
*Almost*, because I broke the internet for a thousand people first (by accident)...
References
----------
- \[1]: [CVE-2016-8864][cve]: A problem handling responses containing a DNAME answer can lead to an assertion failure
- \[2]: [Happy Eyeballs for the DNS][bindshare] by Geoff Huston & George Michaelson
[slxh.nl]: https://slxh.nl
[slxh.eu]: https://slxh.eu
[www.slxh.nl]: https://www.slxh.nl
[www.slxh.eu]: https://www.slxh.eu
[dnsviz]: http://dnsviz.net/d/www.slxh.nl/dnssec/
[DNSSEC]: https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions
[cve]: https://kb.isc.org/article/AA-01434
[bind]: https://www.isc.org/downloads/bind/
[bindshare]: https://labs.apnic.net/presentations/store/2015-10-04-dns-dual-stack.pdf
Loading…
Cancel
Save