If you implemented filtering with a default starting point of block all, then yes, you would need to add everything to an allow list. This is not really practical and would have a high admin overhead.

Products such as pi-hole, adguard@home operate in reverse. By default all dns is allowed and dns results are blocked as required.

Using consolidated blocklists from online sources allows for low admin overhead to block different categories of dns addresses. If a dns entry you need is included in a blocklist you use, you would add that dns entry to an allow list in your dns blocker which takes priority over the blocklist entry.

This is far more manageable and has a lower admin overhead with most additions to the allow list being a one time action.

Thanks!

 This community is a great resource for learning about the effects of networks on Sonos.  I’ve been lucky so far, but still want to learn what can go wrong.

Hi @MoPac, here are the sites to whitelist for DNS filtering …

• *.sonos.com
• *.optimizely.com

… to ensure that the Sonos app works.

press250:

 Thanks!  Not using DNS filtering at this point, but it seems like a useful tool.  Just happened on mentions of Pi_hole etc. & was wondering if some folks were having issues because of DNS filtering they were not aware of.  Although it seems like something that has to be consciously implemented.

Using DNS filtering is like using a hammer, the wrong filter/hammer is going to leave you with busted apps/fingers.

I’m a fan of Pi-Hole myself, I’ve used several others and find it most flexible. In particular is the ability to filter by device so you can allow a service you really don’t want but a device demands - but - only for that device. So here my Sonos all have a “device group” that allows the services they need to work properly but the services are still blocked for all my other devices.

Hi @MoPac 

Thanks for your post!

You may find this of help:

But please be aware that it’s unlikely that a DNS Sink such as Pi-Hole would filter such sites as Spotify, Tidal etc. by default. Instead, they are more focused on blocking ad servers and trackers.

So, no - you would not need to whitelist such sites - unless you had a more aggressive profile working, I suppose.

Some DNS issues are just due to poor ISP DNS servers - sometimes things just work better when using Google (8.8.8.8) or OpenDNS (1.1.1.1) as the DHCP-defined DNS server in the router’s settings.

Personally, I combine Pi-Hole with the Unbound service, Unbound being a local, caching DNS server, so I don’t even need an external server such as Google’s or OpenDNS’s. So, in the Pi-Hole DNS configuration page, Pi-Hole just links to Unbound on a specific port on the same machine.

I hope this helps.

The local resolver, Unbound is my choice too.

Using any upstream resolver that redirects you to an ad-serving site instead of providing a proper error message can break a lot of things. For you in a browser it is easy to see you got snookered, for an app it can be confusing to not only not get a proper error but be served up a random page of ads. Yes the app programmer should have coded for that but they rarely do.