Amplifi, PiHole and Bonjour DNS requests (._dns-sd._udp)

  • I am using AmpliFi HD as the router/DHCP server for my home network and PiHole as the internal DNS (set up as per instructions on the PiHole website). The Amplifi is set to "bypass DNS cache", whereas the PiHole is set to have conditional forwarding to the Amplifi. With this setup, I can manage all local hosts from within the Amplifi app and see them by name from within the PiHole admin interface. Everything is working fine, and access to internet is faster than light indeed!

    However I have noted that among the top permitted domains in PiHole there are a few domains starting with ._dns-sd._udp (as an example, with a very high number of hits, which I understand are related to Bonjour / mDNS requests for name resolution over the local network. I am using both a Mac and a Fedora machine, and such requests only appear when using the Mac (no Avahi on Fedora), so this behaviour seems reasonable to me.

    The PiHole has "Never forward non-FQDNs" (i.e. domain-needed in dnsmasq.conf) and "Never forward reverse lookups for private IP ranges" (i.e. bogus.priv) set. The Bonjour request, however, are indeed forwarded.

    I tried at neutralizing such requests for permitted domains (and their related workload) by adding a line such as:


    to Dnsmasq configuration file in /etc/dnsmasq.d, and all permitted domains and their related number of hits have disappeared.

    I wonder if this is the correct solution or if there are other better ways to neutralize the Bonjour requests (my doubt is, who is the localhost to which I am forwarding the request, the Raspberry where PiHole resides or the originating Mac, or the Amplifi or ... whom else???).

    Any suggestion would be very much appreciated.

  • @valerio-morganti it will never forward to the upstream server (ie Googe) if that is checked. It is forwarding it back to Amplifi with conditional forwarding turned on, which then forwards it back to pihole in a vicious loop.

    I asked on this thread why is Amplifi forwarding these requests at all since it is the dhcp server. My guess is since I have disabled DNS cache the pihole is the first device in a client's DNS and said client sends the initial requests which pihole sends to Amplifi (CF enabled) which for some reason sends it back to pihole.

    I don't know how to fix this. It is above me. We can't disable dhcp on Amplifi and have a guest network, I don't have access to Amplifi via SSH so the only option appears to be to disable conditional forwarding from pihole.

    Maybe there is a way to convince pihole manually to perform conditional forwarding but block these requests from looping? I tried enabling loop detect with no help.

    Waiting a response still on that thread but I had noticed one loop caused over 1.6m requests before I stopped it. Just left conditional forwarding turned off for now.

  • @michaele Michael, your posts were very useful to help me identify the issue. Apparently, normal requests are kept local within Amplifi, but Bonjour requests enter into the loop when DNS cache is bypassed. Let’s wait for a response!

  • @valerio-morganti, @MichaelE There are two ways to solve this problem.

    1. Teach pihole to use external dns only - never use dns servers provided by dhcp server (of Amplifi). The most reliable is to avoid dhcp at all
    2. Wait for the next release of Amplifi firmware which should contain quick fix for this situation.

    Apparently this problem emerged with the latest pihole update.
    Basically this is dns request forwarding loop between pihole and AmpliFi.

  • @ubnt-brett what is the fix?

  • @ubnt-brett in the next release can we please have traffic pausing in bridge mode enabled for both wired and wireless traffic.

    As well as the Wan port working in Mesh point mode as a LAN port.

    As for DNS I noticed pi hole block the amplfi ping domains depending on the block list used. can we change it to an NTP server that it pings instead or to avoid this problem, so I think that might be the cause of the op's issues

  • @ubnt-brett

    Teach pihole to use external dns only - never use dns servers provided by dhcp server (of Amplifi). The most reliable is to avoid dhcp at all

    We send reverse lookups to the router so the PiHole knows is mycellphone.lan, not just

    This is done in PiHole under conditional forwarding where we add the IP of the router and the domain (lan in this case).

    PiHole will use whatever upstream DNS servers are configured, in my case that is Google.

    This isn't a new thing with the recent update to PiHole, except that PiHole now is showing PTR requests, thus we are now seeing the loops that have probably been happening all along. Seeing this happen now actually explains some issues I have had in the past.

    I wouldn't want the fix to be too block DNS requests, but instead, within Amplifi just to have the ability to set it to not forward local requests, including reverse lookups.

    So PiHole can continue to ask Amplifi what an IP is but not get stuck in this loop where Amplifi sends the request back to PiHole.

    I hope that along with the intention is clear.

  • @michaele ahh you are asking for the same option that my Asus router has do not forward local queries to upstream DNS servers.

  • @michaele @UBNT-Brett

    to prevent million-query-records-per-hour overload in the interim, pi-wise, I've had to disable conditional forwarding and NOT send reverse lookups from the pihole back to the amplifi unit, either.

    (i.e., no adjusted dnsmasq.conf entries from stock at all).

    having entries in the pihole's /etc/hosts seems to work (pihole-FTL is smart enough to deal with building PTRs as well as A records) so that client names appear in pihole's admin portal.

    based on information from here, that particular mdns entry is a bit strange to deal with.

    pointing it at localhost ( doesn't seem to be the correct thing to do, and pointing it at null ( per rfc1122) might not be right either.

    based on output of a dns-sd browse on my LAN, I think it technically wants ".local" (versus .lan) since the PTR per spec, goes to @ (the indicator for "this domain") which is ".local" -- confirming this based on a dns-sd -Z dump of the browse in zone format.

    EDIT: to reduce the load, per here, mac users might be able to disable mDNS service advertising with

    defaults write /Library/Preferences/ NoMulticastAdvertisements -bool YES

    and rebooting.

    ... that stops service advertising without affecting DNS resolution. doesn't do much for other apple iThings, but might be useful for somebody.



    PS: does anyone get the amplifi unit insisting on inserting itself as the 3rd dns server for dhcp clients?

    on the amplifi router I have only the pi's address listed twice (v2.93, app v1.89), but resolv.conf on the clients still gets the pi twice and the amplifi as #3. and I can't for the life of me get it to stop adding itself.

  • @rob-vanhooren "PS: does anyone get the amplifi unit insisting on inserting itself as the 3rd dns server for dhcp clients?"
    I absolutely subscribe to this one ... almost (as I haven't checked on all) is having the AmpliFi router listed as a DNS (on top of the defined ones) ... Reason unknown, yet 😐

  • This post is deleted!

  • @valerio-morganti I just set up pihole in my home and noticed this behavior, too. Disabled the conditional forwarding until a fix comes around. Happy to have found this thread started, and commenting to keep tabs on a fix.

  • @rob-vanhooren I noticed amplifi inserting itself as the 3rd DNS server, too.

    Has anyone tried the latest beta amplifi firmware to see if any of this is resolved?

  • @carmine-granucci At first glance, mine does not seem to be doing it (injecting itself as a third DNS provider) right now. That said, it was doing it a few weeks ago (on multiple devices, multiple OSes). I'm really not sure what the difference is at this point.

  • Looks like the latest firmware (2.9.5) addresses these issues. I'm not getting bombarded with those reverse arpa addresses and the DHCP isn't injecting the router as the 3rd DNS service.

  • I have just set up Pi-hole on my network, working beautifully except last night got the best part of a million PTR reverse dns lookups in the glad to see it's not just me!

    In Pi-hole v5 you can uncheck Never forward non-FQDNs and Never forward reverse lookups for private IP ranges and retain conditional forwarding for IP resolution on the local network. I'm going to let this run for 24 hours and see what happens!

    This is with firmware 3.1.2 on the Amplifi by the way.

  • I shared this on a similar thread outside of ui ... First let me apologize for the poorly written reply here. I'm answering too quickly, in an informal rapid reply.
    There are a few solutions that do not involve disabling the conditional forwarding, or the other solutions presented thus far. I'm assuming that you 1) setup the non-default conditional forwarding to get reverse resolution on the hosts on that segment from the DHCP server, and 2) that you had a good reason for the DHCP server to be where it is, and not on your pi-hole, because it's a good bet that is the case. And 3) that you don't want to point your DHCP device to the upstream DNS server because you want it to know about local non-DHCP entries, or 4) because you want it to get pi-hole protection as well.

    If all of those are the case, here are two additional options for you:
    Option A: configure your DHCP server to "know" how to reply for that query. It may be as simple as creating an entry in the ```
    /etc/hosts file so that it can give pi-hole an answer (or so that, if it is the originator of the query it never even asks). It's difficult to share exactly how (or even if it is possible) to do this because it depends on the DHCP server.... good luck.
    Option B:
    step 1 configure a blacklist regex entry, something like the following will probably work for everyone, and for all of the different service discovery and similar requests (tcp and udp)
    add as a regex blacklist


    step 2 delete the huge number of entries from the FTL database with the sqlite3 command (use sudo if you are not root (and I hope you don't log as root) because otherwise you may not have permissions to delete

    sudo sqlite3 /etc/pihole/pihole-FTL.db "DELETE FROM queries WHERE domain LIKE '%in-addr%';"

    step 3 check your pi-hole server disk space with df -k and if / (root) or another partition such as /var/ are showing high use, consider cleaning (sed or similar) or deleting the very large files you'll find this way:

    ls -l /var/log/pihole*

    step 4 reboot the pi-hole server and log in as soon as it comes up, and watch the services spool up

    sudo shutdown -r now

    terminal drops.... ping pi-hole-addr (until it responds, and immediately) ssh pi@pi-hole-addr , uptime, top etc

    Here you are confirming that your pi-hole is returning to normal service and isn't choking on the .db file or from some bitrot due to high disk use, etc.

    step 5 watch the DNS query tally for a few minutes, make sure it is not showing 200+ qps to confirm that the regex is handling the specific query on your network.

    For those of you who may be interested in what is happening, a device makes the service discovery request to the pi-hole DNS, which triggers a conditional forwarding for that subnet (because your pi-hole is configured to refer unknown reverse queries to the DHCP server.) The DHCP server probably runs dnsmasq, or similar, and seeks to answer the question. If it was for a single host, it would be answered and that would be the end of it. However, this is a question the DHCP does not know how to answer, so it asks it's DNS server(s) ... which naturally is the pi-hole server. Repeat into a feedback loop. Now, I don't know about these other networks, but on mine the speeds and systems are healthy, so very quickly (minutes) I'm getting 200 qps on the pi-hole, and shortly after that (minutes) it approaches 2000 qps. Load on the pi-server begins to peg out, if there are switch ports that do not limit unicast traffic then it's a race to see if 1) pi-hole FTL fails due to memory or 2) the disk fills up due to pi-hole.FTL.log files or 3) the disk fills up due to the FTL database size or 4) the system load becomes too much and the applications crawl to their death, or 5) your switch gives up the ghost or 6) the ethernet chip can't get a word in edgewise and you achieve a steady state and then 1, 2, 3, or 4 are inevitable or 7) something like a system crash on either side interrupts the feedback loop. In that case, if it's the DHCP server, then you might luck out for a while if it does not repeat within the next 24 hours. If at any time in the next 24 hours the pi-hole server is restarted (service or system) then it's likely that the db is too large and pi-hole services (FTL mainly) will choke while starting up, and load will begin to climb from 1 to 3 to ... and so on.

Log in to reply