Since the summer we have been carrying out routine upgrades and rebuilds of our anycast constellations. In July and August we rebuilt dns3.easydns.org and dns3.easydns.ca, while more recently we moved dns4.easydns.info from an outsourced anycast provider to one we have rebuilt and deployed ourselves.
On Friday November 10, 2017 we were made aware that dns4.easydns.info had been sporadically allowing zone transfers for zones it was carrying, and subsequent revelations were that the dns3 nodes were similarly afflicted when they were rebuilt in the summer, 2017.
Our investigation into this matter discovered a bug in BIND itself and we reported it to ISC who assigned it BIND bug #46603:
Zones created with rndc addzone could temporarily fail to inherit the allow-transfer ACL set in the options section of
named.conf. [RT #46603]
While unintentional AXFR / zone transfer is widely considered an information disclosure issue, please read the following before anybody panics:
Don’t Panic: It’s not as bad as it sounds
When US Cert put out an advisory in 2015 about how misconfigured nameservers could unintentionally allow AXFR, a lengthy thread ensued on the dns-operations mailing list over whether allowing AXFR really was a security issue or not.
The overall consensus was that restrictions around AXFR were historically more about conserving server resources (think BIND4 days) than improving security. After all, we are talking about a bunch of records you are by definition publishing to the world to see.
The reality is that in this day and age of abundantly available processing power for cheap, most zones or large portions thereof, are discoverable via brute force. To quote Paul Vixie (who originally created the BIND nameserver) from that thread:
You are running bare naked through the internet, covered in honey, whether you allow AXFR or not. so, disallowing AXFR is at best a professionalism matter, and not really a security matter”
DNS zones are now largely computable. There are numerous tools freely available to do just that.
What was affected and what wasn’t
This leak affected your domains’ zone records only. No other information from within the control panel or member account info was affected by this.
Was my zone leaked?
Because we normally don’t allow zone transfers from public facing nodes we were not logging xfer-out’s at the time of the vulnerability. In retrospect, not the wisest assumption. Unfortunately we cannot tell which specific zones where leaked.
Again, the vast majority of most zones can be enumerated computationally, and if on the odd chance you really are trying to secure some secret by putting it into a DNS record you think nobody else knows about, you really should rethink that. That isn’t what DNS was designed for.
Why the delayed disclosure
We figured this out in November 2017 and here we are disclosing it in January 2018, why? Was it to give me enough time to sell $30,000,000 worth of easyDNS stock? I wish.
The reality is that ISC asked that we hold off disclosure until they were able to address the bug and issue their own notification. By their own classification system this was not considered a security issue and therefore was not scheduled for an accelerated fix. We would have to wait for a maintenance release and the timeframe they initially put on it was January 2018.
They did end up releasing 9.12.0rc1 on December 13, 2017 but by the time we got an “all clear” for disclosure, I was worried that we were too close into the holidays and we’d look like we were trying to bury this under the Christmas rush.
Thank you for the disclosure. The only question I have is: is there anything I need to do on my end? Do I need to re-set any passwords, settings, entries, etc.?