 Well, good evening, good afternoon, good morning, wherever you are, and welcome back to the DEF CON Groups Village. I'm here from DC603, which if your phone code, phone area code memory is not great, is New Hampshire. And so 603 does as an NPA cover all of New Hampshire, but really we are located in the upper valley. And I'm going to ask that the speaker assistant here advance the slide for the next slide real quick. And so we're like halfway up New Hampshire, which makes it far enough away from Boston that we're not really part of the Boston commuter area, the Boston suburbs that kind of extend into the southern part of the state. And then there's an awful lot of security meetups down in that area and around Boston generally. So we are actually up in an area that has a lower population density and definitely a lower tech job density. And if you could advance the slide, that'd be great. There we go. And let's just go one more part of that, please. I mean, it's an interesting red that we got there on the state, but the one that's about space VR. So just as an aside, I will say that if we make it through this slide, this talk today, I don't know about Jim Frautman, my compatriot here, who I'll introduce in a second, but certainly from my point of view, I feel like this may be the most complicated setup we've done for a talk. So I'll feel like I can present on Mainline, I'll present anywhere if I can make it through this one. Thank you for bearing with us as we do this. And so what you should be seeing on Twitch is that we've got, there we go, that's weird. So I don't know where the slide is at right now, because I see something on Twitch that is, I've got it, you just came through on my Twitch. So yeah, so that meeting room that you see there, that was our last virtual meeting back in March, and our last physical meeting back in March. And of course, with the lockdown situation, which I think we'd originally figured would not maybe last quite as long as it has so far, and as it looks like it's going to, we didn't immediately dive into a virtual mode, although we're kind of spinning that up more now. But yeah, so we've been getting together in person every month, and having some talks that are accessible, if you're listening to this, and if you're in the area and you're new, and you're like, well, I'm not a super, super skilled hacker, doesn't matter, come along. I think as long as you've got the interest in the topic, and the passion in the topic, we're going to be delighted to contribute to you, and get your contribution and your experience back and just work as a group to share those experiences and expertise. So in the case of the talk that we're about to present, this is actually a talk that Jim Fratman has done before, and he gave the talk originally at Shmucon as part of the Shmucon Fire Talk series, and won the top prize for that this past year at Shmucon. But when we did it locally in DC 603, what happened there was it provoked an awful lot of conversation, and that's typically how it goes, right? We're looking to have not just talk sessions, but we're looking to have a meetup where it's small enough that we can really dive in and talk about some of the topics in some detail. The Twitter that we have is easily findable. It's DC underscore 603, because I think somebody else has spotted on DC 603. But yeah, if you follow our DC underscore 603, it's a low volume list. We're just sending out when there's particular things to be aware of. And then we also have a Slack, which if you want to join with us and come to meetings and so forth, we can get you on the Slack. And I think the expectation coming out of this DEFCON is I think there's going to be some evolution with how we're doing Discord. And I suspect we'll probably look to do more with Discord going forward. So rather than preempt that, we'll wait and see how that plays out through Khan and after closing and then any updates without that. So I don't think the way this is set up that I'm going to be able to hear anyone's questions. If there are questions that you want to try and yell out, go for it or throw it into the text in Discord. And I'll take a look at it and catch up on that and maybe get back to you at the end. But without further ado, we have Jim Frautman on the line with us. He is ventriloquizing through me. So you're seeing, I think, one disembodied body on stage. But there's actually two of us in the one body, which is kind of how I feel about Jim. He's an amazing guy. Some of you probably know he does Sky Talks with me while I do Sky Talks with him. And he is with us here to dive in on a topic that has been part of his life, I think, for a hell of a long time. He's been playing around with Telcom and DNS and all that stuff forever. And when he first said to me many months ago he was going to do a talk on DNS, I was like, cool, that's a Meet 101 talk. And then he did the talk and I'm like, oh my goodness, there is so much about this that I've just been oblivious to and not keeping up on the tech. And there's some really interesting stuff here. So if you think you know DNS, maybe you do. More power to you, but I suspect there's a few folks out there that are going to learn something today. Jim, over to you, man. Hey, good afternoon. Can you guys hear me? They better. Just keep going. We hope so. All right. Well, if we can take the slide forward to the title slide, there might be a next one over here. Thank you. So thank you guys for the DC Groups team for setting this up and making all this work. And I know there's been a lot of technical challenges, but I think it's been a good learning experience for everybody involved. And thank you to Donald for inviting me to come and do this presentation today. OK. So DNS New World Order. Quadex.do.de. So I'm a guy on the internet. You can find me easily. I've been around, done a lot of things in ISP land, been on the internet since 87. I have to issue a disclaimer. I am a director and co-founder of a nonprofit internet exchange called Nenix. We happen to host some servers for one of the companies that I'm going to be discussing today, Quad9. So just a little disclaimer. All right. So here's what we're going to learn today, topics of presentation. We're going to talk about the DNS system in general and some of these new encrypted DNS methods like Doe and Dot. We're going to talk about operational reasons why you should monitor your DNS, about all these cloud services that are out there offering easy to remember DNS servers and why would they want to do such a thing? The privacy implications of some of the web browser product decisions. And then I'm going to end with some recommendations on how to mitigate the impact of all of these new encryption methods and those cloud-based DNS services. So this slide here, which talks about the new troubleshooting procedure, it is not DNS. There's no way it's DNS. It was DNS. I'm going to pause here until the slides catch up. We should be on the one that says new troubleshooting procedure. It's not DNS. There's no way it's DNS. It was DNS. We know it was always DNS. And if, Jim, if you can do it next every time from now on, hopefully we can keep it that same. So we're on the graphic, right? That is new troubleshooting procedure sitting on a cube wall. There is a little bit of a delay on the screen. I can see that. Who would have thought? There's a latency on the internet. Yeah, it's amazing. Are we going to share these slides afterwards, Jim? Yes, yeah. OK, so if there's anyone in the audience who's trying to throw bricks at us right now, we will make sure you get a copy of the slide deck. And you can just play through in your own mind afterwards again. Oh, I see it loading. I see a cube wall loading. It's rendering line by line on my Twitch. I don't know about yours. Yeah, I apologize. That's awesome. Apparently, my slides gave the systems. They're not even all that complicated. Hey, look, graphics. Last slide, PNGs, right? Yeah, I wonder if it's upscaling them into some sort of ludicrously detailed resolution that it doesn't need to. Anyway, I'm proceeding onward. So let's talk about DNS next slide. So what the heck is DNS? So it's the domain name system. And it is really about the most fundamental technology that makes the internet work other than packets and wires and fiber. And it works so well that most people never even think about it. We don't think about it until it breaks. Most end users really have no knowledge about it. So what DNS does is that it simply converts the names that humans can remember into numbers, which is what computers use, network addresses. Next slide, please. It's also used internally by almost every organization because almost everybody is running Microsoft Active Directory. And guess what? Active Directory depends entirely on DNS working correctly and reliably. Next slide, please. So really everything you do on the internet needs DNS to function. This is why a lot of people will say something like, and I'm sure those of you in the audience that have done any sort of tech support or help desk, you've heard this before, the internet is down. And usually that's not the case. The internet is just fine. But DNS resolution was broken for that user. So DNS requests are usually called queries. And next slide, please. These queries that you issue all the time with your browser and with your phone and pretty much every single app that you use, they reveal an awful lot about you and what you are doing online. The games you play, email, et cetera. So a little refresher about what DNS is. Next slide, please. Domain names are hierarchical. They start at the root or the dot. And then we have top level domains. And there's the original generic top level domains like .com and .gov and .net. There are various country codes like .uk, .jp. Originally, there was just a very few number of top level names. Now there's more than 1,000. You have such things as .bank, .coop, even .horse, which is kind of fascinating. All right, so this next slide, please. So we have some example DNS names. Google.com, www.bbc.co.uk, et cetera. If you get the idea, I'll just let you guys know how DNS is structured. So DNS is a service that converts names into numbers. So for example, next slide, please. You look up a record like www.cnn.com when you punch that into your browser. You'll get an IPv4 address that you can almost remember, 151.101.67. But with IPv6, you're going to get a big, long, hexadecimal address that nobody in the world should try to remember. This is why we have DNS. Next slide. So DNS was originally conceived in 1983, roughly. At least the RFC was published then, RFC 882. And that was superseded by RFC 1035 in 1987. And that is basically the more or less the DNS that we have today. Bind, the Berkeley internet name demon, was created in 1985. And this DNS is really the last major plain text protocol that's left on the internet. Although, as we're going to discuss, there's lots of people trying to make it go away. A little more background on the DNS. In order for DNS to work, you have to have the root servers. Next slide, please. The 13 root servers in the world, letter A through M. And they're operated by 12 different organizations. And it's important to understand that these 13 servers that are the root of the DNS, they are by no means individual servers. These are clusters of servers with load balancers and multiple instances all over the world. Some of these root servers have over 160 separate physical instances around the world in various data centers. Because they're so widely distributed, this allows scaling of traffic volumes and lots of increased resiliency and redundancy, particularly against direct-to-the-tax, like DDoS attacks, which root servers get all day long. Next slide, please. So all of the root servers in the letters A through M, they get a massive amount of traffic in terms of queries and transactions. We're talking double-digit billions of queries per day processed by these root servers. That's trillions of DNS queries per month. And the DNS has actually managed to scale over nine orders of magnitude in the last 35 years. And it will continue to do so. I think that's pretty impressive for a protocol designed in the mid-'80s. One of the ways that DNS scales, next slide, please, is a technique called IPN casting. This is where you take an IP address block and you advertise it in multiple locations on the internet at the same time, via DGP routing. The same address appears in multiple locations, and your ISP or your network makes decisions to steer the traffic to the best nearest instance of that IP address. So all the DNS servers, all the root DNS and all the cloud DNS in the world, use as anycast. Next slide, please. So we talked about traditional DNS, started in 85. It's what some people are now calling DO53, since we have DOH and DOT. DO53 is the original unencrypted DNS. Again, so it's UDP port 53 for queries, TCP port 53 for zone transfers. And again, it's been largely the same for the last 35 years. Next slide, please. The wonderful thing about DNS, from a network management point of view and a security point of view, is that it's plain text. So you can monitor it over the wire very easily. And I have to say, if you're in a corporate environment and your IT security staff isn't monitoring DNS, they're doing it wrong. If you are the IT security staff for your organization and you are not monitoring DNS, you really ought to. It is incredibly useful to monitor DNS, lets you know what your endpoints are up to, and makes it easier to find malware, and of course, good old AUP violations on your network. Next slide, please. So there was some other, again, DNS is unencrypted. And some people have thought, well, that's kind of a problem. I don't really want people to know what I'm doing and what my DNS queries are. So there was a group of folks that were not IETF and did not come up with a official standard, but they created a thing out of the free VSD community called DNS Crypt. And I skipped over DNS Sack. You may have heard of DNS Sack is a way to cryptographically authenticate DNS data, but it doesn't actually hide it. It just authenticates it. And DNS Sack is really not a topic of this presentation. That's like a whole other presentation to itself. OK, next slide. DNS Crypt, 2011, bunch of folks in the free VSD world were instrumental in that. They created an encryption protocol. It worked. It actually used port 443, but didn't use TLS. Used another encryption method. So it worked. It solved the problems, but it really didn't get much traction at the time with anybody. Because you know what? DNS is kind of boring. So fast forward a little bit. Next slide. DNS over TLS, or commonly known as DOT. This was an RFC process issued May 2016. And this is basically traditional DNS with TLS encryption running on a different port. This uses TCP port 853. And the nice thing about that is it keeps the network control traffic separate from your application data traffic. Now, you may not be aware, but next slide, please, support for TLS at DNS over TLS DOT has actually been around for a while. It started in Android 9 for the whole OS. So if you have recent Android, it's enabled by default. And it will just work if it's supported by the server that you're talking to. Microsoft says they may eventually support DOT in the operating system. And Apple is going to be supporting DOT in the new iOS 14 and in Mac OS 11. So this is fairly recent developments. And this is good to have encrypted DNS, I think, from an end user perspective in your operating system. Next slide, please. So there was a different group of folks that decided to create DNS over HTTPS or DOE. This is a different RFC, 8484, issued in December of 2018. So this is a protocol that uses TCP port 443 with TLS encryption. What does that remind you of? Yes, it is the same as HTTPS for websites. So it implements DNS queries using a special HTTP GET with JSON responses that get parsed. It can be a little bit slower than regular DNS by several milliseconds, but it's not really a big deal. Microsoft has actually just added support for DOE, starting in Windows 10 preview build, 19628. And Apple is going to support DOE in the OS, starting in iOS 14 and Mac OS 11, both of which are coming out this fall. So we'll talk about why DOE and DOT exist a little bit. I'm going to talk about DNS in the cloud. Next slide, please. So you may be aware that for many years, there's been public DNS servers, usually operated by ISPs, as a resource. If you've been around on the internet for a while, you may recognize some of these numbers on the slide, like 4.2.2.2, operated by level 3, 75, 75, 75, 75, which I believe is Comcast, and there's others out there. And these were really just primarily for network engineers and network people who just needed to set up DNS to get something working real quick. And most end users didn't really know about them, until DNS in the cloud. Next slide. So Google, back in December 2009, and some of you are probably still in high school then, they launched a service called 8.8.8.8.8. And why did they do that? Well, they said they wanted to improve the speeds and the user experience versus a lot of ISPs that had broken DNS, and still do. And I believe that it also gave them all sorts of data about what people were doing and where they were going. Now, using Google DNS 8.8 back then, it's useful to work around censorship issues at the time. Next slide. You may or may not remember this picture, which will probably take a minute and a half to load on the stream. It's a picture from the Arab Spring uprising where people were actually spray painting graffiti with the DNS numbers on buildings more than once all over the place. And this at the time was actually an effective way to avoid censorship by the government. Not so much anymore. Censorship and network control has gotten a lot more sophisticated. Next slide, please. So Google their Quad 9 for several years, and there wasn't really any others. And then now there's more. Cloudflare came up with 1.1.1.1 in cooperation with the APNIC that controlled that IP space. Then there's another organization called Quad 9 that is all 9s. And then there's been other cloud-based next slide, please, such as Open DNS, which is now Cisco Umbrella, because Cisco bought them, because that's what Cisco does, they buy things. And most recently, Sierra, the Canadian.ca registry authority, they created a new service called Canadian Shield with an IP address that is available to the public. So next slide, please. If you can control the DNS for what someone goes to, what they're resolving, what your end users see, if you control the DNS, you basically control everything. It's almost as good as controlling the entire network, which is the reason why so much malware that attacks home routers and things like that, they want to modify your DNS settings on your network router if your clients are pointed at your local router so that they can send you to illegitimate sites. So next slide, please. Again, read of rate. DNS, it's great for tracking. If you monitor DNS queries, you know where everyone goes online. Your shopping, your entertainment, what you do for work, most likely, any medical sites, the apps you run on your phone. And even right down to depending on the device, you can figure out what device it is in your house or your business, and particularly with IoT devices, based on those DNS queries. Next slide, please. So if you control the DNS, again, you control where users go or don't go. I believe strongly DNS monitoring is great for fighting malware and intrusions. And I, again, say it is essential for blue team network defense and monitoring. But DNS also is money because many ISPs, and this includes your cell phone company because they are, in fact, an ISP because you use data on your phone, many of these ISPs, including your cable TV companies, iLex, telcos, wireless carriers, et cetera, they are monitoring your DNS. And they are actually, many of them, selling that information to a variety of data brokers and advertising companies and other companies that want to track people. And in some cases, those ISPs and carriers, they actually own some of the advertising companies themselves, which is why, when they say things in their acceptable use policy, like, we will not sell your data, you're able to tie you directly via your cell phone ID numbers, your home IP address range, whatever IP address you had at the time, they can tie that data directly to you demographically. They know it's you and not somebody else. Next slide, please. So there are different estimates what this data is worth and how they can sell it for. I have seen everything from $3 a year per subscriber up to several hundred. I think it varies upon the demographics of the value of the person. So if you are not paying for a product on the internet, you are the product. So next slide. So why do we have DOE? Well, the reason we have DOE is up until just recently, the operating system vendors, really, they had not implemented any sort of encrypted DNS. They are now about to release dot support. But for years, they really weren't doing anything. So some of the browser makers, like Firefox, Mozilla, they decided that they needed to take matters into their own hands. And that's in part how DOE came about. So Firefox added DOE support in September of 2018. And then in January of this year, they made it an option that you could enable DOE if you wanted to in Firefox. But since February 25 of this year, DOE is now enabled by default for all Firefox users in the US. Next slide, please. So this is a picture of the opt-out in Firefox. And I think most end users are just going to see this thing and say, OK, yeah, that's great. It's more encryption and it's more privacy. And in fact, that is true to a point. So Mozilla picked Cloudflare as their first and default DOE provider. And they drew up a contract. And there's various requirements that they have to honor. And that's interesting. Firefox also includes a domain name canary, which is something that your ISP can set in their DNS servers, which will actually disable DOE in Firefox. Because you see there's a whole lot of tension over who gets to monetize you because you are the product. So the ISPs have been doing the monetization. And now there are other folks that would like to do that. And it's also the monitoring. Next slide, please. So there are other web browsers besides Firefox supporting DOE now. Chrome supports it, but it's not enabled by default yet. I understand there is some A-B testing going on. And I imagine Chrome will be enabling it soon. But Chrome says they will have a GPO. They'll enable you the disabled DOE entirely. Microsoft Chromium Edge supports it. It's not enabled by default. Opera supports it. Brave supports it, et cetera, not enabled by default. So DOE does encrypt things. And it makes it harder for people to see where you're going on the internet by encrypting your DNS traffic. But this is a double-edged sword. There's a lot of malware now using DOE. And because it's using DOE, you're not seeing that traffic anymore. There's been at least one piece of malware, I guess Godlula backdoor for Linux and Windows. And that came out in January of 2019. And it was using DOE for its CNC servers. And I expect there's going to be all sorts of additional malware developed that's going to use DOE because it makes it easier for them to hide. So I think you're going to need to start deploying man-in-the-middle TLS proxies in your corporate environments if you aren't already. Next slide, please. And again, I think the adversary's TTPs are changing to adapt to DOE. I suspect there's probably some malware out there in the wild using DOE that people don't even know about right now. I think that's going to be a big, big thing for the rest of this year and next year. So DNS in the cloud, going back to that. It's really surveillance. Next slide, please. Not all of the DNS cloud providers have a clear privacy policy. Some things they're retaining for a couple of years, in summary, maybe just 24 hours. OK, some of that doesn't bother me, some of it does. However, everybody is just assuming that DOE actually does give you privacy. And the answer is not as much as you think. It also is centralizing your DNS queries by using these sort of well-known cloud providers to provide DNS service for all sorts of people. You're really centralizing the places where that data can be monitored and collected. So DNS over HTTPS, it's not as secure. Next slide, please. We're up to 49. DOE doesn't actually encrypt the data that you can't get in other unencrypted forms. You see, because where you go with DOE, SNI information, the IP address you're actually talking to, OSCP checks for certificates, and all of that is still in clear text. So if they know the IP address of the website you're going to, there's been studies that can pretty much correlate that with the website, something like 85% of the time. So you think that you may be getting all sorts of privacy from using DOE, but you're not. Just because they can't see exactly what DNS queries you were issuing doesn't mean they can't figure out what you're actually doing. Next slide. Here's a tweet from DA667 pointing out some of the same things. It really consolidates trust of confidential data to organizations that may not deserve it. Next slide, please. And then we have TLS session resumption tickets. And this was an area that I did not know about and was unaware of until I started doing the research for this talk. These are basically unblockable cookies that can track you everywhere you go by resuming your previous TLS sessions. Now this was done and included in the standards to help reduce session setup time and increased performance. But by renewing these resumption tickets, which can be done over a long period of time, up to seven days with TLS 1.3, that provides a method to track you across the internet no matter what you're doing and where you're doing it. So if you get up in the morning and you are using your phone at home, let's say on your home Wi-Fi, and then you leave and you go out in the world and you use your phone on your cellular carrier with cellular data, you go to an office and you go back when people used to do that, go to a coffee shop, back when that was safe to do. Any Wi-Fi that you use, they're still able to track you. You go someplace else, you go back home. The point is, is that across all of those sessions and all of those multiple ISPs and multiple wireless networks, your traffic is directly back to you because of these session resumption tickets. Another problem with DNS in the cloud, particularly for people outside the US, next slide, is all of these DNS cloud services, they're USA-based, USA companies. So that means they are subject to getting national security letters. They're subject to FISA 702 and other laws. So that means that the government can go to one of these providers and say, we would like a copy of all of your server locks. And yes, you may be deleting them, but we don't have to. And if it's a national security letter, they can't even talk about it or tell anyone. So by centralizing into these cloud services, it just makes it easier for governments and law enforcement to get your information. So what do we do about all of this? Next slide. So I have some recommendations. Number one, if you should be running your own internal recursive DNS server for your network, this will give you the absolute best performance for DNS because it's the lowest latency because it's on your network. Now the good news is, if you're in a corporate environment, you're probably running Microsoft Active Directory, you're already running a local recursive DNS server. But it's probably not set up well. You should have this internal recursive DNS server, and you should put all kinds of logging and monitoring on this server. This is where your logging and monitoring goes here. Because logging on the server level, of course, it's decrypted those packets. This allows you to monitor your internal endpoint traffic. Next slide. On your firewalls, you set your firewalls to block all TCP and UDP port 53 traffic for all your endpoints out to the world. So they can't use regular DNS. This will force your endpoints to use your internal DNS. You also want to block TCP port 853 to block dot on your corporate firewall. Now, when it comes to Doe, Doe is a lot harder to block because Doe looks just like regular HTTPS traffic. So there are some vendors, depending on what kind of firewall that you have, and which vendor, and how much money you're giving them. They have some rule sets to help enable blocking of Doe. Some of them work just by blocking the IP addresses of well-known Doe servers. Others actually use man and middle proxy functionality built in their solutions, and they may have rule sets. This is an area where I think a lot of corporate defenders are going to need to invest time specifically to monitor Doe queries via some sort of man in the middle proxy that you're going to have to manage. And this is what you're going to have to do, ultimately. You're going to want to set your endpoint configuration standards to disabled Doe and any browsers on your endpoints. And you do have endpoint configuration standards, right? In your organization, that magical golden image, as they say. So you want to make sure that all of your endpoints are configured to talk to your internal recursive servers only. Yeah, whatever method you have to do that, whether it's DHCP options, group policy objects, static configs, registry keys, whatever, make it so. You can also set up Doe logging in Firefox if you have to use Firefox. So now that you have everybody talking, next slide, please, to your internal recursive servers, that's great. But now you want to protect your traffic from those servers out to the internet. Because if you don't do that, then it's still possible to watch the data stream coming out of your environment, whether that's home or at work. So you can set your internal servers to use an external resolver where it will just automatically forward, as some of the software calls this forwarding, all of those queries to a particular outside server rather than talking to the root servers directly. So if you do this, if you have an internal recursive server and you tell it to talk to some external server over an encrypted protocol, whether that's . or DNSCrypt, Doe still leaks information, and you use an external server, particularly an external server in a GDPR country that has some actual privacy protection. And if that server has enough other users, you're going to get a privacy mixer sort of herd protection for your DNS queries. If there's tens of thousands or hundreds of thousands of people all using a particular server, it's going to be a lot easier, a lot harder rather than that to tie those queries back to you. The other option that you can do is you can set up your own DOH server in like a VPS. If you trust DOH, you can also set up your own DOT server. It's not very hard, and if you are at all handy with a Linux command line, it's the sort of thing that you can do in a couple of hours. Another recommendation particularly for your corporate networks, but I would also extend this to any power user geek home network, is you want to capture all of the IP addresses of those well-known public DNS resolvers in addition to doing a block at the edge. And this is because you will be surprised to find out how many devices are using some sort of hard-coded DNS. In particular, I know Google Chromecasts, they ignore whatever you set in DHCP. They will use Google DNS always, and there's others. So many, many ISPs and a lot of hotel hospitality networks already do this sort of network capturing, and you just haven't noticed. Many times, you think you may be talking to Google Quad-H or some other server, but you're not. It's just something they've done particularly in hospitality networks to give you that hotspot login. Next slide. Now, a recommendation if you're in a small business environment or home environment, you might want to use Quad-9 or Cisco umbrella or Canadian Shield if you're not as concerned with privacy issues, because all of those services include some malware blocking, where they get threat intelligence feeds about the latest command and control servers, the latest compromised servers that are feeding downloads of malware. And so they are specially set up to not return the correct DNS information for any of those DNS queries. So that provides a level of additional protection, particularly in an environment that just simply can't afford anything else. The other recommendation that I give everyone, typically the enthusiasts, is you want to look at running something like PyHole. Next slide. PyHole was originally meant to run on a Raspberry Pi. Doesn't have to. You can run it pretty much on any Linux or in a container. And it works by blocking advertising servers, known advertising servers. And it's pretty effective. It's not perfect, but it's pretty effective. And you can use PyHole to do your internal resolution and then chain it to external DOH servers or DOT. So that's my presentation. And remember, it's always DNS, always. I will be making this slide deck available for download. There is a whole bunch of bibliography, about five pages of interesting links if you are at all interested in this sort of topic. I recommend that you read much further. Also, there are various folks in the DNS community, the true legends, like Paul Vixie, who is one of the original authors of Bind. And he's been doing DNS for decades. And Bert Hebert of Power DNS, those guys have many wonderful talks available on YouTube. And they are the real experts. I'm just the guy doing some research and bringing it to you folks. Jim, thank you so much. That was amazing.