Thank you, Giglio. I appreciate the heads up there.
Well, good evening, good afternoon, good morning, wherever you are.
And welcome back to the DEF CON group's village. I'm here from DC 603, which if your phone code,
phone area code memory is not great, is New Hampshire. And so 603 does, as an MPA,
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 to 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 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 think that's an interesting red that we've got there on the state.
The wonders 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 Troutman, 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 or present
anywhere if I can make it through this one. So 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...
oh, there we go. I got it. I got it. It 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. It 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 Foutman has done before,
and he gave the talk originally at ShmooCon as part of the ShmooCon Fire Talk series,
and won the top prize for that this past year at ShmooCon. But when we did it locally in DC603,
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, you know, 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 sort of topics
in some detail. The Twitter that we have is easily, you know, findable. It's DC underscore
603, because I think somebody else has spotted on DC603. But yeah, if you follow us, 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 Slack. And I think the expectation coming out of this DevCon 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 Con and after closing, and then, you know, any updates with that
there. So I don't think, with 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 that and catch up on that and maybe get back to you at
the end. But without further ado, we have Jim Froutman on the line with us. He is ventriloquizing
through me. So, you know, 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 or 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 telecom 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, oh, cool, that's a neat 101 talk. And then he did the talk, 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,
if we can take the slide forward to the title slide. 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. Okay. So, DNS New World Order. What the fuck? 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. I've been on the internet
since 87. I have to issue a disclaimer. I am a director and co-founder of a non-profit internet
exchange called Weenix. 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 is, talks about the new troubleshooting procedure.
It is not DNS. There's no way it's DNS. It was DNS.
And 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 a
next every time from now on, hopefully we can keep it that same.
So, we're on the graphic, right guys? New troubleshooting procedure sitting on a cube wall.
There's a little bit of a delay on the screen. I can see that.
Who would have thought? Latency on the internet. Yeah, it's amazing.
All right, are we going to share these slides afterwards, Jim? Yes, yeah. Okay, 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 it through in your own mind afterwards again.
Yes. Oh, I see it loading. I see your cube wall loading.
It's rendering like line by line on my Twitch. I don't know about yours. Yeah,
I apologize. That's awesome. Apparently, my slides...
They're not even all that complicated. Hey, look, graphics.
Masterized PNGs, right? Yeah. I wonder if it's like 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's
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 or various country codes like .uk, .jp. Originally, there was just a very few number
of top-level domains. Now there's more than a thousand. 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. You get the idea.
Most of 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.167. 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 more or less
the DNS that we have today. BIND, the Berkeley Internet named
Daemon, 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,
lettered 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 directed attacks 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 IP NCASI.
This is where you take an IP address block and you advertise it in multiple locations
on the internet at the same time via BGP 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
uses NCAST. Next slide, please. So, we talked about traditional DNS started in 85. It's what
some people are now calling DO-53, since we have DOH and DOT. DO-53 is the original unencrypted DNS.
So, it's UDP port 53 for queries, TCP port 53 for zone transfers. And it's, 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. It makes it easier to find malware and, of course,
good old AUP violations on your network. Next slide, please. So, there is some other,
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 an official standard, but they created a thing out of the free VSD
community called DNS Crypt. And I skipped over DNSSEC. You may have heard of DNSSEC.
It's a way to cryptographically authenticate DNS data, but it doesn't actually hide it,
it just authenticates it. And DNSSEC is really not a topic of this presentation,
it's like a whole other presentation unto itself. Okay. 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 macOS 11.
So, this is fairly recent developments. And this is good to have encrypted DNS,
right? 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 19.6.2.8.
And Apple is going to support DOE in the OS, starting in iOS 14 and macOS 11,
which are coming out this fall. So, we'll talk about why DOE and DOT exist in 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
were probably still in high school then, they launched a service called 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 back then was useful to work around censorship issues at the time.
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, they're quad nine 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 nine that is all nines.
Interesting. And then there's been other cloud-based... next slide, please... such as OpenDNS,
which is now Cisco Umbrella, because Cisco bought them, because that's what Cisco does.
They buy things. And most recently, CIRA, 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,
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. Ah, 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, that they'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 25th of this year,
Doe is now enabled by default for all Firefox users in the U.S. 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, okay, 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's
some A-B testing going on and I imagine Chrome will be enabling it soon. But Chrome says they
will have a GPO that will enable you to disable 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, you know, 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, the, I guess, God Lula 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, you know, 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 Adversaries 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. Okay, 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, it's... and if they know the IP address of the website you're going to,
there's been studies that can pretty much correlate that with, you know, 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
are 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 increase 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,
back when people used to do that, go to a coffee shop, back when that was standard 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 in all of those multiple ISPs and
multiple wireless networks, we're tracking directly back to you because of these session
resumption tickets. The other problem with DNS in the cloud, particularly people outside the US,
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 logs. 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-in-the-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 disable DOE in 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
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
DOT or DNS Crypt, 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, you know, a couple hours.
Another recommendation for your, 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 8 or some other server, but you're not.
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, particularly, you know,
enthusiasts, is you want to look at running something like PyHole. Next slide. PyHole
was originally meant to run on a Raspberry Pi. It 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 Hubert of PowerDNS. Those guys have many wonderful talks
available on YouTube. And they are the real experts. I'm just the guy doing some research
bringing it to you folks.
Jim, thank you so much. That was amazing.