There have been a few high-profile attacks which have been somewhat incorrectly called “DNS” attacks. The problem is not with DNS; the problem is with how some organizations handle their DNS.
The majority of attacks are not a weakness with DNS per se as much as they are an attack against whatever web control panel controls DNS records. For institutions that still know how to edit a zone file  by hand, and who run their DNS from their own well protected servers (ideally, only port 53—that’s the DNS port—visible to the internet, and only port 22—that’s the SSH port—available behind the firewall), this is not a problem.
As long as companies do not use GoDaddy or some other web control panel to manage their DNS, they should be fine.
Now, in terms of the DNS server to use, if security is important, I would use either Knot DNS or NlLab’s NSD server. They both support DNSsec and they both have good security histories. While the majority of these “DNS” attacks would not had been helped by DNSsec, it does protect against the unusual case of a rogue router rewriting DNS answers for people not using HTTPS to connect to a web page.
If a big institution has to use a web control panel for DNS record handling, please use non-SMS two factor authentication.
 “zone file” is the file used by DNS servers to determine which IPs are associated with names. Here’s how one looks when using my particular DNS server: https://
 Note that I did not list my own MaraDNS here; MaraDNS does not have DNSsec. Nor does DjbDNS, although there are patches which add DNSsec support. Personally, instead of using patches from multiple third parties, it makes more sense to just use a DNS server with built-in DNSsec support.
 There is not a single DNS server out there without at least one security hole which has needed to be patched, but these two do not require constant updates.
 HTTPS, which the majority of internet traffic uses, has the same protections which DNSsec offers.
 SMS based two-factor authentication can be defeated with forged documents and a visit to one’s cell phone provider.
I have made an update to MaraDNS’s documentation based on a support request which I couldn’t answer with a simple “RTFM; here’s the relevant documentation”.
I am also updating how I number MaraDNS. Back in the 1990s, software companies would update the version number of their program to look as mature and stable as competitors. Microsoft Word for Windows jumped from version 2.0 to version 6.0; Slackware Linux jumped from version 4 to version 7.
This is not why I am jumping MaraDNS’s version number. MaraDNS has two components, MaraDNS and Deadwood, with different version numbers. MaraDNS is currently at 2.0.17; Deadwood is at 3.3.02. I will make the next MaraDNS 3.3.03 so that both MaraDNS and Deadwood have the same version number.
In addition to MaraDNS, I have gone back to my Prosperity 7 Puzzles which I have not looked at since 2011. I have taken the code I used to make these puzzles (both the original 2007 GPL Java applet and my HTML and CSS to display the puzzle on a web page) and updated it to include scripts for automatically generating puzzles (requiring me to modify the old 2007 Java to be able to run in batch mode) and making PDFs from those generated puzzles. The code is available on GitHub as well as locally.
Comments are closed.