[HN Gopher] Open DNS resolvers, from bad to worse
___________________________________________________________________
Open DNS resolvers, from bad to worse
Author : zdw
Score : 76 points
Date : 2022-05-13 16:40 UTC (6 hours ago)
(HTM) web link (blog.apnic.net)
(TXT) w3m dump (blog.apnic.net)
| lfkdev wrote:
| Aachen wrote:
| Not sure you've understood the article, or at least I don't
| understand your question in relation to it. What would make a
| DNS server the "best" in this regard?
|
| From my point of view, anything supporting cookies and RRL is
| going to be sufficient, which means any standard server out
| there is fine to use.
| tptacek wrote:
| It's not an article for end users.
| bingo-bongo wrote:
| I don't think the end user is the target audience for the
| article.
| [deleted]
| quyleanh wrote:
| Currently I'm using NextDNS [0] and happy with its ultralow
| server.
|
| Fast. Block ads. Privacy. Even support the Anonymized ESC.
|
| Sometimes it still chooses the wrong ultralow server, but in
| overall it's good and fit my case.
|
| [0] https://nextdns.io/
| leokennis wrote:
| Love it too. You set it up and it just works. Basically once a
| year PayPal notifies me I paid them $20, and in exchange I
| don't see any ad, ever, anywhere.
| sigg3 wrote:
| That's awesome! What about yt ads? I'm using a pihole but I
| can't seem to cover the google ad servers in the region
| (northern Europe).
| JackGreyhat wrote:
| If im not mistaken, yt serves ads from its first party
| domain, making it hard to block from a dns perspective.
| Blockers such as uBlock do it by blocking elements or code,
| not dns lookups.
| simonjgreen wrote:
| What is it that Google, Cloudflare, OpenDNS, etc are doing
| exactly that make their open DNS resolvers acceptable?
| rsync wrote:
| I have run a totally open 'unbound' instance in my personal
| infrastructure for many years now.
|
| Anyone in the world can query it and get correct name resolution
| (if they scanned for it and found it).
|
| Convince me that this is negative ...
| [deleted]
| jabroni_salad wrote:
| You could be party to a dns amplification attack:
| https://www.cisa.gov/uscert/ncas/alerts/TA13-088A
|
| & a quote from the article:
|
| >Our findings revealed that we can reduce the overall potential
| by 80% if we patch around 20% of the most potent amplifiers
| (see Figure 1).
| sliken wrote:
| This DNS likely participates in DoS attacks. Attackers craft
| queries with a maximum amplification factor and offer up the
| victim's IP as the query IP. This results in bandwidth from the
| attacker getting multiplied by amplification factor and the
| attackers IP is hidden from the victim.
|
| Rate limiting, blocking abusive IPs, and blocking large
| transfers like zone transfers can help.
| andrewmcwatters wrote:
| Oh neat, somewhat related, I wanted to use ANY but realized that
| recently per RFC 8482, most DNS servers will not respond to it
| meaningfully anymore, so you have to query each query type.
|
| So I wrote digany(1) for the primary use case of backing up DNS
| records.[1]
|
| [1]: https://github.com/andrewmcwattersandco/digany
| DerekBickerton wrote:
| Anyone use alternative DNS resolvers? (Apart from the usual
| suspects of): 1.1.1.1 8.8.8.8
| 9.9.9.9
| mdasen wrote:
| I used to use AdGuard's DNS (https://adguard-dns.io/). It looks
| like they're going to be launching an upgraded version that you
| can customize in the future.
|
| Right now, I'm using NextDNS (https://nextdns.io). It lets me
| add ad/tracking block lists, block specific domains (especially
| ones that serve annoying embeds in many sites), and setup
| rewrites so that I can have my-fake-domain.com resolve to
| localhost. I can use their DNS-over-HTTPS with
| Chrome/Edge/Firefox and I can setup my router to to use their
| DNS. It's basically my own little PiHole without needing the
| RaspberryPi (which are very hard to come by these days).
|
| (Anxiously awaits someone on HN telling me that I shouldn't be
| using NextDNS)
| treesknees wrote:
| Beyond running Adguard, I use OpenDNS
| (208.67.220.220/208.67.222.222) as I can setup some block
| categories like phishing/malware as a layer of last resort.
|
| I could probably switch, but I've been using them since ~2010
| (back before these other ones were available) with no issues.
| mobilio wrote:
| Yup.
|
| I've used them as backup DNS resolvers on all machines.
| 1vuio0pswjnm7 wrote:
| The authors proposed solution is to reduce the number of open
| resolvers.
|
| In 2009, someone else identified the amplifciation for DDoS
| problem, he associated it with DNSSEC not open resolvers, and
| proposed a different solution.
|
| https://cr.yp.to/talks/2009.08.11/slides.pdf See page 43
|
| I use dnscurve on the home network. I also disable EDNS0 when I
| run DNS servers. I have no problems as a result of these choices.
| I can remember the internet before the post-2008 campaign for
| DNSSEC and before EDNS0. From the end user perpsective, IMO the
| internet worked just fine without DNSSEC and EDNS0.
|
| The need for DNSSEC is due the use of shared DNS caches run by
| third parties, e.g., Google, Cloudflare, OpenDNS, etc. As such,
| another solution to amplificiation risks is to stop using third
| party DNS caches. This obviates the need for DNSSEC.
| TechBro8615 wrote:
| > stop using third party DNS caches
|
| What is the best way to go about this? AFAIU the root DNS
| servers will refuse requests for recursive resolutions. So I
| understand the need for a self-hosted caching resolver in the
| middle. But is it actually necessary? If I configure my iPhone
| DNS to use a root server IP [0], will it perform the recursive
| resolution locally? And if so, is there any downside, other
| than increased latency, to contacting the root servers
| directly?
|
| I guess privacy and trust might be issues, when asking
| untrusted computers (any of the intermediate resolvers) to
| resolve an address for your client. You would certainly give
| the host of a domain more information when you contact it than
| you would by using a third party caching resolver as an
| intermediary. It's basically a question of spraying small bits
| of activity to many resolvers, or all your activity to one
| resolver. Which is a smaller attack surface? Depends.
|
| [0] https://www.iana.org/domains/root/servers
| Aachen wrote:
| In the past year I designed two UDP protocols (for connection
| measurements and a game server) and last week wrote a DNS server.
| In my own protocols, I always made sure that the sender has to
| put in more bytes until a >2^64-bit secret was echoed. Only with
| DNS this does not seem to be possible. At best, you can refuse a
| query in an equal number of bytes, but useful responses
| necessitate amplifying.
|
| Every nameserver out there, from duckduckgo to hacker news, will
| send back larger responses because it must echo the query.
|
| Does anyone know why this is not considered an issue? Are we just
| waiting for open resolvers to be eliminated and attackers to
| switch over to this lesser amplification factor before we start
| fixing it?
|
| The only solution given the current protocol, considering
| reasonable compatibility, is to use rate limiting per source IP,
| which means that someone can use source IP spoofing to block
| benign sources. This problem can be mitigated with DNS cookies,
| but I don't know if those are universally supported enough to
| simply reject any clients that don't support DNS cookies yet. It
| also means state keeping per client (hello IPv6). If clients
| would just send back a slightly larger packet than the response
| they expect, and servers didn't have to echo the query,
| amplification protection would be much easier to implement.
| hannob wrote:
| There's no ultimate solution, but there are a few things being
| done in common DNS servers that can mitigate the issue:
|
| * Large answers like ANY queries or large DNSSEC records should
| either be not supported or only supported via TCP (see RFC 8482
| e.g. for ANY).
|
| * DNS software can implement response rate limiting:
| https://kb.isc.org/docs/aa-00994
|
| This doesn't prevent all amplification, but it prevents strong
| amplification, i.e. you'll be less valuable for attackers.
| RL_Quine wrote:
| Presumably this could be mitigated by the DNS request needing
| padding?
| pkulak wrote:
| Pretty sucky to have to bloat a fundamental protocol of the
| internet, and thus, all traffic, forever, to avoid
| amplification attacks.
___________________________________________________________________
(page generated 2022-05-13 23:00 UTC)