Ubiquiti UniFi - WAN/VLAN DNS Server Setting Scenarios

Summary

Highlights

• The video explores DNS server settings for both WAN and VLAN interfaces using Ubiquiti UniFi. 📡
• Complex DNS behaviors like ghost queries and unexpected server settings are tackled comprehensively. 👀
• Manual vs automatic DNS settings show different impacts on DNS traffic and server usage. ⚖️
• Using Pi-hole with Unbound allows for advanced DNS configuration, including DoH (DNS over HTTPS). 🔍
• The tutorial discusses setting DNS server on the UniFi network controller and its effects on network traffic. 🎯

Key Takeaways

• Setting DNS servers for WAN and VLAN interfaces can greatly impact network behavior! 🌐
• Ghost DNS queries on UniFi devices can stem from default or unexpected settings. 👻
• Each scenario of DNS configuration offers unique insights into traffic handling and troubleshooting! 💡
• Pi-hole with Unbound can provide enhanced DNS management and encryption, helping with privacy and security. 🔒
• Understanding native configurations versus manual settings helps prevent unintended traffic leaks. 🚧

Overview

Chapters

• 00:00 - 00:30: Introduction In the second video of the series about UniFi and DNS server settings, the importance of watching the first video is emphasized. The first video covered how the One D server setting and the V settings influence backend configurations and their interoperability.
• 00:30 - 01:30: DNS Settings Overview The chapter discusses the increasing complexity of DNS settings in modern local networks. It notes that if you're using a UniFi router, you can configure the DNS server within the UniFi network controller. This can be done either in one section or for each VLAN in the DHCP settings. The transcript also mentions using a cloud key to run the network controller, suggesting this is part of the setup process.
• 01:30 - 04:30: Ghost DNS Queries Explained This chapter explains different methods for supporting name servers within a UniFi router, highlighting its use of DNS mask for local DNS services. The chapter also describes the variability in setting or overwriting DNS server settings on client machines, depending on the system. Additionally, it touches on the use of Pyle for DNS name resolving and the necessity to set an Upstream DNS server when using it.
• 04:30 - 10:00: Scenario 1: Default Settings The chapter 'Scenario 1: Default Settings' discusses configuring DNS settings using Unbound. It mentions the need to configure the DNS forward and provides examples of DNS server settings. Before exploring real scenarios, the chapter addresses a special case involving 'ghost DS queries,' which are queries whose origins are unclear.
• 10:00 - 17:00: Scenario 2: Manual DNS on Client In this chapter, the scenario explores the effects of manually setting a DNS server on a client. The focus is on understanding why certain DNS servers are being queried even though they weren't explicitly configured by the user. The speaker demonstrates this issue using a lab environment. Initially, the network controller's primary DNS setting is altered from its default to '9999'. The chapter utilizes Wireshark to monitor and diagnose the situation, aiming to uncover the reasons behind the unexpected DNS query behavior.
• 17:00 - 23:00: Scenario 3: Manual DNS in VLAN DHCP The chapter explains a scenario involving manual DNS configurations within a VLAN DHCP setup. The focus is on monitoring DNS queries using Wireshark, specifically targeting the WAN part of a router to capture outbound DNS queries. The process includes setting a DNS display filter in Wireshark and observing DNS queries originating from the router's WAN to different destinations.
• 23:00 - 29:00: Scenario 4: Manual DNS on WAN In Chapter 4 titled 'Manual DNS on WAN', the protagonist is puzzled by unexpected DNS queries in their network. Despite having set their network controller's settings to 9999, they observe frequent queries to DNS servers 1111 and 8888, which should be unknown to any clients. The protagonist is determined to investigate the source of these strange DNS queries by using SSH on their network devices.
• 29:00 - 41:00: Scenario 5: Using Pi-hole with Unbound The chapter discusses the use of Pi-hole in conjunction with Unbound, focusing on network configurations and traffic monitoring. The setting involves access to a router via SSH (Secure Shell), enabling the user to display network packages from one perspective. The user is running a TCP dump command on the router, set to capture traffic across all router interfaces. The focus of the traffic capture is filtering for port 53.
• 41:00 - 41:30: Conclusion The chapter titled 'Conclusion' provides insights into DNS traffic analysis through a router. It highlights the significance of examining DNS queries, specifically focusing on common DNS resolver IPs like 1.1.1.1 and 8.8.8.8. The chapter suggests using TCP dump to capture and scrutinize DNS frames on an ethernet interface, specifically on ux3 pro, to understand the network behaviors and query patterns.

