Pi-hole + Unbound + DNS Over TLS (Ubiquiti/UniFi/DoT/DoH)

Summary

In this comprehensive guide, Creator 777 or 404 takes us through the intricate setup of Pi-hole and Unbound with DNS over TLS, focusing primarily on DNS settings and security configurations within a Ubiquiti/UniFi network. The video covers the importance of DNS resolvers and the potential security hazards of incorrect configurations. By explaining the integration of Pi-hole for ad blocking and Unbound for DNS resolution, it provides a detailed walkthrough for setting up a secure DNS environment at home, emphasizing the necessity of encrypting DNS queries using TLS to counteract possible Man-in-the-Middle attacks.

Highlights

• Understanding DNS and its function is crucial for setting up secure networks 🌐.
• DNS queries can be intercepted or redirected if not properly secured 🛑.
• Pi-hole modifies DNSMasq to act as a DNS proxy and ad blocker 💻.
• Unbound and Pi-hole together provide comprehensive DNS security 🛡️.
• Using DNS over TLS protects against Man-in-the-Middle attacks 🔐.
• Securing DNS traffic is vital for maintaining privacy on the internet 🕵️.

Key Takeaways

• DNS is more complex than it appears in OS settings 🧩.
• Pi-hole acts as a DNS sinkhole to block unwanted domains 🚫.
• Unbound provides secure DNS resolution by querying authoritative servers 🔍.
• Combining Pi-hole and Unbound offers a robust home network DNS setup 🏠.
• DNS over TLS (DoT) enhances privacy by encrypting DNS queries 🔒.
• Configuring DNS over HTTPS (DoH) requires additional steps 💡.

Overview

Navigating the complexities of DNS can be daunting, but with the right setup, it becomes a powerful tool for enhancing your home network's security. The video delves into the specifics of how DNS works, showcasing its importance beyond just being an address look-up service.

By integrating Pi-hole and Unbound, users can create a comprehensive solution that not only blocks unwanted ads but also ensures that DNS queries are secure and direct. The setup detailed in the video uses Pi-hole as a DNS sinkhole, preventing malicious queries from connecting to harmful sites.

Enhancing this setup further, the inclusion of DNS over TLS shields your queries from potential interception, a method particularly pertinent for those concerned with privacy. This configuration ensures your digital footprints remain minimal and your internet experience remains uninterrupted and secure.

Chapters

