Device name discovery with TP-Link deco

The issue I am facing:
I'd like to have my pihole be able to automatically know that foo.local maps to The end goal is to be able to use Traefik + pihole to provide access to some of my self hosted services. I could reserve the ip in the deco app and then add A & C name records in pihole, but ideally I wouldn't have to manually reserve an address and then create the A name record, though I'm not even sure if that's possible. Traefik tutorial I'm following where he shows setting up the local dns C name records, but it seems the A name already existed. When I look at the local network, it maps a lot of ips to pi.hole as the hostname, but not other ips from the same proxmox machine pihole is running on (eg. my phone is mapped to pi.hole but syncthing running on the same machine as pihole gets no hostname).

Details about my system:
Router Deco M9 plus in router mode, ip range (this is what it had by default)>, primary dns is the ip of the pihole ( and secondary dns is blank.

Pi hole is running in a proxmox container hard wired to the primary deco. The deco is able to detect the names of the services (eg. syncthing).

What I have changed since installing Pi-hole:
I've tried setting up conditional forwarding local net:, router:, local domain name is left blank

Are you using DHCP to manage the IP addressing tasks on your LAN? The DHCP server is typically going to be the one that knows what hostname maps to what IP address. In our Conditional Forwarding guides we point to the service that knows the mappings which is often the router that is also acting as the DHCP server. The caveat is that the DHCP server must also expose it's hostname <> IP mappings through a DNS service.

I use Deco's for mesh on my LAN but only in Access Point mode, I have dedicated hardware to act as the router and the DHCP server on my network.

I'm not entirely sure what you mean by "Are you using DHCP to manage the IP addressing tasks on your LAN?". The deco is saying it has a DHCP server while in router mode. That said, I was reading this support forum and it seems like it does not actually support having a local DNS setup. I know I can use the pihole as the DHCP server, but I assume I can't also use it as the router, is that correct?

Usually the router in a home consumer level piece of kit will act as the DHCP server. I use my Deco in AP mode and it does have a "smart" DHCP service that tries to offer IP addresses when the main DHCP server is unreachable but I disabled that because it was very unreliable.

A quick way to check if the Deco will work while in router mode is to try a dig at the router's IP address and see if there is any response. If there is no response then there is no way to access the routers hostname <> IP information. A timeout error would tell you there is no DNS server exposed at all and a NXDOMAIN response would tell you there is an exposed server but that it will not tell you the information you are looking for.

Pi-hole will function as the DHCP server and many people have it set up in that way when they have a router that will not work for local hostname resolution or their router is not very configurable. You would need to be able to disable the DHCP server on the router for that kind of setup since you only want one DHCP server on any network segment. (There are exceptions to that rule but that gets in to more complex network models.)

You are correct that Pi-hole will not work as the router since it only sees DNS (and in some cases DHCP) information and can not route packets out to the WAN.

Yea unfortunately it's giving me an NXDOMAIN, that's too bad. I appreciate your help!

Well, NXDOMAIN means at least there is a response and a DNS server listening which might not be as bad as you think. I was expecting no response at all.

If you don't mind, can you share what domain you queried and what you were expecting?

A debug log might be helpful to just kind of see how things are. I'm open to playing around a bit and seeing what we can find out if you're interested in seeing what might be possible.

Sorry, I don't know I fully understand.

I queried dig (the router), is that the domain you're referring to? Or the local service I'm trying to access?

Debug logs:

What is the full dig command you tried?

I just ran dig and got this back

; <<>> DiG 9.10.6 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33103
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4000
;			IN	A

.			900	IN	SOA 2024051500 1800 900 604800 86400

;; Query time: 137 msec
;; WHEN: Wed May 15 12:34:18 EDT 2024
;; MSG SIZE  rcvd: 116

Oh. That's not an actual dig command for anything of value. You need to look up a domain with dig, dig <hostname> @<DNS_server_IP> ex dig @ If you leave off the IP address of the DNS server then the default DNS server is used.

What you did was ask for the IP address of, which doesn't exist because it's not a hostname, it's an IP address.

A better test would be to dig syncthing @ or any other hostname from your LAN setup.

Ahh OK, sorry about that. Yea running dig syncthing.local gave no answers.

In your dig statement, the DNS server IP address lacks the @ prefix, i.e. it should read @

Sorry about that, there's still no luck when using dig snapserver.local @

Could you please share the full output?

; <<>> DiG 9.10.6 <<>> snapserver.local @
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12021
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096
;snapserver.local.		IN	A

.			2656	IN	SOA 2024051600 1800 900 604800 86400

;; Query time: 117 msec
;; WHEN: Thu May 16 09:05:35 EDT 2024
;; MSG SIZE  rcvd: 120