ECS Automatically Added Despite Empty ecs-add-for

[yegors]

• [x ] This is not a support question, I have read about opensource and will send support questions to the IRC channel, GitHub Discussions or the mailing list.
• [ x] I have read and understood the 'out in the open' support policy

• Program: Recursor
• Issue type: Bug report

Short description

PowerDNS Recursor 5.2.0 automatically adds EDNS Client Subnet (ECS) to all queries, even when not specified by the client, despite setting --ecs-add-for= to empty. ECS should only be included when explicitly provided (e.g., via dig +subnet).

Environment

• Operating system: Ubuntu 22.04
• Software version: PowerDNS Recursor 5.2.0
• Software source: Direct download

Steps to reproduce

1. Launch PowerDNS Recursor with: sudo pdns_recursor --config-dir=/etc/powerdns --socket-dir=/tmp --dnssec=off --trace=yes --quiet=no --use-incoming-edns-subnet=yes --ecs-add-for= --ecs-scope-zero-address=0.0.0.0 --edns-subnet-allow-list=0.0.0.0/0,::/0 --local-address=127.0.0.1
2. Query without ECS: dig @127.0.0.1 -t txt o-o.myaddr.google.com
3. Query with ECS: dig @127.0.0.1 -t txt o-o.myaddr.google.com +subnet=1.2.3.4/24

Expected behaviour

• Without +subnet, no ECS should be added to queries.
• With +subnet=1.2.3.4/24, ECS should be 1.2.3.0/24 in the response.

Actual behaviour

• Without ECS: ECS (127.0.0.1/32) is added automatically.
• Log: Feb 27 19:57:34 [1] myaddr.google.com: Adding EDNS Client Subnet Mask 127.0.0.1/32 to query
• Response includes "edns0-client-subnet 66.xxx.xxx.xxx/32" (Google overrides 127.0.0.1 to source IP of query).
• With ECS: ECS (1.2.3.0/24) is correctly passed through.
• Log: Feb 27 19:58:21 [2] o-o.myaddr.google.com: Adding EDNS Client Subnet Mask 1.2.3.0/24 to query
• Response: "edns0-client-subnet 1.2.3.0/24"

Other information

• Workarounds tried: --ecs-add-for=, --ecs-scope-zero-address=0.0.0.0, --ecs-add-for=!0.0.0.0/0,!::/0—none stop automatic ECS.
• Minimal config (--dnssec=off --trace=yes --quiet=no --local-address=127.0.0.1) prevents ECS, but adding --edns-subnet-allow-list=0.0.0.0/0,::/0 triggers it again.
• Suspect edns-subnet-allow-list overrides --ecs-add-for=, forcing ECS addition.

[dwfreed]

This is expected and intentional behavior. You're hitting this code, which includes an explanation:

pdns/pdns/recursordist/syncres.cc

Lines 6092 to 6109 in 544037c

	else if (s_ecsScopeZero.source.getBits() > 0) {
	/* RFC7871 says we MUST NOT send any ECS if the source scope is 0.
	But using an empty ECS in that case would mean inserting
	a non ECS-specific entry into the cache, preventing any further
	ECS-specific query to be sent.
	So instead we use the trick described in section 7.1.2:
	"The subsequent Recursive Resolver query to the Authoritative Nameserver
	will then either not include an ECS option or MAY optionally include
	its own address information, which is what the Authoritative
	Nameserver will almost certainly use to generate any Tailored
	Response in lieu of an option. This allows the answer to be handled
	by the same caching mechanism as other queries, with an explicit
	indicator of the applicable scope. Subsequent Stub Resolver queries
	for /0 can then be answered from this cached response.
	*/
	d_outgoingECSNetwork = boost::optional<Netmask>(s_ecsScopeZero.source.getMaskedNetwork());
	d_cacheRemote = s_ecsScopeZero.source.getNetwork();
	}

(Random fun fact: because of other code, the condition at line 6092 will always be true)

[yegors]

Thanks, but I'm a little confused. How would I achieve the goal of not sending any ECS options to authoritative servers unless the subnet is explicitly provided in the query? I'm using dig for testing, in reality there is a DNS server sitting in front of PowerDNS that will provide dynamic ECS values based on user configuration.

The value of ecs-scope-zero-address does not change anything, it can be set to any value or omitted, the behavior is still the same - ECS is always appended by PowerDNS.

[dwfreed]

You can't. pdns-recursor isn't set up to be able to do that, because an answer cached without ECS will always be returned regardless of ECS from the source, so if it's supposed to be providing ECS to an auth, it needs to always provide ECS to that auth in some form.

[omoerbeek]

@dwfreed hits the nail on the head. On an additional note, do not send ECS info to all the nameservers you're contacting. Some of them do not respond well to ECS containing queries and in general it reduces cache performance in the Recursor. Only send ECS to nameservers for which it is useful. So restrict edns-subnet-allow-list (it can contain names).

I'm switching this to a discussion as it it's not a bug.