Live data from Hacker News

Shutting down our public encrypted DNS

mullvad.net

101–110 of 240 posts

Re: Shutting down our public encrypted DNS

#101
post #51

Earlier quoted context omitted.

I use Mullvad's adblocking DNS server on my phone which is not always behind my home router.

If you're on Android, FF supports add-ons. If you're on an iPhone, uBlock is now supported: https://apps.apple.com/us/app/ublock-origin-lite/id674534269... There's also Orion browser, but I found it to be a bit more glitchy, especially around sites like YouTube (fuck the app, I'm not watching videos there): https://orionbrowser.com/

The uBlock Origin lite that can run on iOS is very limited compared to the uBlock Origin that runs on Firefox Android.

Re: Shutting down our public encrypted DNS

#102
post #55

Earlier quoted context omitted.

You can't compare running a single service in your home network with the operations it takes to serve a public DNS

> https://freedns.afraid.org/ This dude has been doing it for 25 years, and actually this is a dns provider for domain names which I'm decently sure makes it more complicated than public dns. They're allowed to say they don't want to pay for it anymore, I just think their logic is bad. Or maybe their lawyer said they're running risks just ignoring takedown and they didn't want to deal with it anymore.

> this is a dns provider for domain names which I'm decently sure makes it more complicated than public dns

Can you expand on this? Isn't all DNS for domain names?

Re: Shutting down our public encrypted DNS

#103
post #27

Does anyone know of good alternatives that also block ads? Seems Quad9 doesn't.

I'm using numa( https://github.com/razvandimescu/numa ) for ad filtering and odoh mode for privacy (shameless plug)

So this is something to use instead of pihole?

Re: Shutting down our public encrypted DNS

#104
post #98
post #5

Earlier quoted context omitted.

Not if Quad9 is using DNSSEC, no. What's the specific threat you're envisioning? If it involves Quad9 themselves being malicious, what would DNSSEC on the forwarding prevent? This page explains how all of this works in detail: https://quad9.net/news/blog/quad9-enables-dnssec-on-all-serv...

Wait, I must be misunderstanding you, because if you're resolving off Quad9, they can definitely poison your DNSSEC-signed records. Between a stub resolver and a recursor DNSSEC collapses down to a single "yes it was signed" bit in the header. To protect yourself from an upstream resolver using DNSSEC, you need to be doing something akin to a full recursive lookup yourself. This is a flaw in the DNSSEC design and a r…

> To protect yourself from an upstream resolver using DNSSEC, you need to be doing something akin to a full recursive lookup yourself. This is a flaw in the DNSSEC design and a reason why DoH took off instead.

What? I don't see how you can call that a flaw in DNSSEC when DoH is no better in this regard; it doesn't even attempt to protect against a malicious recursive resolver. The only way to do that is to validate DNSSEC on the client.

Re: Shutting down our public encrypted DNS

#105
post #104
post #98

Earlier quoted context omitted.

Wait, I must be misunderstanding you, because if you're resolving off Quad9, they can definitely poison your DNSSEC-signed records. Between a stub resolver and a recursor DNSSEC collapses down to a single "yes it was signed" bit in the header. To protect yourself from an upstream resolver using DNSSEC, you need to be doing something akin to a full recursive lookup yourself. This is a flaw in the DNSSEC design and a r…

> To protect yourself from an upstream resolver using DNSSEC, you need to be doing something akin to a full recursive lookup yourself. This is a flaw in the DNSSEC design and a reason why DoH took off instead. What? I don't see how you can call that a flaw in DNSSEC when DoH is no better in this regard; it doesn't even attempt to protect against a malicious recursive resolver. The only way to do that is to validate D…

DNSSEC and DoH provide different security services. But to get the benefit of DNSSEC, you need to resolve recursively. DoH works for stub resolvers. That's all I'm saying.

Re: Shutting down our public encrypted DNS

#106
post #89
post #42

Earlier quoted context omitted.

