Question about best practices for DNS setup on LAN

[DLite]

I have my Unifi network set up to assign the following DNS servers to local devices on the LAN: Primary DNS server of 1.1.1.1 (Cloudflare), and Secondary DNS server of 192.168.0.1 (my router).  I did this under the theory that if the internet goes out, my local devices would still be able to communicate with each other by using the router for DNS.  However, having read some of the recent discussion on this forum about DNS setup, I'm wondering if I misunderstood what DNS is used for and also wondering if I ever really needed to add the router to the DNS list.

Do I need to insert my router as the secondary DNS server?  Specifically, in the event of an internet outage, would my local devices still be able to communicate with each other even if all the listed DNS servers were out on the internet?  If it is unnecessary to worry about this internet outage scenario, maybe my secondary DNS server should just be Google at 8.8.8.8?

Thanks for any advice.

[msgreenf]

I don't think you understand what DNS is 

[DLite]

15 minutes ago, msgreenf said:

I don't think you understand what DNS is 

Yes, that certainly seems so!  What would be a good set of DNS addresses to enter?

[C4 User]

8.8.8.8, 8.8.4.4, your 1.1.1.1 should be good if it’s reliable. But im an amateur here. Definitely not your internal router IP. 

[DLite]

 

3 minutes ago, C4 User said:

8.8.8.8, 8.8.4.4, your 1.1.1.1 should be good if it’s reliable. But im an amateur here. Definitely not your internal router IP. 

Thanks! 1.1.1.1 seems to be working well. I'll add the Google addresses to the other fields then.

[ekohn00]

1 hour ago, C4 User said:

8.8.8.8, 8.8.4.4, your 1.1.1.1 should be good if it’s reliable. But im an amateur here. Definitely not your internal router IP. 

This!
 

[Popolou]

No, you do not want each and every device to be going out over the 'net for its lookups. Best practice is that this is contained within your network, not just for security but also for latency. Your router will cache any responses for repeat searches and is far more responsive than having to go over multiple hops to fetch the same data. You are gaining more this way and the router will refresh its own record if the DNS system instructs clients to do so. Configure the primary and secondary on the router (with different hosts if you prefer) and have all your devices pick up the router IP via DHCP in the usual way.

[ekohn00]

5 hours ago, Popolou said:

No, you do not want each and every device to be going out over the 'net for its lookups. Best practice is that this is contained within your network, not just for security but also for latency. Your router will cache any responses for repeat searches and is far more responsive than having to go over multiple hops to fetch the same data. You are gaining more this way and the router will refresh its own record if the DNS system instructs clients to do so. Configure the primary and secondary on the router (with different hosts if you prefer) and have all your devices pick up the router IP via DHCP in the usual way.

Actually most routers will reply to the DHCP request with the DNS addresses you put in NOT the router's address.

[DLite]

9 hours ago, Popolou said:

No, you do not want each and every device to be going out over the 'net for its lookups. Best practice is that this is contained within your network, not just for security but also for latency. Your router will cache any responses for repeat searches and is far more responsive than having to go over multiple hops to fetch the same data. You are gaining more this way and the router will refresh its own record if the DNS system instructs clients to do so. Configure the primary and secondary on the router (with different hosts if you prefer) and have all your devices pick up the router IP via DHCP in the usual way.

Thanks, @Popolou.  This is helpful and clarifying.  

There is one remaining issue that confuses me.  Previously, I had set up Unifi so that the WAN was using CloudFlare DNS servers, while the LAN DNS server was set to auto, which essentially did what you are suggesting -- each device on my local network used my router's local IP address as its DNS server address. However, I have been battling laggy performance on my Roon music server, and in reading the various threads on streaming here, I saw several dealers recommend the best-practice for music streaming of using a public DNS server address not just on the router, but also on every individual streaming device and even every device on the entire LAN.  After reading these posts, I started tinkering with the LAN DNS settings in Unifi, hoping it would improve streaming performance.  (As an aside, my streaming did get better, but I am not certain this was because of the DNS change.)  