Ubiquiti UniFi - WAN/VLAN DNS Server Setting Scenarios Transcription

• 00:00 - 00:30 this is the second video of the topic about unify one versus weand DNS server settings if you missed the first video I strongly recommend you to watch that one first because in the first video I discussed how the One D server setting and the V settings they impact the backand configurations and how they work together so in this video I will
• 00:30 - 01:00 directly jump to the different scenarios nowadays in our local network system the DLS related settings are becoming more and more complicated if you use UniFi router just on the UniFi network controller you can set the DNS server on the one part or for each V in the DHCP setting you can set the DNS server and if you use cloud key to run the network controller later you will see it used
• 01:00 - 01:30 totally different ways to support name server and then within your UniFi router you may know it runs DNS mask to support the local DNS service then in your client machine different system has different ways to customize or overwrite the DNS server setting to make things even more complicated some people will run Pyle to provide DNS name resolving you need to set Upstream DNS server in pyo or some people will even write
• 01:30 - 02:00 Unbound and then in Unbound you need to configure the DNS forward so this are just several examples about where you can make DS server settings in this video Let's explore several selective scenarios before exploring the real scenarios let's first discuss a very special case sometimes you will observe some ghost DS queries when I say ghost I mean you don't understand where the
• 02:00 - 02:30 queries come from why they even use some specific D server because you never set it to do so let me show you the symptom then let's try to find out what's the reason in my lab environment in the network controller setting for internet for the primary one part the default setting for DS server is Alter let me change it to let's say 9999 okay apply changes then in the lower part I have a wire shock as shown
• 02:30 - 03:00 on the diagram the wire shock is monitoring the one part not the L part because I want to see what's the ultimate DNS queries going out of the router so let me start capturing I already set the DNS as the display filter so you can see I haven't done anything about DNS queries right then there are a whole bunch of queries happening already so the source is from the routers one part and the destination
• 03:00 - 03:30 is 1111 8888 and it happen so frequently but in my network controller setting I set it to 9999 you already saw it right I never expect any queries against these two servers because theoretically no clients even can know the existence of these two servers where are this strange DNS queries come from let's find it out so in the left side let me SSH into the
• 03:30 - 04:00 router so the right side wire shock is only showing the package from the one part perspective now I'm in the SSH into the router so I have the opportunity to show the package for any interfaces within this router let me simply wrun a TCP dump for interface I say any I want to capture all the interfaces traffics I need to filter the part to 50 three
• 04:00 - 04:30 which is for DNS so let me write you can see the busy DNS traffics just within the router and if you compare the left and the right side side by side whenever in the right side you see queries against 1111 or 888 in the left side let me kill the TCP dump so you can examine the captured frames carefully let's examine this example packet so see the interface is ethernet 3 for ux3 pro
• 04:30 - 05:00 router the ethernet 3 is the fourth part is for my L part on my lamp part there's a in packet and it is from this particular machine and the destination is the 1111 right then we simply need to find out what's this machine before the dot is unify after the dot is internal das1 I know for my default Network I set the local domain name to internal -1 so
• 05:00 - 05:30 that means this particular machine is within my default Network then the host name is unify you may know for UniFi network controller it keeps the hardcoded host name for the machine which runs the UniFi network controller so in my case I use cloud key plus so my cloud key plus has the UniFi as the host name I do have a video in my channel talking about layer 3 adoption for UniFi Network it t related to this UniFi
• 05:30 - 06:00 domain name thing just from this information I already know the Troublemaker is the cloud key but even if unified host name thing doesn't ring a bell you can still easily find it out what's this domain name for let me go to this DNS mask config DOD folder and within the folder there's a file called DNS config let me display it you can see this host record set settings so they
• 06:00 - 06:30 have the host name unify the same machine has different host records in different v l but they all have the same IP address I know this IP address is for my cloud key this is just another way to identify what's the UniFi host name for okay so now we know it's the UniFi Cloud key which did all the ghost queries so why the router's DNS configuration does
• 06:30 - 07:00 impact the cloud key while the cloud key is still using the 1111 or 888 to do some strange DNS queries let's go to the cloud key to find it out okay in the right side Linux session let me SSH into the cloud key the cloud key is also Runing a Linux in order to find out how the name resolving works we first check this Linux configuration file it's pointing to this strange IP address
• 07:00 - 07:30 apparently we already see it's working differently than UniFi router so let's continue looking let's see what's happening on this IP address let me run the standard Linux command next stat try to find out who listening on the part number 53 okay only several of them the very first line is already the answer you can see this process name system D resolve it is listening on the part number number 53 this process is
• 07:30 - 08:00 providing the name server service to This Cloud key Linux if you are not familiar with the process name it's for the resolve D part of the system D so it's a service to provide network name resolution to local applications if you watched my first video you may remember for UniFi router it use DS mask but apparently for cloud key it's using different technology it's using the system D resolve D to find out the
• 08:00 - 08:30 resolve D configuration to see what's the external name server it used we need to go to the system configuration so for resolve D the default configuration folder is under Etc systemd resolve D config DOD folder let me CD to it no it doesn't exist then let me try systemd Okay this folder exist what's inside okay apparently you beated decides to
• 08:30 - 09:00 directly put the configuration file under the system D let's see what's inside the resolve d. config okay it's super simple it specifies the DNS servers that's why we see those ghost DNS queries they are not ghost at all they are simply from the cloud key and Cloud key is not following what we said in UniFi controller it has its own hardcoded name server so we are clear about this special scenario the reason I
• 09:00 - 09:30 want to discuss this first is in all the following scenarios you will see those annoying 8888 11111 DNS queries without having it discussed we will have difficulties to understand the real crucial traffics so we are done with this one let's move on to the first scenario in this scenario we keep all the settings default which means on the land part is Alter DS server for the Vlad we also keep the setting alter so
• 09:30 - 10:00 in the right side in UniFi network controller let's make sure for internet for the primary one part I revert back the DN server setting so that it's alter then from whe for example this V 10 let's Double Check Yes for DNS server is Alter so now it's alter settings all the way then in the wire shock as you can see the wire shock is running here it's monitoring the rout one part okay start capturing then in
• 10:00 - 10:30 the lower part from the V 10 Linux client let me dig x.com something's captured let me stop it let's examine what's captured this Source IP address is the router's one part IP address first DNS request is sent to this IP address before we continue let me show how my lab network works as you can see my home lab is behind another router
• 10:30 - 11:00 this main router is sitting in my home network this main router has a whe it has this2 subnet my home Labs router the uxc pro the one part is connecting to this home networks do2 subnet so that's why the one part the internet IP address for my home lab is in the2 subnet okay just to explain why you see the2 do1 IP address because that's the IP address
• 11:00 - 11:30 for my home network router hopefully it's clear go back to the first scenario so the first DNS query is sent to my home networks router that makes sense later we will check the backend configuration but you can see this strange DNS query it's sent to 1111 I never set my external DNS server to 11111 I simply keep it alter then why the system did this separate DNS query and then later you can see from my home
• 11:30 - 12:00 networks router it did reply and from the 1111 it reped as well so we have two things to clarify first where this2 do1 information is configured in backend second where this second DNS query 21111 where it comes from in the SSH session to the router I expect a DNS mask configuration file and Etc let me list
• 12:00 - 12:30 it okay so in fact this file is simply a link to this file now it's clear because we see both D servers let's try to understand so first you see the comment is dynamic name server and it's for the one part and the server is my home router's IP address so in unify network controller for the one part you can see for ipv4 configuration I choose the DHCP
• 12:30 - 13:00 which means the one part for my router get the IP address and the DNS server automatically from the Upstream server in my case the Upstream server is my home network it makes sense we receive this Dynamic name server and then for this 1111 thing the commment says is static name servers which means when you configure the one part with DHCP the system will automatically add this
• 13:00 - 13:30 so-called static name servers I don't like it in my opinion it's not good without letting the users know the UniFi router is leaking the users DNS queries to 1111 it may be a problem to some users it may violate their policies if you have any insights about why you be to even include this 1111 as the static name server why this one cannot be
• 13:30 - 14:00 simply removed please let me know in comment another thing I want to point out is by default if your system has two name servers so in our case we have the 2.1 and the 1111 right if the first one serves the DNS query successfully the second one won't be used at all but why in our case the system automatically queries both name servers the reason is in the DNS mask configuration the DNS
• 14:00 - 14:30 config file see this particular setting or servers by setting this flag it forces DNS mask to send all queries to all available servers but the reply from the server which answers first will be returned to the original requestor that's how the system works before we move on let's examine the client machine one more time see this right side we 10 Linux client because we set the routers
• 14:30 - 15:00 we 10 DHCP to alter which means the Linux client will also receive the DNS server configuration let's validate what's the current value go to the wired settings see the DNS is this 10.1 which is my router's V 10 IP address right internally the router use DNS mask to forward the DNS query to the real external DNS name resolver which are
• 15:00 - 15:30 these two21 and 1111 it's all clear about this very first scenario let's move on in the second scenario let's manually set the client machines DNS server setting so in this Linux machine go to wired setting then enter ipv4 let me say menu for IP address give it this subnet 10 IP address net mask for Gateway give it the
• 15:30 - 16:00 router's IP address then for DNS let me remove the order then hard code to 8888 okay apply settings and FSE the refresh so now in the client we have hardcoded DNS server at this time the router DNS server settings don't matter anymore it doesn't matter whether we have alter or we manually set it they won't be effective let me show you so in
• 16:00 - 16:30 the wies shck let me start capturing and then in the SSH session to the router let me run TCP dump and the interface ethernet 3.10 which is for whe 10 and for part let me say 53 right okay so I'm running two parallel package capturing one on the one part the other one on the L part more specifically for V 10 in the client let me do the same dig x.com okay
• 16:30 - 17:00 let me stop capturing let's examine the one part wire shock capturing first from the routers one part to 8888 and the reply is from 8888 you don't see the queries to 1111 as in first scenario because the UniFi routers DN settings are not relevant at all in this scenario then in the SSH session let's see what's captured for V 10 L interface the
• 17:00 - 17:30 request is from this Linux machine and the destination is Google then reply is from Google so basically the same information as we see in one part right this scenario is very simple and the complete end to endend process makes sense there's no surprise the system strictly follow what we set in the client site in scenario three let's manually set the external name server in
• 17:30 - 18:00 vlans DHCP server setting so let me go to VLAN 10 for DNS server let me say 8888 apply changes then for the client let me go to the wired setting this time let me use DHCP I don't want to do menu for this scenario apply changes refresh DHCP let's check what's the new setting see the DNS is 8888 it comes from the router from from whe 10 for this
• 18:00 - 18:30 scenario the one part DNS setting doesn't matter at all similarly I launched the wire shock for one part and in the SSH for ux3 Pro run TCP dump monitoring the ethernet 3 we 10 part then go back to the Linux client let me dig the same domain name x.com something happened in both capturing sessions see the wire shock the router from the one part send the
• 18:30 - 19:00 DNS query to 8888 and then it doesn't send the request to anyone else you don't see one11 right it makes sense from the wi shock side then let's check the SSH session so you can see this one from this Linux machine I can tell from the host name and the local domain name right the destination is directly Google it's not the UniFi router right and then the Google directly replied so
• 19:00 - 19:30 everything makes sense the whole process works as expected but this scenario has a problem the problem is not about the external Internet domain name it's about your local domain name for example for this V 10 in the DHCP setting I said it local domain name to be V 10. home.app but because I manually set the DHCP server for V 10 the client will bypass
• 19:30 - 20:00 the DNS mask for V 10 which means whatever I said here won't be effective anymore let's validate so from the Linux client let me dig itself debing 10 is its host name and this part is its local domain name right let me dig it see it got result back from Google and the answer count is zero of course Google doesn't know the IP address for my local machine but in fact UniFi router does
• 20:00 - 20:30 know that you can even tell from the left side SSH session see this one the system knows the the main name for my Linux client but because the Linux client bypass the UniFi router that setting is not effective why the client bypass it we didn't force it to bypass it it's simply because we changed the V tense DN server and then the Linux client derived the change from DHCP okay so this is one potential problem if you
• 20:30 - 21:00 choose this way to change the DNS server for scenario four instead of changing the whe 10 DNS let's change the one Parts DNS server setting so in the right side UniFi network controller for V 10 let me change the DHCP server back to alter then for the one part primary internet change the DNS server to 8888
• 21:00 - 21:30 apply changes then from the Linux client Let me refresh the hcp setting disconnect reconnect see the DNS server is 10.1 so it is the UniFi router even though in the one part we already changed the DNS setting it doesn't impact our V 10's DNS server setting the Linux client still treat the router as the DN server so internal the router will run DNS mask it will forward the
• 21:30 - 22:00 DNS query to external DNS name server then let me restart the capturing in wir shck and in SSH run the same dig command dig x.com stop capturing let's see what's captured in wies shck so there's only one request from the router to Google and Google replied back no surprise then if we check the SSH this time is different than previous scenario
• 22:00 - 22:30 see the source is still the de in 10 Linux client but the destination is not Google the destination is the router itself because DNS mask is running on this IP address to act as a local DNS name resolver and then even the reply is coming from the router not from Google so internally the router is doing the forwarding okay so all the traffic F makes sense and in the end see the Linux
• 22:30 - 23:00 client it got reply back from this DNS server which is the router so the Linux client doesn't know the existence of 8888 at all it doesn't care it directly talks to the router okay then let me restart the capturing this time let me dig the local domain name okay stop capturing see the wire shock there's no DNS query at all about this dig while why because the UniFi router knows this
• 23:00 - 23:30 domain name is a local domain name it didn't bother asking Google it directly handle it internally within the DNS mask and then in the left side in SSH you can see the similar DNS query asking the V tense DNS local server and then the DNS mask replied in this scenario both the Internet domain and the local domain work if you compare this one with the web very first scenario with test
• 23:30 - 24:00 remember in the scenario one we see a strange annoying DNS query to 1111 right but this time we don't see it why is that let's check the DNS mask resolve configuration file let me display this configuration file for DNS mask see this time it only has one entry and the commment says static because this time we are not relying on the DH CP for the one part we hard code the DNS name
• 24:00 - 24:30 server that's why it has only one entry and this entry is already a static name server it doesn't have Dynamic name server because it already has a static entry the system didn't add the additional one which is 1111 that's why we only have one active external name server which is 8888 the very last scenario for this video Let's see what if you use py hole in this configuration
• 24:30 - 25:00 I have a Linux machine running py hole and Unbound and in the py hole configuration you can see it's Upstream DNS server is pointing to Unbound and in the right side let me show you the nbound configuration so the configuration file is named pyo do config it's under this folder display it it's a very simple configuration file because in this particular server I
• 25:00 - 25:30 simply enabled the do DNS over TRS so in forward Zone I use Google to forward the DNS query too so it's very simple straightforward setting in pyo and andbank side then let's see how it works in UniFi of course in UniFi network controller I need to rever back the one part setting even though it really doesn't matter in this case but I still want to make it utter then go to network
• 25:30 - 26:00 let me use V 10 as example in the DNS server side I need to use the pyo server IP address so let me find it out okay 10135 apply changes then because we changed the vland 10 DNS server I need to refresh the DHCP in the Linux client let's check the current DNS
• 26:00 - 26:30 server see it's from the pyo server right let me start capturing in wi shck let me first dig x.com you see nothing's captured in wire shck why remember I used unband and I enabled do so now the DNS queries are not using DNS protocol anymore it's using the TRS so let me change the display filter to TRS okay so now you see the query it's
• 26:30 - 27:00 from the router to Google and it's in TRS all the package are the encrypted TCP Communications I have no way to see what they are talking about because they are in TRS protocol and then see the Linux client it got result back from pyo and it got the correct result back if we choose to take the local domain name let's try it let me enable the wire shock very quickly then dig it see
• 27:00 - 27:30 nothing's captured py hole plus Unbound is smart enough because this domain name is local domain name they didn't send the query to Google okay this is the end of the video it's a very long one back and force changes thanks for watching