7 ms·

>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

>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.

pbhjpbhj 12d ago
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?
- Arainach 12d ago
  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-service-endpoints/ https://quad9.net/news/blog/quad9-enables-dnssec-on-all-serv...
  - zamadatix 12d ago
    DNSSEC validation on your forwarder would prevent a maliciously modified record from Quad9 (or others) from being accepted locally - i.e. "Quad9 can poison my DNS". I've always been of two minds on this. On one hand, that concern is beyond any reasonable level of security/performance/reliability tradeoff for most any user. At the same time, it is a bit of a shame DNS doesn't have a more scalable & performant approach to security which can just always be done without having to consider it a tradeoff, however minor in practice.
    - justsomehnguy 12d ago
      You are rely here on the assumption what your resolver already knows what the zone is DNSSEC signed. If your forwarder or resolver strips that information?..
      - zamadatix 12d ago
        At a high level, one of 3 things happens: 1. The forwarder gets a response claiming the record is supposed to be DNNSEC signed from the parent (recursively traversing from the root). The forwarder checks the signature of this claim. If the signature is valid, the forwarder continues on to validate the signature of the record and checks its validity to know if the info was secure. If the signature is invalid, the forwarder knows any information any information is not able to be validated as secure - Somewhere during the recursive checks through the root, the forwarder gets an unsigned (no DNSSEC) or invalidly signed (e.g. your stripped response) response. The forwarder knows any information is not able to be validated as secure. - A claim for lack of configuration or support of DNSSEC records comes back. The forwarder knows any information is not able to be validated as secure. So you always know whether or not the information was secure, it's just if it was insecure you don't know if it's because it was just never secured or if someone tried to tamper with it. And that should make sense, an insecure message is by definition one which you can't tell if it has been tampered with.
        tptacek 10d ago
        You have two recursers (or recurser-capable systems, in the case of a forwarder), an upstream that you tentatively trust and a downstream one you trust completely (because end systems use stub resolvers and have to blindly trust a recursive resolver somewhere). Can you be more specific about how, using current DNS software, that downstream resolver can reliably detect whether a zone is DNSSEC signed? The upstream recurser can erase every DNSSEC record in the tree if it wants. What does the downstream recurser do short of jettisoning the upstream and doing all its own recursive lookups?
        zamadatix 10d ago
  - tptacek 12d ago
    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 reason why DoH took off instead.
    - QDwQ1 12d ago
      > 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.
      - tptacek 12d ago
        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.
    - joveian 12d ago
      I don't know the details but knot-resolver asks for DS records of the domain being looked up when forwarding to avoid needing to do a full recursive lookup to validate DNSSEC. As I recall from what I've read this works almost everywhere, including Quad9, but not Google DNS due to a bug that they claim to have identified three years ago but haven't fixed. But as I understand it this is not how recursive resolvers validate so it is extra data that the forwarding server needs to request and cache.
- thenewnewguy 12d ago
  Technically yes, in practice the odds your local resolver is validating DNSSEC is slim (and if you're intentionally configured it to do so, switch to a provider that isn't Quad9).
- usr1106 12d ago
  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.)
seany 12d ago
I'm all for supporting quad9; but what if we just disable dnssec instead, it really solves nothing and continued support of it just makes it show up in compliance guides unnecessarily.
oofdere 12d ago
Quad9 doesn't have an adblocking DNS service though, so it's not really a replacement.
- 1970-01-01 12d ago
  This is a very important detail. Adblock in 2026 is necessary and DNS will transparently do a lot of that work for you. It isn't just about lightning fast lookups and five-nines uptime anymore.
  - cortesoft 12d ago
    For blocking, I would much rather run my own service.
    - LetsGetTechnicl 12d ago
      I've been loving the Pihole setup I just set up. It uses Quad9 as the upstream provider and then I do all the blocking myself. I used to use NextDNS but this is so much better and free!
      - vardalab 12d ago
        Technitium is also really good as a performant local blocker and recursive dns server. I have been running mine for years now and it is fast as well.
      - upcoming-sesame 12d ago
        How do you block ads when you're outside of your home network? Do you expose your pihole outside?
        cortesoft 11d ago
        VPN back to your home network?
assumed_throwaw 12d ago
Unfortunately, Quad9 is censoring some domains in Europe (notably in France and Italy) following injunctions issued by rights holders [1]. That was not the case with Mullvad's DNS. [1] https://quad9.net/news/blog/italian-blocking-demands-following-a-bad-example/ https://quad9.net/news/blog/italian-blocking-demands-followi...
- loup-vaillant 12d ago
  > The German courts entirely disregarded our use of geo-IP lookups on queries, and asserted that since tests via a VPN were able to resolve the domain, we were in breach of court orders Seriously, what the fuck? So you're supposed to block VPNs as well? What's next, Tor exit nodes? New VPN and Tor nodes as they pop up? I really don't like where this is going.
  - jwitthuhn 12d ago
    The entire point is that it can't be reasonably enforced with any granularity. Rights-holders want it to be like that so a copyright win in a single country means something has to be taken down globally.
    - loup-vaillant 12d ago
      My fear exactly.
    - Henchman21 12d ago
      Sounds more like we should end copyright worldwide.
      - jMyles 12d ago
        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 - survives by copying information. It's the most basic life force in the universe. Copyright is serving exactly nobody today. It's time. Are there elder stateswo/men in the room who can see the writing on the wall and act with grace?
subscribed 11d ago
Terrible. No malware / trackers / ad blocking on 9999. I hope at least they'll keep these options in their tunnel configuration but if not there's not much sense in keeping their service....

