[dns-operations] Force TCP for external quereis to Open Resolvers?

[Vernon Schryver]

> From: Jim Reid <jim at rfc1035.com>


> 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    vjs at rhyolite.com