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

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