[Pdns-dev] PDNS Recursor functionality request re:SERVFAIL outages of today
gowen at swynwyr.com
Sat Oct 22 01:48:11 UTC 2016
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
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:
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
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.
gowen - Greg Owen - gowen at swynwyr.com
CISSP, GCIA, GCFA, GWAPT
More information about the Pdns-dev