{"id":340,"date":"2019-02-22T00:05:58","date_gmt":"2019-02-21T17:05:58","guid":{"rendered":"http:\/\/www.seven-stones.biz\/blog\/?p=340"},"modified":"2019-02-22T06:03:07","modified_gmt":"2019-02-21T23:03:07","slug":"prevalent-dns-attacks-is-dnssec-the-answer","status":"publish","type":"post","link":"https:\/\/www.seven-stones.biz\/blog\/prevalent-dns-attacks-is-dnssec-the-answer\/","title":{"rendered":"Prevalent DNS Attacks – is DNSSEC The Answer?"},"content":{"rendered":"\n

Recently the venerable Brian Krebs<\/a> covered a mass-DNS hijacking attack<\/a> wherein suspected Iranian attackers intercepted highly sensitive traffic from public and private organisations. Over the course of the last decade, DNS issues such as cache poisoning and response\/request hijacking have caused financial headaches for many organisations.<\/p>\n\n\n\n

Wired does occasionally dip into the world of infosec when there’s something major to cover, as they did here<\/a>, and Arstechnica published an article<\/a> in January this year that quotes warnings about DNS issues from Federal authorities and private researchers. Interestingly DNSSEC isn’t covered in either of these.<\/p>\n\n\n\n

The eggheads behind the Domain Name System Security Extensions (obvious really – you could have worked that out from the use of ‘DNSSEC’) are keeping out of the limelight, and its unknown as to exactly how DNSSEC was conceived, although if you like RFCs (and who doesn’t?) there is a strong clue from RFC 3833<\/a> – 2004 was a fine year for RFCs. <\/p>\n\n\n\n

The idea that responses from DNS servers may be untrustworthy goes way back, indeed the Council of Elrond<\/a> behind RFC 3833 called out the year 1993 as being the one where the discussion on this matter was introduced, but the idea was quashed – the threats were not clearly seen in the early 90s. An even more exploitable issue was around lack of access control with networks, but the concept of private networks with firewalls at choke points was far from widespread.<\/p>\n\n\n\n

DNSSEC Summarised<\/h2>\n\n\n\n

For a well-balanced look at DNSSEC, check Cloudfare’s version<\/a>. Here’s the headline paragraph which serves as a decent summary “DNSSEC creates a secure domain name system by adding cryptographic signatures to existing DNS records. These digital signatures are stored in DNS name servers alongside common record types like A, AAAA, MX, CNAME, etc. By checking its associated signature, you can verify that a requested DNS record comes from its authoritative name server and wasn\u2019t altered en-route, opposed to a fake record injected in a man-in-the-middle attack.”<\/p>\n\n\n\n

DNSSEC Gripes<\/h2>\n\n\n\n

There is no such thing as a “quick look” at a technical coverage of DNSSEC. There is no “birds eye view” aside from “it’s used for DNS authentication”. It is complex – so much so that’s it’s amazing that it even works at all. It is PKI-like in its complexity but PKIs do not generally live almost entirely on the Public Internet – the place where nothing bad ever happened and everything is always available.<\/p>\n\n\n\n

The resources required to make DNSSEC work, with key rotation, are not negligible<\/strong>. A common scenario – architecture designs call out a requirement for authentication of DNS responses in the HLD, then the LLD speaks of DNSSEC. But you have to ask yourself – how do client-side resolvers know what good looks like? If you’re comparing digital signatures, doesn’t that mean that the client needs to know what a good signature is? There’s some considerable work needed to get, for example, a Windows 10\/Server 2k12 environment DNSSEC-ready: client side configuration<\/a>.<\/p>\n\n\n\n

DNSSEC is far from ubiquitous<\/strong>. Indeed – here’s a glaring example of that:<\/p>\n\n\n\n


 iantibble$ dig update.microsoft.com dnskey 

<\/pre>\n\n\n\n