I think you are saying that this advice, of using a public DNS server on local clients, is either unhelpful for device performance or has countervailing drawbacks in terms of latency and security.  Am I following your logic or am I missing something still?  Thanks!

[ekohn00]

19 minutes ago, DLite said:

Thanks, @Popolou.  This is helpful and clarifying.  

There is one remaining issue that confuses me.  Previously, I had set up Unifi so that the WAN was using CloudFlare DNS servers, while the LAN DNS server was set to auto, which essentially did what you are suggesting -- each device on my local network used my router's local IP address as its DNS server address. However, I have been battling laggy performance on my Roon music server, and in reading the various threads on streaming here, I saw several dealers recommend the best-practice for music streaming of using a public DNS server address not just on the router, but also on every individual streaming device and even every device on the entire LAN.  After reading these posts, I started tinkering with the LAN DNS settings in Unifi, hoping it would improve streaming performance.  (As an aside, my streaming did get better, but I am not certain this was because of the DNS change.)  

I think you are saying that this advice, of using a public DNS server on local clients, is either unhelpful for device performance or has countervailing drawbacks in terms of latency and security.  Am I following your logic or am I missing something still?  Thanks!

You have a lot going, and I can help a bit since im running about the same.....

Unifi will have 2 DNS entries. One under WAN which is used for the device itself. Another is found under networks in the DHCP section, this is what is haded out to devices and may default to WAN if not entered. (I enter both).

For your Roon server, I would make this a static IP address and use 1.1.1.1 & 1.0.0.1 for DNS. 

This should remove any issues with DNS you'd have.

 

[Popolou]

49 minutes ago, DLite said:

Thanks, @Popolou.  This is helpful and clarifying.  

There is one remaining issue that confuses me.  Previously, I had set up Unifi so that the WAN was using CloudFlare DNS servers, while the LAN DNS server was set to auto, which essentially did what you are suggesting -- each device on my local network used my router's local IP address as its DNS server address. However, I have been battling laggy performance on my Roon music server, and in reading the various threads on streaming here, I saw several dealers recommend the best-practice for music streaming of using a public DNS server address not just on the router, but also on every individual streaming device and even every device on the entire LAN.  After reading these posts, I started tinkering with the LAN DNS settings in Unifi, hoping it would improve streaming performance.  (As an aside, my streaming did get better, but I am not certain this was because of the DNS change.)  

I think you are saying that this advice, of using a public DNS server on local clients, is either unhelpful for device performance or has countervailing drawbacks in terms of latency and security.  Am I following your logic or am I missing something still?  Thanks!

Yes, that is about right. It is some myth that using public DNS for all your internal clients is advisable - it really isn't and it merely suggests that the internal DNS config is misconfigured. A proper internal DNS is almost always more performant and can be very useful, especially if you want to blacklist certain domains or as part of steps to anonymise/obscure your own web data. CloudFlare's 1.1.1.1 DNS server (or its content filtered nameserver if you need that at home) are a good bet too, they are much faster than googles (which has its occasional blips) and Quad9 is a strong a fallback which consistently gives the lowest latency on my networks.

[DLite]

22 minutes ago, Popolou said:

Yes, that is about right. It is some myth that using public DNS for all your internal clients is advisable - it really isn't and it merely suggests that the internal DNS config is misconfigured. A proper internal DNS is almost always more performant and can be very useful, especially if you want to blacklist certain domains or as part of steps to anonymise/obscure your own web data. CloudFlare's 1.1.1.1 DNS server (or its content filtered nameserver if you need that at home) are a good bet too, they are much faster than googles (which has its occasional blips) and Quad9 is a strong a fallback which consistently gives the lowest latency on my networks.

Thanks, @Popolou and @ekohn00.

For my primary and secondary WAN connections, I now have DNS addresses set up as 1.1.1.1 for primary and 9.9.9.9 for secondary.  For my LAN settings in Unifi, I think I'll go back to my prior setup where the DNS server is set to auto, so clients will grab the router's IP address as the DNS server.  

