Resolving conflicting DNS security approaches

There are numerous techniques by which someone with malicious intent can attack your network through the use of the domain name system (DNS).

In fact they’re so numerous that Michael Dooley and I wrote an entire book to enumerate these attack vectors — as well as tactics you can implement to prevent, detect and mitigate such attacks. Our book, DNS Security Management, was recently published by Wiley IEEE Press and defines a comprehensive DNS defence in depth approach within the context of the de facto standard NIST Cybersecurity Framework.

Coexistence and interaction of DNS security tactics

With such a vast array of available DNS security tactics, a logical question arises as to the effects of their co-existence and interaction. In many cases, multiple security tactics reinforce each other and provide multiple layers of defence or ‘defence in depth’. However, certain tactics may conflict with each other, creating the need to decide which should take precedence.

Take DNSSEC and DNS firewall for instance. DNSSEC (DNS security extensions) defines the internet standard mechanism for digitally signing DNS data using asymmetric key cryptography. This process enables recipients of such signed DNS data to validate the data signature which proves the DNS data as authentic, i.e. as published by the DNS administrator and that the data was not modified or tampered with en route. DNSSEC also provides a means to authenticate the non-existence of requested DNS data.

The role of DNS firewalls

A DNS firewall is a specially configured DNS server which analyses, and potentially applies policies to, DNS data, before passing it back to the requestor. DNS firewalls are indispensable for identifying malware-affected devices when they attempt to contact the malware author’s command and control (C&C) centre for attack instructions or to export sensitive information. In either case, when the malware attempts to contact the C&C centre by looking up its IP address in DNS, the DNS firewall matches certain elements of the DNS data and can apply corresponding policies to the data. These policies may entail passing through the answer unaltered, dropping the response altogether, or modifying the data. Responses may be modified such that the data appears as ‘not found’ or by changing the answer altogether, thereby redirecting the querying device to a mitigation portal, for example.

Signature issues

As you’ve probably guessed, such modifications of DNS data by a DNS firewall would invalidate DNSSEC signatures. As stated earlier, DNSSEC authenticates DNS data as published by the administrator responsible for that information, i.e. the corresponding authoritative DNS zone data. Any modification of that data by a ‘man in the middle’ — or a DNS firewall in this case — including falsely denoting data as ‘not found’, will prevent successful DNSSEC validation.

So, should a malware author choose to sign his or her DNS data using DNSSEC, would the DNS firewall violate DNSSEC in order to modify a potentially malicious answer? Or, would it honour DNSSEC and pass it on unmodified? While the popular open source ISC BIND DNS implementation supports an option to configure whether DNSSEC or firewall policies take precedence, BIND accords precedence to DNSSEC by default. Thus, an attacker could simply sign their resolution data and program their malware to request DNSSEC-signed DNS data in order to bypass a DNS firewall configured with default settings. If you would prefer to apply DNS firewall policies to all query responses, regardless of the presence of DNSSEC signatures, you have to set the BIND DNS ‘break-dnssec yes’ option parameter.

Balancing risk

You need to weigh which of these two potentially conflicting defence mechanisms should take precedence in minimising the overall risk to your network and organisation. Most would favour breaking DNSSEC in favour of applying DNS firewall policies if you have a reliable firewall feed and configuration. DNSSEC validation would only be broken for DNS data that matches your DNS firewall triggers; all other validations would be honoured. Allowing signed data to pass through provides a simple means for attackers to bypass your DNS firewall. On the other hand, since a DNS firewall configured to ‘break dnssec’ passes on a modified answer while stripping off now invalid signatures, this may cause validating clients to interpret an unsigned response as bogus. Thus, you may have circumstances similar to this that make the signed pass-through risk more acceptable than denying DNSSEC validation on matching queries.

Choosing your trade off

As with most decisions, security-oriented and otherwise, a trade-off must be made. Identify the risks of each option carefully then apply that which minimises your overall risk.