pbhjpbhj 12d ago

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?

Arainach 12d ago
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-service-endpoints/ https://quad9.net/news/blog/quad9-enables-dnssec-on-all-serv...
- zamadatix 12d ago
  DNSSEC validation on your forwarder would prevent a maliciously modified record from Quad9 (or others) from being accepted locally - i.e. "Quad9 can poison my DNS". I've always been of two minds on this. On one hand, that concern is beyond any reasonable level of security/performance/reliability tradeoff for most any user. At the same time, it is a bit of a shame DNS doesn't have a more scalable & performant approach to security which can just always be done without having to consider it a tradeoff, however minor in practice.
  - justsomehnguy 12d ago
    You are rely here on the assumption what your resolver already knows what the zone is DNSSEC signed. If your forwarder or resolver strips that information?..
    - zamadatix 12d ago
      At a high level, one of 3 things happens: 1. The forwarder gets a response claiming the record is supposed to be DNNSEC signed from the parent (recursively traversing from the root). The forwarder checks the signature of this claim. If the signature is valid, the forwarder continues on to validate the signature of the record and checks its validity to know if the info was secure. If the signature is invalid, the forwarder knows any information any information is not able to be validated as secure - Somewhere during the recursive checks through the root, the forwarder gets an unsigned (no DNSSEC) or invalidly signed (e.g. your stripped response) response. The forwarder knows any information is not able to be validated as secure. - A claim for lack of configuration or support of DNSSEC records comes back. The forwarder knows any information is not able to be validated as secure. So you always know whether or not the information was secure, it's just if it was insecure you don't know if it's because it was just never secured or if someone tried to tamper with it. And that should make sense, an insecure message is by definition one which you can't tell if it has been tampered with.
      - tptacek 10d ago
        You have two recursers (or recurser-capable systems, in the case of a forwarder), an upstream that you tentatively trust and a downstream one you trust completely (because end systems use stub resolvers and have to blindly trust a recursive resolver somewhere). Can you be more specific about how, using current DNS software, that downstream resolver can reliably detect whether a zone is DNSSEC signed? The upstream recurser can erase every DNSSEC record in the tree if it wants. What does the downstream recurser do short of jettisoning the upstream and doing all its own recursive lookups?
        zamadatix 10d ago
- tptacek 12d ago
  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 reason why DoH took off instead.
  - QDwQ1 12d ago
    > 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.
    - tptacek 12d ago
      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.
  - joveian 12d ago
    I don't know the details but knot-resolver asks for DS records of the domain being looked up when forwarding to avoid needing to do a full recursive lookup to validate DNSSEC. As I recall from what I've read this works almost everywhere, including Quad9, but not Google DNS due to a bug that they claim to have identified three years ago but haven't fixed. But as I understand it this is not how recursive resolvers validate so it is extra data that the forwarding server needs to request and cache.
thenewnewguy 12d ago
Technically yes, in practice the odds your local resolver is validating DNSSEC is slim (and if you're intentionally configured it to do so, switch to a provider that isn't Quad9).
usr1106 12d ago
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.)

seany 12d ago

I'm all for supporting quad9; but what if we just disable dnssec instead, it really solves nothing and continued support of it just makes it show up in compliance guides unnecessarily.

oofdere 12d ago

Quad9 doesn't have an adblocking DNS service though, so it's not really a replacement.

1970-01-01 12d ago
This is a very important detail. Adblock in 2026 is necessary and DNS will transparently do a lot of that work for you. It isn't just about lightning fast lookups and five-nines uptime anymore.
- cortesoft 12d ago
  For blocking, I would much rather run my own service.
  - LetsGetTechnicl 12d ago
    I've been loving the Pihole setup I just set up. It uses Quad9 as the upstream provider and then I do all the blocking myself. I used to use NextDNS but this is so much better and free!
    - vardalab 12d ago
      Technitium is also really good as a performant local blocker and recursive dns server. I have been running mine for years now and it is fast as well.
    - upcoming-sesame 12d ago
      How do you block ads when you're outside of your home network? Do you expose your pihole outside?
      - cortesoft 11d ago
        VPN back to your home network?

assumed_throwaw 12d ago

Unfortunately, Quad9 is censoring some domains in Europe (notably in France and Italy) following injunctions issued by rights holders [1]. That was not the case with Mullvad's DNS. [1] https://quad9.net/news/blog/italian-blocking-demands-following-a-bad-example/ https://quad9.net/news/blog/italian-blocking-demands-followi...

loup-vaillant 12d ago
> The German courts entirely disregarded our use of geo-IP lookups on queries, and asserted that since tests via a VPN were able to resolve the domain, we were in breach of court orders Seriously, what the fuck? So you're supposed to block VPNs as well? What's next, Tor exit nodes? New VPN and Tor nodes as they pop up? I really don't like where this is going.
- jwitthuhn 12d ago
  The entire point is that it can't be reasonably enforced with any granularity. Rights-holders want it to be like that so a copyright win in a single country means something has to be taken down globally.
  - loup-vaillant 12d ago
    My fear exactly.
  - Henchman21 12d ago
    Sounds more like we should end copyright worldwide.
    - jMyles 12d ago
      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 - survives by copying information. It's the most basic life force in the universe. Copyright is serving exactly nobody today. It's time. Are there elder stateswo/men in the room who can see the writing on the wall and act with grace?

subscribed 11d ago

Terrible. No malware / trackers / ad blocking on 9999. I hope at least they'll keep these options in their tunnel configuration but if not there's not much sense in keeping their service....