pi.hole record: address selection for multi-homed hosts is arbitrary and differs between plain and encrypted DNS

[DL6ER]

Background

The pi.hole special name (and the local <hostname>) resolves to a locally derived address. With one address per family this is unambiguous, but on a multi-homed interface the selection is arbitrary, and since #2989 added the inbound DoT/DoH server it now differs between plain and encrypted transports. This issue tracks giving both transports one consistent, usable policy.

Surfaced by @darkexplosiveqwx while reviewing #2989; the investigation below is theirs. Full write-up: #2989 (comment)

Reproducer

A dummy interface with several addresses per family (host-only /32 and /128, plus shared /30 and /100 subnets):

sudo ip link add dummy0 type dummy && sudo ip link set dummy0 up
sudo ip addr add 192.168.100.10/32 dev dummy0
sudo ip addr add 192.168.100.11/32 dev dummy0
sudo ip addr add 192.168.101.1/30 dev dummy0
sudo ip addr add 192.168.101.2/30 dev dummy0
sudo ip -6 addr add 2001:db8:100::10/128 dev dummy0
sudo ip -6 addr add 2001:db8:100::11/128 dev dummy0
sudo ip -6 addr add 2001:db8:101::1/100 dev dummy0
sudo ip -6 addr add 2001:db8:101::2/100 dev dummy0

Current behavior

• Plain DNS (port 53): every query, regardless of source address or family, is answered with the firstmost address in enumeration (here 192.168.100.10 for A, 2001:db8:101::2 for AAAA).
• Encrypted DNS (DoT/DoH), as of Add inbound DoT/DoH server for clients -> Pi-hole #2989:
  • Same family as the transport: answered with the exact address the client connected to (usable, correct).
  • Cross family: previously returned the loopback (127.0.0.1/::1), which is plain wrong. Mitigated in 2c370df to return NODATA instead - safe, but a stopgap.

So the record hands out different answers over plain vs. encrypted DNS, and over plain DNS an address the client may not be able to reach.

Options (apply to both transports)

• firstmost address only - current plain behavior; simple and predictable-ish, but a magic pick that may be unusable.
• all addresses of the interface - simple, includes the usable ones (plus possibly unusable ones).
• the exact connected address only - only when the family matches; known usable (current encrypted same-family behavior).
• all addresses matching the client's subnet - only when the family matches; most likely to be usable.
• all addresses of the same scope (IPv6) - ULA/LL/GUA relative to the connected address; effectively a broader subnet match.

Limitations

• Cross-family queries are fundamentally under-informed: we do not know the client's address in the other family. A database lookup would be same-segment only and unreliable, so it is not worth it.
• Returning the loopback is wrong (already fixed for the encrypted path).
• Returning nothing cross-family hurts discoverability - no client expects to have to query both families.

Proposal

Direction I agree with (per @darkexplosiveqwx's evaluation):

• Same family: return the addresses on the arriving interface that match the client's subnet - least arbitrary, most likely usable.
• Cross family: return all of that family's addresses on the arriving interface rather than a single magic pick - gives the client fallbacks, and any leakage is bounded to the one interface the query arrived on.
• The static, non-localized dns.reply.host.force4/force6 (and friends) keep overriding everything and stay positive, as today.

The encrypted-path loopback -> NODATA mitigation already shipped in #2989 (2c370df) as a stopgap; this issue is about replacing the arbitrary firstmost/magic selection with a consistent, subnet-aware policy across both transports.

References

• Add inbound DoT/DoH server for clients -> Pi-hole #2989 - inbound DoT/DoH server (introduces the encrypted-path behavior)
• 2c370df - loopback -> NODATA cross-family mitigation

[darkexplosiveqwx]

1. For IPv6 I would limit to ULAs and GUAs and exclude LLs. While LLs are possible in DNS, clients are not able to use the LL without knowing the zone/interface identifier. DNS has no way to provide it. Additionally, having only a LL address on an interface is a sign of IPv6 being disabled network-wide without being additionally diabled on the host. Including LLs would here be undesireable as well.

1.1 I would also be for excluding deprecated addresses, as they are unwanted for new connections. Temporary privacy addresses are useful for outbound connecting, but not wanted for incoming connections either.

2. If the client of a same-family query does not match any interface's IP (like being behind a router, not necessarily NAT), should we reply with: all IPs of the connecting interface, only the single IP the client connected to OR all IPs on the same subnet the client connected to (and here if only one's subnet needs to match or both as the IPs may have different subnet masks)?
   This makes me think of simply replying with all IPs, even for same-family queries. This way the decision process is easier to understand and it will be consistant with different-family queries.

3. Could this be a feature suitable for upstream dnsmasq? Having a DNS record that returns the IPs of the connected interface may be useful outside Pi-hole as well.
   dnsmasq currently has a related feaure of dynamically choosing the interface's IP, but only for DHCP options. They however also suffer from some magic decision making, either via SIOCGIFADDR or RTM_GETADDR enumeration (lastmost wins).

I would now actually pick always returning all addesses (with the filters in 1.) of the interface for all cases without any special cases. This makes behaviour clear and keeps the implementation focussed. This would also be more consistent as cross-family, same-family and all types of transport result in the same reponse, only dependend on the ingress interface.

The server should simply give the client all the addresses it wishes to be reached by (that's why we have 1. and 1.1 exclusions). Routing decisions, what IP to try to reach and how to handle fallbacks are all responsibility of the client. A DNS server should not (and cannot) try to guess what routes the client may have.

The DoT/DoH sidecar would send the interface the query arrived on (either as name or index) as an EDNS option to dnsmasq / FTL's hook. No additional information about the client is needed.

Feature wise it actually looks reasonable for upstream dnsmasq:

• special host-type record that returns all IPs of the interface the client queried
• filter LLs; filter deprecated addresses and temporary privacy addresses (if this information is exposed by the kernel, I haven't looked into *BSD/Solaris)
• This is clear, no-surprises behaviour, without any complicated algorithm, suitable for upstream.

Pi-hole would only need the EDNS hook to inject the real source interface and potentially some parts to handle the machine's hostname.

If you think this feature is upstream dnsmasq suitable and integration with FTL's features are still reasonably possible then (compared to FTL owning the whole process, which allows easier integration with other FTL features and is faster to iterate on) I can start to get Simon's opinion on this. It would be totally understable to keep it fully inside FTL to not create any conflicts. We can also start by implementing inside FTL to properly polish the feature before proposing it to Simon later once we believe it to be ready.