• 00:00 - 00:30: Introduction to DNS Settings and Resolvers The chapter introduces the topic of DNS settings and resolvers, focusing on how users can interact with DNS configurations on operating systems like Mac OS. It describes the process of navigating to the network settings, specifically the Ethernet settings, and how to define a DNS server there. The chapter explains the function of this server in resolving domain names to IP addresses, correcting common misconceptions about its role.
• 00:30 - 02:00: How DNS Queries Work This chapter explains the workings of DNS queries and responses. It begins by showing a simple diagram of how a DNS query is processed. Initially, a user program that needs to access an internet resource only knows the domain name, not the IP address. To find the IP address, it sends a query to the DNS server configured in the operating system. The chapter highlights that this is a simplified explanation and that real-world situations can be much more complex.
• 02:00 - 03:00: Focus on DNS Resolver and Pi-hole The chapter discusses DNS resolvers, highlighting their role in forwarding queries to DNS name servers to retrieve IP addresses. It clarifies that a resolver, rather than being the main name server, acts as an intermediary that performs the necessary steps to provide DNS responses to user programs. The text implies the importance of correct configuration, hinting at issues that might arise if the resolver is misconfigured.
• 03:00 - 04:00: Introduction to DNSMasq and Pi-hole Functionality This chapter serves as an introduction to DNSMasq and Pi-hole, explaining their functionalities. It highlights the risks associated with DNS name server vulnerabilities, and the importance of having a robust DNS resolver. The chapter focuses on the role of DNSMasq as a foundational element for Pi-hole. Furthermore, it discusses potential scenarios and impacts when only Pi-hole is configured in a home network.
• 04:00 - 08:00: Pi-hole in Action The chapter titled 'Pi-hole in Action' discusses the functionality and necessity of the Pi-hole service, focusing on how it works and why users should consider using it. It outlines the steps for configuring Pi-hole alongside Unbound to ensure they operate cohesively.
• 08:00 - 12:00: Introduction to Unbound DNS Resolver The chapter titled 'Introduction to Unbound DNS Resolver' discusses the lightweight software often utilized across various Linux distributions. It's likely used daily due to its integration in numerous IoT devices. The software is versatile, though it's primarily described as a DNS proxy and DHCP server. In one example, DNS mask plays a role in network management.
• 12:00 - 16:00: Configuring Pi-hole and Unbound Together This chapter explains how to configure Pi-hole with Unbound. It describes that DNS mask acts as a DNS proxy rather than a real recursive resolver. DNS mask is used to send requests from your home network to the recursive resolver on the internet. Pi-hole is highlighted as a popular tool in this configuration.
• 16:00 - 20:00: Testing Pi-hole and Unbound Setup The chapter discusses the core functionality of Pi-hole, which is essentially a modified version of DNSMasq. Pi-hole acts as a DNS sinkhole, meaning it suppresses unwanted DNS queries by sending them into a 'sinkhole,' similar to a black hole. This feature helps in blocking unwanted domains effectively. Pi-hole refers to its DNS capabilities as FTL DNS, or 'Faster Than Light' DNS.
• 20:00 - 30:00: Security Concerns and DNS Over TLS Setup This chapter provides a practical walkthrough for setting up DNS over TLS in a controlled lab environment. It begins with a description of the lab setup, which consists of three Linux virtual machines: one serving as a Pyle and Unbound server, another as a DNS client, and the third as a network traffic monitor using Wireshark. The chapter is likely to delve into the functionalities of these machines, demonstrating how the DNS client sends requests for name resolutions, and how the server and monitoring tools interact in this setup.
• 30:00 - 24:00: Conclusion In this chapter, the author discusses network configurations in their lab environment, specifically focusing on the use of UniFi switches and routers. The author has set up a DNS server configuration under the DHCP server, particularly hard-coding the DNS server to a specific IP address for a pyo Linux virtual machine. The chapter concludes with a mention of using Google's DNS server for DNS configuration.

Pi-hole + Unbound + DNS Over TLS (Ubiquiti/UniFi/DoT/DoH) Transcription

