[dns-operations] First experiments with DNS dampening to fight amplification attacks

[Vernon Schryver]

> From: Paul Vixie <paul at redbarn.org>
> To: John Kristoff <jtk at cymru.com>

> >> We could encode the encrypt the correct destination in the CNAME, for
> >> A and AAAA this is trivial. If you come back to resolve
> >> encoded-12.32.43.43.attackeddomain.com, you get 12.32.43.43 etc. For
> >> extra resilience encrypt it.
>
> as before, i think this could be done for a recursive talking to a stub,
> but that an authority server should only speak zone truth. ..

I still don't understand why anyone would do it.  From context, it seems
to have something to do with reflection amplification.

Costs:
  - server CPU cycles to generate DNSSEC signatures on the fly for the
     synthetic CNAMEs
  - twice as much bandwidth for legitimate requests
  - twice as much network delay for legitimate requests
  - twice as much client CPU processing to process the synthetic CNAMEs,
      including validate the signatures on the CNAMEs 
  - new bugs in additional code (more code *always* has more bugs)

Benefits:
  - decrease DNS reflection amplification for non-DNSSEC ANY queries

So at high cost it would stop last year's ANY based reflection attacks
and do less than nothing for next year's DNSSEC reflection attacks.

Don't forget the extra special free benefit of it not mitigating even
last year's ANY reflection attacks if you don't encrypt the synthetic
CNAME.  An adversary that can predict the synthetic CNAMEs could send
ANY requests for the CNAMEs and bypass the whole thing.

I'm guessing that "encrypt it" means encoding in the CNAME the DNS
client IP address, qname, and a nonce to prevent an attack consisting
of repeated requests for the synthetic CNAME.  The machinery to prevent
abusing the synthetic CNAME requests would be quite similar to rate
limiting.  It must drop both requests for old synthetic CNAMES and
excessive requests for a current CNAME.  In other words, to make it
work as a defense against reflection attacks, you'd have to implement
rate limiting.  
After you have rate limiting, why bother with the costs of the
synthetic CNAMES?


Vernon Schryver    vjs at rhyolite.com