[00:00.000 --> 00:03.040]  Thank you, Giglio. I appreciate the heads up there.
[00:04.640 --> 00:08.100]  Well, good evening, good afternoon, good morning, wherever you are.
[00:08.820 --> 00:15.660]  And welcome back to the DEF CON group's village. I'm here from DC 603, which if your phone code,
[00:15.660 --> 00:22.280]  phone area code memory is not great, is New Hampshire. And so 603 does, as an MPA,
[00:22.280 --> 00:29.180]  cover all of New Hampshire. But really, we are located in the Upper Valley. And I'm going to
[00:29.180 --> 00:35.640]  ask that the speaker assistant here advance the slide to the next slide real quick.
[00:36.340 --> 00:43.100]  And so we're like halfway up New Hampshire, which makes it far enough away from Boston that we're
[00:43.100 --> 00:48.280]  not really part of the Boston commuter area, the Boston suburbs that kind of extend into the
[00:48.280 --> 00:54.360]  southern part of the state. And there's an awful lot of security meetups down in that area and
[00:54.360 --> 01:00.980]  around Boston generally. So we are actually up in an area that has a lower population density
[01:01.820 --> 01:07.580]  and definitely a lower tech job density. And if you could advance the slide, that'd be great.
[01:07.580 --> 01:12.140]  There we go. And let's just go one more part of that, please.
[01:13.900 --> 01:17.120]  I think that's an interesting red that we've got there on the state.
[01:17.720 --> 01:24.200]  The wonders about space VR. So just as an aside, I will say that if we make it
[01:24.200 --> 01:32.380]  through this slide, this talk today, I don't know about Jim Troutman, my compatriot here who I'll
[01:32.380 --> 01:39.300]  introduce in a second, but certainly from my point of view, I feel like this may be the most
[01:39.300 --> 01:45.520]  complicated setup we've done for a talk. So I'll feel like I can present on mainline or present
[01:45.520 --> 01:50.780]  anywhere if I can make it through this one. So thank you for bearing with us as we do this.
[01:50.780 --> 02:03.540]  And so what you should be seeing on Twitch is that we've got... there we go. That's weird. So
[02:05.520 --> 02:10.880]  I don't know where the slide is at right now because I see something on Twitch that is...
[02:10.880 --> 02:15.220]  oh, there we go. I got it. I got it. It just came through on my Twitch. So yeah, so that meeting
[02:15.220 --> 02:22.400]  room that you see there, that was our last virtual meeting back in March,
[02:22.840 --> 02:28.700]  and our last physical meeting back in March. And of course, with the lockdown situation, which I
[02:28.700 --> 02:32.860]  think we'd originally figured would not maybe last quite as long as it has so far, and as it
[02:32.860 --> 02:38.120]  looks like it's going to, we didn't immediately dive into a virtual mode, although we're kind of
[02:38.120 --> 02:43.400]  spinning that up more now. But yeah, so we've been getting together in person every month,
[02:43.400 --> 02:49.780]  and having some talks that are accessible if you're listening to this, and if you're in the
[02:49.780 --> 02:55.500]  area and you're new, and you're like, well, I'm not a super, super skilled hacker. It doesn't
[02:55.500 --> 03:02.160]  matter. Come along. I think as long as you've got the interest in the topic and the passion in the
[03:02.160 --> 03:07.120]  topic, we're going to be delighted to contribute to you and get your contribution and your experience
[03:07.120 --> 03:14.800]  back and just work as a group to share those experiences and expertise. So in the case of
[03:14.800 --> 03:21.640]  the talk that we're about to present, this is actually a talk that Jim Foutman has done before,
[03:22.240 --> 03:29.320]  and he gave the talk originally at ShmooCon as part of the ShmooCon Fire Talk series,
[03:29.320 --> 03:40.560]  and won the top prize for that this past year at ShmooCon. But when we did it locally in DC603,
[03:40.560 --> 03:47.080]  what happened there was it provoked an awful lot of conversation, and that's typically how it goes,
[03:47.080 --> 03:51.520]  right? We're looking to have not just, you know, talk sessions, but we're looking to have
[03:52.440 --> 03:57.960]  a meetup where it's small enough that we can really dive in and talk about some sort of topics
[03:57.960 --> 04:05.820]  in some detail. The Twitter that we have is easily, you know, findable. It's DC underscore
[04:05.820 --> 04:13.040]  603, because I think somebody else has spotted on DC603. But yeah, if you follow us, DC underscore
[04:13.040 --> 04:19.460]  603, it's a low volume list. We're just sending out when there's particular things to be aware of.
[04:19.460 --> 04:25.600]  And then we also have a Slack, which if you want to join with us and come to meetings and so forth,
[04:25.600 --> 04:32.040]  we can get you on Slack. And I think the expectation coming out of this DevCon is,
[04:32.040 --> 04:37.140]  I think there's going to be some evolution with how we're doing Discord, and I suspect we'll
[04:37.560 --> 04:43.800]  probably look to do more with Discord going forward. So rather than preempt that, we'll wait
[04:43.800 --> 04:49.600]  and see how that plays out through Con and after closing, and then, you know, any updates with that
[04:49.600 --> 04:54.080]  there. So I don't think, with the way this is set up, that I'm going to be able to hear anyone's
[04:54.080 --> 05:00.360]  questions. If there are questions that you want to try and yell out, go for it or throw it into
[05:00.360 --> 05:04.640]  the text in Discord, and I'll take a look at that and catch up on that and maybe get back to you at
[05:04.640 --> 05:12.120]  the end. But without further ado, we have Jim Froutman on the line with us. He is ventriloquizing
[05:12.120 --> 05:18.640]  through me. So, you know, you're seeing, I think, one disembodied body on stage, but there's actually
[05:18.640 --> 05:23.000]  two of us in the one body, which is kind of how I feel about Jim. He's an amazing guy.
[05:23.000 --> 05:27.080]  Some of you probably know he does Sky Talks with me or I do Sky Talks with him.
[05:28.640 --> 05:37.160]  And he is with us here to dive in on a topic that has been part of his life, I think, for
[05:37.800 --> 05:42.080]  a hell of a long time. He's been playing around with telecom and DNS and all that stuff
[05:42.880 --> 05:48.720]  forever. And when he first said to me many months ago, he was going to do a talk on DNS,
[05:48.720 --> 05:55.280]  I was like, oh, cool, that's a neat 101 talk. And then he did the talk, I'm like, oh, my goodness,
[05:55.280 --> 06:01.580]  there is so much about this that I've just been oblivious to and not keeping up on the tech. And
[06:01.580 --> 06:07.320]  there's some really interesting stuff here. So, if you think you know DNS, maybe you do. More
[06:07.320 --> 06:11.400]  power to you, but I suspect there's a few folks out there that are going to learn something today.
[06:11.500 --> 06:17.640]  Jim, over to you, man. Hey, good afternoon. Can you guys hear me?
[06:18.200 --> 06:24.560]  They better. Just keep going. We hope so. All right. Well, if we can take the slide,
[06:24.560 --> 06:32.040]  if we can take the slide forward to the title slide. Thank you.
[06:32.520 --> 06:40.140]  So, thank you, guys, for the DC Groups team for setting this up and making all this work. And
[06:40.140 --> 06:46.200]  I know there's been a lot of technical challenges, but I think it's been a good learning experience
[06:46.200 --> 06:54.480]  for everybody involved. And thank you to Donald for inviting me to come and do this presentation
[06:54.480 --> 07:10.180]  today. Okay. So, DNS New World Order. What the fuck? So, I'm a guy on the internet. You can
[07:11.120 --> 07:19.960]  find me easily. I've been around, done a lot of things in ISP land. I've been on the internet
[07:19.960 --> 07:30.520]  since 87. I have to issue a disclaimer. I am a director and co-founder of a non-profit internet
[07:30.520 --> 07:37.560]  exchange called Weenix. We happen to host some servers for one of the companies that I'm going
[07:37.560 --> 07:46.840]  to be discussing today, Quad9. So, just a little disclaimer. All right. So, here's what we're going
[07:46.840 --> 07:53.160]  to learn today. Topics of presentation. We're going to talk about the DNS system in general
[07:53.160 --> 08:00.860]  and some of these new encrypted DNS methods like Doe and Dot. We're going to talk about operational
[08:00.860 --> 08:07.100]  reasons why you should monitor your DNS, about all these cloud services that are out there
[08:07.100 --> 08:13.340]  offering easy-to-remember DNS servers and why would they want to do such a thing.
[08:14.140 --> 08:20.900]  The privacy implications of some of the web browser product decisions. And then I'm going
[08:20.900 --> 08:25.660]  to end with some recommendations on how to mitigate the impact of all of these new
[08:26.300 --> 08:33.170]  encryption methods and those cloud-based DNS services.
[08:34.890 --> 08:44.090]  So, this slide here, which is, talks about the new troubleshooting procedure.
[08:44.690 --> 08:50.710]  It is not DNS. There's no way it's DNS. It was DNS.
[08:54.110 --> 08:59.710]  And I'm going to pause here until the slides catch up.
[09:02.730 --> 09:06.830]  We should be on the one that says new troubleshooting procedure. It's not DNS.
[09:06.830 --> 09:12.810]  There's no way it's DNS. It was DNS. We know it was always DNS. And if Jim, if you can do a
[09:12.810 --> 09:17.330]  next every time from now on, hopefully we can keep it that same.
[09:18.470 --> 09:25.210]  So, we're on the graphic, right guys? New troubleshooting procedure sitting on a cube wall.
[09:25.350 --> 09:28.030]  There's a little bit of a delay on the screen. I can see that.
[09:28.030 --> 09:32.710]  Who would have thought? Latency on the internet. Yeah, it's amazing.
[09:35.230 --> 09:40.310]  All right, are we going to share these slides afterwards, Jim? Yes, yeah. Okay, so if there's
[09:40.310 --> 09:45.150]  anyone in the audience who's trying to throw bricks at us right now, we will make sure you
[09:45.150 --> 09:49.790]  get a copy of the slide deck and you can just play it through in your own mind afterwards again.
[09:50.430 --> 09:56.930]  Yes. Oh, I see it loading. I see your cube wall loading.
[10:01.650 --> 10:06.810]  It's rendering like line by line on my Twitch. I don't know about yours. Yeah,
[10:06.810 --> 10:11.030]  I apologize. That's awesome. Apparently, my slides...
[10:16.610 --> 10:20.950]  They're not even all that complicated. Hey, look, graphics.
[10:20.950 --> 10:27.810]  Masterized PNGs, right? Yeah. I wonder if it's like upscaling them into some sort of
[10:27.810 --> 10:36.310]  ludicrously detailed resolution that it doesn't need to. Anyway, I'm proceeding onward. So,
[10:36.310 --> 10:43.490]  let's talk about DNS. Next slide. So, what the heck is DNS? So, it's the domain name system.
[10:44.250 --> 10:50.590]  And it is really about the most fundamental technology that makes the internet work
[10:50.590 --> 10:59.650]  other than packets and wires and fiber. And it works so well that most people never even think
[10:59.650 --> 11:06.830]  about it. We don't think about it until it breaks. Most end users really have no knowledge about it.
[11:07.290 --> 11:17.610]  So, what DNS does is that it simply converts the names that humans can remember into numbers,
[11:17.610 --> 11:22.650]  which is what computers use, network addresses. Next slide, please.
[11:24.060 --> 11:29.450]  It's also used internally by almost every organization because almost everybody's
[11:29.450 --> 11:36.270]  running Microsoft Active Directory. And guess what? Active Directory depends entirely
[11:36.270 --> 11:43.370]  on DNS working correctly and reliably. Next slide, please.
[11:46.370 --> 11:53.550]  So, really, everything you do on the internet needs DNS to function. This is why a lot of people
[11:53.550 --> 11:59.290]  will say something like, and I'm sure those of you in the audience that have done any sort of
[11:59.290 --> 12:05.390]  tech support or help desk, you've heard this before, the internet is down. And usually,
[12:05.390 --> 12:12.450]  that's not the case. The internet is just fine. But DNS resolution was broken for that user.
[12:13.000 --> 12:21.010]  So, DNS requests are usually called queries. And next slide, please.
[12:23.040 --> 12:29.270]  These queries that you issue all the time with your browser and with your phone and pretty much
[12:29.270 --> 12:37.890]  every single app that you use, they reveal an awful lot about you and what you are doing online.
[12:37.890 --> 12:45.350]  The games you play, email, et cetera. So, a little refresher about what DNS is.
[12:45.350 --> 12:53.330]  Next slide, please. Domain names are hierarchical. They start at the root or the dot. And then we
[12:53.330 --> 13:01.190]  have top-level domains. And there's the original generic top-level domains like .com and .gov and
[13:01.190 --> 13:11.750]  .net or various country codes like .uk, .jp. Originally, there was just a very few number
[13:11.750 --> 13:19.850]  of top-level domains. Now there's more than a thousand. You have such things as .bank, .coop,
[13:19.850 --> 13:31.160]  even .horse, which is kind of fascinating. All right. So, this next slide, please.
[13:35.090 --> 13:46.130]  So, we have some example DNS names. Google.com, www.bbc.co.uk, et cetera. You get the idea.
[13:46.290 --> 13:53.110]  Most of you guys know how DNS is structured. So, DNS is a service that converts names into
[13:53.110 --> 14:03.310]  numbers. So, for example, next slide, please. You look up a record like www.cnn.com when you
[14:03.310 --> 14:10.530]  punch that into your browser. You'll get an IPv4 address that you can almost remember,
[14:10.530 --> 14:19.050]  151.101.167. But with IPv6, you're going to get a big, long hexadecimal address that
[14:19.050 --> 14:24.570]  nobody in the world should try to remember. This is why we have DNS.
[14:25.630 --> 14:39.590]  Next slide. So, DNS was originally conceived in 1983, roughly. At least the RFC was published
[14:39.590 --> 14:48.690]  then, RFC 882. And that was superseded by RFC 1035 in 1987. And that is basically more or less
[14:48.690 --> 14:56.210]  the DNS that we have today. BIND, the Berkeley Internet named
[14:57.050 --> 15:07.330]  Daemon, was created in 1985. And this DNS is really the last major plain text protocol that's
[15:07.330 --> 15:12.890]  left on the Internet. Although, as we're going to discuss, there's lots of people trying to
[15:12.890 --> 15:20.190]  make it go away. A little more background on the DNS. In order for DNS to work,
[15:20.190 --> 15:28.190]  you have to have the root servers. Next slide, please. The 13 root servers in the world,
[15:28.190 --> 15:35.050]  lettered A through M. And they're operated by 12 different organizations. And it's important
[15:35.050 --> 15:41.810]  to understand that these 13 servers that are the root of the DNS, they are by no means
[15:41.810 --> 15:48.110]  individual servers. These are clusters of servers with load balancers and multiple
[15:48.110 --> 15:55.790]  instances all over the world. Some of these root servers have over 160 separate physical
[15:55.790 --> 16:02.270]  instances around the world in various data centers. Because they're so widely distributed,
[16:02.670 --> 16:09.590]  this allows scaling of traffic volumes and lots of increased resiliency and redundancy,
[16:09.590 --> 16:16.410]  particularly against directed attacks like DDoS attacks, which root servers get all day long.
[16:16.470 --> 16:24.150]  Next slide, please. So, all of the root servers in the letters A through M,
[16:24.150 --> 16:30.870]  they get a massive amount of traffic in terms of queries and transactions.
[16:30.870 --> 16:38.190]  We're talking double digit billions of queries per day processed by these root servers.
[16:38.190 --> 16:49.090]  That's trillions of DNS queries per month. And the DNS has actually managed to scale
[16:49.090 --> 16:57.810]  over nine orders of magnitude in the last 35 years. And it will continue to do so.
[16:57.810 --> 17:04.570]  I think that's pretty impressive for a protocol designed in the mid-80s.
[17:05.290 --> 17:12.750]  One of the ways that DNS scales... next slide, please... is a technique called IP NCASI.
[17:12.750 --> 17:17.990]  This is where you take an IP address block and you advertise it in multiple locations
[17:17.990 --> 17:25.710]  on the internet at the same time via BGP routing. The same address appears in multiple locations
[17:25.710 --> 17:34.550]  and your ISP or your network makes decisions to steer the traffic to the best, nearest instance
[17:34.550 --> 17:41.770]  of that IP address. So, all the DNS servers, all the root DNS and all the cloud DNS in the world
[17:41.770 --> 17:52.110]  uses NCAST. Next slide, please. So, we talked about traditional DNS started in 85. It's what
[17:52.110 --> 18:02.770]  some people are now calling DO-53, since we have DOH and DOT. DO-53 is the original unencrypted DNS.
[18:03.440 --> 18:11.890]  So, it's UDP port 53 for queries, TCP port 53 for zone transfers. And it's, again,
[18:11.890 --> 18:18.230]  it's been largely the same for the last 35 years. Next slide, please.
[18:18.230 --> 18:25.110]  The wonderful thing about DNS from a network management point of view and a security point
[18:25.110 --> 18:30.970]  of view is that it's plain text. So, you can monitor it over the wire very easily.
[18:31.930 --> 18:39.610]  And I have to say, if you're in a corporate environment and your IT security staff isn't
[18:39.610 --> 18:47.590]  monitoring DNS, they're doing it wrong. If you are the IT security staff for your organization
[18:47.590 --> 18:57.090]  and you are not monitoring DNS, you really ought to. It is incredibly useful to monitor DNS,
[18:57.090 --> 19:05.010]  lets you know what your endpoints are up to. It makes it easier to find malware and, of course,
[19:05.010 --> 19:17.570]  good old AUP violations on your network. Next slide, please. So, there is some other,
[19:17.570 --> 19:22.870]  and some people have thought, well, that's kind of a problem. I don't really want people to know
[19:23.410 --> 19:31.730]  what I'm doing and what my DNS queries are. So, there was a group of folks that were not IETF
[19:31.730 --> 19:37.530]  and did not come up with an official standard, but they created a thing out of the free VSD
[19:37.530 --> 19:48.250]  community called DNS Crypt. And I skipped over DNSSEC. You may have heard of DNSSEC.
[19:48.470 --> 19:57.330]  It's a way to cryptographically authenticate DNS data, but it doesn't actually hide it,
[19:57.330 --> 20:02.710]  it just authenticates it. And DNSSEC is really not a topic of this presentation,
[20:02.710 --> 20:12.850]  it's like a whole other presentation unto itself. Okay. Next slide. DNS Crypt, 2011,
[20:12.850 --> 20:20.690]  bunch of folks in the free VSD world were instrumental in that. They created an encryption
[20:20.690 --> 20:30.650]  protocol. It worked. It actually used port 443, but didn't use TLS, used another encryption method.
[20:31.510 --> 20:37.150]  So, it worked, it solved the problems, but it really didn't get much traction
[20:37.930 --> 20:44.530]  at the time with anybody. Because, you know what? DNS is kind of boring.
[20:46.470 --> 20:54.510]  So, fast forward a little bit. Next slide. DNS over TLS, or commonly known as DOT.
[20:54.510 --> 21:03.230]  This was an RFC process issued May 2016. And this is basically traditional DNS
[21:03.230 --> 21:11.070]  with TLS encryption running on a different port. This uses TCP port 853. And the nice thing about
[21:11.070 --> 21:19.800]  that is it keeps the network control traffic separate from your application data traffic.
[21:21.440 --> 21:31.960]  Now, you may not be aware, but... next slide, please... support for TLS at DNS over TLS DOT
[21:31.960 --> 21:42.380]  has actually been around for a while. It started in Android 9 for the whole OS. So,
[21:42.380 --> 21:48.660]  if you have recent Android, it's enabled by default and it will just work if it's supported
[21:48.660 --> 21:56.320]  by the server that you're talking to. Microsoft says they may eventually support DOT in the
[21:56.320 --> 22:06.000]  operating system. And Apple is going to be supporting DOT in the new iOS 14 and in macOS 11.
[22:06.000 --> 22:18.620]  So, this is fairly recent developments. And this is good to have encrypted DNS,
[22:18.620 --> 22:26.260]  right? Next slide, please. So, there was a different group of folks that decided to create
[22:26.260 --> 22:37.520]  DNS over HTTPS or DOE. This is a different RFC, 8484, issued in December of 2018.
[22:38.240 --> 22:46.920]  So, this is a protocol that uses TCP port 443 with TLS encryption. What does that remind you of?
[22:46.920 --> 22:54.480]  Yes, it is the same as HTTPS for websites. So, it implements DNS queries using a special
[22:54.480 --> 23:02.500]  HTTP GET with JSON responses that get parsed. It can be a little bit slower
[23:02.500 --> 23:08.280]  than regular DNS by several milliseconds, but it's not really a big deal.
[23:10.920 --> 23:19.640]  Microsoft has actually just added support for DOE, starting in Windows 10 Preview Build 19.6.2.8.
[23:19.800 --> 23:27.360]  And Apple is going to support DOE in the OS, starting in iOS 14 and macOS 11,
[23:27.360 --> 23:37.860]  which are coming out this fall. So, we'll talk about why DOE and DOT exist in a little bit.
[23:37.860 --> 23:41.320]  I'm going to talk about DNS in the cloud. Next slide, please.
[23:42.760 --> 23:52.480]  So, you may be aware that for many years, there's been public DNS servers, usually operated by ISPs,
[23:52.480 --> 23:55.840]  as a resource. If you've been around on the internet for a while,
[23:55.840 --> 24:03.640]  you may recognize some of these numbers on the slide, like 4.2.2.2, operated by level 3,
[24:04.300 --> 24:12.560]  75.75.75.75, which I believe is Comcast. And there's others out there. And these were really
[24:12.560 --> 24:18.980]  just primarily for network engineers and network people who just needed to set up DNS to get
[24:18.980 --> 24:27.540]  something working real quick. And most end users didn't really know about them. Until
[24:28.660 --> 24:38.200]  DNS in the cloud. Next slide. So, Google, back in December 2009, and some of you
[24:38.200 --> 24:45.880]  were probably still in high school then, they launched a service called 8.8.8.8. And why did
[24:45.880 --> 24:51.720]  they do that? Well, they said they wanted to improve the speeds and the user experience
[24:52.680 --> 25:01.260]  versus a lot of ISPs that had broken DNS and still do. And I believe that.
[25:01.800 --> 25:08.000]  It also gave them all sorts of data about what people were doing and where they were going.
[25:08.260 --> 25:18.380]  Now, using Google DNS back then was useful to work around censorship issues at the time.
[25:19.160 --> 25:26.260]  You may or may not remember this picture, which will probably take a minute and a half to load
[25:26.260 --> 25:33.160]  on the stream. It's a picture from the Arab Spring uprising where people were actually
[25:33.160 --> 25:42.060]  spray painting graffiti with the DNS numbers on buildings more than once all over the place.
[25:42.060 --> 25:50.340]  And this, at the time, was actually an effective way to avoid censorship by the government.
[25:50.340 --> 25:56.970]  Not so much anymore. Censorship and network control has gotten a lot more sophisticated.
[25:58.940 --> 26:05.800]  Next slide, please. So, Google, they're quad nine for several years, and
[26:06.660 --> 26:15.360]  there wasn't really any others. And then now there's more. Cloudflare came up with
[26:15.760 --> 26:24.100]  1.1.1.1 in cooperation with the APNIC that controlled that IP space.
[26:24.720 --> 26:30.160]  Then there's another organization called quad nine that is all nines.
[26:30.800 --> 26:38.660]  Interesting. And then there's been other cloud-based... next slide, please... such as OpenDNS,
[26:38.660 --> 26:43.680]  which is now Cisco Umbrella, because Cisco bought them, because that's what Cisco does.
[26:43.680 --> 26:53.700]  They buy things. And most recently, CIRA, the Canadian.ca registry authority, they created a
[26:53.700 --> 27:00.000]  new service called Canadian Shield with an IP address that is available to the public.
[27:03.620 --> 27:14.120]  So, next slide, please. If you can control the DNS for what someone goes to, what they're resolving,
[27:14.120 --> 27:20.160]  what your end users see, if you control the DNS, you basically control everything. It's
[27:20.160 --> 27:29.320]  almost as good as controlling the entire network. Which is the reason why so much malware
[27:30.240 --> 27:37.340]  that attacks home routers and things like that, they want to modify your DNS settings
[27:37.340 --> 27:43.620]  on your network router, if your clients are pointed at your local router,
[27:43.620 --> 27:53.240]  so that they can send you to illegitimate sites. So, next slide, please. Again,
[27:53.240 --> 28:01.640]  DNS, it's great for tracking. If you monitor DNS queries, you know where everyone goes online.
[28:01.640 --> 28:07.600]  Your shopping, your entertainment, what you do for work, most likely, any medical sites,
[28:07.600 --> 28:13.280]  the apps you run on your phone, and even right down to depending on the device,
[28:13.280 --> 28:17.820]  you can figure out what device it is in your house or your business, and particularly with
[28:17.820 --> 28:28.220]  IoT devices based on those DNS queries. Next slide, please. So, if you control the DNS,
[28:28.220 --> 28:36.940]  again, you control where users go or don't go. I believe strongly DNS monitoring is great for
[28:36.940 --> 28:42.820]  fighting malware and intrusions, and I, again, say it is essential for Blue Team network defense
[28:42.820 --> 28:55.940]  and monitoring. Ah, but DNS also is money, because many ISPs, and this includes your cell phone
[28:55.940 --> 29:03.520]  company, because they are, in fact, an ISP, because you use data on your phone. Many of these ISPs,
[29:03.520 --> 29:10.720]  including your cable TV companies, iLex, telcos, wireless carriers, et cetera, they are monitoring
[29:10.720 --> 29:18.360]  your DNS, and they are actually, many of them, selling that information to a variety of data
[29:18.360 --> 29:25.360]  brokers and advertising companies and other companies that want to track people. And in some
[29:25.360 --> 29:34.920]  cases, those ISPs and carriers, they actually own some of the advertising companies themselves,
[29:34.920 --> 29:41.400]  which is why, when they say things in their acceptable use policy, like, we will not sell
[29:41.400 --> 30:02.610]  your data, that they're able to tie you directly via your cell phone ID numbers, your home IP
[30:02.610 --> 30:09.250]  address range, whatever IP address you had at the time, they can tie that data directly to you
[30:09.250 --> 30:16.890]  demographically. They know it's you and not somebody else. Next slide, please. So,
[30:17.950 --> 30:25.010]  there are different estimates what this data is worth and how they can sell it for. I have seen
[30:25.010 --> 30:34.490]  everything from $3 a year per subscriber up to several hundred. I think it varies upon the
[30:34.490 --> 30:41.070]  demographics of the value of the person. So, if you are not paying for a product
[30:41.610 --> 30:54.770]  on the Internet, you are the product. So, next slide. So, why do we have Doe? Well,
[30:54.770 --> 31:01.990]  the reason we have Doe is, up until just recently, the operating system vendors,
[31:01.990 --> 31:08.470]  really, they had not implemented any sort of encrypted DNS. They are now about to release
[31:09.390 --> 31:17.470]  dot support. But for years, they really weren't doing anything. So, some of the browser makers,
[31:17.470 --> 31:23.710]  like Firefox, Mozilla, they decided that they needed to take matters into their own hands,
[31:23.710 --> 31:34.770]  and that's in part how Doe came about. So, Firefox added Doe support in September of 2018.
[31:35.970 --> 31:43.050]  And then, in January of this year, they made it an option that you could enable Doe,
[31:43.050 --> 31:52.170]  if you wanted to, in Firefox. But since February 25th of this year,
[31:52.170 --> 31:59.750]  Doe is now enabled by default for all Firefox users in the U.S. Next slide, please.
[32:00.250 --> 32:08.950]  So, this is a picture of the opt-out in Firefox. And I think most end users are just going to see
[32:08.950 --> 32:14.830]  this thing and say, okay, yeah, that's great. It's more encryption and it's more privacy.
[32:16.570 --> 32:26.650]  And, in fact, that is true, to a point. So, Mozilla picked Cloudflare as their first and
[32:27.110 --> 32:31.590]  default Doe provider. And they drew up a contract and there's various requirements
[32:32.190 --> 32:41.610]  that they have to honor. And that's interesting.
[32:43.970 --> 32:52.290]  Firefox also includes a domain name canary, which is something that your ISP can set
[32:52.290 --> 32:57.120]  in their DNS servers, which will actually disable Doe in Firefox.
[32:57.510 --> 33:03.890]  Because you see, there's a whole lot of tension over who gets to monetize you.
[33:06.570 --> 33:12.050]  Because you are the product. So, the ISPs have been doing the monetization.
[33:12.650 --> 33:17.650]  And now there are other folks that would like to do that. And it's also the monitoring.
[33:18.410 --> 33:24.010]  Next slide, please. So, there are other web browsers besides Firefox
[33:25.030 --> 33:31.810]  supporting Doe now. Chrome supports it, but it's not enabled by default yet. I understand there's
[33:31.810 --> 33:40.170]  some A-B testing going on and I imagine Chrome will be enabling it soon. But Chrome says they
[33:40.170 --> 33:51.230]  will have a GPO that will enable you to disable Doe entirely. Microsoft Chromium Edge supports it.
[33:51.230 --> 33:56.890]  It's not enabled by default. Opera supports it. Brave supports it, et cetera. Not enabled by
[33:57.130 --> 34:06.130]  default. So, you know, Doe does encrypt things. And it makes it harder for people to see
[34:06.790 --> 34:12.150]  where you're going on the internet by encrypting your DNS traffic.
[34:13.310 --> 34:19.370]  But this is a double-edged sword. There's a lot of malware now using Doe.
[34:21.820 --> 34:26.360]  And because it's using Doe, you're not seeing that traffic anymore.
[34:26.920 --> 34:35.060]  There's been at least one piece of malware, the, I guess, God Lula backdoor for Linux and Windows,
[34:35.060 --> 34:41.540]  and that came out in January of 2019. And it was using Doe for its CNC servers.
[34:42.340 --> 34:48.220]  And I expect there's going to be all sorts of additional malware developed that's going to use
[34:48.220 --> 34:53.800]  Doe because it makes it easier, you know, for them to hide. So, I think you're going to need
[34:53.800 --> 34:58.540]  to start deploying man-in-the-middle TLS proxies in your corporate environments
[34:58.540 --> 35:02.260]  if you aren't already. Next slide, please.
[35:04.600 --> 35:12.660]  And again, I think the Adversaries TTPs are changing to adapt to Doe. I suspect there's
[35:12.660 --> 35:19.340]  probably some malware out there in the wild using Doe that people don't even know about right now.
[35:19.880 --> 35:23.760]  I think that's going to be a big, big thing for the rest of this year and next year.
[35:26.080 --> 35:36.980]  So, DNS in the cloud, going back to that. It's really surveillance. Next slide, please.
[35:37.680 --> 35:44.000]  Not all of the DNS cloud providers have a clear privacy policy. Some things they're retaining
[35:44.000 --> 35:51.800]  for a couple of years in summary, maybe just 24 hours. Okay, some of that doesn't bother me.
[35:51.800 --> 36:01.920]  Some of it does. However, everybody is just assuming that Doe actually does give you privacy.
[36:02.480 --> 36:13.460]  And the answer is, not as much as you think. It also is centralizing your DNS queries by using
[36:14.300 --> 36:20.880]  these sort of well-known cloud providers to provide DNS service for all sorts of people.
[36:21.520 --> 36:28.600]  You're really centralizing the places where that data can be monitored and collected.
[36:32.080 --> 36:42.600]  So, DNS over HTTPS, it's not as secure. Next slide, please. We're up to 49.
[36:44.380 --> 36:52.080]  Doe doesn't actually encrypt the data that you can't get in other unencrypted forms.
[36:52.160 --> 37:00.200]  You see, because where you go with Doe, SNI information, the IP address you're actually
[37:00.200 --> 37:09.400]  talking to, OSCP checks for certificates, and all of that is still in clear text.
[37:09.400 --> 37:15.000]  So, it's... and if they know the IP address of the website you're going to,
[37:15.000 --> 37:20.380]  there's been studies that can pretty much correlate that with, you know, the website,
[37:20.380 --> 37:28.180]  something like 85% of the time. So, you think that you may be getting all sorts of privacy
[37:28.180 --> 37:36.780]  from using Doe, but you're not. Just because they can't see exactly what DNS queries you
[37:36.780 --> 37:43.480]  are issuing doesn't mean they can't figure out what you're actually doing. Next slide.
[37:43.480 --> 37:53.620]  Here's a tweet from DA667 pointing out some of the same things. It really consolidates trust
[37:53.620 --> 38:00.980]  of confidential data to organizations that may not deserve it. Next slide, please.
[38:01.460 --> 38:10.080]  And then we have TLS session resumption tickets. And this was an area that I did not know about
[38:11.040 --> 38:16.520]  and was unaware of until I started doing the research for this talk.
[38:18.000 --> 38:24.960]  These are basically unblockable cookies that can track you everywhere you go by resuming
[38:24.960 --> 38:30.240]  your previous TLS sessions. Now, this was done and included in the standards to
[38:30.240 --> 38:37.040]  help reduce session setup time and increase performance. But by renewing these resumption
[38:37.040 --> 38:45.100]  tickets, which can be done over a long period of time, up to seven days with TLS 1.3,
[38:45.100 --> 38:52.240]  that provides a method to track you across the internet no matter what you're doing
[38:52.960 --> 39:00.140]  and where you're doing it. So, if you get up in the morning and you are using your phone
[39:00.580 --> 39:05.700]  at home, let's say on your home Wi-Fi, and then you leave and you go out in the world
[39:05.700 --> 39:12.560]  and you use your phone on your cellular carrier with cellular data, you go to an office,
[39:12.560 --> 39:18.840]  back when people used to do that, go to a coffee shop, back when that was standard to do,
[39:19.440 --> 39:24.500]  any Wi-Fi that you use, they're still able to track you. You go someplace else, you go back home.
[39:24.500 --> 39:30.600]  The point is, is that across all of those sessions in all of those multiple ISPs and
[39:30.600 --> 39:37.300]  multiple wireless networks, we're tracking directly back to you because of these session
[39:37.300 --> 39:54.480]  resumption tickets. The other problem with DNS in the cloud, particularly people outside the US,
[39:54.480 --> 40:01.120]  they're USA-based, USA companies. So, that means they are subject to getting national security
[40:01.120 --> 40:11.980]  letters. They're subject to FISA 702 and other laws. So, that means that the government can go
[40:11.980 --> 40:19.240]  to one of these providers and say, we would like a copy of all of your server logs. And yes,
[40:19.240 --> 40:26.180]  you may be deleting them, but we don't have to. And if it's a national security letter,
[40:26.180 --> 40:34.770]  they can't even talk about it or tell anyone. So, by centralizing into these cloud services,
[40:35.620 --> 40:41.830]  it just makes it easier for governments and law enforcement to get your information.
[40:43.310 --> 40:52.210]  So, what do we do about all of this? Next slide. So, I have some recommendations.
[40:52.790 --> 41:00.590]  Number one, if you should be running your own internal recursive DNS server for your network,
[41:00.590 --> 41:05.450]  this will give you the absolute best performance for DNS because it's the lowest latency because
[41:05.450 --> 41:10.930]  it's on your network. Now, the good news is, if you're in a corporate environment,
[41:10.930 --> 41:14.610]  you're probably running Microsoft Active Directory, you're already running
[41:15.130 --> 41:19.790]  a local recursive DNS server, but it's probably not set up well.
[41:20.710 --> 41:26.390]  You should have this internal recursive DNS server, and you should put all kinds of logging
[41:26.390 --> 41:32.750]  and monitoring on this server. This is where your logging and monitoring goes here. Because
[41:32.750 --> 41:39.110]  logging on the server level, of course, it's decrypted those packets. This allows you to
[41:39.110 --> 41:47.930]  monitor your internal endpoint traffic. Next slide. On your firewalls, you set your firewalls
[41:47.930 --> 41:57.030]  to block all TCP and UDP port 53 traffic for all your endpoints out to the world. So, they can't
[41:57.030 --> 42:04.710]  use regular DNS. This will force your endpoints to use your internal DNS. You also want to block
[42:04.710 --> 42:16.330]  TCP port 853 to block DOT on your corporate firewall. Now, when it comes to DOE, DOE is a lot
[42:16.330 --> 42:24.150]  harder to block because DOE looks just like regular HTTPS traffic. So, there are some vendors,
[42:24.150 --> 42:28.810]  depending on what kind of firewall that you have, and which vendor, and how much money you're giving
[42:28.810 --> 42:35.890]  them. They have some rule sets to help enable blocking of DOE. Some of them work just by
[42:35.890 --> 42:43.250]  blocking the IP addresses of well-known DOE servers. Others actually use man-in-the-middle
[42:43.250 --> 42:49.990]  proxy functionality built in their solutions, and they may have rule sets. This is an area where I
[42:49.990 --> 42:56.550]  think a lot of corporate defenders are going to need to invest time specifically to monitor DOE
[42:56.550 --> 43:04.210]  queries via some sort of man-in-the-middle proxy that you're going to have to manage.
[43:05.650 --> 43:13.330]  And this is what you're going to have to do, ultimately. You're going to want to set your
[43:13.330 --> 43:22.050]  endpoint configuration standards to disable DOE in any browsers on your endpoints. And you do have
[43:22.050 --> 43:29.010]  endpoint configuration standards, right, in your organization? That magical golden image,
[43:29.010 --> 43:36.230]  as they say. So, you want to make sure that all of your endpoints are configured to talk to your
[43:36.230 --> 43:42.430]  internal recursive servers only. Yeah, whatever method you have to do that, whether it's DHCP
[43:42.430 --> 43:51.730]  options, group policy objects, static configs, registry keys, whatever, make it so. You can also
[43:51.730 --> 44:02.730]  set up DOE logging in Firefox if you have to use Firefox. So, now that you have everybody talking
[44:03.570 --> 44:11.810]  to your internal recursive servers, that's great. But now you want to protect your traffic
[44:11.810 --> 44:19.150]  from those servers out to the internet. Because if you don't do that, then it's still possible
[44:19.150 --> 44:24.610]  to watch the data stream coming out of your environment, whether that's home or at work.
[44:24.850 --> 44:31.630]  So, you can set your internal servers to use an external resolver where it will just automatically
[44:31.630 --> 44:37.470]  forward, as some of the software calls this forwarding, all of those queries to a particular
[44:37.470 --> 44:44.590]  outside server rather than talking to the root servers directly. So, if you do this, if you
[44:44.590 --> 44:49.790]  have an internal recursive server and you tell it to talk to some external server
[44:49.790 --> 44:52.560]  over an encrypted protocol, whether that's
[44:54.430 --> 45:03.710]  DOT or DNS Crypt, DOE still leaks information, and you use an external server,
[45:04.350 --> 45:12.800]  particularly an external server in a GDPR country that has some actual privacy protection,
[45:12.800 --> 45:19.540]  and if that server has enough other users, you're going to get a privacy mixer sort of
[45:19.540 --> 45:25.500]  herd protection for your DNS queries. If there's tens of thousands or hundreds of thousands of
[45:25.500 --> 45:31.920]  people all using a particular server, it's going to be a lot easier, a lot harder rather than
[45:31.920 --> 45:40.180]  that to tie those queries back to you. The other option that you can do is you can set up your own
[45:40.180 --> 45:47.760]  DOH server in like a VPS. If you trust DOH, you can also set up your own DOT server.
[45:47.880 --> 45:53.760]  It's not very hard, and if you are at all handy with a Linux command line,
[45:53.760 --> 45:58.460]  it's the sort of thing that you can do in, you know, a couple hours.
[46:00.780 --> 46:05.380]  Another recommendation for your, particularly for your corporate networks, but I would also
[46:05.380 --> 46:14.340]  extend this to any power user geek home network, is you want to capture all of the IP addresses of
[46:14.340 --> 46:22.320]  those well-known public DNS resolvers in addition to doing a block at the edge. And this is because
[46:22.320 --> 46:29.960]  you will be surprised to find out how many devices are using some sort of hard-coded DNS.
[46:30.620 --> 46:37.120]  In particular, I know Google Chromecasts, they ignore whatever you set in DHCP.
[46:37.580 --> 46:46.540]  They will use Google DNS always, and there's others. So, many, many ISPs and a lot of hotel
[46:46.540 --> 46:52.280]  hospitality networks already do this sort of network capturing, and you just haven't noticed.
[46:52.300 --> 46:58.860]  Many times you think you may be talking to Google Quad 8 or some other server, but you're not.
[46:58.860 --> 47:05.140]  Just something they've done particularly in hospitality networks to give you that hotspot login.
[47:06.680 --> 47:15.180]  Next slide. Now, a recommendation if you're in a small business environment or home environment,
[47:16.040 --> 47:24.920]  you might want to use Quad 9 or Cisco Umbrella or Canadian Shield if you're not as concerned
[47:24.920 --> 47:30.440]  with privacy issues, because all of those services include some malware blocking,
[47:30.440 --> 47:36.220]  where they get threat intelligence feeds about the latest command and control servers,
[47:36.220 --> 47:44.580]  the latest compromised servers that are feeding downloads of malware. And so, they are specially
[47:44.580 --> 47:52.080]  set up to not return the correct DNS information for any of those DNS queries. So, that provides
[47:52.360 --> 48:01.260]  a level of additional protection, particularly in an environment that just simply can't afford
[48:01.260 --> 48:09.200]  anything else. The other recommendation that I give everyone, particularly, you know,
[48:09.200 --> 48:15.840]  enthusiasts, is you want to look at running something like PyHole. Next slide. PyHole
[48:15.840 --> 48:20.960]  was originally meant to run on a Raspberry Pi. It doesn't have to. You can run it pretty much
[48:20.960 --> 48:28.700]  on any Linux or in a container. And it works by blocking advertising servers, known advertising
[48:28.700 --> 48:34.780]  servers. And it's pretty effective. It's not perfect, but it's pretty effective. And you can
[48:34.780 --> 48:44.040]  use PyHole to do your internal resolution and then chain it to external DOH servers or DOT.
[48:45.000 --> 48:52.420]  So, that's my presentation. And remember, it's always DNS. Always.
[48:54.180 --> 49:00.640]  I will be making this slide deck available for download. There is a whole bunch of bibliography,
[49:00.640 --> 49:07.220]  about five pages of interesting links. If you are at all interested in this sort of topic,
[49:07.220 --> 49:14.600]  I recommend that you read much further. Also, there are various folks in the DNS community,
[49:14.600 --> 49:19.460]  the true legends, like Paul Vixie, who is one of the original authors of Bind, and he's been
[49:19.460 --> 49:29.660]  doing DNS for decades. And Bert Hubert of PowerDNS. Those guys have many wonderful talks
[49:29.660 --> 49:37.100]  available on YouTube. And they are the real experts. I'm just the guy doing some research
[49:37.100 --> 49:39.360]  bringing it to you folks.
[49:41.420 --> 49:44.040]  Jim, thank you so much. That was amazing.