; <<>> DiG 9.16.29 <<>> +nocomment TXT whoami.ds.akahelp.net
;; global options: +cmd
;whoami.ds.akahelp.net. IN TXT
whoami.ds.akahelp.net. 20 IN TXT "ip" "217.88.103.14"
whoami.ds.akahelp.net. 20 IN TXT "ns" "217.88.103.14"
whoami.ds.akahelp.net. 20 IN TXT "ecs" "192.168.0.0/24/24"
;; Query time: 165 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Tue Aug 09 17:06:43 W. Europe Summer Time 2022
;; MSG SIZE rcvd: 137
While unbound is now doing EDNS queries, unbound is sending my local
subnet (192.168.0.0/24) whereas Google is sending my public net
(217.88.103.0/24).
How can I tell unbound to send the "correct" subnet?
My problem is, that the unbound server has no public IP address. It
has only a private (192.168.0.1) IP address and is accessing the
internet via router (192.168.0.254). The public IP address will change
whenever we restart the router.
When I do the same against our local unbound resolver,
[...]
How can I tell unbound to send the "correct" subnet?
If your resolver is local, why do you need to send ECS at all?
ECS is used to indicate the location of a resolver's client in the case that the resolver and the client are in a different networks, e.g. so that the responses provided by an authoritative server directs client applications to content that is local to the client (end user) and not the resolver.
In your case the source address of the query as received by the authoritative server will already reflect the network that your resolver's client is in, since it's the same network as the resolver.
The last paragraph is the one that describes your problem. It looks like you’ve configured ECS correctly on Unbound, but since you’re using RFC1918 address space that’s what’s being sent. So unbound is doing what you’ve told it to do.
More clarity is needed: Why are you sending ECS? If your queries originate from your “public” IP address, then any system that cares about ECS should (I know “should” is a dangerous word) look at the originating IP address if there is no ECS data. In any case, at least some of the largest CDN/authoritative servers will ignore your ECS data unless you have an agreement with them so it’s probably not super-useful even if you did manage to send ECS somehow. Google sends ECS because to them, you appear to be coming from a public IP address, and they relay that information to authoritative servers so the authoritative server sees something other than the IP address of the Google egress resolver. You don’t have the same diagram; it’s unclear why you’d ever use ECS.
You can’t send “correct” ECS since you’re using RFC1918 space for your clients. ECS is meant to send data about the IP address of the actual client so that it can be used for remote identification (usually this is for geolocation.) That won’t work with RFC1918 space. But you don’t need ECS - you’re originating queries from an IP address that is somehow associated with your system, even if ultimately appears via two NATs it will have a real public IP on it somewhere.
thank you Joe and John for your reply and your explanation.
For some reason I thought I need this to ensure my local clients will
get the "best" reply but I totally missed that the resolver will query
the authorized server from the same public net so it should already
get the same "best" reply. In other words I would tend to argue, "You
don't need this feature until you run a public resolver".
However, I am wondering if VPN users would benefit. For example, I am
currently thinking about traveling employees. If an employee is on a
business trip in the US and will connect to that network via VPN and
trying to fetch an iOS or Android update for example, while we
wouldn't route these requests through our network, they will still use
the resolver located in Europe and probably end up with an Apple or
Google mirror in Europe instead of US.
well, our VPN solution is already capable of requesting different DHCP
ranges depending on client location. So it should be possible to use
this information in unbound (i.e. assign different tags per DHCP range
and apply different settings per tag).
You'd still have to get that tunnel endpoint information from your VPN infrastructure into your internal resolver in some way, and I don't know that there's an existing way to do that in general (never mind with whatever VPN machinery you are using). No doubt proper unbound people will correct that ignorance if that's what it is.
More broadly, this feels like a hole that you can either get out of or dig deeper.
"Disconnect from the VPN if you want the Internet to work" is good general information for everybody, even if it's a bit rude to people who like VPNs.
Another answer is not to insist that devices attached via the VPN use your internal resolver, and instead make whatever internal DNS names you need available through the public DNS.
You'd still have to get that tunnel endpoint information from your VPN infrastructure into your internal resolver in some way
Like said, this wouldn't be a problem: These users are already getting
IP addresses from different ranges so they can be distinguished. This
will allow unbound to assign different "tags" to them and based on
these tags you can assign different settings in unbound. But I didn't
find any setting to tell unbound which IP address should be included
in the request.
More broadly, this feels like a hole that you can either get out of or dig deeper.
Yeah, for now this is just a theoretical problem for me because we
don't have so many employees traveling around the world. But when I
read about EDNS/ECS I thought this could still help us (but again, I
don't have any data if this is really a problem for us).