[Cyknight]

1 hour ago, Popolou said:

It is some myth that using public DNS for all your internal clients is advisable

 

6 minutes ago, DLite said:

so clients will grab the router's IP address as the DNS server

While that is true/fine for most common setups, there are devices and systems that benefit from using public dns servers. Generally, because they're optimized for it.

 

I'd also say that using a local dns server (as in using a router for it) gives better performance is just as much of a myth as using public servers is faster - obviously for content filtering using a local dns server is (potentially) better, but only if you manage it well (if not, better off using just using cloudflare or similar)

 

[DLite]

7 minutes ago, Cyknight said:

 

there are devices and systems that benefit from using public dns servers. Generally, because they're optimized for it.

 

Would music streaming devices (Roon and Sonos, in my case) and/or C4 controllers fall into this category of devices that are optimized for public DNS? 

[Cyknight]

8 minutes ago, DLite said:

Would music streaming devices (Roon and Sonos, in my case) and/or C4 controllers fall into this category of devices that are optimized for public DNS? 

Wouldn't know for Roon specifically, Sonos used to be back in the early days, not sure if still true - i suspect they likely stepped away from it as you can't set static ip on them at all. C4 may or may not be optimized as such (I don't have that sort of insight/access), but seems more stable for sure.

The latter is easily setup using (reserved) dhcp for network address and static DNS though - which is what I do standard on setup.

 

Mind you, using your router as DNS server internally and using google/cloudflare/other for the router to use fixes MOST dns issue (provided of course, your router can do a good job as a DNS server). I just prefer setting C4 that way because it's next to no effort to do, and it certainly doesn't hurt.

 

[ekohn00]

3 hours ago, DLite said:

Thanks, @Popolou and @ekohn00.

For my primary and secondary WAN connections, I now have DNS addresses set up as 1.1.1.1 for primary and 9.9.9.9 for secondary.  For my LAN settings in Unifi, I think I'll go back to my prior setup where the DNS server is set to auto, so clients will grab the router's IP address as the DNS server.  

I think you're asking for problems you won't be able to trace. I would not use 9.9.9.9 with 1.1.1.1 as a primary.

9.9.9.9 using DNSSEC and blocklists.... good in theory by itself but a waste if your primary is 1.1.1.1. Go with 8.8.8.8 as your secondary and avoid any problems.

 

Also as far as using the router for a home to speed DNS...well that's kinda stupid. Sure if you have 1000s of users you might get some cache hits, but the reality is you could end up slowing down streams because a name may not be cached and your going to your router, which then goes out to look for it. 

Since the Roon server is the device talking to the internet, and will be unique, you might as well do your DNS from it directly without the useless router in the middle.

The only time you should use the router for DNS is if you have local names that need to be resolved.

 

[DLite]

58 minutes ago, ekohn00 said:

I think you're asking for problems you won't be able to trace. I would not use 9.9.9.9 with 1.1.1.1 as a primary.

9.9.9.9 using DNSSEC and blocklists.... good in theory by itself but a waste if your primary is 1.1.1.1. Go with 8.8.8.8 as your secondary and avoid any problems.

 

Also as far as using the router for a home to speed DNS...well that's kinda stupid. Sure if you have 1000s of users you might get some cache hits, but the reality is you could end up slowing down streams because a name may not be cached and your going to your router, which then goes out to look for it. 

Since the Roon server is the device talking to the internet, and will be unique, you might as well do your DNS from it directly without the useless router in the middle.

The only time you should use the router for DNS is if you have local names that need to be resolved.

 

I dunno. You may well be right, but I'm just a simple caveman Unifi end user, and it's hard for me to sort through the subtle points of contention here.

I ended up unwinding all the experimentation I've done over the past week and reverting back to my longstanding settings: 1) Unifi WAN DNS directing to Cloudflare (with Google as secondary, as you do); 2) Firewalla box in bridge mode serving up DNS over HTTPS to its default set of DNS servers, which are Cloudflare, Quad9, OpenDNS, and Google; and 3) Unifi LAN DNS set to "auto."  Roon search and streaming are still snappy, and all else remains well on the network, so maybe the DNS experimentation wasn't really doing anything for Roon anyway.  Dollars to donuts that rebooting the Nucleus was all I actually needed to do!

 

 

[Andrew luecke]

So, I'm not sure if it has already been discussed in this thread, but in regards to performance.

% ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=60 time=2.682 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=60 time=3.116 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=60 time=2.502 ms

Unless you are doing 100 lookups at a time, you're not likely to notice any performance difference on any decent internet doing internet lookups, especially because the TTL on a lot of major domains is likely set to a long period anyway (so won't be fetched regularly), can be done in parallel and Google / Cloudflare mostly colocate DNS servers close to many users around to the world. Maybe only if your ISP really sucks (or you have enterprise requirements)

