0

Are there alternative ways to operate an open/forwarding DNS server, without having to use rate limiting or other means of traffic inspection to prevent being used for DNS amplification attacks?

Within a given network, the DNS server can be easily restricted to only answer to specified IP adresses, but given the increased usage of mobile devices I would like to avoid this restriction. (lets ignore VPNs for this question)

Can you point me to any alternative approaches that try to prevent access to the DNS server or amplification attacks by other means then actually keeping track of requests and client behaviour?

Are there any client-side solutions, less heavy than a VPN, to authenticate to a DNS server?

edit: as this question has been marked as a duplicate to an unrelated question, I have edited the title to include "client-side". This is not a duplicate. I have mentionend the traditional way to to limit the effects of an amplification attack on the server in my question and I tried to indicate my search by mentioning the VPN based solutions.

Martin
  • 316
  • 2
  • 13
  • Nope. Open resolvers are an anathema to the internet and the problems are too low level to be solved without changing how the clients themselves operate. – Andrew B Jan 06 '16 at 16:36
  • @AndrewB Yes and that is my question and it is different to the linked "duplicate". I am aware of the problem and the potential solutions, that rely on traffic inspection or limiting. I am asking for alternatives, that might imply using differnet clients etc. – Martin Jan 06 '16 at 17:16
  • Fair enough, I'll give it a reopen vote. The answer isn't going to change much though. – Andrew B Jan 06 '16 at 17:38
  • @AndrewB It still looks like a duplicate question to me. But I don't like the current answer. I recall writing an answer to a very similar question in which, I gave an actual technical solution which would work if implemented. – kasperd Jan 06 '16 at 18:21
  • @kasperd Feel free to link it if not contribute it. Very interested to see. – Andrew B Jan 06 '16 at 18:29
  • 1
    @AndrewB Here is one [answer](http://serverfault.com/a/708143/214507) where I briefly covered the method. I should write a slightly more detailed version of that as an answer to the [open resolver question](http://serverfault.com/q/634793/214507). – kasperd Jan 06 '16 at 18:33
  • @kasperd You can, but that method is somewhat contested. I remember seeing it recently on the dns-operations mailing list. [Here's the link.](https://lists.dns-oarc.net/pipermail/dns-operations/2015-October/thread.html#13816) (edit: Okay, my bad, that was TC=1 without whitelisting to remove the overhead.) – Andrew B Jan 06 '16 at 18:37
  • @AndrewB I took a look on that thread. Some are opposed to the idea due to additional roundtrips. With a whitelist it will cost two roundtrips for the first query, and none after that. With a blacklist approach those extra roundtrips can be avoided (but the blacklist has other drawbacks). Some are opposed to the idea because of clients which don't conform to the RFC requiring them to use TCP when told to. And some seems are opposed to the idea without explaining why. – kasperd Jan 06 '16 at 19:02
  • @AndrewB Somebody mention EDNS cookies, which require a protocol extension supported by both client and server. That means EDNS cookies is likely to cause breakage for more clients than my approach. However if EDNS cookies are standardized it would be a better solution than my approach. And it is entirely possible for a server to support both approaches to work for as many clients as possible. I am personally slightly opposed to EDNS cookies, because if you are going to introduce protocol changes then why aim only for DNS and not for UDP? – kasperd Jan 06 '16 at 19:06

0 Answers0