 So I'm gonna do an updated video to talk a little bit more in depth about DNS over TLS and DNS over HTTPS and what the two use cases are for these. So with, let's say your home or business network and you have your own PF sense router, I bring PF sense up because I know it supports DNS over transport layer security. This is kind of a really basic network setup. You have your laptop, desktop, your computers of your local network or whatever devices you may have on there. And hopefully if you're going to a majority of websites they do support HTTPS. So we know the website is secure and the traffic between your endpoint and the internet is encrypted via HTTPS. But for many people, the out of the box default settings is what they leave on there. And that means your unencrypted DNS comes from your workstation through your router and out to the internet unencrypted. Well, then we go in PF sense and we turn on DNS over TLS and we choose a supported DNS server that does support this as well. Now we've encrypted everything leaving our network to the greater internet. Now not every workstation is going to support encrypted DNS. Matter of fact, many of your IoT devices will not have this facility built in as of right now that's changing in the future as more devices get this way. So we're just going to assume that most of the time you're using standard DHCP and acquiring whatever DNS servers are given to you on your local network. But as I said, that's unencrypted traffic. But when you're at your home or office, generally speaking, you trust this network not to be messing or monkeying with the DNS or doing anything you don't want done with it. Therefore it should work and you are secure in this. Then we look at the other method here. Let's go to a coffee house or somewhere that has publicly available wifi. You then have encrypted HTTPS, which is great because years ago when there was not HTTPS on many things it was really easy to sniff passwords or anything at any publicly available wifi. With HTTPS that's become much, much more difficult but you would do so by monkeying with the DNS because your unencrypted DNS requests go out to go through the router here at the coffee house. They can see your DNS. They can also manipulate the DNS. This is sometimes what they do to get you to go to those sign in pages. They create redirections and get you to sign into their proxies or would agree with their terms and conditions but because you're passing it back along to the internet it comes out over here unencrypted and this is where more concerns can happen. The reason you may want to run DNS over TLS in your PF sense is to block your ISP from knowing what DNS queries you're making because they don't just go out unencrypted. They go out completely available and logged many times by ISPs because this is more data that they can sell. They already have your personal information like where you live and details about you and what internet packages you may have purchased from them and then they can now have a list of websites that you go to based on the DNS queries even though they're only collecting essentially metadata because they can't see into these encrypted HAPS streams they know you went to this website, that website so on and so forth. But where the real risk comes in is with unencrypted DNS and they monkey with it here where are they sending you? But she in a public setting. Now this is a scenario and this is from Impravva, I'll leave a link here. They did a little write up on this to kind of talk about DNS spoofing but let's say this is the public WiFi scenario. So we have a client issues a request to a real website, the attacker or whoever owns the router who is providing free WiFi, injects fake DNS entries and it resolves to a fake website and gets you to the wrong place. So this scenario is obviously very problematic and it's one of the reasons that a lot of people recommend using whenever you're in a public setting like this you would do a VPN. That way you're encrypting the traffic all the way here and kicking it down the road and saying that you trust the VPN provider. I say that because once again if you're still using unencrypted DNS, they can't. Now this is the goal to be solved with DNS over HTTPS is I go in, I change to DNS over HTTPS and instead of just using unencrypted DNS, I'm using TLS, encrypted DNS via HTTPS. And this is the video I did the other day. So if you have TLS encrypted DNS over HTTPS then now the entire layer is going to be transported over here and now there's no more visibility. The can see can change goes away. They just see TLS traffic and this does not allow them to sync all the DNS and does not allow them to monkey with it so to speak and it breaks the attacker scenario of trying to inject or change to the DNS servers. But as someone pointed out and I was slightly incorrect about how it worked but we're gonna bring over pop OS over here an install I have and we're going to show that I took this network TRR mode modified integer two. This is what switches the DNS over HTTPS on in Mozilla's under about config and then the network URI the default one is HTTP Mozilla dot cloudflare dash DNS.com slash DNS query but the part I made a mistake on is it was caching the request. I currently have DNS blocked on this and I can confirm if you block DNS from a reboot so it has no chance to cache the lookups it will not resolve with this. So I did find this to be a little bit of a problem but there's a couple of mitigations you could do. One, you could figure out what the DNS is this and add a host entry so it has a static entry in the system so you can still keep from requesting DNS or you can use DNS but it's gonna do one query here and as long as it gets to this proper website you're good. I did wanna point out for people that had the comments on that that you are correct that it was caching it I just didn't check it so we're gonna go ahead and here and show there's no DNS queries on this I'm gonna go ahead and unblock it into firewall rules. So now I've grayed out that rule right there so it can have DNS queries again and Google starts resolving and lots of DNS queries again. So for those wondering if you were correct about that you were it was my mistake for when I turned off DNS to show that you can once resolved you can turn off DNS again and it will continue working once it's resolved, I don't know why I typed that. I'm already on Google. So we're gonna go back over here to the firewall and re-enable the rule, apply. We wait a minute, all these will die. All these DNS requests will die but it'll hold on to the cache and then continue to work like it did in my other video. So once it resolves that one. So like I said, if you wanted to continue using this you could mitigate that. Now I do not have a list because someone had asked if there's other places that support this. I don't have a list at the moment of who all supports DNS over HGS queries but that list would be your 11 if I made it in a video because there's probably always more companies doing it. And as of right now to my knowledge it is not supported in PF sense. So standing up your own at this moment isn't available but I'm sure soon enough as this becomes a more popular standard it'll be easy enough to stand up your own DNS over HGAPS so you can do this. But I do like this as a methodology because you're encrypting the DNS queries and everything at that level. Granted there's still the operating system level that needs to at least first resolve the domain before it can pass the rest of the domains over that but it's still interesting. It's still effective. It's still a methodology that does help mitigate the attack of DNS spoofing and anything that helps block some of the attack spoofing or doesn't give our ISPs one way to monetize this because I'm not gonna discount for it. So if that's a concern of yours this does at least block a lot of that visibility that your ISP would have into there or the other option as I said before is using a VPN when you're on a public wifi so you encapsulate more of your traffic. And that's really what it's about is encapsulating your traffic in encryption layers via VPN or DNS for each of these. Both are ways you want to avoid things like DNS spoofing or people messing with data streams because encrypted data streams much, much harder to mess with than an unencrypted one. All right, hopefully this is helpful. This is the follow up for that particular video I did the other day. So this is kind of part two of that. Thanks for watching. If you liked this video, give it a thumbs up. If you want to subscribe to this channel to see more content, hit that subscribe button and the bell icon and maybe YouTube will send you a notice when we post. If you want to hire us for a project that you've seen or discussed in this video, head over to laurancesystems.com where we offer both business IT services and consulting services and are excited to help you with whatever project you want to throw at us. Also, if you want to carry on the discussion further, head over to forums.laurancesystems.com where we can keep the conversation going. And if you want to help the channel out in other ways, we offer affiliate links below which offer discounts for you and a small cut for us that does help fund this channel. And once again, thanks again for watching this video and see you next time.