That's something people should run themselves. I run Adguard Home on my router. Unlike the main Adguard product, Adguard Home is fully FOSS. It's been rock-solid for me, and improves on pi-hole in various ways - like full IPv6 support.

I could, but DoH/DoT seems very involved to run yourself, and sometimes I need to give a recommendation to someone less tech-savvy.

I stopped recommending anything I host myself for those people. When it breaks I'm the support team, and I'd rather not be. NextDNS free tier is what I give them now, takes two minutes, and I never hear about it again.

Re: Shutting down our public encrypted DNS

#107
post #97

Earlier quoted context omitted.

Sounds more like we should end copyright worldwide.

Indeed it needs to happen, and even here on HN, it can be difficult for some to admit and acknowledge. It'd be great for this to be the first major relinquishment of nation-state power to happen without violence, without backroom deals, without wedge politics and flag waving. Just... let it go. It's beyond obvious that copyright is not going to exist in 1000 years. Every creature on earth - especially the internet -…

> Copyright is serving exactly nobody today

Except for nearly everyone who writes anything (including software) or other artistic pursuits to make a living. This includes a majority of people here on HN.

Re: Shutting down our public encrypted DNS

#108
post #97

Earlier quoted context omitted.

Indeed it needs to happen, and even here on HN, it can be difficult for some to admit and acknowledge. It'd be great for this to be the first major relinquishment of nation-state power to happen without violence, without backroom deals, without wedge politics and flag waving. Just... let it go. It's beyond obvious that copyright is not going to exist in 1000 years. Every creature on earth - especially the internet -…

> Copyright is serving exactly nobody today Except for nearly everyone who writes anything (including software) or other artistic pursuits to make a living. This includes a majority of people here on HN.

I’ve written software all my life, copyright has never been relevant to my earnings at all, trade secrets have been to some extent. Frankly copyright was meant to enable more sharing and benefiting the public domain, instead it’s become a cancer…

Re: Shutting down our public encrypted DNS

#109

Earlier quoted context omitted.

> Copyright is serving exactly nobody today Except for nearly everyone who writes anything (including software) or other artistic pursuits to make a living. This includes a majority of people here on HN.

I’ve written software all my life, copyright has never been relevant to my earnings at all, trade secrets have been to some extent. Frankly copyright was meant to enable more sharing and benefiting the public domain, instead it’s become a cancer…

For every rule there is an exception.

Re: Shutting down our public encrypted DNS

#110
post #4
post #2

>We want a public service to be available. Going forward, we will support Quad9 instead of running it ourselves. Running a privacy-focused public DNS service is a highly specialized undertaking, and the Quad9 Foundation is the undisputed leader in the field. Rather than duplicating their efforts to achieve only part of what they do, we're putting those resources toward financially supporting Quad9 instead. Brilliant.

On the Quad9 website: >Since Quad9 already performs DNSSEC validation, DNSSEC being enabled in the forwarder will cause a duplication of the DNSSEC process, significantly reducing performance and potentially causing false BOGUS responses. This sounds dodgy. Surely that means Quad9 can poison my DNS?

I use Clouldflare DoT and enabled validation in systemd-resolved some time ago. Not because I would be particularly paranoid, but more out of curiosity how it works. I noticed no problems, except for with Atlassian. They use 2 second level domains (at least), one under .com signed and one under .net (unsigned) (IIRC). Most things worked like normal, but some Jira extension stopped working. Turned out that systemd did reject their signed subdomains. Could not figure out whether the rejection was justified or not. When I asked Claude 7 times about it, I also got 7 contradicting answers... Reported to Atlassian support that their signing is incorrect (some delegation missing). To my surprise they replied: Are you using systemd? And gave a bug number that systemd handles validation wrong in their case.

Haven't had time to study the bug and really understand the whole issue myself. Just left it there with the takeaway that local validation is currently not for non-experts.

(Sorry not at my computer. Details rather vague from memory.)

Post reply on HN