> From: Jim Reid <[email protected]>
> I'm not sure it will make a difference though. The bad guys won't > bother to do TCP for the obvious reason and will stick with their > current, DNS protocol conformant, behaviour. The bad guys would not be able to stick with anything. The idea is to change all DNS servers to answer all DNS/UDP requests (or perhaps all outside requests) with truncated (TC=1) responses to force clients to retry with DNS/TCP. It might make sense for the few resolvers whose owners want them to be open (never mind that most of those owners are mistaken), but it assumes that it is possible to install new software on 21 million open resolvers that are open only because they are not properly maintained. > Remember too that in these DDoS attacks truncated UDP responses > would still be going to spoofed addresses. So those victims still > get hit, albeit without the amplification factor of a chubby DNS response. That amplification is the reason why the bad guys bother. > I expect TCP to an anycast resolver -- say 8.8.8.8? -- will prove > tricky for long-lived connections. Which long-lived DNS/TCP connections are those? DNS/TCP to 8.8.8.8 in `dig +vc example.com @8.8.8.8` works for me and takes a fraction of a second. (`dig` claims "Query time: 50 msec", but that evidently only covers one of the TCP round trips. `tcpdump` timestamps show a total of about 150 ms.) > Keeping state for bazillions of DNS TCP connections to a resolving > server will present further challenges. Yes, that could be a problem on busy DNS servers handling lots of legitimate traffic. The costs are not only holding the TCBs for the fraction of a second of a DNS/TCP transaction but holding them for the time-wait delay. See https://www.google.com/search?q=tcp+time+wait+exhaustion > [Maybe TCPCT could help.] I don't see anything in https://tools.ietf.org/html/rfc6013 that reduces the costs of TCP for DNS. Perhaps you mean T/TCP to bypass the TCP 3-way handshake. However, the expensive 3-way handshake in which the DNS client says "Yes, I really did send that DNS request" is why DNS/TCP prevents reflection DoS attacks. If you bypass the 3-way handshake, you get the same reflection DoS tool that you have with DNS/UDP. If you can change the software on 21 million open resolvers to use DNS over T/TCP, why do the the easier thing of closing them? If you could change their software and want to keep them open, then you could install RRL and DNS cookies. The problems that RRL has on resolvers would be solved with DNS cookies. DNS cookies don't need kernel changes but only changes in DNS client and server software. https://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03 > Another problem is lots of crapware -- CPE, hotel networks, coffee > shop wi-fi, etc -- assume DNS is only ever done over UDP. That invalidates many rationalizations for keeping resolvers open. In real life, travelers wanting to use the home office resolver must use VPNs and so don't need the home office resolver to be open to outsiders. Vernon Schryver [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
