What is DNS? (and how it makes the Internet work)

Summary

Highlights

• Discover how DNS works as the essential phonebook of the internet, translating domain names into IP addresses. 🌐
• Learn about the multi-step journey of DNS queries through caches, resolvers, and authoritative servers. 🚀
• Understand the importance of DNS security protocols like DNS over HTTPS, preventing eavesdropping and spoofing. 🔐
• See how Twin Gate offers innovative solutions for secure DNS practices in both personal and professional environments. 🔧
• Explore the various DNS records that make up the backbone of internet communication, from A records to MX records for email. 📬

Key Takeaways

• DNS acts as the internet's phonebook, enabling browsers to find websites using domain names instead of IP addresses. 📖
• A DNS query journey involves multiple servers, from resolvers to authoritative sources, to find a website's IP address. 🕵️‍♂️
• Security is a crucial part of DNS, with solutions like DNS over HTTPS providing encrypted queries to avoid snooping. 🔒
• Tools like Twin Gate can help enforce secure DNS practices across networks, protecting user data. 🛡️
• DNS is not just about IP addresses; it involves a range of records like MX for mail and PTR for reverse lookups. 📨

Overview

Chapters

• 00:00 - 00:30: Introduction to the Concept of DNS This chapter introduces the concept of the Domain Name System (DNS). It explains how web browsers function in terms of navigating to websites. The transcript uses a metaphor to illustrate the concept: comparing a web browser trying to access a website to someone attempting to call a friend without knowing their phone number. The key idea is that while users enter website addresses, the browser actually needs the IP address of the server where the website is hosted, akin to needing a phone number to make a call.
• 00:30 - 01:00: The Function of DNS in Browsers The chapter explains the role of DNS (Domain Name System) in browsers. It compares DNS to a contact list on a phone, where you may not know a person's phone number but can find it by searching for their name. Similarly, your browser does not know IP addresses for websites but refers to DNS servers to map domain names to their corresponding IP addresses, like a contact list does with phone numbers.
• 01:00 - 01:30: Why DNS is Critical for the Internet This chapter explains the importance of DNS (Domain Name System) in the functioning of the internet. DNS translates human-friendly domain names into IP addresses that computers use to identify each other on the network. For example, when you type a website address into your browser, a DNS server translates that domain into an IP address, allowing your device to connect to that website. This process is crucial for internet functionality, as without it, websites, emails, and other internet services would fail to operate. The chapter highlights that although this process can sometimes fail, leading to disruptions, it is essential for the smooth operation of the internet.
• 01:30 - 02:00: The Complexity and Vulnerabilities of DNS This chapter delves into the intricacies and weaknesses of the Domain Name System (DNS), a critical part of how the internet operates. The author explains that DNS processes can be vulnerable to hacking, highlighting the importance of using secure DNS services like the one from Twin Gate, the video's sponsor, which offers advanced DNS features. The chapter proceeds to demonstrate by tracing DNS queries made by a computer attempting to access a particular website, showcasing the complexity behind a seemingly simple action of opening a web page.
• 02:00 - 02:30: Tracing DNS Queries This chapter introduces the concept of tracing DNS queries, part of an IT course that includes topics such as laptop and mobile device basics. The discussion starts with a scenario where a user launches a browser and types a URL, triggering the DNS client, or 'stub resolver,' on their machine to potentially utilize known IP addresses.
• 02:30 - 03:00: Exploring Stub Resolver and Caching The chapter discusses the function of a "stub resolver" in the context of domain name system (DNS) queries. It explains that the stub resolver first checks the local cache to see if the IP address of a visited website, such as academy.networkcheck.com, is stored. If the IP address is cached, it means the website has been visited before, so there is no need to query a DNS server. However, if it is the user's first time visiting the website, the stub resolver realizes it needs assistance and will reach out to a DNS server using the network configuration and IP address to obtain the necessary information.
• 03:00 - 03:30: Understanding DNS Server Configuration The chapter 'Understanding DNS Server Configuration' introduces the concept of configuring DNS servers and how this configuration can be provided by the DHCP server in your network. It references the use of Google's public DNS server, highlighting its IP address as 8.8.8.8, which is memorable and commonly used. The chapter explains the function of a Stub Resolver, which queries Google's DNS server for IP addresses, using the example of querying for academy.networkchuck.com. However, it notes that sometimes even Google's server may not have the requested IP address immediately.
• 03:30 - 04:00: Recursive DNS Servers and Google's Role Google's public DNS server acts as a recursive DNS server. It may not directly know the IP address for every website but can query other DNS servers to obtain this information, essentially asking 'a guy who knows a guy.' This process involves making multiple requests to locate the necessary IP address. Occasionally, the DNS server may use a cached IP address from a previous request, similar to a stub resolver, to expedite the process if someone has already visited a certain website. The function describes whether the DNS server needs to query others or can quickly provide an answer from its own cache.
• 04:00 - 04:30: The DNS Hierarchy and Root Servers The chapter titled 'The DNS Hierarchy and Root Servers' begins with a question about what happens if Google doesn't have the necessary information. It introduces the concept of a DNS hierarchy, likened humorously to mafia bosses, with the 'Roots' at the top. These Roots are operated by 12 major companies or organizations including NASA and DOD, which manage 13 server groups or named authorities. Contrary to what might be expected, these aren't just a handful of servers but a massive network of 1,865 servers distributed globally.
• 04:30 - 05:00: Top Level Domains and Their Servers The chapter titled 'Top Level Domains and Their Servers' discusses the function of root servers when resolving domain names. Root servers, described as 'the mafia bosses', are not responsible for the direct mapping of domains to IP addresses. Instead, they focus on top-level domains (TLDs) such as .com and .net. When a service like Google queries these root servers, it is primarily concerned with these TLDs, as they represent the top layer of internet domain structure. The chapter offers a metaphorical insight into the hierarchical nature of domain resolution on the internet, emphasizing the role of TLDs.
• 05:00 - 05:30: Second Level Domains and Authoritative Servers The chapter titled 'Second Level Domains and Authoritative Servers' explains the concept of top-level domains (TLDs) like '.co', '.coffee', and country-specific TLDs such as '.jp' for Japan or '.ph' for the Philippines. The focus is on the role these TLDs play in domain name systems. They essentially delegate tasks without directly providing IP address information themselves. Instead, they maintain a list of other DNS servers that can assist users with these top-level domains. This delegation is likened to lazy behavior, as the main role is assigning tasks to 'middle management' or other DNS servers.
• 05:30 - 06:00: Role of Recursive DNS Server and Final Query This chapter explains the role of a Google recursive DNS server in resolving domain queries. It details how the server interacts with DNS root servers to obtain a list of authoritative DNS servers for the .com top-level domain. The process is likened to querying a 'Mafia Boss' root server that provides information on who manages the .com domain. The analogy highlights the hierarchical and authoritative nature of DNS server responsibilities.
• 06:00 - 06:30: Zone Files and DNS Record Types This chapter discusses the role of DNS servers in managing top-level domains, specifically focusing on the .com domain. It explains the process of how a Google DNS server interacts with root servers and top-level domain (TLD) servers, using example interactions such as querying gtld-servers.net to find the IP address for specific networks like academy.network. The narrative gives a step-by-step labeling of how DNS query and response work, emphasizing the hierarchy from root servers to TLD servers.
• 06:30 - 07:00: Security Concerns with DNS Queries The chapter discusses security concerns related to DNS queries, specifically the targeting of second-level domains (SLDs) and how top-level domain (TLD) servers manage their queries. An example is given using the domain 'check.com' where Google retrieves only specific information about domains. The role of TLD servers in directing these queries to the appropriate authorities for SLDs is highlighted.
• 07:00 - 07:30: DNS Over HTTPS (DOH) The chapter discusses DNS Over HTTPS (DoH) and explains the process of DNS querying. It elaborates on how databases or lists of authoritative servers for website domains function. The text compares the process to a 'know a guy who knows a guy' scenario, using NS lookup as an example. It describes how a query might be constructed and explains that the '.com' top-level domain (TLD) server will respond with authoritative server information for a domain such as 'networkcheck.com'. The authoritative server for 'networkcheck.com' mentioned in this chapter is CloudFlare.
• 07:30 - 08:00: Client and Server Support for DOH This chapter discusses the interaction between client and server support for DNS over HTTPS (DOH). The process is illustrated through a narrative, explaining how Google's recursive DNS server finally identifies that the next authority to be queried is CloudFlare's server, humorously named Pablo. The chapter highlights the step-by-step journey of DNS queries, culminating in Google sending a final DNS query to CloudFlare to retrieve the IP address for academy.network chuck.com.
• 08:00 - 08:30: Using Twin Gate for Secure DNS This chapter discusses the use of Twin Gate for securing DNS, featuring a character named Pablo who is knowledgeable about the domain network chuck.com. The focus is on the concept of a zone file, which contains important information such as the state of authority (SOA) record, used to identify the entity in charge of the domain. Pablo is the authoritative name server for chuck.com, able to provide details about various network components, including the IP address for both networkchuck.com and its subdomain academy.networkchuck.com. The chapter underscores the importance of understanding zone files and the role of the name server in managing domain queries for a secure DNS setup.
• 08:30 - 09:00: Additional Security Measures and Tools This chapter discusses additional security measures and tools for domain handling and internet navigation. It highlights a scenario involving Pablo, celebrating Google's accomplishment of updating domain-related functionalities with the code 104182.1.39. Pablo is depicted quickly updating his cache with this new information, which is crucial for later use. He is then depicted managing the computer's stub resolver and the IP address tied to academy.network. This involves understanding domain segments like 'academy' positioned to the left of second-level domains, emphasizing the importance of correctly managing domain-related information.
• 09:00 - 09:30: Understanding Different DNS Records The chapter "Understanding Different DNS Records" explains the concept of subdomains and how they function. It highlights the example of creating a subdomain for an academy and pointing it to a different URL, separate from the main website 'networkchuck.com'. It emphasizes the seamless and almost instantaneous nature of DNS operations, which work in the background every time a user visits a website for the first time, creating an impression of magic.
• 09:30 - 10:00: TXT Records and Their Uses This chapter discusses the security vulnerabilities associated with DNS queries, particularly highlighting the use of UDP port 53 for DNS queries. The lack of encryption in this process means that the DNS queries are sent in plain text, exposing them to potential interception and exploitation by malicious actors, such as hackers. The chapter also mentions the ease with which such traffic can be monitored or intercepted, underscoring the need for more secure DNS resolution methods.
• 10:00 - 10:30: DNS and Email Security The chapter titled 'DNS and Email Security' delves into the vulnerabilities and solutions related to DNS queries. It highlights the potential risks of DNS spoofing, where malicious entities can manipulate the DNS server responses to redirect users to harmful websites. This threat isn't limited to hackers; even ISPs can view DNS queries, exposing users' online activities. The discussion emphasizes the growing importance of DNS security with assurances that solutions are available to protect users from such risks.
• 10:30 - 11:00: Buying a Domain and ICANN's Role The chapter discusses acquiring your own Domain Name System (DNS) and highlights the significant role of DNS over HTTPS (DOH) in securing online connections. It explains that DOH allows DNS resolution over the secure protocol HTTPS, which is the same protocol used for accessing websites securely, such as YouTube. This secure connection ensures encryption and prevents hackers from viewing your activities online, thus enhancing privacy.
• 11:00 - 11:30: Choosing Name Servers and Updating Registries The chapter discusses the security enhancements brought by using HTTPS for DNS queries. Normally, DNS traffic is identifiable by its use of UDP Port 53, but encrypting it with HTTPS makes it indistinguishable from regular web traffic, enhancing security against eavesdropping. Even if a hacker intercepts web traffic, they cannot see the DNS queries because they are encrypted and disguised as regular HTTPS traffic.
• 11:30 - 12:00: WHOIS Database and Privacy The chapter explores the WHOIS database in the realm of internet privacy, focusing on how DNS (Domain Name System) traffic can be indistinguishable within general web traffic, much like "Where's Waldo" without his signature attire. It highlights the increased privacy through the use of DNS over HTTPS (DoH). The implementation of DoH requires both the user's browser and the DNS server to support this protocol, which is now widely supported, enhancing privacy by encrypting DNS queries using HTTPS.
• 12:00 - 12:30: Hosting Your Own DNS Server The chapter discusses the importance and challenges of enabling DNS over HTTPS (DOH) on client devices. While many popular DNS servers like Cloudflare and Google support DOH, and it's important for client devices to have it enabled, managing this on multiple devices can be time-consuming. The chapter further introduces Twin Gate as a remote access solution to simplify network management while traveling or working remotely.
• 12:30 - 13:00: Intro to DNS Hacking and Conclusion The chapter introduces DNS hacking and the significance of using secure connections for accessing network systems remotely. Nick connects to the studio's network from Florida using a Twin Gate client, demonstrating the importance and ease of establishing a super secure connection, even remotely. This method emphasizes a zero trust access model, allowing granular control over permissions. The narrative shifts focus to the concept of secure DNS, hinting at a demonstration on using Twin Gate's dashboard to manage and secure such connections.