OpenDNS is the exception however, as I did notice in the past, that here in Australia, there was a considerable ping delay (I seem to recall 200ms), but this has likely changed now (as I think they're owned by Cisco now)

Either Cloudflare or Google servers are mostly much of a muchness honestly

 

[Popolou]

12 hours ago, Cyknight said:

While that is true/fine for most common setups, there are devices and systems that benefit from using public dns servers. Generally, because they're optimized for it.

Curious to know which you've come across that have exhibited this. I may run a little project to see why this could be the case. Fundamentally, devices using DNS must work to RFC1035 so i could only assume some butchered implementation is in play with these select devices.

 

12 hours ago, DLite said:

Would music streaming devices (Roon and Sonos, in my case) and/or C4 controllers fall into this category of devices that are optimized for public DNS?

As an aside to this line of discussion, it was not long ago when a bug with Roon servers caused them to hammer DNS requests at their configured server which caused the DNS host to consider this as Denial of Service and rate-limit and/or block traffic back to it. However, since most of these implementations were behind NAT'd connections, it meant that the public IP was blacklisted knocking out the whole (home?) network from all its DNS. Always contain this internally.

 

7 hours ago, Andrew luecke said:

Unless you are doing 100 lookups at a time, you're not likely to notice any performance difference on any decent internet doing internet lookups....

Hi @Andrew luecke, ICMP replies test only the hardware level (i.e. port, Layer 3) and not the DNS stack (application, Layer 7). The latency in this case is the DNS stack actually responding to service requests, not the ping back from the physical port. Most competent DNS hosts are on the edge of the big networks anyway.

 

[Cyknight]

8 hours ago, Popolou said:

which you've come across that have exhibited this

Sonos, Autonomic and those using logitech media software/clones/bases are some I've seen it in the past.

 

8 hours ago, Popolou said:

Most competent DNS hosts

COMPETENT being the operative word. The biggest issue as I mentioned is that many ISP don't fall in that category. This will differ by area/location/country for sure - for us here it's less an issue within the city where regular 'wired' isps (cable/fibre) do fine, but we've seen issues with any and all 'wireless' providers (tower, cellular and satellite) that we deal with for clients outside city limits

[cbasssssss]

Im running pihole as my primary DNS with google as the backup. Would that pose any issues?

[Andrew luecke]

On 1/3/2025 at 4:52 AM, cbasssssss said:

Im running pihole as my primary DNS with google as the backup. Would that pose any issues?

Just be careful what you're blocking. I wouldn't recommend blocking anything on your C4 controller. Problem is, if you start blocking random things on your C4 controller, you can:

1. Make troubleshooting a lot more difficult by causing issues with logging.

2. Potentially block security updates

3. Cause subtle issues with drivers (there might be services they need only intermittently).

4. Interfere with licencing

5. It may cause issues with upcoming functionality where the implications may not be immediately obvious

6. Sometimes there are mechanisms which are implemented for long term compatibility. This might begin months or years before these changes happen.