• 00:00 - 00:30 we are all very familiar with the DNS setting in the operating systems for example in this Mac OS in the ethernet network setting if I go to details in DNS yes I can designate so-called DNS server you may think yeah this is the server which is reaching out to those DNS name servers to get the IP address for a given main name right in fact the
• 00:30 - 01:00 situation is much more complicated for example here what you see this IP address is simply my router this is a simplified diagram about how DNS query and response work you have a user program it needs to access a internet resource but it only knows the domain name for IP protocol you need the IP address it send the query to the DNS server you configured in your operating
• 01:00 - 01:30 system which we just saw in fact what you configured is simply a resol not a the main name server this resolver will forward your query to different levels of DNS name servers it will do all the lag work get the IP address for you and then provide the result to the user program as the DNS response you can see if this resolver is pointing to wrong
• 01:30 - 02:00 DNS name servers or even worse itself is hacked you can imagine what dangerous situation your user program is in right so this video is mainly focusing on this resolver part in this video we will first talk about DNS mask which is what py ho is based on then let's talk about if you only have Pyle configured in your home network what is the situation here comes the here Z for this video and
• 02:00 - 02:30 bound service how it works and why you need it later we will cover how you can configure py hole and Unbound to make them work together then we discuss some weak points in the typical Pyle plus Unbound configuration in the end of the video let's talk about how we can make the configuration safer okay a lot of things to discuss let's jump into them let's start with DNS mask it is a free
• 02:30 - 03:00 lightweight software it's widely used in different Linux distributions it's very possible you are using it every day because it's widely used in different iot devices it can do a lot of things but the software project itself describe it as DNS proxy and the hcp server in this example diagram DNS mask is bring
• 03:00 - 03:30 inside your router so your DNS client within your home network send the request to DNS mask and the DNS mask act as a proxy to work with the recursive resolver on the internet to resolve the DNS domain name so here DNS mask is simply a stop resolver it's not a real recursive resolver that's why it calls itself DNS proxy py ho is very popular
• 03:30 - 04:00 among home users so the core functionality of py hole is nothing but modified DNS mask and the nature of py hole is a DNS syn hole which means if py hole doesn't like a DNS domain name it will simply throw it into the syn hole just like a black hole and Pyle refers to its DNS functionality as FTL DNS or faster than light DNS so let's see how
• 04:00 - 04:30 it works in action then we go back to this diagram this is my lab environment for this video I'm going to run three Linux virtual machines the top right one is for Pyle and Unbound server the lower right is a DNS client I'm going to use it to request DNS name resolving and in the lower left is a wire shock I'm going to use a to capture ethernet frames so
• 04:30 - 05:00 that we can understand the communications better I use UniFi switches and routers in my lab environment for my default Network I already configured the DNS server setting under DHCP server as you can see I hard code the DNS server to this IP address is for this pyo Linux virtual machine if I go to pyo's configuration you can see for DNS I use Google server
• 05:00 - 05:30 as the Upstream DNS server then in the lower part of the screen I already launched wi shck I filtered on the captured frames with DNS so you see nothing captured here because I don't have any DNS resolving going on yet but it is running now and in the right part I launched a terminal session so let me try to resolve a domain name which I
• 05:30 - 06:00 know is blocked by Pyle by default at service. google.com let's see what will happen if I try to resolve the IP address for this domain name okay let me stop the capturing let's examine the Dig result first in the right side the status no error but the result is all zero apparently this result is not really the IP address for the domain name right why why because it's blocked
• 06:00 - 06:30 so let's go to the left side you see only two frames first one from my client machine to the pyo machine asking for the IP address for this domain name and then the second frame from my pyo server to the DNS client it simply answers okay the IP address is all zero now let's see what if I request something I have never requested in the right side let me dig
• 06:30 - 07:00 x.com okay stop capturing so from the Dig result you can see it Returns the real IP address right in the left side let's see it has additional frames instead of just two now it has four let's see what are the four frames the first one the same thing from my client to the pyo server and the second one is from the pyo server to this destination
• 07:00 - 07:30 this is the Google DNS server which we configured in pyo okay and then the Google server tells the pyo server was the IP address and then the pyo server tells the result back to the DNS client that's how the DNS resolving works if you use Pyle so the py hole is simply a proxy it is a stop resolver it send the request to a real recursive resolver we are not done yet this time in the DNS
• 07:30 - 08:00 client let's s the same domain name again remember we just did it right so let's see what's the difference if we did it again okay now you see the differences first let's check the Dig result so this is the one we try to resolve the name the first time this is the query time for the second try see the difference the second try has much less time the response is the same the same IP address
• 08:00 - 08:30 for the same domain name then let's check the left side interestingly this time we again only have two frames we don't have the frames for the Pyle to communicate with Google DNS server why is that because pyo cached the domain name resolving result so that it can save time if the requested Dom main name is already in cash I believe after these three short demos you understand pyo's
• 08:30 - 09:00 basic functionalities go back to the diagram Pyle receives the DLS name resolving request from the client it will check whether the domain name is in the cache whether it's blocked if the answer is no it will simply forward the request to external Upstream DNS server sorry I just realized a typo is a DNS server not DBS for sure now we can talk about ound this is a document from pyo
• 09:00 - 09:30 it explains the problem who you can trust because pyo simply forward your DNS request to external DNS resolver what if the DNS resolver is compromised for example if you request the IP address for your bank instead it send you a fishing site so that leads to the need of okay if you don't trust the external DNS resol how about you run
• 09:30 - 10:00 your own DNS resolver that's what Unbound is for here is how mband works so your DNS client send the DNS query to mband nbound First reach out to the root name server let's say the DNS client asks for x.com the first root name server will tell mband who handles.com once mband knows who handles.com it will will reach out to that server which is a
• 10:00 - 10:30 top level domain name server ask for a second question which is who handles x.com this top level domain name server gets the answer back to ound and ound ask the third question to the third name server this time the name server is the second level name server or authoritative domain name server so this time this server will know the final answer which is the authoritative answer
• 10:30 - 11:00 was the IP address for x.com once this server returns back to ound Mand knows the answer the client asked for and then it will handles the answer back to the DNS client if you remember in the beginning of the video we talk about how DNS resolving works right this is very familiar it's exactly the same way because Unbound is nothing but a DNS resolver the only special thing is it runs by yourself your own Hardware
• 11:00 - 11:30 maintain it by yourself that's the special thing for ound since many home users are already running py hole as the ad blocker it's naturally without any new investment on Hardware you can easily run and bound together with pyo so the combination of the two can work very well it will become your own ultimate DNS solution in your home network on pyo website there's very
• 11:30 - 12:00 detailed instructions about how to install ound and make it work together with pyo it's super easy it take just zal minutes you are done so I won't waste your time in this video let's go to the system to see how they work together let me first go to the server to check the nbound configuration the configuration file is pretty straightforward in the beginning it indicate the interface and the part number which will be used in pyo
• 12:00 - 12:30 configuration and by default ipv4 UDP TCP they are all enabled if you scroll to the end it simply indicate what the subnet are for SOC called private address or your local network very simple it even doesn't need any configuration about the root name server you don't need to worry about that if you don't want to so let me create this configuration file then let's check the
• 12:30 - 13:00 pyo setting in pyo remember before we add Unbound we have the Google enabled as the Upstream DNS servers right so now we have our own DNS resol so we don't need this part anymore I disabled this setting in the custom part I added one which is our nbound server this IP address and part number are what we configured in the nbound configur configuration file we just saw so now we
• 13:00 - 13:30 are ready to test it out using Pyle plus nbound let's see what's the difference from end user experience perspective and what are the problems in the wi shck I already started the capturing and filtered on the DNS frames in the right side in the DNS client let me try to dig a random domain name let's say abc.com okay a lot of frames are
• 13:30 - 14:00 captured let me stop capturing remember last time when we only had the py ho without ound installed the captured frames were pretty straightforward right py ho simply forward the query to external DNS resolvers we had much less frames captured but this time see yes the first one easy to understand is from my DNS client to the pyo server but then you see starting from the second one
• 14:00 - 14:30 things are different from the pyo plus ound server it send a request to this IP address and then there are whole bunch of back and force between this ound server and various DNS servers why there are so many see the diagram the simplified flow it need to quer different DNS servers for different reasons that's why there are so many back force and then in the end it
• 14:30 - 15:00 received the IP address from the authoritative domain name server a lot of things happen it's so complicated because the weightlifting the the work was really done by a server running inside your home from the nbound so that's why many people complain once they enabled ound they can feel the internet speed are impacted you may have the similar experience depending on your usage scenario it may be a problem
• 15:00 - 15:30 basically only the first time the mang need to go through all the processes to to resolve a domain name but if you reuse it it will be cached by Pyle plus Mound so it won't take a lot of time this video is not about performance testing or speed tuning for ound so I won't spend time on that part if you want you can do more research what I want to focus on is about the security part see how my DNS client communicate
• 15:30 - 16:00 with pyo plus ound through DNS protocal if I go to the captured frame details even from the description you can already see I want to visit abc.com is that a problem for you for some people maybe yes then see all the traffics between the abound server and the external DNS servers they are all in clear code using the s protocol for any
• 16:00 - 16:30 of them you can clearly see all the details what are the domain names where is from where is two right many people don't like it they want to hide the information from outside so that's why we want to improve our configuration furtherly we want to secure the communications for the red Dash lines the DNS client communicate with Pyle plus nbound using DNS protocol so this
• 16:30 - 17:00 is one weak point and then when ound communicates with the external DNS servers is using DNS protocol as well it's another weak point why they are weak because the bad guys can do DNS spoofing there may be many in the middle attacks to your Communications I don't really worry too much about this part because this part happens inside your home network the the right side part which happens on internet may be more
• 17:00 - 17:30 concerning so in the remaining part of the video let's see how we can secure this part using DNS or TLS if you want here just provide you some information you can do something in the left part inside your home network utilizing DNS or https or DNS or trls you may ask what's the difference between do and the do isn't https based on TRS the reason for
• 17:30 - 18:00 two different terms do and do is simply because they are originated from different standards they Evol independently and you may also hear another term DNS SEC this is not related to our today's topic it's more about the DNS server how they communicate we will not spend time on the left part but this diagram just give you some idea this is
• 18:00 - 18:30 one possible approach so you may want to run n Jinx server inside your home network maybe on the same Hardware as pyo and Unbound you use it simply as a reverse proxy so that your DNS client can communicate with your DNS server using https even within your home network you can secure the communication then when it comes to different operating system there are different ways none of them is
• 18:30 - 19:00 very easy they work differently so it's not as simple as what you configur in tcpip simply indicate the DN server name no it's more complicated but in this video we will focus on this part DNS over TLS or do to enable TLS we need to have the certificate bundle fortunately I'm using debing is already there after installing the default operating system
• 19:00 - 19:30 under this folder there is sear file already I simply want to include this file in my ound configuration let me show you the configuration file which already had the TRS enabled the beginning part is the same as previous one scroll to the end you'll see a new section so remember our previous example ends here right the
• 19:30 - 20:00 private address this part is new if you want to enable TRS TCP Upstream yes TRS Upstream yes and then you need to include the certificate bandle we just talked about here the last section is called forward Zone because now you are using TLS andand will simply forward your DNS request using TLS to the server you designate here so what I'm saying is
• 20:00 - 20:30 forward the request through TLS to this IP address we have a little bit more configurations if you compare to the non TRS case but not complicated at all let me exit it because I just changed the configuration so I need to restart the nbound server okay so we restarted now let's do a similar testing we still capture the frames but this time Unbound has the TRS enabled let's see what's the
• 20:30 - 21:00 difference I just started wies shck I filter on DNS so what you see now has nothing to do with my testing because I haven't started my testing yet so in the right part let me dig a brand new domain name just to avoid the cach so let me use fox.com cck okay stop capturing see the result is alarmingly simp simple there are only two frames captured so see the
• 21:00 - 21:30 first one my DNS client send to the anbang server asking for fox.com this part is still in clear code it's not encrypted because we haven't enabled the DNS or https so this is not we want to check then see the second package my ound simply responded back telling the DNS client the IP address where is the DNS request nothing's here is there anything wrong why we don't see anything
• 21:30 - 22:00 between these two frames because now we are filtering using DNS all the DNS request happened on internet they are not using DNS protocol anymore remember we just enabled TRS so the protocol has changed then let me remove this filter let's see what's happening now we see much more communication frames see this one is from my DNS client to Unbound
• 22:00 - 22:30 server right nothing's interesting it's asking for fox.com IP address then see Unbound communicate with this 8888 server using trls protocol so why TRS because we enabled the TRS in nbound configuration why the 8888 server because in the nbound configuration we configured it to use the Google server in the forward zone right so it's clear
• 22:30 - 23:00 about this Frame later it's just Communications between my nbound server and the Google server I have no way to see what's happening because they are using TRS they are encrypted in the end nbound server received the IP address again through TRS the nbound server simply reply back to my DNS client this time it's in clear code with the IP address for Fox just by using the simple configurations
• 23:00 - 23:30 I enabl the DNS or TRS right but you may already observe that the other difference see this time once you enable TRS the mound server is not really asking questions all the way from the root server to the top level domain server to the authoritative domain server no it simply forward the query to the Google server that's another difference okay so this is the end of
• 23:30 - 24:00 the video I know it's a long one thanks for watching