[HN Gopher] A lock with many keys: Spoofing DNSSEC-signed domain...
___________________________________________________________________
A lock with many keys: Spoofing DNSSEC-signed domains in 8.8.8.8
Author : sintax
Score : 83 points
Date : 2022-03-12 15:04 UTC (7 hours ago)
(HTM) web link (www.sidnlabs.nl)
(TXT) w3m dump (www.sidnlabs.nl)
| dutchmartin wrote:
| Very cool to see a SIDN labs post here. SIDN operates the .nl
| extension and puts the money earned into these kinds of research
| projects that benefit everyone.
| stingraycharles wrote:
| And they're also a major sponsor of NLNetLabs since forever,
| which funds the Unbound DNS server, among other things.
| rvz wrote:
| > For reporting this bug, we received $5,000 from Google's bug
| bounty programme.
|
| Excuse me?
|
| That's quite an urgent and serious bug and I'm afraid that is too
| low, especially from a $1TN dollar company with billions of
| users.
| rosndo wrote:
| There's no such thing as a serious DNSSEC bypass.
| hannob wrote:
| It's really not.
|
| Not many things rely on DNSSEC. Things that do rely on DNSSEC
| usually tend to have their own verifying resolver. (Because the
| idea of "we need signed DNS records, but we'll let google check
| that and maybe not even encrypt our connection to google" is
| not a very good one.)
| Avamander wrote:
| The very few who actually enforce DNSSEC, so that it would
| actually matter, probably don't trust Google.
| [deleted]
| teddyh wrote:
| TLDR: Google Public DNS would, until 23 February, not check that
| the ZSK (signing key used to sign DNSSEC DNS responses) was in
| turn signed by the KSK. Google would accept any signed response,
| by any ZSK. Even worse, they would cache this response, and
| present it to end users as being non-DNSSEC signed.
|
| Upon further testing, only Google was found to have had this
| problem.
| jeffbee wrote:
| Condensation of these wordy vulnerability disclosures is a true
| service to the public.
| jzer0cool wrote:
| What free or (non-free) DNS services is everyone using?
| errantmind wrote:
| Two general approaches:
|
| 1. A pi-hole on my local network for most devices. I configured
| my router to forcibly capture all (unencrypted) DNS queries and
| forward them to my pi-hole, which then forwards them upstream
| to Cloudflare's DNS (over TLS).
|
| 2. I wrote a simple DNS forwarder (over TLS) that uses a
| 'shotgun' approach to ensure timely query responses, among
| other performance-sensitive features. I use this on all my
| Linux machines. It runs as a service and never fails, mean
| latency is much lower than other forwarders I've tried,
| including systemd-resolved, unbound, etc.
| FireInsight wrote:
| Used to use Pihole but pi disk corrupted and didn't bother to
| set up again. Nowadays Quad9 9.9.9.9 and local ad/tracker
| blocking.
| tentacleuno wrote:
| AdGuard[0]. Ad-blocking included :) It's on 94.140.14.14,
| 94.140.15.15 (know them by heart now) if you want to try it.
| I've never had a problem with them.
|
| There's also a comprehensive list and comparison of various DNS
| providers at PrivacyGuides[1].
|
| [0]: https://adguard-dns.com/ [1]:
| https://privacyguides.org/providers/dns/
| teddyh wrote:
| Run your own resolver, on your local machine. It's the only
| way.
|
| Only if you have a local network of machines can you consider
| making one of these machines the resolver for the local
| network. A typical example of this might be your router. This
| machine should then _not_ forward the DNS requests to some
| centralized resolver, it should resolve DNS queries itself.
| ftobin wrote:
| Cloudflare's malware blocking service is my go-to. 1.1.1.2,
| supporting DoH and DoT. I prefer them over Quad9 because Google
| blog post listed several malware domains and Quad9 only caught
| half, while Cloudflare caught them all.
| https://www.reddit.com/r/Quad9/comments/t9b9v1/quad9_not_cat...
| xorcist wrote:
| apt-get install unbound
___________________________________________________________________
(page generated 2022-03-12 23:00 UTC)