[dns-operations] How many kinds of DNS DoS attacks are we trying to stop ?

[Vernon Schryver]

> From: Stephane Bortzmeyer <bortzmeyer at nic.fr>

> > Experiment to see if OS fingerprinting yields useful signal on DNS
> > UDP queries (I suspect not?).
>
> I'm not an expert in OS fingerprinting but, judging from the traffic
> of today's fingerprinting tools (I tried with nmap), it takes tenths
> of packets exchanged with the target to get an idea of the OS it
> uses. I don't think that one only UDP packet coming in cannot yield
> anything interesting.

In this case, we're generally talking about a lot more than only one
UDP packet, and so that objection to fingerprinting might not stand.
I'd worry about passive fingerprinting.  Unlike like TCP O/S fingerprinting,
a DNS server can't poke a UDP client much without denying service to
the client.  Sending TC=1 is at the limit.

A more cogent worry is what one would do with system fingerprints.
Imagine that you could say "DNS requests from 10.2.3.4 have been
purple."  Then what?--the common answer is "Drop excessive DNS requests
of other colors."  The trouble is that before turning on the flood,
your adversary can spend a day or a week forging a modest number of
ecru requests to convince your fingerprinter that 10.2.3.4 now uses
ecru and that purple is forged.  Your adversary doesn't need to know
the color of the target; it need only send a few requests from the
systems that it will eventually use for the flood to make them look
legitimate.  This problem can affect not only operating system
fingerprinting but also databases of IP TTLs.

   ....

} From: Phil Pennock <dnsop+phil at spodhuis.org>

}   It's possible that this could be used to defer DNSSEC responses to
}   non-ANY queries too, during DoS; the RRSIG belongs in the ANSWER
}   section, but a TC response which skips the RRSIG and causes a TCP
}   retry would:
}
}   (1) return smaller results, turning off a large chunk of the
}   amplification

How do you return smaller DNSSEC results but still verify?  If the
recursive server thinks there are supposed to be crypto RRs thanks to
DS RRs from the parent zone, won't the recursive server answer the
local client with SERVFAIL if the authoritative answer doesn't verify?
http://dns.comcast.net/ has real life examples.  SERFFAIL sounds less
useful than an empty TC=1.


}   (2) with non-existent RR queries causing NSEC3 responses, defer the
}   crypto work for NSEC3 until there's a TCP connection, which
}   rate-limits the queries and reduces the CPU burden on the
}   authoritative server

What authoritative server crypto work for NSEC3 is that?  Aren't NSEC3s
pre-computed by dnssec-signzone or equivalent?  Check references to
NSEC3 in your favorite hit in https://www.google.com/search?q=dnssec-signzone


}   All of this assumes that a modern server can be adequately tuned for
}   TCP query volumes; for a dedicated DNS auth server, some very
}   aggressive TCP state timeouts can be used (and can anyway, if the OS
}   permits timeout tuning on a per-port/socket basis).

What does TCP tuning have to do with a DoS reflection attack?  Are you
proposing that a server would punt all requests with TC=1 after seeing
a flood of requests from one IP address block?  Without interesting
ideas such as moving all of the TCP state machine into the DNS server,
I don't see any TCP tuning that would keep that from turning a DoS
reflection attack into a DoS attack on the authoritative server.

The DNS TCP problem is not with any state that might be kept from the
receipt of the SYN until receipt of the data segment with the request.
If you move the TCP state machine into the DNS server, you can play
games with the TCP ISN to avoid keeping any of that state.  The
troublesome state is that must be kept after the DNS answer is sent
and until the FIN-ACK is received.  You can't tune that away, because
you might need to retransmit the segment containing the DNS answer
many seconds later.


} Yes, any response _can_ be large and be used, but for DDoS amplification
} to spoofed source to be easy and useful, there needs to be something
} _consistently_ large which can be sent back in a UDP response. 

As long as it's large often enough, why is consistency needed?

}                                                                 The main
} candidates today are ANY and DNSSEC. 

And TXT and SPF and TLSA and the forthcoming SMTP DANE type and ...

}                                       If we have a way to mitigate the
} impact of those and can turn it on by default, we shrink the general
} amplification ratio of the Internet's nameservers.  It's likely that in
} future another RR type will result in similar amplificiation.  Perhaps
} future RFCs for DNS should be required to tackle UDP amplification ...

Perhaps if wishes were horses, then beggars would ride and the problem
would solve itself.  In the real world, the problem exists and won't
go away by itself this year or next.


}                           if we refuse to reduce the typical impact of
} those attacks because the solution isn't perfect,

I trust you have looked at other imperfect solutions such as rate limiting
by (qname,qtype,IP address).  In your estimation, how does that compare
to trimming ANY and DNSSEC responses?


Vernon Schryver    vjs at rhyolite.com