[dns-operations] dnsop-any-notimp violates the DNS standards
michael at brokendns.net
Tue Mar 17 16:40:29 UTC 2015
On 3/17/15 6:17 AM, Yunhong Gu wrote:
> > Sounds to me this is the root cause of the problem and ANY is the just a
> > scapegoat.
> Giving NSEC3PARAM a positive TTL would prevent my headache, but it
> wouldn't help the victim of the attack, and would probably make it worse
> for the victim.
> The reason that this response can be used for an amplification attack is
> its size, not the ANY type. A responses with 200 A records can be used
> for the same purpose. The (even deeper) root cause is the use of UDP in
> DNS protocol. I just do not think banning ANY touches any of these
> fundamental issues.
Ah, this is a different argument.
I don't believe that I ever suggested "banning" ANY. What I suggested
is that if you want to use TC=1 to stop the current en vogue attack, you
need to apply it everywhere and make sure that all implementations
handle it the same way: All ANY responses get TC=1 with a *minimal*
response. Not all implementations currently do that. Another option
is cookies, although I haven't fully thought through how that would mesh
with the current attack dynamics.
I recognize you can do reflection attacks with A records, although there
are even better attacks out there that don't use ANY or A. But ANY has
basically three uses: reflection attack, troubleshooting, and supporting
old qmail. I'd be interested in methods that can be implemented in a
matter of weeks or months, which can reduce the attack vector, while
retaining as much of the "legitimate functionality" as possible, knowing
that the threat can't be fully eliminated.
As it stands, operators are taking matters into their own hands and
simply blocking ANY responses (which makes my headache bigger because I
slave for some of those operators and they're pushing more of the
iterative ANY queries at me).
More information about the dns-operations