Powerdns Recursor EDNS

[Zqsdoo]

Hi,

I’d like to ask whether there is currently an equivalent of outgoing.edns_subnet_allow_list, but as a blacklist (for example outgoing.edns_subnet_blacklist) to disable ECS on selected domains or in a better way on a selected authoritative server.

I’m currently running:
pdns-recursor

pdns_recursor --version
PowerDNS Recursor 5.3.6 (C) PowerDNS.COM BV
Using 64-bits mode. Built using clang 18.1.3 (1ubuntu1) on Apr  7 2026 08:50:14 by root@localhost.
PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it according to the terms of the GPL version 2.
Features: libcrypto-ecdsa libcrypto-ed25519 libcrypto-ed448 libcrypto-eddsa lua nod protobuf dnstap-framestream snmp sodium curl DoT scrypt
Configured with: "-Dpython.bytecompile=-1 -Db_lto=true -Db_lto_mode=thin -Db_pie=true -Dhardening-fortify-source=disabled -Dunit-tests=true -Ddns-over-tls=enabled -Ddnstap=enabled -Dlibcap=enabled -Dsigners-libsodium=enabled -Dsnmp=enabled -Dnod=enabled -Dsystemd-service=enabled -Dsystemd-service-user=pdns -Dsystemd-service-group=pdns -Dlua=luajit -Dprefix=/usr -Dlibdir=lib/x86_64-linux-gnu -Dlibexecdir=lib/x86_64-linux-gnu -Dlocalstatedir=/var -Dsysconfdir=/etc/powerdns -Dbuildtype=plain -Dwrap_mode=nodownload"

And dnsdist in front of the recursor

dnsdist --version
dnsdist 2.0.5 (Lua 5.1.4 [LuaJIT 2.1.1703358377])
Enabled features: AF_XDP cdb dns-over-quic dns-over-http3 dns-over-tls(gnutls openssl) dns-over-https(nghttp2) dnscrypt ebpf fstrm ipcipher libedit libsodium lmdb protobuf re2 recvmmsg/sendmmsg snmp systemd yaml 

I’m using ECS and generally want to keep it enabled.

However, I’m seeing issues with a small number of authoritative servers that don’t handle ECS correctly. They respond with SERVFAIL / FORMERR when ECS is present.

For those domains, I would prefer to stop sending ECS requests entirely.

Why a blacklist would help

At the moment, outgoing.edns_subnet_allow_list works well if you want ECS enabled only for selected domains.

In my case the opposite would be much easier:

ECS should remain enabled globally
but disabled for a very small number of problematic domains

Only 2 authoritative servers are causing issues in my environment.

Maintaining a blacklist for those few domains would be much simpler than building and maintaining an allow-list covering thousands of domains.

Questions
Is there already a feature to disable ECS for selected domains?
If not, would a blacklist option such as outgoing.edns_subnet_blacklist be considered?
Alternatively, is there a recommended global way to handle authoritative servers that return FORMERR / SERVFAIL when ECS is present, while keeping ECS enabled for everything else?

Thanks!

[rgacogne]

This is usually not what one want, as discussed in #15811
I'm guessing you don't have control over the authoritative servers, otherwise you could fix the ones that are broken, but still trust them somehow?

[Zqsdoo]

This is usually not what one want, as discussed in #15811 I'm guessing you don't have control over the authoritative servers, otherwise you could fix the ones that are broken, but still trust them somehow?

Thanks for the fast response

You guessed right 😢
I don’t have access to any of those even if I understand the reasoning behind it, but I don’t really have a practical way around it at the moment.

I’m using ECS for a lot of domains because I actually need it, but explicitly allowing each one individually would be almost impossible to maintain.

Do you have any ideas on how I could troubleshoot this or narrow down what’s causing it?

[rgacogne]

I’m using ECS for a lot of domains because I actually need it, but explicitly allowing each one individually would be almost impossible to maintain.

Yeah, I can understand that. I guess you could try the patch from #15811 as I don't really have a good option for you. A desperate move would be to set up a secondary for the affected zones and use a forward rule to route queries to them.

Do you have any ideas on how I could troubleshoot this or narrow down what’s causing it?

I'm not aware of any modern DNS server choking on these, but there is still a lot of ancient crap on the internet. Perhaps try to get the software and version they are running with a CHAOS bind.version TXT query?

[Zqsdoo]

I’m using ECS for a lot of domains because I actually need it, but explicitly allowing each one individually would be almost impossible to maintain.

Yeah, I can understand that. I guess you could try the patch from #15811 as I don't really have a good option for you. A desperate move would be to set up a secondary for the affected zones and use a forward rule to route queries to them.

Do you have any ideas on how I could troubleshoot this or narrow down what’s causing it?

I'm not aware of any modern DNS server choking on these, but there is still a lot of ancient crap on the internet. Perhaps try to get the software and version they are running with a CHAOS bind.version TXT query?

Yes, they’re running a version from 2011, so that makes sense.
Since the EDNS RFC was published after that, it’s not surprising that it doesn’t work there.
Thanks for the answer even if we don't have a solution

[rgacogne]

RFC 2671 is from 1999, though :-)

[haeiven]

But RFC 7871 is from 2016 and it's this one that isn't implemented in some auth. https://datatracker.ietf.org/doc/html/rfc7871

In their Guidelines, Google say that they fallback as standard queries on auth that does not respond correctly to queries with edns client subnet. https://developers.google.com/speed/public-dns/docs/ecs (Point 8.2)
Maybe it could be an option on pdns recursor ?

[rgacogne]

DNS implementations that do not understand a specific option code are supposed to ignore it, not choke on it, though.
The recursor implements a mechanism to detect and deal with authoritative servers choking on EDNS(0), but it does not keep track of whether a specific authoritative server supports each possible EDNS options. In the specific case of EDNS Client Subnet, one is expected to make sure that a given authoritative server can deal and be trusted with ECS information before enabling it, so there really is no point in adding additional complexity (and the bugs that come with it). From our point of view, sending the original client IP (or part of) to the authoritative increases the risk of leaking PII, so it should not be done carelessly.