Hi, I've had this idea, read about it and let me know what you think. https://www.tuxis.nl/blog/what-if-dns-over-tcp-20180207/ -- Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ Mark Schouten | Tuxis Internet Engineering KvK: 61527076 | http://www.tuxis.nl/ T: 0318 200208 | info@tuxis.nl
Dag Mark, On 07/02/2018 16:14, Mark Schouten wrote:
Hi,
I've had this idea, read about it and let me know what you think. https://www.tuxis.nl/blog/what-if-dns-over-tcp-20180207/
Thank you for writing down your ideas. I have some questions and a couple of comments for you to consider. Question 1: Was the recent DDOS armed by open resolvers allowing for a DNS amplification attack? I didn't heard about the specifics other than a botnet, hired for a nominal fee. Question 2: Are DNS amplification attacks still an issue? As far as I understand are most name servers equipped with RRL (response rate limiting), effectively nullifying (well almost) the spoofed traffic reflection. I guess most DNS name servers (authoritative/recursive) do support TCP to deal with TC bit (truncated answer) and (should try) TCP fallback. Measuring name server TCP capabilities by scanning name servers might be quite an effort (i.e. which name server to scan?), but you can also look at the different DNS server implementations, e.g. BIND, PowerDNS, Knot DNS and NSD/Unbound. ;-) In the past years, we (the open source DNS community) made substantial progress with introducing DNS-over-TLS in the different code bases. This started in the IETF DPRIVE working group and implementations are well on the way. See for more information https://dnsprivacy.org/wiki/. All this DNS-over-TLS work focuses on stub to resolver interactions: the easy part wrt scaling (up to 10.000 clients). The hard part is still the authoritatives that see up to millions queries per second. Cheers, -- Benno -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/
Hi Benno, On woensdag 7 februari 2018 16:53:55 CET Benno Overeinder wrote:
Question 1: Was the recent DDOS armed by open resolvers allowing for a DNS amplification attack? I didn't heard about the specifics other than a botnet, hired for a nominal fee.
I don't know.
Question 2: Are DNS amplification attacks still an issue? As far as I understand are most name servers equipped with RRL (response rate limiting), effectively nullifying (well almost) the spoofed traffic reflection.
IMHO RRL is a workaround (which might be pretty effective, but still), not a solution. And correctly configured nameserver probably aren't a big issue whatsoever. But, by depending on DNS over UDP, we cannot just filter it and let people that misconfigure their servers be the victim of their own fault.
I guess most DNS name servers (authoritative/recursive) do support TCP to deal with TC bit (truncated answer) and (should try) TCP fallback. Measuring name server TCP capabilities by scanning name servers might be quite an effort (i.e. which name server to scan?), but you can also look at the different DNS server implementations, e.g. BIND, PowerDNS, Knot DNS and NSD/Unbound. ;-)
I'm scanning as we speak. The script I wrote (which probably contain a few bugs, but gives some insight) has scanned 8240 nameservers so far, 495 of which did not respond to TCP. Input is a version of the alexa top 1 million and a dump of my resolvercaches, of which the nameservers are looked up and checked. Newly discovered domains get added to the queue in the process.
In the past years, we (the open source DNS community) made substantial progress with introducing DNS-over-TLS in the different code bases. This started in the IETF DPRIVE working group and implementations are well on the way. See for more information https://dnsprivacy.org/wiki/.
All this DNS-over-TLS work focuses on stub to resolver interactions: the easy part wrt scaling (up to 10.000 clients). The hard part is still the authoritatives that see up to millions queries per second.
DNS-over-TLS specifically focus on client-resolver communication. Which is nice, but still doesn't allow me to just filter UDP/53 on my edges. Possibly handling millions of queries over TCP is hard (not an expert on that), but I guess we have other services handing lots of requests as well, don't we? -- Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ Mark Schouten | Tuxis Internet Engineering KvK: 61527076 | http://www.tuxis.nl/ T: 0318 200208 | info@tuxis.nl
Hi Mark and Benno, On 7 February 2018 at 17:16:11, Mark Schouten (mark@tuxis.nl) wrote:
Hi Benno,
On woensdag 7 februari 2018 16:53:55 CET Benno Overeinder wrote:
Question 1: Was the recent DDOS armed by open resolvers allowing for a DNS amplification attack? I didn't heard about the specifics other than a botnet, hired for a nominal fee.
I don't know.
The recent DDoS attacks that I see are mainly synflood attacks. Relatively small in Gbit/s. UDP attacks are not that popular anymore in comparison with 2016. We received over 100 DDoS attacks last month, between 2 - 40 Gbit/s.
Question 2: Are DNS amplification attacks still an issue? As far as I understand are most name servers equipped with RRL (response rate limiting), effectively nullifying (well almost) the spoofed traffic reflection.
IMHO RRL is a workaround (which might be pretty effective, but still), not a solution. And correctly configured nameserver probably aren't a big issue whatsoever. But, by depending on DNS over UDP, we cannot just filter it and let people that misconfigure their servers be the victim of their own fault.
I guess most DNS name servers (authoritative/recursive) do support TCP to deal with TC bit (truncated answer) and (should try) TCP fallback. Measuring name server TCP capabilities by scanning name servers might be quite an effort (i.e. which name server to scan?), but you can also look at the different DNS server implementations, e.g. BIND, PowerDNS, Knot DNS and NSD/Unbound. ;-)
I'm scanning as we speak. The script I wrote (which probably contain a few bugs, but gives some insight) has scanned 8240 nameservers so far, 495 of which did not respond to TCP. Input is a version of the alexa top 1 million and a dump of my resolvercaches, of which the nameservers are looked up and checked. Newly discovered domains get added to the queue in the process.
In the past years, we (the open source DNS community) made substantial progress with introducing DNS-over-TLS in the different code bases. This started in the IETF DPRIVE working group and implementations are well on the way. See for more information https://dnsprivacy.org/wiki/.
All this DNS-over-TLS work focuses on stub to resolver interactions: the easy part wrt scaling (up to 10.000 clients). The hard part is still the authoritatives that see up to millions queries per second.
DNS-over-TLS specifically focus on client-resolver communication. Which is nice, but still doesn't allow me to just filter UDP/53 on my edges.
Possibly handling millions of queries over TCP is hard (not an expert on that), but I guess we have other services handing lots of requests as well, don't we?
-- Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ Mark Schouten | Tuxis Internet Engineering KvK: 61527076 | http://www.tuxis.nl/ T: 0318 200208 | info@tuxis.nl_______________________________________________ NLNOG mailing list NLNOG@nlnog.net http://mailman.nlnog.net/listinfo/nlnog
Regards, Thomas de Looff
participants (3)
-
Benno Overeinder -
Mark Schouten -
Thomas de Looff - PCextreme