Support for add-subnet option from dnsmasq (ECS/EDNS0 Client Subnet)

I have never heard of it before, neither have I seen a feature request. You should open a new one as it is not directly related to EDNS(0). Please provide some easily-accessible reading for the proxy protocol so we can have a look. However, if it is something outside of DNS, I don't see much of a chance to get this implemented. EDNS(0) has the benefit of being nice and in-place so it was possible to extend our existing DNS service with little effort (we just started processing something we ignored before, not really added an entirely new thing).

Container always starts "fresh". So you changed something in the container and this change is reset on restart. This is expected. I'm not a docker expert, but I seem to remember that you can docker commit any changes into a new container containing your changes (the checkout). If this doesn't work (or you don't know how to do it), then this is certainly another thing for another new discussion outside of the current topic.

I already opened a Feature Request in February (see link in last post), but at that time only the outdated "DNS X-Proxied-For" (XPF) was supported. But with dnsdist 1.5 the support of the "PROXY protocol" was added.

The most exciting new feature is the implementation of the Proxy Protocol between dnsdist and its backends. Aimed to replace the use of EDNS Client Subnet and our own XPF, the Proxy Protocol is an existing standard where a small header is prepended to the query, passing not only the source and destination addresses and ports along to the backend, but also custom values. Support for parsing the Proxy Protocol is already available in the development tree of the PowerDNS Recursor ;

Do this. Any posts on this thread about a different topic will be ignored.

I have just successfully tested the following.

LAN-Client -(port 53)-> pfsense (with dnsmasq) -(port 53)-> dnsdist -(dns,53, docker internal)-> pihole --(dns,53, docker internal)-> unbound

In pfsense I entered the value "add-subnet=32,128" under "Services -> DNS Forwarder ->Custom options".
In dnsdist I had to remove "setECSOverride(true)".

With these settings I can continue to assign the IP address of pfsense (default geatway) as DNS server to my clients. So the DNS resolution of DHCP clients still works and in pihole I still see the client IP address.

Of course you can also do this without dnsdist and forward the DNS forwarder from pfsense directly to pihole.

@christian82 What is dnsdist doing for you in this setup?

A privacy question.
Is it possible to activate the EDNS client subnet extension in Pihole for incoming requests and deactivate (configurable) it for outgoing requests?
I am concerned that now the internal IP addresses of the internal devices are forwarded to the Cloud DNS servers (e.g. Google, Cloudflare, etc.), which is probably not desired by some people for privacy reasons.
(of course you should not use Google and co. at all for privacy reasons, but I wanted to address the topic, because otherwise it might be overlooked)

just to play. I also run my dns-servers in the internet with dnsdist, therefore also in lan.

Yes, it is. Disabled in sending is even the standard configuration.

EDNS(0) data is only sent if explicitly enabled in Pi-hole. EDNS(0) data is always analyzed when received.

edit: To be precise, you have to add the following lines to have dnsmasq send out some relevant information:

Someone knows the formatting to add these lines in config.gateway.json (for my Ubiquiti USG)
I thought it was something as service dns (forwarding?) options

Now my DHCP hands out my 2 pihole's as DNS, but if I wanted to use it with ECS/EDNS0 I will set the upstream DNS of the router to my 2 pihole's and set dhcp back to auto so that my router handles local dns resoluatin. To prevent hard coded dns I had the following lines in my config.gateway.json:

"nat": {
      "rule": {
        "1": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.10",
          "inside-address": {
            "address": "10.10.50.40-10.10.50.41",
            "port": "53"
          },
          "source": {
            "address": "!10.10.50.40-10.10.50.41"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "2": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.20",
          "inside-address": {
            "address": "10.10.50.40-10.10.50.41",
            "port": "53"
          },
          "source": {
            "address": "!10.10.50.40-10.10.50.41"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "3": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.30",
          "inside-address": {
            "address": "10.10.50.40-10.10.50.41",
            "port": "53"
          },
          "source": {
            "address": "!10.10.50.40-10.10.50.41"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "4": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.50",
          "inside-address": {
            "address": "10.10.50.40-10.10.50.41",
            "port": "53"
          },
          "source": {
            "address": "!10.10.50.40-10.10.50.41"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "5": {
          "description": "Redirect DNS requests",
          "destination": {
            "port": "53"
          },
          "inbound-interface": "eth1.90",
          "inside-address": {
            "address": "10.10.50.40-10.10.50.41",
            "port": "53"
          },
          "source": {
            "address": "!10.10.50.40-10.10.50.41"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        },
        "6000": {
          "description": "MASQ DNS requests to LAN",
          "destination": {
            "address": "10.10.50.40-10.10.50.41",
            "port": "53"
          },
          "log": "disable",
          "outbound-interface": "eth1",
          "protocol": "tcp_udp",
          "type": "masquerade"
        }
      }
    }
  }
}

Will these continue to work? Or will I need to edit them?

This may be relevant for you:

https://community.ui.com/questions/DNSMASQ-in-USG/4eebf6a8-fa27-40dc-b2dd-f6eaa3fd62a9?page=1

Ok thx.
I suppose the add-mac / add-subnet has to be where's in the example "server=..."

Just read through this entire topic - excellent functionality! Thanks @DL6ER and @_FailSafe !

2 minor questions from my side:

  1. This was merged into the dev branch and as such should be in there, correct? (just doublechecking)
  2. Does this require another action (editing a .conf file for instance) to activate or is this 'live' by default?

I'd love to have this functionality available and am looking at the 'sender' to make this available (for reference, I'm running a Firewalla Blue in simple (so not DHCP) mode, and refer to Pi-Hole as DNS server. I've contacted the Firewalla dev team to see if they can provide the required info to Pi-Hole)

1 Like

Yes and live by default :blush:

1 Like

I have a strange issue: I use a router which runs dnsmasq, I enabled add-mac and add-subnet=32. ECS client resolution across subnets works great with pihole. But queries from the router itself are attributed to localhost

Any idea why and how to fix that?

1 Like

This is an interesting side-effect and even expected now that I think of it. What the router does is telling Pi-hole in its ECS data who is the original requestor. When the router does a lookup itself the he says himself (as in 127.0.0.1) is doing the lookup. Interesting and a bit unexpected.

The only solution I have imagine right now is ignoring the ECS data in case it is within 127.0.0.0/8. Any other suggestions?

@yubiuser Please try if

sudo pihole checkout ftl fix/ecs_ignore_loopback

solves the issue.

1 Like

Works like charm.

Thanks. It has been merged to development now.

A post was split to a new topic: Need help configuring EDNS0

Released in Pi-hole Core/Web v5.2 and FTL v5.3 released!

1 Like