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, lb._dns-sd._udp.x.x.x.x.in-addr.arpa) 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:

    address=/lb._dns-sd._udp.x.x.x.x.in-addr.arpa/127.0.0.1

    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
      or
    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 192.168.1.45 is mycellphone.lan, not just 192.168.1.45.

    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 (127.0.0.1) doesn't seem to be the correct thing to do, and pointing it at null (0.0.0.0 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/com.apple.mDNSResponder.plist 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.

    hth,

    R.

    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.


Log in to reply
 

Looks like your connection to AmpliFi was lost, please wait while we try to reconnect.