What is DNS? (and how it makes the Internet work) Transcription

• 00:00 - 00:30 Your web browser is kind of dumb. You see, when you type in a website address like academy.network shock.com, it has no idea how to get there because to actually visit the website, you have to know the IP address of the server it lives on. It's essentially its phone number and your web browser doesn't know it, but if you press enter, it does get there. What am I talking about? It's kind of like this. If I actually, hold on. If I handed you an old phone and said, here, call your friend Bernard. Go ahead. There you go. Put the number in. You couldn't do it. You don't know Bernard's phone number. We don't memorize those anymore.
• 00:30 - 01:00 You just know his name, Bernard. But if you could grab your phone, open up your contacts app and type in Bernard Boom, you would see his phone number and then you could dial the number. Oh, that's really fun. That is DNS the domain name system. Your browser doesn't know Bernard's phone number or the IP address for academy.network check.com, so it has to check its contacts, and in this case that'll be a DNS server. A server that's similar to your contacts app will map domain names or website
• 01:00 - 01:30 names to an IP address, Bernard's name, Bernard's phone number, website name, IP address, so your browser will query or ask the DNS server, Hey, what's the IP address for Academy network check.com? I got to get there and the DNS server will respond with the IP address and boom, you're good to go. You can visit that website. This DNS process is vital to how the internet works without it, websites, emails, and pretty much anything to do with the internet would break, and it often does when DNS stops working, which often happens because this process I outlined here is a bit more complex
• 01:30 - 02:00 than I've shown. Also, this process can be hacked. There are ways to secure yourself. I use secure DNS from Twin Gate, the sponsor of this video, twin Gate is my VPN replacement, and they have amazing DNS features. We'll talk more about them here in a bit. This is going to be fun. We're going to trace all the DNS queries that your computer will use to get to academy.network chuck.com, and there's quite a few. You're about to see how the internet works. So here we go. You open your browser, you're ready to learn because you want to go out to academy.network chuck.com
• 02:00 - 02:30 where I teach on this and many other things like our new course, intro to laptops and mobile devices, part of our new a plus course. If you're just getting started in it, oh, by the way, here's you, you're excited and you got a cup of coffee so you're ready to learn it. That just gave you a refill coffee break. So you launch your browser and type in academy.network chuck.com. Now, before your computer goes anywhere, he might actually already know the IP address of academy.network chuck.com. He'll use his stub resolver, which sounds hilarious. I love saying that. It's just the term for the DNS client running on your machine,
• 02:30 - 03:00 but it's called a stub Resolver. The Stub Resolver will check your cache because if you've recently been to academy.network check.com, the IP address might be there stored in your cache for safekeeping, and if it is, you're good to go. You don't have to go out to a DNS server and ask it questions, but in this case, this is your first time. You've never been there before. That's crazy. How have you never been there before? Let's keep going. So your step Resolver knows he needs some help. It's time to ask his DNS server, his DNS server. What do you mean your computer will have? And it's a network configuration along with its IP address, A DNS server that I can talk to.
• 03:00 - 03:30 This is something that you configure or it's just given to you by the D HT P server in your network. What is that? You'll learn about that in Network Check Academy. Check it out. You're about to go there right now. A very common DNS server you might use is Google. They have a DNS server found at the IP address, 8 8 8 8. It's one of the very few IP addresses I have memorized. So your Stub Resolver will send a query a DNS query saying, Hey, Google my public DNS server. Surely you know the IP address of academy.network chuck.com, right? And Google might go, actually, no, I don't Wait, wait, what?
• 03:30 - 04:00 Yes. You see Google's public DNS server is a recursive DNS server, which means he may not know all the IP addresses for every website, but he knows a guy who knows the guy who can tell him he's going to make multiple requests to other DNS servers to find out, are you ready for this adventure? I'm telling you, it's a crazy one. Now, sometimes he may not have to ask anybody because similar to your Stub Resolver, he may have some cash. Someone may have already been to academy.network check.com, and he's got the IP address saved in his cash, and in that case, he'll just tell you, but we're going to assume he doesn't.
• 04:00 - 04:30 So if Google doesn't know then who does? Now the next step involves some mafia bosses. Yes, DNS does have a hierarchy, and at the very top are the DNS mafia bosses. I'm not kidding. It's kind of crazy. They're called the Roots. That's for real. The roots are run by these 12 companies or organizations, big names like nasa, the DOD ign, they control and manage 13 server groups or 13 named authorities, and these are hundreds of servers strewn about the world. Here's the map. Oh, did I say hundreds? I meant 1,865.
• 04:30 - 05:00 So Google will reach out to one of the root servers, the mafia bosses, because surely of anyone, they would know the IP address of academy.network chuck.com, right? Wrong. These are the bosses. They don't deal with the peasant work of domain to IP address mapping. Now, they're all big picture. All they care about and know about are top level domains or TLDs. What is that? Well, when Google talks to these root servers, he's only asking about one thing. This section of our URL right here, the.com, this is a top level domain or a T ld, so.com, dot net,
• 05:00 - 05:30 dot co, dot coffee, these are all top level domains. Also country specific ones like.jp for Japan or pH for the Philippines. Now, what does it mean they handle the top level domains? Well, it means they're lazy. They delegate everything, meaning they're not going to tell you any IP addresses for any domains, but they'll say, you know what? I know who can help you. Middle management, my underling. So what they maintain is a list of other DNS servers that can help you with these top level domains. So in our example here,
• 05:30 - 06:00 our Google recursive DNS server is only asking about the.com top level domain, and our root server will return a list of other DNS servers that are responsible for that.com domain. And when I say responsible, I also mean authoritative. They're the bosses of those domains. Using NS lookup, the query might look like this, and we'll pick up one of the root servers here. I'll choose J, and we'll ask that mafia boss root server, Hey, who manages the.com top level domain, and the Mafia Boss root server responds with a database, a list of servers that are authoritative,
• 06:00 - 06:30 responsible for the.com top level domain. These servers here, these DNS servers are referred to as top level domain servers or TLD servers, but I want to make sure I'm labeling our journey here. The steps. So our Google DS server asks for it, the root server responds. He says, you can ask a gtld servers.net. He manages.com, talk to him. So armed with that knowledge, our Google recursive DNS server will send another query to a dot gtld servers.net because surely he knows the IP address for academy.network
• 06:30 - 07:00 check.com. Right? Wrong, he does it. It's a whole journey I told you, but Google knows that he's only asking about one very specific piece of information. This right here me network, Chuck, this part of our domain is called the second level domain or an SLD. So Google's not asking this T LD server, Hey, what's CIP address for academy.network chuck.com. Now he's asking, Hey, who manages network chuck.com? Who is the authority for that second level domain? And that's what top level domain servers do.
• 07:00 - 07:30 They keep a database or list of authoritative servers for website domains. I know it kind of feels like a, I know a guy who knows a guy situation With NS lookup. The query might look like this, and the.com TLD server will respond with an authoritative server or servers for network check.com. The second level domain, and as you can see here, the authoritative server for my network check.com domain is CloudFlare.
• 07:30 - 08:00 That is who manages my stuff. So now finally, the Google recursive DNS server knows who to ask. This whole process so far has been like, Hey, hey, to find out who might know, and now he knows the server is CloudFlare, his name is Pablo. I love their DNS server name server schemes. So Google sends one last DNS query, please, sir, you're the last top of my journey. Do you know the IP address for academy.network chuck.com? And guess what Pablo does? Pablo does.
• 08:00 - 08:30 Pablo knows everything about the domain network, chuck.com. He's got what's called the zone file, which looks something like this. Here's an example of a zone file starting with a state of authority record, an SOA essentially, Hey, who's in charge here? It's Pablo. He's the name server that you can contact to find out anything you want to know about network chuck.com, including things like and not limited to the IP address for network chuck.com. If you want to visit the main website, you should. It's really cool. And the reason we came here, the record for academy.network chuck.com and the IP address it belongs
• 08:30 - 09:00 to. Finally, oh my gosh, it's here. And that's what Pablo responds with. Good old 1 0 4 18 do 40 two.one three nine. Google has done it. He quickly updates his cash saving that precious tidbit of information for later. And then finally, he can tell us our computer, our stub resolver, the IP address for academy.network shock. And by the way, the academy portion of this domain to the left of the second level domain,
• 09:00 - 09:30 this is called a subdomain, which allows me to do cool things like make an academy and point just that URL, that website name to a different location, my actual academy from my main website network, chuck.com. Now, step back for a second and think about this. All of this happens every time you visit a website. It's magic, and it happens like that because when you visit a website you've never been to before, you just go there. No time really goes by. You don't even notice it. But behind the scenes, all this stuff is happening. That's so crazy. But what's also pretty stinking crazy,
• 09:30 - 10:00 the fact that this process is often done insecurely. You see, when you're PC your client, your stub resolver queries a DNS server. It will by default use UDP port 53. This is done in plain text, meaning it's not encrypted. It's naked for all the world to see. So if I were a hacker, if I were a hacker, and I've demonstrated this numerous times on my channel, I could sniff or get in the middle of that traffic, take that traffic, and I could just look at it without any problems.
• 10:00 - 10:30 I could see what websites you're visiting. If I really wanted to be bad, I could pretend to be a DNS server and respond with another IP address, maybe an IP address that goes to another server that's bad. This is what happens all the time. It's called DNS spoofing, and it's not just the hackers. You want to worry about your ISP, your internet service provider, the person providing you internet can also see your DNS queries, which means they can see what websites you're visiting. I don't want them to know that get out of here. That's why DNS security has become a pretty big thing. Thankfully, we do have a solution.
• 10:30 - 11:00 Let me talk about how you can secure your own DNS right now. A big hero to the rescue was a thing called DOH, which is really cool. It stands for DNS over H-T-T-P-S. This is actually pretty crazy. So H-T-T-P-S, this is the protocol we use to securely access websites. So right now as you're watching this video, you're on YouTube and you're connected to YouTube via H-T-T-P-S. That connection is secure and encrypted hackers can't see inside of that. They don't know what videos you're watching. No one does, but you and that guy standing behind you watch out.
• 11:00 - 11:30 So H TT PS is a secure encrypted connection. DNS, when it goes over H-T-T-P-S also becomes a secure connection. So we get things like encryption. Even if a hacker happened to be in the middle of a conversation, they were sniffing your web traffic, they wouldn't be able to see that DNS query, it's hidden. Not only is it hidden, it's wearing a costume. It's wearing an H TT PS costume. You see, normally it's pretty easy to identify DNS traffic when you're looking at traffic captures. You can search for things that are using UDP Port 53, but if DNS is using H-T-T-P-S along with all the other web traffic,
• 11:30 - 12:00 I can't identify DNS traffic, it's just all the website traffic. DNS is hiding in a crowd of people. It's like, where's Waldo? Except he's not wearing a bright shirt. He's just as a regular person, you would never know, okay, this sounds great, right? So how do you use DNS over https? Well, the short answer is it's pretty easy. There are a couple of considerations. You have to know, for example, the client, you, your browser has to support DOH, which thankfully most do nowadays. Also, the DNS server you're connecting to, the one you choose to connect to also needs to support DOH.
• 12:00 - 12:30 Choose a DNS server that supports DOH. Just search that CloudFlare Google. They all have it and makes sure your client has DOH enabled. Cool, that's great for you. But what about your family? What about your employees? Are you going to go to every device and make sure they're using DOH and they have the appropriate settings enabled and they're connected to the right DNS server? You could do that, but I don't have that time you. This is why I like to rely on tools like Twin Gate. Now, twin Gate is my remote access solution. So when I'm out and about traveling the world, like I for real use this when I was in Japan or when my employees are working
• 12:30 - 13:00 from home like Florida, Nick, this is what he uses to access our stuff here. He'll connect to our network in the studio using his Twin Gate client from Florida, getting a super secure connection to us. That's cool by itself, you should definitely try it. It's free for up to five users. It's zero trust access. You've got granular control over what anyone can access. I love it. I've been using it for a long time. But back to DNS, A cool feature we can enable is secure DNS. Lemme show you what it looks like. I'm going to log into my Twin Gate dashboard, and by the way,
• 13:00 - 13:30 I don't pay for Twin Gate and they don't give it to me for free. I'm using the free version right now. So in their internet security settings, they have what's called secure DNS. So essentially any Mac, windows or Linux computer with my Twin Gate client installed this policy forces them to use DOH. I can actually enforce that and make sure this is happening. I can choose which DOH server I want to use so I can use CloudFlare, Google Open DNS, next DNS. All these are public DNS servers, DNS or cursive resolvers that support DOH. Now, if I had some restrictions on what DNS servers my company could use,
• 13:30 - 14:00 I can specify a custom DNS server here, and this is pretty cool with client configuration, I can add this machine key to my clients and I can deploy this with any kind of MDM solution I have. And as long as this machine key is on their computer, it doesn't matter. If the Twin Gate connection is open and connected to my network, it'll still make sure they're using DOH, making sure the DNS queries are always encrypted and secure. It's persistent. Now, you also got fallback in case something loses connection, whatever that might be. You can say, you know what? Just fall back to the system's DNS. Maybe you got your DNS server handed to you from your ISP,
• 14:00 - 14:30 and it's actually their DNS providers. You don't want to do that. Then they're really seeing what you're doing. So in that case, you might want to go, Hey, I want to be pretty strict, require DOH, even when resolvers fail, and the resolvers would be the DNS servers themselves. Hey, network, Chuck from the future here. Twin Gate just gave me DNS filtering. They unlocked it for me. Thank you. Twin Gate. I'm going to enable it. Enable it for everyone. Okay, now let's edit our filtering profile. Allow list, deny list security categories that's already blocking threat intelligence feeds content restrictions. Oh yeah, Mike has a gambling problem.
• 14:30 - 15:00 Alex is always on Facebook. We'll leave YouTube on privacy protection. We can block ads and trackers done. This is pretty cool. Thank you. Twin Gate. I just turned it on and we already have so much in there. It's all from Nick, Florida, Nick and Austin's MacBook. I'm actually really excited about this. It's already doing stuff. If you're not already using Twin Gate, you need to use it. Check it out. Link below. I'm a massive fan of it, and I've got a video up here somewhere where I show you how to set this up and some really cool features of how it handles additional DNS. Now, back to DNS security. DOH is not the only option,
• 15:00 - 15:30 even though it is one of the more popular ones. We've got DOT or DNS over TLS, transport layer security, which also is secure and encrypted. We've got DNS Crypt doing a lot of the same things. DNS sec, which is actually a suite of tools on how to make sure every query and response is valid, not just encrypted. And then you have DNS servers like Quad nine that do advanced things like when you use them as your DNS server, they could do malware prevention. If you happen to be going to a website or URL, that's bad known bad, they can prevent you from doing that. Now,
• 15:30 - 16:00 DNS is more than just domain names to IP address mapping. Check this out. So looking back at our zone file for network check.com, there's a lot of stuff going on. Some things you're familiar with. Others we're like, what? So for example, right here we have what's called a records. These are our domain names to IP address mappings probably the most popular one you're aware of. Another one that we just saw as we were looking at our life of a query going through that process was a name server, otherwise known as an NS record. The NS record or name server record tells us what server,
• 16:00 - 16:30 what authoritative DNS server is responsible for a second level domain. So network shuck.com, this is his name server, or at least one of them. If you scroll down just a little bit more, you'll see this crazy thing quadruple a records overpowered. All it is is a domain name mapping to an IPV six address. I'm not going to cover IPV six and this video here just know it's bigger and more than IPD four addresses, but they have the same function. And if we scroll down a bit more, we're getting to some more exciting things. This is kind of crazy.
• 16:30 - 17:00 We have what's called MX Records or Mail Exchanger Records. These records identify what servers for a domain handle email. What does that mean? What means if you were to send an email to me, which my email address is chuck@networkchuck.com, let's draw it up here real quick. And if you're interested in sponsoring one of my videos, it'll be sponsor@networkchuck.com. When you type in this email address into your email client and you click send, your email server has to figure out who manages the emails for a network chuck.com, which server does that? So here is just a demo record.
• 17:00 - 17:30 You might see mail.network chuck.com. In reality, I use Gmail or Google Workspace, and it would reply with a bunch of Google servers that handle my email. Then we have a fun one down here, PTR records or pointer records, how I like to refer to 'em. These are for reverse DNS, very important for security. These allow you to take an IP address and go, boom, which domain name belongs to this IP address? You're like doing DNS in reverse. So this allows you to verify that when you have just the IP address,
• 17:30 - 18:00 that's a great situation. You don't have to query anything, but maybe it's not the right one. Maybe it's not secure. Let's verify that. So you can query a DNS server and say, do you have a pointer record for this, A PTR? And it'll reply with the actual domain name it belongs to. It'll look crazy like this often, but that's what it's doing. Kind of a crazy concept. Now, C names are really fun. They stand for canonical name. Just kind of a fun word to say. And isn't that the company that runs Ubuntu Canonical? Yes, it is canonical. Can I spell this first time? I think I did. This allows you to create an alias for a domain. So for example,
• 18:00 - 18:30 shop network check.com, or even www.network chuck.com, and point it to another domain, a canonical domain, which means true the real one, so alias to real. So just think when you want to point a domain name to a domain name, it's usually going to be a C name. And yes, when you want to go to www.whateverwebsite.com, that's going to be a C name record pointed to the real domain name. And then finally, one more record we'll talk about, this is not exhaustive because DNS is a whole thing,
• 18:30 - 19:00 even though we've covered a lot so far. You are going to know DNS by the end of this video. I mean, you already are there. Last thing we're going to talk about is TXT records, which just stand for text records. These back in the day were made just to kind of share messages with admins. I dunno, would they leave notes when they would do DNS requests? Sounds kind of fun. Tell you what, I'm going to leave a secret message for you guys. If you can query this, it's going to be secret message.network chuck.com. Query that using your favorite DNS querying tool and see what it says. And please comment that below. That's your homework. Now,
• 19:00 - 19:30 text records are used for a lot more than just playing around. In fact, they're vital in how we secure email. Now, yes, we're back to email. For example, this one right here is an SPF record or a TXT record specifying an SPF server. This TXT record defines which servers are legit for a domain. So for example, this one might say only mail from mail.network chuck.com is valid for our domain. If it comes from anywhere else, any fishy area, that's not it. Deny it, reject it. You don't want this. And other mail servers can query these TXT records to see that list of verified
• 19:30 - 20:00 mail servers. You also might see D-K-I-M-T-X-T records to verify that emails weren't messed with in transit or DM a C, which is a fairly new thing. We actually have a course on DAC on academy.network check.com, and this is all about configuring policies on how to deal with mail that doesn't pass DKIM or SPF and how a domain will utilize SPF and DKIM telling you DNS is extremely powerful. Now for you, if you want to get your own domain, this is not sponsored by any kind of domain provider.
• 20:00 - 20:30 Let's say you wanted to buy, I love coffee. Coffee. How does that process work and how do all the DNS servers we talked about find out about you? Well, it starts with going to a domain registrar. Registrar. It's kind of fun to say, go ahead and say it for me real quick, say it out loud so I can hear you. Squarespace is one of those main domain registrars now because they bought Google Domains. Now there's actually one boss I didn't talk about that's above the mafia bosses. This organization has ultimate authority. They're called I can because they can do whatever they want. They're the internet corporation for assigned names and numbers.
• 20:30 - 21:00 That's a mouthful. I really don't want to write this, so I'm going to do anyway. These guys help govern DNS making sure it's run smoothly. They're actually the ones who can delegate, who can become a TLD server. And another main role they have is they accredit domain registrars. Registrar, meaning they sign off on these guys. They're legit. You can buy a domain from them. We said you could. Now I am curious if I love coffee, coffee is available. Let's see, because that's one of the biggest things you got to worry about is if your domain is available, it is for 50 bucks. No one steal it.
• 21:00 - 21:30 Once I buy it, I then have a choice. I can actually use Squarespace as my name server, so my authoritative name server for my domain, which means they would hold my zone file DNS servers would ask them for any information about my domain. Now, if I didn't want to do that, and this is a common thing, let's say I wanted to use CloudFlare as a name server because CloudFlare has a bunch of cool features to protect your websites and assets. So I might say, you know what, Squarespace, you're cool is a domain registrar. I love you for it. I don't want to use you as a name server.
• 21:30 - 22:00 So here are the name servers I want to use. So you would tell Squarespace that. So I want it to be Pablo. Pablo, I trust this man with my life. This is the guy I'm going to tell everything about me. You can ask him. He knows. So Squarespace now armed with the knowledge of your name servers, has a duty of updating the T LD registry, the top level domain registry with these name server records or NS records. Now, I'm curious, who operates coffee? I've got to find out. I'm going to query I I'm for an NS record for coffee.
• 22:00 - 22:30 I'll ask one of the root servers. I'll ask Jay again. I trust him. Okay, so V zero N zero.nick.coffee. That's interesting. Who is that? That's a great segue into who is when you register a domain, you actually kind of register a lot of stuff about you as the owner of that domain, the name, the company address, and that information is maintained in the who is database. I'm going to discover who this Vic Coffee is. So I looked it up and check it out. I can't see it because you can also pay your DNS registrar when you register to
• 22:30 - 23:00 make your information private. It's an extra fee, but I can see that it says Identity Digital Inc. I dunno if that's real or not because everything's redacted. But if I searched for google.com or let's do a cia.gov, everything's redacted. Let's try someone real Facebook. Okay, cool. We got some stuff for Facebook. There it all is. So I don't know who nick.coffee is, but Squarespace would have to tell them if I bought. I love Coffee. Coffee. Now, two more things I want to talk about.
• 23:00 - 23:30 At the risk of making this video way too long. I don't care. It's my video. And if you're still here, thank you so much. You're awesome. Let's take a little sip of coffee together. First thing is you can actually run your own DNS server inside your house. It'll be a recursive DNS server, similar to a public Google server where it'll have a cache of a records domain, names to IP addresses that it's remembered that you've been to before. And if it doesn't know an IP address, it'll be configured to go to an upstream DNS server. So for example, right now I've got a raspberry pie in my server room running as my local DNS
• 23:30 - 24:00 server for my studio. It's running what's called ad guard, which is fantastic because it can block ads. But when it doesn't know about a website, it'll just ask the upstream server, which I've configured as Quad nine, CloudFlare, Google. I've got a few, actually, another popular one. Pi Hole. Pi Hole is very fun, but you can absolutely run your own DNS server in your house. It's a really fun project. Fairly easy to do. I've got two videos on it right up here. Go check 'em out. Last thing I want to talk about, it's a bit of foreshadowing, is that I talked about how DNS can be hacked. And what I want to do is walk you through how those hacks look and how you can
• 24:00 - 24:30 actually learn those hacks yourself. Not for various purposes, but for ethical hacking purposes. And that'll be a part two of this video. How to hack DNS. It may already be out. Go ahead and go there right now. That's all I got for this video. See you guys later. I.