[Pdns-dev] PDNS Recursor functionality request re:SERVFAIL outages of today

[Greg Owen]

On 2016-10-21 19:53, John Todd wrote:
> I’d like to propose an extension to PowerDNS Recursor for mitigating
> (partially) events like we had today where major authoritative
> nameservers were put out of commission. This might be a particularly
> foolish or error-prone method - it only took me a few minutes to think
> up. But I’d at least like to hear a discussion as to why this isn’t a
> good idea. The comment of “But this might end up giving out the wrong
> answer!” is true, but I view a wrong answer as better than no answer.
...
> If that query fails due to a SERVFAIL, then the TTL timer on this
> “old” record is set back to zero and the “old” record is provided as
> a response. If an authoritative server is marked as “down” due to
> repeated SERVFAIL responses (see packetcache-servfail-ttl) then the
> “old” record is handed back immediately without a new query attempt,
> and the TTL timer is set back to zero to keep the answer in a state
> of perpetual validity as long as....

There are security concerns to doing this.  Most simply, a wrong answer 
is worse than no answer if the "wrong" answer is a maliciously sourced 
record.

Consider the two following cases:

1) The attacker poisons the records for a zone - either indirectly, or 
via compromise of the actual authoritative servers - and then takes the 
actual servers down hard, causing SERVFAIL until the owners either fix 
the servers, weather the DDoS, or redirect the root NS records.

2) The attacker poisons the records directly via compromise of the 
actual authoritative servers, and the owner takes the servers down until 
they can be replaced with clean, secured versions.

In these two cases, the measure you're proposing would persist the 
malicious entries past their expiration and for the duration of the 
attack's effectiveness on the authoritative servers.

Even if your measure is triggered manually - in today's event, for 
example, one says "Gosh, I know records are offline because of a Dyn 
DDoS, so I know I can compensate by saving records, throw the switch!" - 
let's say that someone DDoSed *ALL* of Dyn after poisoning records for a 
single zone.  You'd have no way of knowing - until the incident is over 
and forensic analysis has hopefully caught that nuance - that you were 
doing the attacker's work for them.

These attack vectors are not without precedent.  So-called "Dark DDoS" 
attacks have been used to distract and mislead defenders, providing a 
smoke screen for other more direct attacks:

http://www.infosecurity-magazine.com/opinions/dark-ddos-growing-cyber-security/

So, in short, your proposal has the caveat that it may extend the damage 
from an attack in more pernicious ways than simple denial of service.  
(I'd rather not get to my bank than get to an impostor posing as my 
bank!)

...

I agree it's worth putting some thought into how to increase redundancy 
and flexibility to compensate for these infrastructure attacks.  For 
example, perhaps taking your idea but only applying it to signed DNSSEC 
records which have slightly higher data integrity?  It's definitely 
worth exploring, but let's be careful of known and reasonable ways 
attackers could take advantage of this compensation.

Thx,
gowen

-- 
     gowen - Greg Owen - gowen at swynwyr.com
     CISSP, GCIA, GCFA, GWAPT