WEBVTT
Kind: captions
Language: en

00:00:00.020 --> 00:00:04.160
Whatever you're giving them, every single click, every page, every object on the web page,

00:00:04.360 --> 00:00:06.420
they don't even need to know what websites you're going to.

00:00:06.470 --> 00:00:07.620
They can actually figure it out through them.

00:00:08.920 --> 00:00:11.660
How much can your ISP see about your web traffic?

00:00:12.040 --> 00:00:18.360
Does encrypted DNS even mean anything if there are still parts of it that aren't quite as encrypted as they should be?

00:00:18.780 --> 00:00:24.920
What's the difference between DNS over HTTPS versus DNS over TLS versus the brand new DNS over Quick?

00:00:25.160 --> 00:00:27.320
What does a privacy-respecting DNS mean?

00:00:27.350 --> 00:00:29.020
What even is a DNS?

00:00:29.380 --> 00:00:35.180
Today, we are going to have pretty much a masterclass with Quad9 on DNS.

00:00:35.680 --> 00:00:39.420
Now, this isn't actually necessarily structured as a formal masterclass,

00:00:39.560 --> 00:00:46.440
but I think this interview itself really gets to the core of pretty much every major question right now in 2026

00:00:46.900 --> 00:00:53.400
regarding privacy, security, DNS, censorship, circumvention, and really everything else you need to know all in one place.

00:00:53.600 --> 00:00:58.620
I really enjoyed doing this one, and I learned a lot from it, so I hope that you all feel the same way coming out of it.

00:00:58.940 --> 00:01:00.280
And now let's get to the interview.

00:01:00.880 --> 00:01:03.900
Why don't you just intro Quad9 a little bit for people who don't know who you guys are?

00:01:04.080 --> 00:01:06.340
So Quad9 is a nonprofit.

00:01:06.620 --> 00:01:08.100
We're based in Switzerland.

00:01:08.520 --> 00:01:16.040
And our mission is to give a basic cybersecurity and privacy protection to as many people as possible at no cost.

00:01:16.560 --> 00:01:24.180
And so we do that by running a recursive DNS resolver located at 9.9.9.9, hence the name Quad9.

00:01:24.340 --> 00:01:28.180
And we give that service away to everybody for free.

00:01:29.140 --> 00:01:35.480
And so, I mean, the first question I'm sure I would ask and many other people is, okay, so how is it free? How do you do that?

00:01:36.000 --> 00:01:40.840
Well, actually, the first question people ask is, what's recursive DNS? Because the tech folks know what that is.

00:01:41.400 --> 00:01:45.980
Got it. So how do we give that away for free? So Quad9 has been around for about 10 years.

00:01:46.580 --> 00:01:54.520
And we were founded and we've been essentially kept running by a combination of grants, sponsorships.

00:01:55.040 --> 00:02:09.979
And now we're actually starting to branch out into figuring out how do we have sustainable income models. So we're actually looking at some of the aggregated data that we have and we're figuring out some ways to monetize some of that as well without jeopardizing user privacy.

00:02:10.580 --> 00:02:22.260
So we are primarily grant and sponsorship funded, but kind of shifting to a mix of trying to come up with some commercial services on the back end while maintaining that grant and sponsorship method going forward.

00:02:22.600 --> 00:02:26.120
People think that we're doing the right thing and they give us money to do the right thing.

00:02:26.620 --> 00:02:30.280
Not as many people as I would like, but we are still continuing on.

00:02:30.400 --> 00:02:32.980
We've been going strong for 10 years and continue to expand.

00:02:33.840 --> 00:02:34.640
Yeah, that's great.

00:02:34.720 --> 00:02:40.620
I'll ask you a little bit more about that because I know some people in our audience, they're going to hear what you just said and they're going to think, oh, wow, that's scary.

00:02:40.920 --> 00:02:44.140
So we'll make sure we can dig into that more and what that looks like.

00:02:44.420 --> 00:02:49.540
Now, if somebody is kind of new to this and kind of like what you were saying, what's recursive DNS?

00:02:50.020 --> 00:02:51.540
Where do you normally start in explaining this to people?

00:02:51.590 --> 00:02:55.580
I know you used a bit of a different analogy last time we had you on than what most people are used to.

00:02:55.900 --> 00:02:57.120
Well, now you've put me on the spot.

00:02:57.220 --> 00:02:58.840
I'm not sure if I'm going to use the same analogy or not.

00:02:58.970 --> 00:03:00.500
So I'm going to go with what I think is most useful.

00:03:00.720 --> 00:03:04.960
So basically the DNS is the equivalent of the phone book of the internet.

00:03:05.060 --> 00:03:09.760
And that's kind of the most common analogy where your computer doesn't actually understand how to use names.

00:03:09.940 --> 00:03:15.600
So when you type in www.amazon.com, your computer doesn't actually know what that means.

00:03:15.620 --> 00:03:17.040
It doesn't know how to get to that server.

00:03:17.260 --> 00:03:22.040
So what it does is that the first thing your computer does is it talks to a recursive resolver.

00:03:22.460 --> 00:03:27.080
It takes that name, gives it to the recursive resolver, and what it's expecting back is an IP address.

00:03:27.400 --> 00:03:31.200
And you've probably seen those or at least references to those, even if you're not a computer person at all.

00:03:31.720 --> 00:03:37.660
And the IP address is what your computer can then use to communicate to the Amazon server to get the content, to get the page load.

00:03:38.420 --> 00:03:48.000
And so Quad9 replaces what typically is provided by your ISP or your school or whatever your organization is.

00:03:48.000 --> 00:03:52.820
Usually there's a recursive resolver somewhere inside that organization that does this very simple job.

00:03:53.140 --> 00:03:56.580
It's actually not very simple, but it does this mapping of names to numbers.

00:03:56.960 --> 00:04:04.360
So it's a phone book where you hand off the task of looking things up in the phone book to the recursive resolver, and it hands you back a number.

00:04:04.680 --> 00:04:05.420
We replace that.

00:04:05.460 --> 00:04:11.220
We're kind of an over-the-top service that does exactly the same thing, but with a few added benefits.

00:04:11.640 --> 00:04:14.240
You mentioned that you are trying to give people privacy through this service.

00:04:14.540 --> 00:04:18.420
So what is typically the concern with maybe a default DNS?

00:04:18.660 --> 00:04:21.340
And we'll talk about how people can maybe see what their default is.

00:04:21.480 --> 00:04:22.660
But what's actually being collected?

00:04:22.840 --> 00:04:23.860
What's the real concern here?

00:04:23.980 --> 00:04:24.240
Right.

00:04:24.400 --> 00:04:28.260
There have been great advances in the last 15 years or so with the encryption of web pages,

00:04:28.460 --> 00:04:33.540
right? You see HTTPS encryption has been really, really moving forward quickly. And that's great

00:04:33.860 --> 00:04:37.660
where people can't snoop on the actual content that you're looking at. For the most part,

00:04:37.780 --> 00:04:41.560
there still are some unencrypted things, but for the most part, things are encrypted. However,

00:04:42.160 --> 00:04:45.360
DNS has not been encrypted and that's actually been much slower to convert.

00:04:45.960 --> 00:04:48.940
So if someone can actually look at the pointers you're doing, like in other words, if they're

00:04:49.040 --> 00:04:53.379
looking at the names you're looking up, they don't even need to see the content. They can kind of

00:04:53.400 --> 00:04:59.040
figure out where you're going and what you're doing. So whoever runs the recursive resolver,

00:04:59.220 --> 00:05:04.100
you need to trust them a lot because whatever you're giving them, every single click, every

00:05:04.420 --> 00:05:08.680
page, every object on the webpage you're looking at creates a name to number mapping. And if

00:05:08.860 --> 00:05:13.440
someone's looking at all those and can associate that with you as a person, then they don't even

00:05:13.620 --> 00:05:17.439
need to know what websites you're going to through looking at the content. They can actually figure

00:05:17.460 --> 00:05:24.440
it out through the metadata. And so when Quad9 does that, when we do that as a service, we do not

00:05:24.640 --> 00:05:28.520
collect any information about you, the individual. In fact, we don't even want to know who you are.

00:05:28.900 --> 00:05:34.060
There's no signup. There's no username required. There's no identification that we ask for. So you

00:05:34.200 --> 00:05:39.700
basically just change the resolver on your laptop or on your phone to Quad9, and that's all you have

00:05:39.700 --> 00:05:44.819
to do. There's nothing else. There's no software. We don't track any unique identifiers. We are a

00:05:44.840 --> 00:05:51.700
Swiss organization. And so we are bounded by extremely strict laws around what we can do with

00:05:51.820 --> 00:05:56.580
data. So we don't simply say we don't collect your data. There are legal constraints about what we can

00:05:56.580 --> 00:06:02.260
do with your data and we can't change our mind. Unlike a US corporation, which can at any time

00:06:02.400 --> 00:06:05.520
basically say, well, you know what, we're doing something different with your data today and

00:06:06.200 --> 00:06:11.139
good luck. We can't do that. And interestingly in Switzerland, and this is kind of the reason

00:06:11.160 --> 00:06:12.140
And people ask, why Switzerland?

00:06:12.800 --> 00:06:17.480
The penalties for us changing our mind and not doing what we say we're going to do, those

00:06:17.480 --> 00:06:18.600
are actually criminal penalties.

00:06:18.860 --> 00:06:19.740
They're not civil penalties.

00:06:20.440 --> 00:06:24.240
In the United States or even in Europe, if you violate someone's privacy, there's civil

00:06:24.980 --> 00:06:25.640
constraints, right?

00:06:25.680 --> 00:06:30.100
There's a fine that you pay and maybe there's something that your company has to do to remediate

00:06:30.100 --> 00:06:30.460
the problem.

00:06:31.000 --> 00:06:36.660
In Switzerland, actually, our foundation council and potentially me and other directors, or

00:06:36.680 --> 00:06:39.040
not directors, but other people in the company, we might go to jail.

00:06:39.340 --> 00:06:41.360
So we have to do what we say we're going to do.

00:06:41.410 --> 00:06:43.640
And so that's why the privacy guarantee with Quad9

00:06:43.730 --> 00:06:45.200
is so much stronger than in other places.

00:06:46.300 --> 00:06:48.820
Yeah, I think the analogy you used last time,

00:06:48.830 --> 00:06:49.960
or it might be confusing interviews,

00:06:50.190 --> 00:06:52.120
but it was a map that I remember.

00:06:52.320 --> 00:06:54.380
Yep, I've used the map analogy as well.

00:06:55.060 --> 00:06:57.020
Yeah, so I guess if people want to see that one,

00:06:57.160 --> 00:06:59.460
the old interviews there, if they really want to view it.

00:06:59.460 --> 00:07:00.600
And I think that's the one with Nate.

00:07:00.940 --> 00:07:02.460
So if I'm kind of new to DNS,

00:07:02.650 --> 00:07:04.440
and again, we'll get more technical in a second here,

00:07:04.620 --> 00:07:05.720
but just for the people who are newer,

00:07:06.220 --> 00:07:06.960
if I'm new to DNS,

00:07:07.300 --> 00:07:09.400
It sounds like I already have a default DNS provider

00:07:09.640 --> 00:07:11.480
that's being used on my computer, it's required,

00:07:11.820 --> 00:07:13.440
and if I swap that to be yours,

00:07:13.860 --> 00:07:15.880
I am getting better privacy

00:07:16.200 --> 00:07:17.720
because you're not collecting all the data

00:07:17.760 --> 00:07:19.160
my normal DNS would collect.

00:07:19.420 --> 00:07:22.360
So how can someone see what their current DNS provider is

00:07:23.940 --> 00:07:25.220
and what are their options?

00:07:25.640 --> 00:07:26.740
Because I think there's you,

00:07:26.880 --> 00:07:28.600
but do you have other DNS providers

00:07:28.720 --> 00:07:30.220
that you think are also good to look into?

00:07:31.120 --> 00:07:32.880
So let's start with how do you see it.

00:07:33.000 --> 00:07:35.420
So typically in your TCP IP settings,

00:07:35.620 --> 00:07:36.700
whether you're on Mac or Windows,

00:07:37.060 --> 00:07:39.020
you have to kind of dig down into the settings.

00:07:39.600 --> 00:07:41.740
Normally your DHCP service,

00:07:41.980 --> 00:07:43.260
whether it's that your router at home

00:07:43.380 --> 00:07:45.840
or whether it's your ISP or your enterprise router,

00:07:46.360 --> 00:07:47.540
it's going to hand back to you

00:07:47.880 --> 00:07:49.140
the IP address you should be using

00:07:49.620 --> 00:07:50.540
for your temporary connection.

00:07:50.640 --> 00:07:52.180
And when you sit down, open up your laptop,

00:07:52.920 --> 00:07:54.500
you get an IP address, a default gateway,

00:07:54.940 --> 00:07:56.220
and then also a DNS server.

00:07:56.780 --> 00:07:58.880
And so those are typically automatically configured.

00:07:59.440 --> 00:08:01.100
You can, however, statically configure it.

00:08:01.300 --> 00:08:03.820
And the details of exactly how you do that,

00:08:04.060 --> 00:08:05.039
we can go to our website

00:08:05.060 --> 00:08:07.480
and we have configuration guides for Windows and Mac.

00:08:07.760 --> 00:08:09.040
And for mobile devices,

00:08:09.160 --> 00:08:10.740
it actually gets a little more complicated.

00:08:10.900 --> 00:08:12.280
Android, it's actually somewhat simpler.

00:08:12.500 --> 00:08:14.480
There's a feature in Android called Private DNS

00:08:15.100 --> 00:08:17.080
and you can put in our settings in there.

00:08:17.140 --> 00:08:19.240
In fact, some phones even come with Quad 9

00:08:19.500 --> 00:08:20.980
basically as in a pull-down list.

00:08:21.140 --> 00:08:23.240
And then iOS is the hardest one.

00:08:23.340 --> 00:08:25.300
Interestingly, you can't actually see

00:08:25.400 --> 00:08:29.540
what your DNS provider is in an iPhone or an iPad device.

00:08:29.780 --> 00:08:31.640
They really hide that quite effectively

00:08:31.640 --> 00:08:33.659
so that people don't stick their fingers in it,

00:08:33.659 --> 00:08:34.680
which I think is unfortunate.

00:08:34.700 --> 00:08:39.380
We have an MDM profile that you can load to override that.

00:08:39.680 --> 00:08:44.660
And interestingly, the best way to override it is to go into your router at home.

00:08:45.320 --> 00:08:52.680
And instead of using the default that your router hands out, go into your router and say, you know, hand out 9.9.9.9 as the DNS server.

00:08:53.300 --> 00:08:56.560
And it will then tell your iPhone to do the right thing.

00:08:57.100 --> 00:08:58.500
So iOS is a little tougher.

00:08:58.620 --> 00:09:03.800
And also Android, we have an app on the F-Droid store called Quad9 Connect, which you can download.

00:09:03.940 --> 00:09:08.100
Not only will it not change the default on your Android device,

00:09:08.300 --> 00:09:09.940
but it also gives you some stats, which is nice.

00:09:10.150 --> 00:09:11.540
You don't have to have that app, by the way.

00:09:11.620 --> 00:09:12.580
It'll work fine without it,

00:09:12.700 --> 00:09:14.440
but having some statistics sometimes is nice.

00:09:15.680 --> 00:09:15.740
Nice.

00:09:15.980 --> 00:09:17.080
And then on the iOS side of things,

00:09:17.190 --> 00:09:18.640
there are a few other DNS providers,

00:09:18.900 --> 00:09:21.880
and they go inside the VPN section,

00:09:22.170 --> 00:09:23.860
and they swap the DNS provider there.

00:09:24.140 --> 00:09:26.400
Is there a reason you guys go for this profile approach?

00:09:27.260 --> 00:09:28.480
Well, essentially, that's the same thing.

00:09:28.780 --> 00:09:30.280
That is the method we're using.

00:09:31.040 --> 00:09:33.020
So it's an XML blob that you download.

00:09:33.080 --> 00:09:35.240
So it's more or less exactly the same model.

00:09:35.400 --> 00:09:37.040
It's just that we distribute it as a text file.

00:09:37.220 --> 00:09:38.700
There's nothing particularly fancy about it.

00:09:38.880 --> 00:09:40.180
We're trying not to make other changes.

00:09:40.400 --> 00:09:42.860
Like when you download our system as a VPN profile,

00:09:43.540 --> 00:09:45.260
we're not trying to actually divert all your traffic.

00:09:45.360 --> 00:09:47.180
We're just grabbing the DNS traffic

00:09:47.800 --> 00:09:49.880
and sending that to our resolvers.

00:09:50.080 --> 00:09:53.660
So I'm sorry that iOS is not a particularly clean method,

00:09:53.820 --> 00:09:57.700
but Apple has not made that as easy as we would like.

00:09:58.800 --> 00:10:00.700
Yeah, it's interesting because, you know,

00:10:00.860 --> 00:10:02.040
Apple's done a lot of good stuff.

00:10:02.140 --> 00:10:03.660
in some areas.

00:10:03.940 --> 00:10:05.280
I think lockdown mode is very cool.

00:10:05.380 --> 00:10:07.560
I think advanced data protection in iCloud is very cool.

00:10:08.140 --> 00:10:10.980
But even with these really good features

00:10:11.180 --> 00:10:12.900
that can prevent government-grade spyware,

00:10:13.200 --> 00:10:16.020
Apple still hasn't documented and made it clear

00:10:16.300 --> 00:10:18.780
when traffic actually goes through a VPN or not,

00:10:18.840 --> 00:10:20.720
which for some threat models is pretty critical

00:10:20.840 --> 00:10:21.680
if you think about it.

00:10:22.280 --> 00:10:24.220
I like a lot of the stuff Apple's doing.

00:10:24.720 --> 00:10:28.120
I give them credit for doing a lot of things the right way.

00:10:28.460 --> 00:10:30.620
But it all still is within their sandbox.

00:10:31.460 --> 00:10:33.700
They don't want traffic leaving their control.

00:10:34.220 --> 00:10:37.140
There's an argument that they say, well, it's better and safer if Apple does all that.

00:10:37.460 --> 00:10:39.240
I don't quite agree.

00:10:39.340 --> 00:10:43.200
I think that people should have choice, more easily have choice as to where their data is

00:10:43.300 --> 00:10:44.780
going and who protects it.

00:10:45.020 --> 00:10:49.060
But that's a philosophical difference between Apple and my own views, I think.

00:10:49.940 --> 00:10:51.680
And other platforms' views, too.

00:10:51.840 --> 00:10:54.860
I think Apple is kind of the best at that right now.

00:10:55.100 --> 00:10:59.600
A couple things to clarify, and then a couple more technical things that I know some of the

00:10:59.680 --> 00:11:00.700
technical folks will appreciate.

00:11:01.400 --> 00:11:04.540
So first, one of the things I get asked a ton is,

00:11:05.160 --> 00:11:06.220
where do I set my DNS?

00:11:06.440 --> 00:11:08.800
Now I know you kind of mentioned the system DNS,

00:11:09.200 --> 00:11:11.760
but on the consumer end, they can change it in their browser.

00:11:11.920 --> 00:11:13.780
The browser lets you change your DNS provider.

00:11:13.900 --> 00:11:16.100
They can change it sometimes per program.

00:11:16.340 --> 00:11:18.780
Some programs let you set a DNS inside just that program.

00:11:18.940 --> 00:11:20.380
They can also set it on the operating system.

00:11:20.540 --> 00:11:23.020
You mentioned the router even, so it would go through your router.

00:11:23.620 --> 00:11:26.180
So it's confusing to a regular person.

00:11:26.300 --> 00:11:28.500
So where do you normally start this conversation

00:11:28.640 --> 00:11:29.580
to kind of ground people?

00:11:30.720 --> 00:11:44.060
This is one of the biggest problems with what we do is explaining how people can be protected by what we do, or both their privacy and their security, is because that configuration is still difficult and there are so many fractured places where it can be done.

00:11:44.470 --> 00:11:47.940
We, of course, are interested in having end users use the platform.

00:11:48.360 --> 00:11:53.460
We love having individual users figure it out, convert over, and start to use Quad9.

00:11:53.820 --> 00:11:56.760
But quite honestly, that isn't where most of our users come from.

00:11:57.010 --> 00:11:58.400
And the reason for that is complexity.

00:11:58.500 --> 00:12:12.660
Most of the users on the Quad9 platform from everything we've been able to determine are coming from organizations or even households where there's a very technical person at the very bottom of the organization chart who says, you know what?

00:12:13.120 --> 00:12:14.240
I like Quad9.

00:12:14.560 --> 00:12:15.700
I like what they stand for.

00:12:15.780 --> 00:12:18.820
I like the fact that I get added security and privacy for my end users.

00:12:19.380 --> 00:12:21.520
So I'm going to configure this on the router and everyone's going to get it.

00:12:21.760 --> 00:12:22.660
And they're not even going to notice.

00:12:22.780 --> 00:12:28.320
And that goes for sysadmins at small or medium sized companies and even some big companies, but not many.

00:12:28.520 --> 00:12:40.960
And then also for households, where if someone who's listening to this podcast, as an example, is going to log into their parents' router, and they're going to make sure that everything in the household is using 9.9.9.9 because it's handed out in the DHCP server.

00:12:41.280 --> 00:12:42.300
We're a very small shop, right?

00:12:42.560 --> 00:12:45.360
So the smaller you are, the harder it is to make things very simple.

00:12:45.540 --> 00:12:46.420
We don't do software.

00:12:46.480 --> 00:12:48.399
We're not a software shipping organization.

00:12:49.240 --> 00:12:49.960
We do services.

00:12:50.460 --> 00:12:57.340
So software is what makes things easy for people if you do it right, where they download a program and it does the thing and changes the service.

00:12:57.460 --> 00:12:59.360
And then the queries would use Quad9.

00:12:59.680 --> 00:13:00.580
We have that for Android.

00:13:00.740 --> 00:13:01.480
It works quite well.

00:13:01.700 --> 00:13:02.700
But we don't have that for Windows.

00:13:02.940 --> 00:13:03.840
We don't have that for Mac.

00:13:04.220 --> 00:13:07.700
We don't have that for, you know, iOS is sort of a half measure.

00:13:07.860 --> 00:13:11.540
And that's because of our size and the fact that we're a services company, we're not a

00:13:11.760 --> 00:13:12.220
software company.

00:13:12.540 --> 00:13:17.620
That said, again, most of our users are brought to us by somebody who's sophisticated, deciding

00:13:17.740 --> 00:13:22.560
that they want to give the benefits to a group of people who aren't necessarily as sophisticated.

00:13:23.220 --> 00:13:26.300
And those often are the people that need the protection, the cybersecurity protection,

00:13:26.340 --> 00:13:30.780
which I haven't even talked about. They need that the most. And then privacy is sort of the second

00:13:31.160 --> 00:13:36.800
most interesting thing that they have. So, you know, I'd say that under 10%, probably less of our

00:13:36.940 --> 00:13:41.080
end users actually go in and configure this themselves. You know, 90% of our users, I'm going

00:13:41.080 --> 00:13:45.940
to guess, are actually, they're using Quad9 and they don't even know it because someone is looking

00:13:46.140 --> 00:13:50.860
out for them. Got it. And then I have a couple of follow-up questions there, but I'll let you expand

00:13:50.980 --> 00:13:54.519
on the cybersecurity stuff because it sounded like you wanted to get to that. Sure. Privacy is a big

00:13:54.540 --> 00:13:58.540
reason for using Quad9. We don't collect user personal information. We don't collect IP addresses.

00:13:59.120 --> 00:14:05.320
We never even write IP addresses to any storage mechanism ever. However, a lot of people don't

00:14:05.330 --> 00:14:09.140
care as much about privacy. They care about sort of the opposite side of the coin, which is

00:14:09.460 --> 00:14:13.280
cybersecurity. They don't want to be defrauded. They don't want to have botnets installed on their

00:14:13.440 --> 00:14:18.060
laptops. They don't want to have phishing attacks. And they're trying to protect people, again,

00:14:18.280 --> 00:14:23.479
who might be more vulnerable to this. Quad9 has the other party trick we have is that we have a

00:14:23.500 --> 00:14:30.820
block list. On our primary service, 9999, we have a list, a rotating list of around roughly 4 million

00:14:31.460 --> 00:14:38.720
different malicious domains that we keep rotating. These are supplied to us by about 35 or more

00:14:38.920 --> 00:14:44.760
partners, mostly very relatively well-known cybersecurity companies who give us lists of

00:14:44.940 --> 00:14:50.680
domain names that they know are malicious. So that's command and control systems, it's stalkerware,

00:14:50.720 --> 00:14:55.540
it's phishing. If you try to look up one of those names on our system, we basically refuse the

00:14:55.660 --> 00:15:00.260
lookup. We hand back what's called an NX domain. And we actually tag that with an indicator that

00:15:00.380 --> 00:15:06.060
says, we gave you back a zero answer, a null answer, because this was a prohibited site.

00:15:06.210 --> 00:15:09.880
This is a user choice. You can choose to use this blocking service or not. We actually have

00:15:09.930 --> 00:15:17.259
different flavors. So 9999 has blocking enabled, 99910 does not. Most people choose the blocking

00:15:17.280 --> 00:15:22.380
enabled service, because why not? So a lot of people, especially in, you know, not to generalize,

00:15:22.380 --> 00:15:26.460
but in North America, as an example, and Western Europe, they're really interested in cybersecurity

00:15:26.840 --> 00:15:32.760
component because we're giving away for free a service that typically costs quite a bit if you

00:15:32.760 --> 00:15:37.200
were to try to build it yourself or to try to buy that service from somebody. We have what we think

00:15:37.320 --> 00:15:43.019
is one of the best combinations of malware and other blocking that you can get. Privacy to them

00:15:43.040 --> 00:15:47.720
is an extra. In other parts of the world, privacy is the primary reason and cybersecurity is an extra.

00:15:48.140 --> 00:15:52.860
So it depends on who I'm talking to as to what the biggest interest is. But again, a small home,

00:15:52.900 --> 00:15:57.740
right, where there's people who are not necessarily as technically capable, you get the benefit of if

00:15:58.040 --> 00:16:02.840
you put that in the router, you're giving everybody in the home some protection against malicious

00:16:03.200 --> 00:16:06.960
activity. It's not perfect, but you know what? It's free. So it's actually pretty good. The return

00:16:07.100 --> 00:16:12.099
on investment is extremely high. And it actually is quite effective at blocking some of the more

00:16:12.120 --> 00:16:18.620
common malware or phishing kind of activities. Do you guys have insight into like how much you

00:16:18.760 --> 00:16:23.860
block on a daily basis? Yeah. What do you prevent? We have volumetric and geographic information

00:16:24.180 --> 00:16:29.940
about where things are happening. And we've got a really cool map that shows that in real time on a

00:16:29.940 --> 00:16:35.160
big globe. We call it the globe of wonder. We do around 600 million blocks a day. Now, what do they

00:16:35.360 --> 00:16:39.479
mean? This is a problem that we've been struggling with for 10 years. What is the value of a particular

00:16:39.500 --> 00:16:46.480
block event. Like how much can you assign a dollar value or euro value to a prevention of someone

00:16:46.620 --> 00:16:50.480
going to a site? It's really hard, but I know there's value there, right? And it's probably

00:16:50.510 --> 00:16:54.540
in the hundreds of millions of dollars a year where we're preventing people from being, again,

00:16:54.800 --> 00:16:59.440
ransomware and phishing. We're preventing people from getting those sites, but you can't prove the

00:16:59.560 --> 00:17:05.520
negative. Prove to me the money you're saving by having antivirus software on your laptop. Well,

00:17:05.620 --> 00:17:06.100
that's hard to do.

00:17:06.640 --> 00:17:07.560
Ty, you know, you guys are a nonprofit.

00:17:07.890 --> 00:17:10.160
If you were like trying to get investors,

00:17:10.439 --> 00:17:11.540
you're like, yeah, billions.

00:17:11.959 --> 00:17:12.959
We've saved billions of dollars.

00:17:13.780 --> 00:17:15.280
We'd make up some really fantastic numbers.

00:17:15.800 --> 00:17:17.720
And the good news is we don't actually have to make it up

00:17:17.839 --> 00:17:18.760
because the numbers are there,

00:17:18.990 --> 00:17:22.199
but we don't, like Quad9 does not do threat analysis

00:17:22.680 --> 00:17:24.000
in the kind of in-depth way.

00:17:24.160 --> 00:17:25.260
We do a quarterly report.

00:17:25.380 --> 00:17:26.280
Our director of threat intelligence

00:17:26.470 --> 00:17:29.180
produces a great quarterly or triannual report

00:17:29.640 --> 00:17:31.700
where we look at, we kind of take a sample and say,

00:17:31.840 --> 00:17:34.000
what are the things we're protecting people against?

00:17:34.340 --> 00:17:38.340
But we have an agreement with our threat intelligence providers that we're not trying to compete with them.

00:17:38.580 --> 00:17:45.280
We're creating a parallel universe where people who couldn't ordinarily pay for this kind of protection get the protection.

00:17:45.940 --> 00:17:49.120
So we don't really dig into their data.

00:17:49.290 --> 00:17:50.960
We just take it as it is and we say, you know what?

00:17:51.110 --> 00:17:54.060
If you're giving us data, we probably believe that it's going to be very effective.

00:17:54.380 --> 00:17:58.660
We don't want to try to create a comparison where one threat provider is better than the other.

00:17:58.830 --> 00:18:02.180
Because if we started to assign values to things, we'd get in that mode.

00:18:02.620 --> 00:18:03.020
And we don't.

00:18:03.120 --> 00:18:04.540
We love all of our threat intelligence provider.

00:18:04.630 --> 00:18:07.380
They all give us great information and insight to protect our users.

00:18:07.640 --> 00:18:12.400
So we don't do the kind of analysis that you would see in a for-profit company where they're

00:18:12.540 --> 00:18:16.240
looking into each and every block and trying to figure out what the value is.

00:18:16.520 --> 00:18:19.720
Or even in some cases, we don't even know what the classification is.

00:18:19.870 --> 00:18:22.860
Although we can look at things and say, right, that's a phishing domain, clearly, because

00:18:22.980 --> 00:18:23.740
it looks like a bank.

00:18:24.590 --> 00:18:29.580
Or this is a command and control system because we can observe how it's being accessed or

00:18:29.900 --> 00:18:31.520
attempted to being accessed worldwide.

00:18:32.000 --> 00:18:36.100
So we can make some guesses, but we don't spend a lot of time doing that.

00:18:36.400 --> 00:18:37.540
There's no payoff for that.

00:18:37.700 --> 00:18:38.980
There's no one who cares.

00:18:39.640 --> 00:18:44.000
I mean, we care, but there's no one who's giving us money based on the outcomes of that.

00:18:44.220 --> 00:18:46.400
I'd love to take some of his funding who would.

00:18:46.780 --> 00:18:50.160
That'd be great, but we only have a limited amount of funds to do things, and we're really

00:18:50.420 --> 00:18:52.100
focused on protection rather than on analysis.

00:18:53.280 --> 00:18:54.600
Yeah, I think it's a fair trade-off.

00:18:55.440 --> 00:18:56.540
Just one quick question.

00:18:56.690 --> 00:18:58.740
You mentioned setting up DNS on a router.

00:18:59.440 --> 00:19:03.040
I know a very common issue nowadays is people have routers that don't let them change their DNS.

00:19:03.220 --> 00:19:05.480
Do you have any quick alternatives for those people?

00:19:05.600 --> 00:19:06.980
Or you just have to do it per device?

00:19:07.600 --> 00:19:08.260
Get a different router.

00:19:09.480 --> 00:19:09.940
That's true.

00:19:10.700 --> 00:19:12.340
That's not an unreasonable thing to say.

00:19:13.020 --> 00:19:19.360
If you have devices that do not let you configure basic things like setting your DNS server, you are the product.

00:19:20.200 --> 00:19:21.160
That's your first key.

00:19:21.340 --> 00:19:23.100
You are being treated as cattle.

00:19:23.600 --> 00:19:24.160
Stop it.

00:19:24.740 --> 00:19:27.460
Replace that device with something else that lets you have control.

00:19:28.040 --> 00:19:31.460
Because the person who's running that device is treating you as a product.

00:19:31.880 --> 00:19:35.940
And this is common, again, in large telcos where they harvest all of your data.

00:19:36.180 --> 00:19:45.700
They want to get all that DNS data going to their service because they're building a profile on not necessarily maybe you as an individual, but they're certainly building it on your household.

00:19:46.340 --> 00:19:51.780
And they're selling that data, and you're seeing customized ads, and you're seeing other things starting to be built on top of that.

00:19:52.040 --> 00:19:55.740
Don't let yourself get locked into equipment that doesn't let you change it.

00:19:56.840 --> 00:19:57.640
Yeah, good advice.

00:19:57.920 --> 00:20:10.740
Before I dive into four more technical questions that I think summarize all the technical questions that most people listening will have before we zoom out on more of the broader fights you guys are fighting and then also a little bit more about you all as a business.

00:20:11.400 --> 00:20:13.960
What's just some common misconceptions that you'd like to clear up?

00:20:13.960 --> 00:20:19.360
I'm sure that you guys have to deal with a lot of education because this is not something that most people think about by default.

00:20:19.680 --> 00:20:24.560
So is there something that you would just point to as an easy thing to clear up that you want people to know?

00:20:24.780 --> 00:20:26.500
The biggest one is that DNS actually matters.

00:20:27.280 --> 00:20:32.600
It's one of the most fundamental things on the internet, and most people have no idea that it exists or how it works.

00:20:32.900 --> 00:20:36.820
And so explaining how it works, I've sort of done a little bit of that here, but not enough probably.

00:20:37.480 --> 00:20:44.340
Understanding where things are and that they exist is an incredibly important component of any knowledge transfer.

00:20:44.600 --> 00:20:48.780
Just like a card catalog in a library, without it, the library is kind of useless.

00:20:49.120 --> 00:20:50.000
Same thing with the DNS.

00:20:50.480 --> 00:20:57.120
If the naming system doesn't work or it's imperiled, then the knowledge itself is at risk.

00:20:57.580 --> 00:21:22.500
And that's really, really important. And we'll talk about this more in the policy side of the conversation. But the impression is that DNS is just a wonky technical thing. Well, it is, but it's also core to keeping the promise of the internet running and the actual data transfer, whether that's economic benefits, human rights benefits, individual productivity benefits. Those are all contingent on an operating DNS.

00:21:22.660 --> 00:21:31.220
That's not necessarily the question you're looking to answer or have me answer, but that's one that I struggle with the most, like how important it is that this works.

00:21:31.590 --> 00:21:35.740
Because most people just think that it'll always keep working and there's nothing that really can stop it.

00:21:36.220 --> 00:21:38.460
Your library analogy is, I think, kind of perfect.

00:21:38.840 --> 00:21:50.700
Especially, you know, let's not get into it now, but the fact that you can block malicious things opens up the opportunity for blocking other things that other people of different interests have.

00:21:50.940 --> 00:21:53.560
HTTPS versus TLS versus now Quick.

00:21:54.920 --> 00:21:55.120
Yes.

00:21:55.900 --> 00:21:57.880
We don't need to go like crazy deep into this,

00:21:58.080 --> 00:22:00.740
but if you could just kind of summarize the main options,

00:22:01.400 --> 00:22:02.680
the differences between them

00:22:03.020 --> 00:22:05.840
and what you kind of are pushing people towards now in 2026.

00:22:06.640 --> 00:22:12.080
DNS until roughly 2017 was an unencrypted protocol using UDP.

00:22:12.640 --> 00:22:13.380
No encryption whatsoever.

00:22:13.590 --> 00:22:14.940
It's super easy to read on the wire.

00:22:15.030 --> 00:22:19.420
In 2017, we were the first standards-based encrypted resolver,

00:22:19.600 --> 00:22:24.120
meaning that you could actually encrypt the connections now between your client and our system

00:22:24.320 --> 00:22:26.020
so that no one could observe them in the path.

00:22:26.540 --> 00:22:28.580
That was with DOT, DNS over TLS.

00:22:28.950 --> 00:22:31.760
That was the first standards-based protocol that we adopted.

00:22:32.060 --> 00:22:36.200
Then quick on its heels came DOH, DNS over HTTPS.

00:22:36.680 --> 00:22:38.200
And this was something that browsers understood.

00:22:38.670 --> 00:22:43.540
So instead of using your operating system, the browser started to actually do DNS lookups.

00:22:43.940 --> 00:22:46.400
And there's still some contention of whether that's a good idea or not.

00:22:46.880 --> 00:22:52.780
But DNS over HTTPS was TCP-based and looked like a standard HTTPS connection.

00:22:53.200 --> 00:22:53.880
Fast forward a little bit.

00:22:54.100 --> 00:22:58.780
Now, in the last few years, we've seen a growing adoption of QUIC protocols, QUIC.

00:22:59.500 --> 00:23:00.600
And these are over UDP.

00:23:01.260 --> 00:23:05.220
And they have some significant advantages as far as speed, like starting up a connection

00:23:05.270 --> 00:23:09.020
is faster, sometimes multiplexing things over the same connection is faster.

00:23:09.700 --> 00:23:11.900
And so we've seen an emergence.

00:23:12.040 --> 00:23:20.420
DOT used to operate, or still operates, sorry, on TCP port 853. DOH operates on TCP 443. So the

00:23:20.420 --> 00:23:25.240
same port as regular HTTPS. But now we're seeing the conversion of both of those protocols to use

00:23:25.360 --> 00:23:32.240
a QUIC underpinning, which is UDP based. And so now we see DOT becoming DOQ, DNS over QUIC.

00:23:32.860 --> 00:23:39.260
That operates over UDP on port 853. So same port as DOT. So DOT and DOQ are very, very similar.

00:23:39.340 --> 00:23:42.080
They use the same port except one's TCP and one's UDP.

00:23:43.020 --> 00:23:47.340
And then DOH and DOH3, technically DOH2 and DOH3.

00:23:47.500 --> 00:23:53.180
DOH2 is TCP on 443 and then DOH3 is UDP over quick over 443.

00:23:53.500 --> 00:23:59.960
So those are now sort of the emerging standards for how end clients communicate with recursive resolvers.

00:24:00.280 --> 00:24:05.200
Although that said, we're barely in some places breaking 20% of our traffic being encrypted.

00:24:05.270 --> 00:24:09.040
And that's in the most aggressive areas where people are really pro encryption.

00:24:09.320 --> 00:24:13.740
So we're not seeing a landslide of people moving to encryption.

00:24:14.090 --> 00:24:15.740
We should be, but we're not.

00:24:16.100 --> 00:24:17.880
And we've really got to work on that.

00:24:18.220 --> 00:24:19.520
Again, this is actually an area that's interesting.

00:24:19.820 --> 00:24:21.680
Apple actually really does a good job at this.

00:24:22.340 --> 00:24:30.120
If you give an Apple device a recursive resolver answer like 9999, the Apple devices will actually

00:24:30.480 --> 00:24:33.320
automatically upgrade to encryption without having to do anything.

00:24:33.490 --> 00:24:37.360
And in fact, they'll not just upgrade to encryption, they'll upgrade to DOQ encryption.

00:24:37.640 --> 00:24:39.420
So performance is really great.

00:24:40.040 --> 00:24:42.120
We're trying to see what we can do to encourage

00:24:42.540 --> 00:24:46.060
and provide some examples to other operating system vendors

00:24:46.480 --> 00:24:47.820
and then also browser operators

00:24:47.980 --> 00:24:50.280
so that they will automatically shift over.

00:24:50.800 --> 00:24:54.440
Because what happens is people put in 9999 into their DHCP server

00:24:54.580 --> 00:24:55.840
and then they never think about it again.

00:24:56.540 --> 00:25:00.800
Going back and trying to type in an encrypted URL into your browser,

00:25:01.580 --> 00:25:03.280
honestly, most people aren't going to do that.

00:25:03.800 --> 00:25:12.180
So what we really need to do is push for automatic upgrade using what's called DDR, the stepping stone where your device says, well, can you support encryption?

00:25:12.380 --> 00:25:13.340
Oh, I can support encryption.

00:25:13.920 --> 00:25:14.840
Let's convert to encryption.

00:25:15.360 --> 00:25:19.400
Everybody should be doing encrypted recursive resolution if they can.

00:25:20.110 --> 00:25:26.840
Again, for their own privacy, but also for things like integrity so that no one can modify or block your connections in the path.

00:25:27.000 --> 00:25:30.860
There's just a whole bunch of other reasons why it's a good idea, but we're not there yet, but we're getting there.

00:25:31.060 --> 00:25:36.660
Quad9 supports all encrypted protocols, including some non-standards-based ones as well.

00:25:37.420 --> 00:25:40.240
Yeah, I remember I had Carl on from Obscura on this podcast,

00:25:40.540 --> 00:25:45.820
and he did a lot of chatting about Quick, especially because Obscura uses Quick.

00:25:46.980 --> 00:25:49.960
And it was actually inspired by Apple using it for private relay

00:25:50.440 --> 00:25:54.520
as kind of like a really novel thing that no one had really done before with a VPN, I don't think.

00:25:54.720 --> 00:25:56.440
Well, it's a relay. It's confusing.

00:25:56.680 --> 00:25:59.920
But just for someone listening, you gave out a lot of technical information.

00:26:00.160 --> 00:26:02.120
Do you want to just give like bullet list,

00:26:02.390 --> 00:26:04.860
max two things, pros and cons of each of these protocols

00:26:05.080 --> 00:26:06.900
so people can kind of understand them

00:26:06.990 --> 00:26:07.820
and what it means for them?

00:26:08.440 --> 00:26:11.380
And also, what's your kind of your go-to recommendation

00:26:11.380 --> 00:26:12.900
if somebody has to pick,

00:26:12.950 --> 00:26:14.420
like they have something really customizable

00:26:14.470 --> 00:26:15.640
that lets them use any of these?

00:26:16.640 --> 00:26:17.680
Let's start backwards then.

00:26:17.820 --> 00:26:18.920
I'd say if you have to pick,

00:26:20.360 --> 00:26:22.800
I would go DOQ first, DNS over quick.

00:26:23.120 --> 00:26:25.520
Then I would fall back to DNS over HTTP3,

00:26:25.610 --> 00:26:26.680
which is also quick-based.

00:26:26.850 --> 00:26:28.379
And the reason I'm saying those in that order

00:26:28.420 --> 00:26:30.280
is because DOQ is probably slightly faster.

00:26:30.280 --> 00:26:31.640
It doesn't have the overhead of HTTP,

00:26:32.600 --> 00:26:34.580
which is a few more bytes in that packet.

00:26:35.160 --> 00:26:38.140
Then HTTP3 is over UDP, so that's faster.

00:26:38.720 --> 00:26:40.240
Again, it has those restart capabilities.

00:26:40.540 --> 00:26:43.340
Then I would move down to DOT, DNS over TLS,

00:26:44.180 --> 00:26:45.140
because again, it's lighter weight.

00:26:45.540 --> 00:26:48.400
And then finally at the bottom of the list, DOH, DOH2,

00:26:48.820 --> 00:26:51.880
meaning the old TCP-based DNS over HTTPS

00:26:51.930 --> 00:26:53.460
would be my last choice.

00:26:53.830 --> 00:26:56.020
And again, these are all for speed and complexity.

00:26:56.680 --> 00:26:58.360
I'll also say that I'm somewhat selfish

00:26:58.680 --> 00:27:03.900
Those are also, from our perspective, those are the ones that have the least amount of CPU load on our side.

00:27:04.460 --> 00:27:09.240
And that's a question that we have to be aware of when you're looking at 120 million plus users on the system.

00:27:10.400 --> 00:27:15.060
You've got a design for large numbers of these encrypted sockets coming in.

00:27:16.580 --> 00:27:19.920
Yeah, another thing I've heard, it's something that Carl talked about and I've seen online.

00:27:20.660 --> 00:27:26.460
People say that because DOH or DNS over HTTPS goes over the same port, it's a little bit harder to block.

00:27:26.700 --> 00:27:30.480
So can you speak to the censorship circumvention of these technologies and if it matters?

00:27:30.880 --> 00:27:33.180
Now we're getting to layer eight politics.

00:27:33.580 --> 00:27:41.200
We took a fairly public stance in saying that DOH was not a great architectural design because it uses the same port as HTTPS.

00:27:41.420 --> 00:27:49.520
It does make it harder to block because you can't simply say block all port 443 outbound because that's not going to work because all of your HTTPS connections will fail.

00:27:49.660 --> 00:27:56.140
On the good side, we do, of course, we're not fans of people censoring the DNS, but there are some environments where it is actually a legitimate thing to do.

00:27:56.900 --> 00:28:07.560
You know, if you're in a business and you want to prevent your infected workstations from exfiltrating data, then, yeah, you should have some ability to prevent them from doing DNS lookups and also doing outbound connections.

00:28:07.820 --> 00:28:15.220
It makes security people's job a lot harder to have both the DNS and the content transmitted over the same port.

00:28:15.440 --> 00:28:20.060
So yes, it is harder to filter. And our bigger concern was not necessarily even the enterprise

00:28:20.520 --> 00:28:24.820
world, but it's the fact that if you make the people with guns very angry, they will shut off

00:28:24.920 --> 00:28:29.200
the internet. And they have done that, right? There are many places now in the world where

00:28:29.330 --> 00:28:33.800
internet interruptions or fragmentation is happening with a much more rapid pace because

00:28:34.420 --> 00:28:38.040
the governments of those places have determined that they can't actually filter content.

00:28:38.880 --> 00:28:43.280
And that's a really tough one to say what the results should be, because of course,

00:28:43.340 --> 00:28:47.740
you want to have people get information, access to information that they wish. At the same time,

00:28:47.800 --> 00:28:51.800
if you're accelerating the destruction of the internet by making it impossible to manage,

00:28:52.200 --> 00:28:57.020
that's also a negative. So essentially by embedding both of these things in the same port,

00:28:57.300 --> 00:29:02.460
you've created an inextricable linkage between the content and the metadata that makes it both

00:29:02.680 --> 00:29:07.700
difficult to censor and it makes it difficult to censor. And so we have a slight preference

00:29:08.160 --> 00:29:13.300
for DOT and DOQ because they operate on a different port. So you can stop the metadata

00:29:13.320 --> 00:29:35.860
It's still encrypted. No one can see what you're doing, but they can basically stop you from getting to the DNS, which I don't like. But I also have to recognize, we as an organization have to recognize that there is the right for a nation to impose their own laws and regulations inside their borders. We might not like it. We might not like it, but that's not our choice. That's an internal problem that that country has to deal with.

00:29:35.960 --> 00:29:44.740
And by pitting the citizens of those countries against their government by essentially conflating these two things together, I'm not sure we do them a service.

00:29:45.260 --> 00:29:46.780
But it doesn't matter what we think, right?

00:29:46.940 --> 00:29:50.320
The DOH is sort of the standard that everyone is moving to, DOH3 as well.

00:29:51.000 --> 00:29:52.460
So that ship has sailed.

00:29:52.790 --> 00:29:55.640
And we'll see the repercussions of that in the coming years.

00:29:55.970 --> 00:29:57.480
And we already are seeing it in some places.

00:29:58.920 --> 00:29:59.200
Got it.

00:29:59.860 --> 00:30:00.940
Another technical thing.

00:30:01.020 --> 00:30:07.100
You know, this to me has been presented as like, here's why DNS doesn't matter and you should never change it anyway.

00:30:07.280 --> 00:30:09.860
And it's this whole concept of SNI and ECH.

00:30:10.360 --> 00:30:10.800
Oh, yeah.

00:30:11.540 --> 00:30:14.020
We don't need to spend a huge amount of time on this.

00:30:14.100 --> 00:30:20.840
But if you can just as quickly as you can kind of break down what's going on and if that's actually something people should be thinking about.

00:30:21.440 --> 00:30:26.960
Well, the pro-censorship crowd has said, well, it doesn't matter what you do for DNS because we're going to be looking at SNI.

00:30:27.220 --> 00:30:44.180
And so SNI, just a quick recap, is that every time you make a connection to an encrypted site, a site that has HTTPS encryption, even though they can't observe what you're downloading, they can observe the very first message that goes out, which includes the host name of the server to which you're connecting.

00:30:44.290 --> 00:30:50.240
So even though they might not be able to see the DNS, they can still block you based on where they see you're trying to connect.

00:30:50.900 --> 00:30:52.740
Well, ECH is turning that around as well.

00:30:53.640 --> 00:30:55.320
And ECH is encrypted client hello.

00:30:56.100 --> 00:31:00.100
And what that does is it encrypts the actual connection to the website.

00:31:00.210 --> 00:31:02.020
So now everything is encrypted.

00:31:02.090 --> 00:31:05.080
The DNS connection is encrypted because you're using DNS encryption.

00:31:05.330 --> 00:31:08.760
The connection to the server itself is now encrypted because you're using ECH.

00:31:09.420 --> 00:31:12.560
And now the content is encrypted because you're using HTTPS on top of that.

00:31:12.590 --> 00:31:16.900
So there is no part of the transaction that is visible to an observer.

00:31:17.540 --> 00:31:20.420
And there are some people who are getting pretty upset about that.

00:31:20.660 --> 00:31:22.120
Yeah, I've actually seen the inverse.

00:31:22.400 --> 00:31:24.280
there's been some videos that are like,

00:31:25.680 --> 00:31:28.040
because of this situation,

00:31:29.080 --> 00:31:31.540
then all your queries are getting exposed anyway,

00:31:31.930 --> 00:31:34.400
so changing your DNS doesn't do anything,

00:31:34.550 --> 00:31:36.780
which is kind of a take I've been seeing a lot so far this year.

00:31:37.520 --> 00:31:39.620
Tell me, I'm not clear on that argument.

00:31:39.800 --> 00:31:41.040
Explain that one in a little bit more detail.

00:31:42.570 --> 00:31:44.560
I think the overall argument is,

00:31:44.690 --> 00:31:47.580
even if you change your DNS provider to something like Quad9,

00:31:47.850 --> 00:31:50.220
it doesn't really matter because you can't guarantee

00:31:50.220 --> 00:31:54.540
that your SNI is actually using ECH.

00:31:54.760 --> 00:31:56.580
Therefore, your queries are getting exposed anyway,

00:31:56.740 --> 00:31:57.940
so it's useless. Don't bother.

00:31:58.200 --> 00:31:59.120
That sounds like somebody

00:32:01.640 --> 00:32:03.300
who's got an ulterior agenda.

00:32:03.480 --> 00:32:06.380
But anyway, saying that you shouldn't encrypt anything

00:32:06.520 --> 00:32:07.960
because at least one thing is unencrypted,

00:32:08.100 --> 00:32:09.320
that seems pretty bogus.

00:32:09.600 --> 00:32:11.340
I see it. It's people online,

00:32:11.720 --> 00:32:13.780
so everyone will take things to extremes.

00:32:14.000 --> 00:32:16.660
I don't know how many people actually have that kind of view on it,

00:32:16.860 --> 00:32:19.560
but the internet can be a bit polarizing.

00:32:19.580 --> 00:32:39.900
I can. So no, I would definitely say that anything you can encrypt, you should. Everything that you can prevent someone else from seeing or blocking should be done. There are second level questions with that, like as an example, DOT and DOQ versus DOH. But no, everything you should do with encrypted. I'm very much hoping that ECH actually continues to gain adoption. I'm hopeful there. We'll see how it goes.

00:32:39.940 --> 00:32:42.880
We don't actually implement ECH, interestingly enough, not yet.

00:32:43.260 --> 00:32:45.800
The reason for that is that it's obvious what you're doing when you're connecting.

00:32:46.820 --> 00:32:49.160
There's two signals you can look at when you're looking at a packet.

00:32:49.440 --> 00:32:51.200
You can look at the IP address of the destination,

00:32:51.600 --> 00:32:54.720
and then you can look at the SNI to kind of figure out what's going on.

00:32:54.840 --> 00:32:58.480
Even if we hit the SNI, you're connecting to 9.9.9.9.

00:32:59.280 --> 00:33:02.400
Okay, there's only one thing that that IP address does, and that's DNS.

00:33:02.660 --> 00:33:04.840
So SNI for us is not as meaningful.

00:33:05.020 --> 00:33:06.580
We will probably implement it eventually,

00:33:06.780 --> 00:33:14.280
But it's not as meaningful because the people who are trying to block those connections or observe them, they know exactly what you're doing when you're connecting to our well-known IP addresses.

00:33:14.700 --> 00:33:16.100
That's a bug and a feature at the same time.

00:33:17.440 --> 00:33:17.660
Got it.

00:33:18.220 --> 00:33:27.300
Yeah, and I mean, in terms of adoption, what I've read, and maybe you can confirm this, is that it's actually helped a lot that some CDNs have adopted it.

00:33:27.420 --> 00:33:32.120
So any site that uses Cloudflare automatically is accepting SNI encrypted.

00:33:32.540 --> 00:33:33.140
Is that true?

00:33:33.760 --> 00:33:34.520
I believe that's true.

00:33:34.620 --> 00:33:37.740
I can't speak for Cloudflare, but I think that that's what's going on there.

00:33:38.260 --> 00:33:40.860
They've been very strongly in favor of ECH.

00:33:41.650 --> 00:33:41.900
Got it.

00:33:42.310 --> 00:33:42.500
All right.

00:33:42.850 --> 00:33:46.560
Now, I think we kind of have covered a lot of the basics, some of the technical things

00:33:46.660 --> 00:33:48.860
that I know our audience is also going to want to hear as well.

00:33:49.900 --> 00:33:51.380
Let's hear about what you guys have been up to.

00:33:51.390 --> 00:33:53.480
I know we've kind of teased some things going on around the world.

00:33:53.630 --> 00:33:56.300
So I'll let you kind of open this up with whatever's going on.

00:33:56.760 --> 00:34:00.360
So in 2021, we actually moved to Switzerland in 2021.

00:34:00.450 --> 00:34:01.820
We were previously a U.S. organization.

00:34:01.850 --> 00:34:03.160
We moved to Switzerland in 2021.

00:34:03.400 --> 00:34:16.540
Within weeks of our movement to Switzerland, we got pinged by Sony Entertainment Germany, who came after us because we were resolving names for hosts which they claimed housed pirated songs.

00:34:16.980 --> 00:34:20.700
And so basically they were trying to force us to block those names.

00:34:21.100 --> 00:34:29.080
They claimed just for Germany, but really they were effectively trying to block those names worldwide by going after us in German courts.

00:34:29.360 --> 00:34:33.840
Long story short, but it's possible for someone in Europe to lodge civil cases against us in

00:34:33.980 --> 00:34:39.740
Switzerland because of treaties with those nations. So it took two years and three appeals,

00:34:40.560 --> 00:34:43.820
and we did actually win that case. It took a lot of money and a lot of our focus,

00:34:44.240 --> 00:34:47.780
which we were very unhappy about because it really stopped a lot of things that we would

00:34:47.780 --> 00:34:51.260
have liked to have been doing with that funding in that time. But we did win that case in Germany.

00:34:51.639 --> 00:34:56.399
Basically, the courts eventually ruled that, no, this is an absurd thing, that blocking the DNS is

00:34:56.419 --> 00:35:02.560
not going to actually stop the pirated site to begin with, because the DNS is an open book,

00:35:02.800 --> 00:35:06.500
right? It's an open, you know, anybody can set up their own DNS server if they wish. They don't

00:35:06.500 --> 00:35:09.640
need to use Quad9. Yeah, the precedent that that would set would be really bad.

00:35:10.540 --> 00:35:16.020
And so the German courts ruled in our favor. So that's great. However, the same copyright cartel

00:35:16.660 --> 00:35:20.839
of, you know, mostly the same people, but some new ones, they circled the wagons and they're now

00:35:20.860 --> 00:35:26.040
going after us in France. So a number of organizations in France have lodged cases against

00:35:26.300 --> 00:35:33.180
us where they're demanding that we block a variety, hundreds actually, of sites that they claim are

00:35:33.340 --> 00:35:39.380
infringing on their copyrights. And we're sympathetic to the concept that copyright infringement is not

00:35:39.540 --> 00:35:43.300
something that we encourage. It's absolutely not. We are in the business of making the internet a

00:35:43.300 --> 00:35:48.600
more lawful place for individuals to prevent them from being defrauded or having crimes occur,

00:35:49.080 --> 00:35:54.060
protecting both the network and the individuals. However, we also are in the mode of giving people

00:35:54.220 --> 00:35:58.960
choice of what they do with their recursive resolution. Our goals are aligned with the end

00:35:59.080 --> 00:36:04.940
user. And these organizations in France want to create basically a pipeline into our platform and

00:36:05.140 --> 00:36:09.820
others. So it's not just us that's on this docket. It's a number of other DNS providers. They want

00:36:09.820 --> 00:36:12.680
to create a pipeline that basically they can say, all right, we're going to block any site

00:36:13.100 --> 00:36:16.420
that we feel like. We're going to tell you about it. And within a few minutes, you need to turn it

00:36:16.440 --> 00:36:20.500
off from a recursive resolving perspective. This is really weird because it doesn't actually

00:36:20.690 --> 00:36:24.640
prevent the site from existing. Anybody can set up a recursive resolver on their own. There's

00:36:24.870 --> 00:36:29.140
free software. There are dozens of packages that you can download and run and let you run your own

00:36:29.180 --> 00:36:33.640
recursive resolver. You don't need Quad9. It's just we're convenient and we're easy, but you don't

00:36:33.760 --> 00:36:39.700
need us. So why are they going after us? Our typical thinking on this is because we're small,

00:36:39.850 --> 00:36:44.200
we're a nonprofit, it's easy to go after us. The other companies they're going after are big US

00:36:44.220 --> 00:36:49.480
tech companies, which in a lot of Europe are persona non grata. You know, there's definitely

00:36:49.670 --> 00:36:55.140
a negative feeling towards large tech companies, which might be exfiltrating data about end users

00:36:55.290 --> 00:36:58.760
to the United States. So we're getting lumped in with them because we're not big enough to really

00:36:59.300 --> 00:37:03.020
hit them back as hard as we could, even though from a moral perspective, we're doing the right

00:37:03.200 --> 00:37:07.820
thing. We're protecting the users of France, as an example, millions of them a day. Our goals are

00:37:08.000 --> 00:37:14.180
aligned in some ways, trying to make a more lawful and safe internet, a more private internet. And

00:37:14.200 --> 00:37:17.420
this doesn't make any sense. This is not going after the problem. This is going after

00:37:18.000 --> 00:37:22.640
kind of a shadow. You're fighting the shadow on the wall of the actual events, which are that,

00:37:22.810 --> 00:37:27.240
you know, there might be these copyright infringing sites, but don't, you can't get to them through us.

00:37:27.610 --> 00:37:30.800
We have no relationship with them. We have no zero. We don't even know who they are.

00:37:31.000 --> 00:37:35.060
Is a fair comparison, like if they were to go after browser vendors for letting you access these sites?

00:37:35.500 --> 00:37:41.240
Yes. And, but, you know, careful there. That is actually exactly where I expect them to go next.

00:37:42.480 --> 00:37:44.220
Yeah, I don't want to give them any good ideas.

00:37:45.120 --> 00:37:45.200
Yeah.

00:37:45.460 --> 00:37:47.240
Safe browsing does the same thing, right?

00:37:47.380 --> 00:37:48.600
There's a block list in safe browsing.

00:37:48.820 --> 00:37:52.800
Your Chromium and Firefox and a bunch of others have safe browsing built in.

00:37:52.860 --> 00:37:54.660
And why would that be excluded?

00:37:54.920 --> 00:37:55.500
It's going to be.

00:37:55.700 --> 00:38:00.300
That's the fear here is that you're letting commercial entities decide what sites can

00:38:00.320 --> 00:38:02.280
be seen and what sites cannot be seen.

00:38:03.160 --> 00:38:04.340
That's a really bad precedent.

00:38:04.680 --> 00:38:06.160
And so we're fighting these cases in France.

00:38:06.340 --> 00:38:10.080
But again, we're not well positioned to do that except from a moral perspective.

00:38:10.100 --> 00:38:15.300
But we certainly don't have the deep pockets that can be reached into for funding this.

00:38:15.540 --> 00:38:16.400
We're looking for allies.

00:38:16.500 --> 00:38:17.340
We're looking for sponsors.

00:38:18.140 --> 00:38:22.040
You know, go to quad9.net and donate a few bucks to us if you'd like, because that's all

00:38:22.140 --> 00:38:27.840
going towards helping us stay operational and do some basic defense in some of these

00:38:28.040 --> 00:38:28.180
nations.

00:38:28.360 --> 00:38:32.940
And we don't expect these problems to go away until there's a definitive ruling in Europe,

00:38:33.160 --> 00:38:39.260
at least, that says the DNS is not an effective or useful place to do content filtering against

00:38:39.280 --> 00:38:40.220
the wishes of the end user.

00:38:40.480 --> 00:38:43.160
That was going to be my next question, so you beat me to it.

00:38:43.240 --> 00:38:47.460
It's like, what's the upstream thing that you could tackle to make it so someone can't sue

00:38:47.580 --> 00:38:48.660
over this kind of situation?

00:38:48.880 --> 00:38:50.360
But you just kind of covered that there.

00:38:50.420 --> 00:38:52.140
Has there been any progress on that?

00:38:52.960 --> 00:38:57.060
Well, there was actually an interesting case earlier this, or I guess late last week that

00:38:57.080 --> 00:39:00.320
I saw that I've not really digested entirely, which was interesting.

00:39:00.480 --> 00:39:07.540
There's a VPN provider who was being sued because they were not blocking access to the

00:39:07.860 --> 00:39:08.640
diary of Anne Frank.

00:39:09.560 --> 00:39:11.400
Oh yes, I read this one. Yeah.

00:39:11.700 --> 00:39:15.860
This is actually an interesting case and I really need to look at it more and talk to our legal team about it

00:39:16.040 --> 00:39:21.100
because it does touch on some of the same aspects as DNS does, even though it doesn't sound like it.

00:39:21.280 --> 00:39:26.640
So I have some hope that we will be able to get this decided at a higher level.

00:39:26.910 --> 00:39:30.740
The DSA in Europe, which is kind of the overarching legislation,

00:39:31.060 --> 00:39:37.280
my reading of it does actually explicitly say that DNS service providers are exempt from this.

00:39:37.600 --> 00:39:40.120
However, you have to get to the European courts.

00:39:40.400 --> 00:39:41.400
Right now we're in the courts in France.

00:39:41.680 --> 00:39:42.780
We were in the courts in Germany.

00:39:43.060 --> 00:39:45.700
And it may have been the case that we actually won that case.

00:39:46.000 --> 00:39:47.080
And that was a strategic failure.

00:39:47.660 --> 00:39:50.840
Like if we had been able to actually argue out of Germany and go up to the European courts,

00:39:51.000 --> 00:39:55.500
maybe we could have had a result that would have been effective across all of the EU.

00:39:55.900 --> 00:39:56.240
But we didn't.

00:39:56.280 --> 00:39:57.440
We won the case in Germany.

00:39:57.540 --> 00:39:59.240
I'm not saying I'm not, I'll take the win, right?

00:39:59.400 --> 00:40:02.880
But like being able to get this up to the courts in the EU might be a useful thing.

00:40:03.160 --> 00:40:03.700
I don't know.

00:40:03.940 --> 00:40:05.980
We'll also take a win in France if we can get it.

00:40:06.160 --> 00:40:17.900
But if there isn't a win in France at the national level, then I think there's enough merit in this case to take it up to the EU and get a ruling so that we don't have to fight this fight in various nations that want to apply this kind of filtering.

00:40:18.250 --> 00:40:27.260
Because we have a specific weakness because we are in what's called the Lugano Convention Nation, which is that treaty that governs these kind of civil lawsuits.

00:40:27.630 --> 00:40:29.580
We really do need to have this happen at the EU level.

00:40:30.360 --> 00:40:38.380
And I'm not sure that we will ever be able to impress upon legislatures or courts that this is a bad idea.

00:40:38.630 --> 00:40:40.500
It needs to have some legal teeth in it somehow.

00:40:40.880 --> 00:40:43.880
Like just the court of public opinion is not enough here.

00:40:44.960 --> 00:40:45.120
Right.

00:40:45.620 --> 00:40:58.580
If someone's listening to this and they're going, okay, so why is blocking malicious traffic acceptable but not blocking this other kind of traffic, which I guess some would argue is malicious in a different way.

00:40:58.760 --> 00:41:02.300
But what's actually the nuance here and why some things are blocked and not others?

00:41:02.920 --> 00:41:04.900
The nuance is that Quad9 provides choice.

00:41:05.280 --> 00:41:09.880
We provide malware blocking as an optional setting.

00:41:10.760 --> 00:41:13.900
You can decide that you want malware blocking or not.

00:41:14.500 --> 00:41:22.180
We provide 99910, which has no blocking of any kind for users who want to experience the whole internet, malware and all.

00:41:22.420 --> 00:41:26.080
When you're working in opposition to the end user, that's the problem.

00:41:26.740 --> 00:41:31.300
When you are doing something that the end user does not want, what they're going to do is

00:41:31.400 --> 00:41:34.400
they're going to simply say, you know what, quad nine doesn't do the thing I want.

00:41:34.500 --> 00:41:35.780
I'm going to change to my own resolver.

00:41:36.200 --> 00:41:41.060
Whatever minor effect you thought you were going to have by applying a block to quad nine,

00:41:41.780 --> 00:41:45.960
that is going to be instantly lost as soon as it happens because the user can choose

00:41:46.180 --> 00:41:47.360
other ways to do it.

00:41:47.600 --> 00:41:51.640
So we try to work with the best wishes of the end user.

00:41:51.720 --> 00:41:55.180
We try to work with their expectations and to their benefit.

00:41:55.280 --> 00:41:58.980
I've not met anybody who said, I want to get ransomware on my computer. But there are people

00:41:58.980 --> 00:42:02.620
who said, you know, I don't want your blocking service. And that's fine. 99910 is your choice.

00:42:02.820 --> 00:42:07.940
Go ahead and make the decision. Giving the end user the ability to make the decision on their

00:42:08.100 --> 00:42:14.760
own is where we create that distinction. When we have mandatory actions on a per nation basis,

00:42:15.020 --> 00:42:19.900
which are incredibly expensive and difficult for us to apply, that becomes a real problem

00:42:20.400 --> 00:42:22.740
where our mission does not, we're not achieving our mission.

00:42:23.120 --> 00:42:26.640
And if people want to follow that fight, where would you send them to keep up with it?

00:42:28.160 --> 00:42:31.480
Take a look at our blog. We're going to post things every once in a while. There are a number

00:42:31.490 --> 00:42:37.840
of other plaintiffs in that case. Cloudflare and Google and Whalebone, I think, are typically

00:42:38.080 --> 00:42:42.600
named in those. So all of us are trying to figure out how we're going to do this independently.

00:42:43.470 --> 00:42:46.460
So no, I don't have a central source for that. There's been some discussion about how do we

00:42:46.590 --> 00:42:52.640
create a centralized clearinghouse of information or public appeal, but none of that's in place yet.

00:42:52.980 --> 00:42:56.560
Yeah, so in terms of you guys, you mentioned that you're a small organization.

00:42:56.870 --> 00:42:58.680
How small? How many people are back there?

00:42:59.290 --> 00:42:59.920
Less than 10.

00:43:01.620 --> 00:43:04.140
And quite a few of those are contractors, so part-time.

00:43:05.120 --> 00:43:07.400
Nice. And what's the setup there?

00:43:07.520 --> 00:43:10.280
Is it mostly engineers? I assume some customer support?

00:43:10.620 --> 00:43:12.100
Full-time, there's only one customer support.

00:43:12.480 --> 00:43:15.040
Mostly, we've got, including myself, four engineers.

00:43:15.800 --> 00:43:18.840
We've got GM. I'm the CTO officially now, which is great.

00:43:18.880 --> 00:43:24.160
I have a general manager that's one of our foundation council members is acting as a general manager for a while.

00:43:24.400 --> 00:43:30.400
We've got some really great people who are doing kind of general catch-all business operations work, but it's a fairly small group.

00:43:30.820 --> 00:43:34.660
We've got some folks doing grants and fundraising as well, kind of paperwork on that side.

00:43:34.860 --> 00:43:38.580
Yeah, you know, there's another, and I want to ask a little bit more about the business model here.

00:43:39.040 --> 00:43:44.960
But this question is inspired by the free Firefox VPN they released that came with 50 gigabytes of free bandwidth.

00:43:45.000 --> 00:43:50.720
And I had them on and I'm like, okay, so if more and more people are using this, is that cheaper for you guys?

00:43:50.920 --> 00:43:51.700
Is it more expensive?

00:43:51.920 --> 00:43:53.740
And I figured I'd kind of throw you the same question.

00:43:53.920 --> 00:43:58.540
You probably want as many people to be using Quad9, but does that increase costs for you guys?

00:43:59.320 --> 00:43:59.900
It does.

00:44:00.220 --> 00:44:03.900
My saying is, we lose money on every user, but we make it up in volume.

00:44:04.420 --> 00:44:06.140
Yes, it does increase our costs.

00:44:06.760 --> 00:44:10.440
But the incremental costs of new users coming onto the network is relatively low.

00:44:10.960 --> 00:44:11.400
Here's why.

00:44:11.460 --> 00:44:15.820
Quad 9 is a nonprofit, which gives us some really interesting magic powers.

00:44:16.580 --> 00:44:18.280
And the magic powers are that people like what we do.

00:44:18.560 --> 00:44:24.800
And so we have now roughly 200 locations worldwide where we actually have physical equipment installed or servers running.

00:44:25.620 --> 00:44:26.860
And we don't pay for any of those.

00:44:27.220 --> 00:44:32.540
So the space, the power, the internet bandwidth, that all gets to us at no cost.

00:44:32.800 --> 00:44:36.420
That's because we bring protections both to the end user, but also to the network.

00:44:37.000 --> 00:44:41.460
And so people are anxious to have Quad9 in their facilities where their end users can use us.

00:44:41.620 --> 00:44:44.660
So what we have to pay for, though, is servers and people.

00:44:45.660 --> 00:44:48.060
Those are the big costs from an operational perspective.

00:44:48.290 --> 00:44:51.460
You know, how do we deploy more and more servers to more and more locations?

00:44:51.890 --> 00:44:54.140
And then how do we pay for the people to maintain those?

00:44:54.620 --> 00:44:56.360
And that's where our costs come in.

00:44:56.640 --> 00:44:59.560
But the ongoing costs for the network are relatively small.

00:45:00.060 --> 00:45:03.300
DNS, even over these new protocols, is relatively small.

00:45:03.880 --> 00:45:13.680
Bandwidth wise, if we look really just at the core of the bandwidth of like what actually people are using, it's measured in probably the low tens of gigabits per second of DNS traffic.

00:45:13.960 --> 00:45:16.540
And so that's not in the relative scope of things today.

00:45:16.720 --> 00:45:18.320
That's not much across 200 sites.

00:45:18.720 --> 00:45:25.940
So the cost of bandwidth, unlike the VPN products where the bandwidth itself is the product, that's a different story.

00:45:26.340 --> 00:45:28.080
But we don't, bandwidth is not our product.

00:45:28.340 --> 00:45:31.400
It's really it's CPU and memory and staffing.

00:45:32.420 --> 00:45:33.080
That's kind of it.

00:45:34.019 --> 00:45:46.000
Yeah, you know, earlier in the podcast, you mentioned that you guys are kind of looking at ways that you can monetize aggregate data. So what does that look like? Because again, to a person listening to this, it's like, oh, you're a privacy.

00:45:46.599 --> 00:45:47.960
Aggregate data, no, bad.

00:45:48.110 --> 00:45:54.480
And then all these things don't seem compatible. Obviously, I know you guys and I trust you guys. So I'd love to hear kind of what's going on there.

00:45:54.560 --> 00:46:00.540
Let me actually reference people to our privacy policy. We have one of the most extensive and

00:46:00.680 --> 00:46:04.960
fully explained privacy policies that I've ever seen, and because we spend a lot of time on it.

00:46:04.990 --> 00:46:09.760
So take a look at that. It explains what we cannot do. Now, let me give you some of the

00:46:09.900 --> 00:46:13.220
things that we're trying to actually figure out how we'd monetize some of this. Because again,

00:46:13.350 --> 00:46:18.300
we have massive user population now. We've got a lot of queries every day. Is there some way that

00:46:18.300 --> 00:46:22.360
we can create a sustainable model that people are interested in some of the data outcomes,

00:46:22.500 --> 00:46:27.360
some of the exhaust from this massive DNS network? And the answer is yes, and I don't think any of

00:46:27.360 --> 00:46:31.480
them are objectionable. Let me give you the most obvious one that we talk about, and that's newly

00:46:31.660 --> 00:46:36.040
observed domains. This is something that cybersecurity folks find really, really interesting.

00:46:36.670 --> 00:46:41.580
When a new domain name starts to get used, basically when it first is registered,

00:46:42.080 --> 00:46:46.020
somebody somewhere in our network is going to look it up, whether that's part of a threat campaign or

00:46:46.600 --> 00:46:51.959
accidentally or whatever, there's going to be some event where we've never seen this domain name ever

00:46:51.980 --> 00:46:58.260
before, you know, foo.com has just been registered and it's just admitted. That data, we don't think

00:46:58.680 --> 00:47:03.060
is, it's really difficult to argue that that somehow is personally associatable with some

00:47:03.280 --> 00:47:07.560
person. But what threat intelligence providers are interested in is when that exact moment happens,

00:47:07.760 --> 00:47:12.040
like as soon as you see the new domain, they want to go out and look at it to make sure that it's

00:47:12.420 --> 00:47:16.519
not malicious. Or does it even fit it? They don't even need to look at it. Just does it fit a pattern

00:47:17.100 --> 00:47:22.040
of something? Does it have another, is it a brand impersonation? Is it somebody trying to

00:47:22.300 --> 00:47:25.520
create a phishing domain with embedded host names somewhere in there?

00:47:26.260 --> 00:47:33.920
Just to interrupt for a second, is what you're implying here that new domains are riskier than

00:47:34.000 --> 00:47:38.100
maybe more established domains? Yes, they are definitely more risky. Definitely more risky.

00:47:38.580 --> 00:47:42.539
Many, many, many domains, I don't know what the percentage is, but they'll appear and disappear

00:47:42.540 --> 00:47:47.140
within a day or two. They get registered, they get used for phishing, or they get registered for

00:47:47.380 --> 00:47:51.140
some other purpose, command and control systems, and then they're deregistered.

00:47:51.680 --> 00:47:58.420
So having very, very rapid knowledge of new domain names as they come online is something

00:47:58.460 --> 00:48:01.980
that threat intelligence providers are really interested in because they're going to then use

00:48:02.160 --> 00:48:06.840
that to protect their customers. In many cases, they feed that back to quad nine. Basically,

00:48:07.380 --> 00:48:11.959
as soon as they notice a new domain, they feed it back to us and we block it. So that we're trying

00:48:11.960 --> 00:48:17.800
to monetize. That's basically, that's an aggregate data set that we have that people are interested

00:48:17.980 --> 00:48:23.520
in that gives not just benefit to the companies that are buying it, but indirectly, and in some

00:48:23.680 --> 00:48:27.460
cases directly, gives benefit back to our end users because new threats are identified much

00:48:27.540 --> 00:48:33.180
more quickly. Yeah, my DNS resolver that I use, I want to ask about kind of the differences later.

00:48:33.520 --> 00:48:37.780
But the way they deal with this problem is they just have an option like block all NRDs. So it

00:48:37.860 --> 00:48:41.280
actually happens a lot on my end where someone sends me something that's brand new. They're like,

00:48:41.400 --> 00:48:44.840
look how cool this is. And then I have to go see why it was blocked. And it's normally the NRD

00:48:45.020 --> 00:48:48.780
filter that does it. The newly registered domains are newly observed domains is what we call them.

00:48:49.120 --> 00:48:52.960
You're probably getting that list from a 24 hour filter. There's a, you can actually download some

00:48:52.960 --> 00:48:58.260
of those things from some of the people that operate TLDs. And those are available in a 24

00:48:58.400 --> 00:49:03.220
hour cycle. Some of these domains don't even make it to the 24 hour cycle. They get registered and

00:49:03.300 --> 00:49:08.000
they get pulled within three hours because they get noticed as doing malicious activity. However,

00:49:08.340 --> 00:49:16.180
Due to the way the DNS works, you can have that name then in your cache for sometimes up to 24 hours, usually 12 hours is the most.

00:49:16.540 --> 00:49:22.120
So names get registered, a bunch of people look them up, they get put into caches, the name gets deregistered,

00:49:22.300 --> 00:49:28.300
but it still gets to be used as spam or as phishing for as long as those recursive resolvers keep it in their cache.

00:49:28.640 --> 00:49:30.640
I thought they did it the inverted way.

00:49:30.660 --> 00:49:34.560
I thought that they would look, oh, is this domain already in our systems?

00:49:34.980 --> 00:49:36.940
Oh, it's not, therefore it is an NRD.

00:49:37.100 --> 00:49:40.600
but you're saying they actually have to verify if it's an NRD on a different list?

00:49:40.920 --> 00:49:42.940
There's a CZDS, I think.

00:49:42.970 --> 00:49:44.420
I'm sorry, I'm not going to remember the acronym well.

00:49:44.600 --> 00:49:52.700
But basically, you can get the newly registered domains delivered to you as a downloadable file every day if you qualify.

00:49:53.120 --> 00:49:54.420
Basically, if you have a reason to get that.

00:49:54.490 --> 00:49:57.000
And so a lot of threat providers get that data, but it's every day.

00:49:57.190 --> 00:50:00.540
Then they look at those names, and then they decide whether they're going to block on them or not.

00:50:00.830 --> 00:50:05.520
And probably the lists you're getting are, I'm going to guess, an outcome of those daily lists.

00:50:05.960 --> 00:50:12.180
When a newly observed domain happens on our network, we can transmit that to our threat intelligence partners within about 15 seconds.

00:50:12.540 --> 00:50:13.920
So the loop is really, really tight.

00:50:14.420 --> 00:50:16.680
And you have to have that because these guys are getting much better.

00:50:16.760 --> 00:50:18.960
The threats are getting much, much, much shorter in cycle.

00:50:19.400 --> 00:50:20.380
So the faster, the better.

00:50:21.100 --> 00:50:24.600
Yeah, sorry, I didn't mean to go on kind of a side trail there.

00:50:24.660 --> 00:50:25.060
I was curious.

00:50:25.400 --> 00:50:28.520
You mentioned a couple other revenue models that you might be exploring.

00:50:29.640 --> 00:50:31.980
Yeah, so there's newly observed domains.

00:50:32.400 --> 00:50:38.600
We basically can also provide to threat intelligence providers an idea of how bad something is going to be if they block it.

00:50:38.820 --> 00:50:49.300
So one of our big things that we have at Quad9 is we really, really try hard not to have false positives, meaning that if someone gives us a domain name that isn't malicious, that's a false positive.

00:50:49.640 --> 00:51:00.280
And we have done a great job in the last 10 years of keeping that number to a very, very low minimum, despite the fact that we have roughly 4 million names in this list every day.

00:51:00.770 --> 00:51:01.940
And a lot of that cycles through.

00:51:01.980 --> 00:51:03.000
There's a lot of churn there.

00:51:03.360 --> 00:51:06.100
You know, we've worked really hard with our threat intelligence providers trying to figure

00:51:06.110 --> 00:51:09.840
out ways that they can improve the data that they give us.

00:51:10.150 --> 00:51:13.780
Instead of just giving us a list without testing it, like, can they figure out, you know, are

00:51:13.780 --> 00:51:14.980
there any false positives in here?

00:51:15.620 --> 00:51:18.740
False positives are usually indicated by a couple of different metrics.

00:51:19.040 --> 00:51:21.320
One is volume, like something gets a lot of queries.

00:51:21.560 --> 00:51:21.960
It's okay.

00:51:21.990 --> 00:51:23.200
You should probably look at that first.

00:51:23.450 --> 00:51:27.080
But then also there are things like geographic distribution, host name distribution.

00:51:27.540 --> 00:51:32.480
There are ways that you can look at a block and say, oh, whoops, we've blocked the wrong thing.

00:51:32.900 --> 00:51:33.980
But it's too late at that point.

00:51:34.040 --> 00:51:37.060
If you block it, we actually give insight to the threat intelligence provider.

00:51:37.220 --> 00:51:41.580
When they give us a name to block, we actually give them telemetry back on every blocking event.

00:51:41.920 --> 00:51:42.740
It's very rough data.

00:51:42.960 --> 00:51:46.540
It's metropolitan area and then the FQDN.

00:51:47.360 --> 00:51:49.960
And so this helps them improve their feeds, right?

00:51:50.080 --> 00:51:52.580
So that's a sort of a virtuous loop here.

00:51:53.240 --> 00:51:55.600
But the problem is that when they give us a block, it's too late.

00:51:55.740 --> 00:51:59.000
The false positives are already in the system and we're already causing people pain.

00:51:59.900 --> 00:52:03.500
And what we said, is there any way we can do this, which doesn't cause pain?

00:52:04.660 --> 00:52:08.700
And so we have a model which allows threat intelligence providers to kind of do a virtual

00:52:08.930 --> 00:52:13.800
block for a very short period of time, which allows them to see what would happen if they

00:52:14.180 --> 00:52:17.140
committed this block to us or they submitted this to us as a block.

00:52:18.020 --> 00:52:20.820
And so that's a product basically that we, that we offer.

00:52:20.870 --> 00:52:24.080
And that's a, that's a four fee because it's actually improving their threat feed.

00:52:24.500 --> 00:52:28.600
They're in turn reselling that threat feed to their downstream customers.

00:52:28.880 --> 00:52:29.280
And that's great.

00:52:29.460 --> 00:52:30.060
That's what we want.

00:52:30.140 --> 00:52:33.280
We're actually fully encouraging that because it helps everybody's security.

00:52:33.720 --> 00:52:38.040
But what we're trying to do is decrease the false positive rates and give them better insights.

00:52:39.200 --> 00:52:39.400
Got it.

00:52:39.620 --> 00:52:42.120
Are there any other things you're exploring or is it mostly those two?

00:52:42.460 --> 00:52:45.520
The one last one that we have is the most powerful one.

00:52:45.720 --> 00:52:47.320
And it's the most difficult one to describe.

00:52:47.740 --> 00:52:52.740
We've had a lot of interest in people who are looking for brand protection kind of issues.

00:52:53.120 --> 00:52:57.460
And this was the sort of the core of when we started to think about this.

00:52:57.570 --> 00:53:02.500
They said, well, you know, I see in all the way in the left-hand side, we've got these

00:53:02.700 --> 00:53:05.260
like domain names with 10 different zone cuts.

00:53:05.420 --> 00:53:09.540
You know, it's foo.blah.bankofamerica.blah, blah, blah, blah.

00:53:09.700 --> 00:53:11.620
Like there's a whole bunch of different zone cuts in here.

00:53:11.880 --> 00:53:15.580
They want to know what's happening in the far left-hand side of the zone.

00:53:16.560 --> 00:53:20.600
And they want to see when there's brand impersonation there, because that's the thing that catches

00:53:20.800 --> 00:53:21.120
people, right?

00:53:21.200 --> 00:53:25.660
They see a long host name that basically they only see the first part of it and it looks

00:53:25.740 --> 00:53:29.600
like a legitimate site and they click on it and too late, you're trapped.

00:53:30.040 --> 00:53:35.680
And so we have a model which allows people to put in strings that they're interested

00:53:35.880 --> 00:53:42.260
in anywhere in the zone to be able to get back host names that look like brand impersonation

00:53:42.290 --> 00:53:43.460
or domain impersonation.

00:53:44.300 --> 00:53:48.120
And we've got actually a fairly powerful set of open source software we developed to do

00:53:48.240 --> 00:53:48.760
just that.

00:53:49.200 --> 00:53:52.960
If you go to our GitHub page, we have a platform called String Simile.

00:53:53.760 --> 00:53:57.200
And what that is, is it's a combination of a whole bunch of different string matching

00:53:57.660 --> 00:54:00.400
algorithms all combined into one big code base.

00:54:00.940 --> 00:54:07.480
So you can say, I want to look for the string Netflix, but instead of eyes, let's say the

00:54:07.580 --> 00:54:08.060
number one.

00:54:08.420 --> 00:54:09.920
So in other words, it has confusables.

00:54:10.280 --> 00:54:15.440
It has Cyrillic and IDN lettering so that if someone tries to make a name that looks

00:54:15.540 --> 00:54:17.340
like something else, it catches that.

00:54:17.340 --> 00:54:21.120
we have phonetic matching there's all kinds of different matching you can do

00:54:21.770 --> 00:54:27.940
so that you can see when a new host name appears if it matches your brand and again this is in the

00:54:28.100 --> 00:54:32.920
same model as the newly observed domains except that you're matching for a very specific set of

00:54:33.080 --> 00:54:36.300
strings and you're doing it for all host names you're not just doing it for the domain name

00:54:36.310 --> 00:54:42.340
you're actually matching anything in the dns that we see on a new basis we have like a 10 10 second

00:54:42.340 --> 00:54:48.140
latency on that. So when a new name appears, or when a name changes, we can run that through the

00:54:48.340 --> 00:54:52.540
filter and get a result within a few seconds. So to summarize that is what you're saying,

00:54:52.740 --> 00:54:57.060
if I am a well-equipped organization, I care a lot about like, let's say I'm Apple, I'm Google,

00:54:57.280 --> 00:55:05.540
and I don't want people to end up on G-O-O-G-L-E, or I don't know, Apple with a three instead of an

00:55:05.540 --> 00:55:10.200
E. These are the most basic versions of these. I know these get very sophisticated. They would

00:55:10.220 --> 00:55:16.100
pretty much become your clients. And then you would pretty much have individualized brand protection

00:55:16.300 --> 00:55:21.120
for them. Right. They tell us what the strings are that they're looking for, you know, roughly.

00:55:21.660 --> 00:55:26.880
And then we can match on that against this giant fire hose of changes that we see and give them

00:55:26.880 --> 00:55:30.760
the insights when those domains are matched or when those strings are matched. This allows them

00:55:30.900 --> 00:55:36.640
to understand what's happening in a brand lookalike. In this same vein, there's another interesting

00:55:36.920 --> 00:55:41.620
product that we've been kicking around that we actually haven't named yet. I'll pull the veil

00:55:41.780 --> 00:55:45.880
back a little bit. But there's another one that we've actually found is quite interesting. And

00:55:45.880 --> 00:55:49.140
that is that most big domain name operators don't actually know what's in their zone.

00:55:49.470 --> 00:55:54.980
They have no idea. Big Fortune 500 companies subdelegate out everything inside their zone

00:55:55.420 --> 00:55:59.400
down to regional offices. And then that regional office dedicates some out to a lab.

00:55:59.830 --> 00:56:04.840
And then the lab might use a commercial provider to do a CDN test. And so the people at the very

00:56:04.860 --> 00:56:10.400
bottom of the network of the namespace, they actually don't know all the things that's in

00:56:10.440 --> 00:56:16.760
their own zone, especially if you're allocating out to CDNs or third parties. We do. We can actually

00:56:17.000 --> 00:56:22.180
tell you what's in your zone because chances are high that almost everything in your zone has been

00:56:22.320 --> 00:56:25.580
looked up on quad nine somewhere. So that's a product we've been kicking around in the same

00:56:25.780 --> 00:56:29.840
space, but it's actually basically telling you what's in your own zone. It sounds like a ludicrous

00:56:29.840 --> 00:56:35.720
thing, but it actually is quite interesting because the larger you get, the less, you know,

00:56:35.740 --> 00:56:41.560
DNS is a decentralized protocol and you don't know what's going on. And so there are really

00:56:41.760 --> 00:56:47.040
interesting compliance issues there, cybersecurity issues there that we can help those zone operators

00:56:47.600 --> 00:56:52.400
answer, especially in the bigger zones. You know, all of these so far that you shared,

00:56:52.860 --> 00:56:57.400
like the first three, to me, again, correct this if I'm wrong, they all seemed like technology that

00:56:57.420 --> 00:57:01.600
you guys have developed to fix a problem. But that fourth one almost sounds like it could be a scale

00:57:02.220 --> 00:57:05.940
because you've gotten large enough, you can then supply that service? Or am I misunderstanding?

00:57:06.340 --> 00:57:11.760
No, no. Well, you're right on both counts. The NOD is definitely a scale question because you need

00:57:11.760 --> 00:57:15.660
to have fast response. You need to have a lot of people on the network to get those newly observed

00:57:15.760 --> 00:57:20.880
domains quickly resolved. Same thing. You have to have scale and you have to have the technology for

00:57:21.100 --> 00:57:25.560
being able to test for false positives. And this last one is both, again, scale and technology.

00:57:25.640 --> 00:57:32.000
You need to have lots and lots of users on the network to churn through all the names in the namespace.

00:57:32.620 --> 00:57:37.100
And then you have to have the ability to be able to process that at scale is also quite significant.

00:57:37.340 --> 00:57:42.700
You know, it's tens of billions of names in a very short period of time that you've got to be able to scan through.

00:57:42.940 --> 00:57:47.960
And we've actually developed some code for that that we've, again, contributed back to various open source repositories.

00:57:48.160 --> 00:57:52.180
So we think we're doing the right thing with both the data and the methods that we're collecting it.

00:57:53.060 --> 00:57:53.320
Very cool.

00:57:53.440 --> 00:57:56.600
I feel like the way that I see DNS talked about a lot,

00:57:56.600 --> 00:57:58.080
and even I sometimes say this too,

00:57:58.840 --> 00:58:00.780
is it's in a way kind of like a VPN

00:58:00.940 --> 00:58:02.220
in the sense that you're shifting trust.

00:58:02.980 --> 00:58:04.780
Instead of trusting your ISP's DNS,

00:58:04.990 --> 00:58:07.660
you now trust Quag9 or whatever other DNS provider.

00:58:08.110 --> 00:58:10.080
So what do you normally say when people ask,

00:58:10.180 --> 00:58:11.480
why should I trust you?

00:58:11.510 --> 00:58:13.980
I know we've kind of covered a lot of the reasons why in the interview,

00:58:14.260 --> 00:58:16.060
but how do you signal trust to people?

00:58:16.220 --> 00:58:17.380
Totally reasonable question.

00:58:17.580 --> 00:58:18.780
First one is kind of a non-event.

00:58:18.960 --> 00:58:20.120
Why would you trust us?

00:58:20.580 --> 00:58:21.620
We don't actually know who you are.

00:58:22.580 --> 00:58:26.340
Meaning that there's no signup, there's no association that we have with you as a person

00:58:27.000 --> 00:58:30.700
with the lookups you're doing. Even if we didn't do anything we said we were going to do,

00:58:31.300 --> 00:58:37.220
there's no mapping of your IP address to you. And we don't collect the IP address either.

00:58:38.020 --> 00:58:42.140
So, but that's the second reason you should trust us. Reason number two to trust us is again,

00:58:42.520 --> 00:58:46.960
because of the constraints that we have put upon ourselves. The legal constraints by being in

00:58:47.100 --> 00:58:51.840
Switzerland, really the ironclad guarantee of privacy that we have that's not backed up

00:58:51.900 --> 00:58:55.900
just by fines. It's backed up by going to jail if we don't do what we say we're going to do.

00:58:56.580 --> 00:58:59.700
And that was the whole reason that we chose Switzerland as a destination to move to,

00:58:59.830 --> 00:59:03.660
because we had to put our money where our mouth was. The third reason you should trust us is that

00:59:03.710 --> 00:59:08.640
we have no incentive for you not to trust us. There is nothing that we have other than your trust.

00:59:09.180 --> 00:59:13.620
There is no, I mean, we have cybersecurity, right? We do give away that really nice service,

00:59:14.180 --> 00:59:17.100
but that would be nothing if people thought that we were collecting their data.

00:59:17.760 --> 00:59:25.080
So really, we have to have people's trust because the friction of leaving Quad9 is the same as coming in.

00:59:25.460 --> 00:59:25.560
Zero.

00:59:26.120 --> 00:59:29.460
If you don't like what you get, there is nothing keeping you here.

00:59:29.830 --> 00:59:36.500
And if you don't believe you're going to be treated in a way that's private and equitable, then there's no reason for you to stay.

00:59:36.800 --> 00:59:37.360
We're a nonprofit.

00:59:37.850 --> 00:59:38.660
We're not a CDN.

00:59:38.660 --> 00:59:39.620
We're not a marketing company.

00:59:40.020 --> 00:59:41.420
We don't do any of those things.

00:59:42.140 --> 00:59:48.520
So the only thing we have to barter with is your trust and the safety we give to our end users.

00:59:49.340 --> 00:59:53.700
So we're very, very concerned that people understand that we do value privacy.

00:59:53.940 --> 00:59:57.780
Like I can't speak for the rest of my staff, but most of us are privacy zealots here.

00:59:58.080 --> 00:59:59.400
We're not doing this for money.

00:59:59.700 --> 01:00:01.260
We're not getting paid particularly well.

01:00:01.660 --> 01:00:05.360
Working for a nonprofit, it pays the bills, but there's no stock options.

01:00:05.740 --> 01:00:07.720
There are no Ferraris and driveways here.

01:00:08.260 --> 01:00:11.120
We're doing this because we believe in what it is that we do.

01:00:11.680 --> 01:00:13.800
Everybody in the team believes in what we do.

01:00:14.580 --> 01:00:17.460
And we think we're making the world a slightly better place.

01:00:18.600 --> 01:00:19.660
Yeah, period.

01:00:20.940 --> 01:00:24.380
I'm going to call this the for Henry's interest only section

01:00:24.540 --> 01:00:26.740
just because I had a few questions come up

01:00:26.840 --> 01:00:29.040
that I think are very much for me.

01:00:29.200 --> 01:00:31.260
But I know that other people listening are going to have them too.

01:00:31.380 --> 01:00:32.360
So I know it's helping others.

01:00:32.580 --> 01:00:34.080
But this is a very bare bones question.

01:00:34.460 --> 01:00:36.480
I think I've actually heard the answer before,

01:00:36.780 --> 01:00:38.220
but maybe it's different how you guys do it

01:00:38.220 --> 01:00:39.480
or maybe my understanding is wrong.

01:00:39.820 --> 01:00:47.460
Let's say someone's deciding between getting malware blocking or 9.9.9.10 without the malware protection.

01:00:47.940 --> 01:00:48.880
Is there a speed difference there?

01:00:49.820 --> 01:00:52.880
Does the filtering itself have a difference on latency and speed?

01:00:53.400 --> 01:00:55.460
Weirdly enough, well, no, I'm sorry.

01:00:56.170 --> 01:00:56.860
No, there is no difference.

01:00:57.060 --> 01:00:58.320
There is no noticeable difference.

01:00:58.440 --> 01:01:00.400
There is a noticeable difference with 9.9.9.11.

01:01:01.120 --> 01:01:02.660
I almost got the wrong question there.

01:01:03.060 --> 01:01:11.340
So 9999 and 99910, you will not notice a difference because it's relatively short.

01:01:11.740 --> 01:01:15.780
We actually notice a difference because there's less CPU usage and less memory usage.

01:01:16.190 --> 01:01:17.920
But from the end user's perspective, no.

01:01:18.940 --> 01:01:26.560
For 99910, there's a slightly lower memory and CPU use, but there is no easily measurable difference between the two of them.

01:01:28.039 --> 01:01:32.000
99911 is a different service, which does have blocking.

01:01:33.040 --> 01:01:38.380
but it also includes what's called ECS, which is EDNS client subnet. And that is a slightly

01:01:38.490 --> 01:01:43.200
different service because there are, do you know about ECS? Do you want to do the whole? Okay.

01:01:43.820 --> 01:01:49.680
Excellent. So 9999 is exceptionally private. We pass no information about the end user

01:01:50.240 --> 01:01:55.060
to the authoritative server that we're asking the questions to. So if you look up amazon.com,

01:01:55.660 --> 01:02:01.280
we ask Amazon servers for the IP address that they're giving and you get it back.

01:02:01.560 --> 01:02:03.620
Now, we have 200 locations around the world.

01:02:03.740 --> 01:02:07.580
That means that relatively close to you, there's a Quad 9 location.

01:02:08.240 --> 01:02:11.860
And you're going to connect to that and you're going to ask it for www.amazon.com.

01:02:12.300 --> 01:02:17.240
Amazon is going to give you back a different answer based on where they think you are.

01:02:17.480 --> 01:02:24.240
So if you're in San Diego, you're going to get back probably on a Los Angeles-based cluster of Amazon servers.

01:02:24.420 --> 01:02:29.480
In other words, the IP address that Amazon gives back to you or gives back to Quad9 that we then

01:02:29.680 --> 01:02:35.980
give back to you is going to be an LA-based cluster of systems. Let's say for some reason,

01:02:36.290 --> 01:02:40.680
and this does happen on occasion, you're in an island nation where Quad9 does not have a server.

01:02:40.860 --> 01:02:46.320
You're coming from Kiribati. So the closest Quad9 known to Kiribati, let's say that's Los Angeles,

01:02:46.690 --> 01:02:51.340
even though from a distance perspective, Sydney would be much closer to you to get an Amazon node.

01:02:51.500 --> 01:02:56.900
there's a problem here. So you're going to be in Kiribati. You're asking for amazon.com from a

01:02:57.440 --> 01:03:03.120
Quad9 cluster in LA. You're going to get back the LA number, IP address. But in fact, that's going

01:03:03.120 --> 01:03:07.640
to give you a really terrible performance based on what you could be getting otherwise. So Amazon

01:03:08.220 --> 01:03:15.080
would prefer it if Quad9 sent information about you, the individual, to Amazon when we make the

01:03:15.240 --> 01:03:20.100
question to them. We, however, would prefer not to send you that information or send them the

01:03:20.120 --> 01:03:24.740
information. So in other words, Quad9 is extremely private. We don't send anything about the end user

01:03:24.980 --> 01:03:32.500
to the authoritative server. That's our default service, 9999 and 99910. In some cases, it does

01:03:32.640 --> 01:03:39.160
make sense for us to leak information about the end user to the authoritative server in order to get a

01:03:39.320 --> 01:03:45.820
more performant end result. This is what ECS does. So services like Google, even though you don't

01:03:45.840 --> 01:03:50.300
know it, every time, if you're to use Google's recursive resolver, 8888, when you make queries

01:03:50.480 --> 01:03:55.660
to it, they send the first three octets of your IP address to the authoritative server.

01:03:56.120 --> 01:04:01.160
We don't think that's a good idea. And so we don't do that, but Google does. And so to their credit,

01:04:01.250 --> 01:04:06.440
they get back probably more geographically accurate results more of the time than we do,

01:04:06.660 --> 01:04:12.420
but they also have a privacy leak. We provide 99911 to provide that exact service.

01:04:13.480 --> 01:04:23.080
So in other words, if you choose to leak those first three octets of your IP address, or in IPv6, I think it's the first slash 48 or 56, I don't remember.

01:04:23.190 --> 01:04:31.360
But you can choose to get more geographically proximate addresses by giving up some of that privacy to the authoritative server.

01:04:31.840 --> 01:04:32.680
That is slightly slower.

01:04:33.070 --> 01:04:38.120
The reason for that is that every slash 24 has to keep its own little version of the cache.

01:04:38.600 --> 01:04:44.520
Like you in San Diego are going to have, you're going to get answers back for the same Amazon

01:04:44.860 --> 01:04:48.040
network, but everyone in your slash 24 is going to get the same answer.

01:04:48.070 --> 01:04:51.740
So that means we have to fragment our cache into a million different little tiny shards.

01:04:52.060 --> 01:04:56.200
So just by kind of by default, the answers are going to be slower because there are lower

01:04:56.440 --> 01:04:57.740
chances of those being cached.

01:04:58.060 --> 01:05:02.920
The chances of someone asking for amazon.com in your same slash 24 are much, much lower

01:05:03.520 --> 01:05:06.580
than on a citywide basis, which is what we have with 9999.

01:05:07.900 --> 01:05:13.280
So you kind of mentioned the reason to do this is it could be faster for you, but then you mentioned it's slower.

01:05:13.460 --> 01:05:15.380
So where is this slower?

01:05:15.440 --> 01:05:16.160
Where is it faster?

01:05:16.260 --> 01:05:24.280
And my understanding is the people incentivized to use this are people who are rural in the sense of they're not near any major server locations.

01:05:24.900 --> 01:05:25.060
Correct.

01:05:25.360 --> 01:05:25.920
That's right.

01:05:26.400 --> 01:05:34.520
So people at the end of very thin pipes, like, again, island nations, they will often have their own CDN distribution in the island nation.

01:05:35.260 --> 01:05:39.760
But if they're using Quad9 and we don't have a node in that nation, they're basically going to be mismatched.

01:05:39.880 --> 01:05:42.780
They're going to be querying a location that doesn't have the CDN facilities.

01:05:43.340 --> 01:05:44.700
So this is kind of our push.

01:05:44.840 --> 01:05:52.040
This is why we have 200 sites, because the closer that our systems are to the end user, we're going to get a better answer from the CDN distribution point.

01:05:52.320 --> 01:05:58.760
We're not big fans of ECS because, again, we're more privacy focused than we are performance focused, quite honestly.

01:05:59.060 --> 01:06:03.180
I mean, there are places you can make lots of tradeoffs if you're willing to give up privacy.

01:06:03.440 --> 01:06:10.040
we're not but we give the users the option in that the dns query might be slightly slower but the

01:06:10.600 --> 01:06:14.440
streaming video or the download of the website might be a lot faster so that trade-off might

01:06:14.440 --> 01:06:19.380
be okay to them and we let them make that decision themselves makes sense yeah i think that's that's

01:06:19.380 --> 01:06:23.060
a good way to put it i didn't know any of this so that was all very new to me so thank you for

01:06:23.180 --> 01:06:28.040
sharing uh i guess something about me so i'm still like doing filtering with next dns i really like

01:06:28.600 --> 01:06:31.000
customizing things in my own portal a lot.

01:06:31.030 --> 01:06:32.160
And that's what I use personally.

01:06:32.960 --> 01:06:34.480
How does that DIY,

01:06:35.060 --> 01:06:36.140
I want to filter everything,

01:06:37.220 --> 01:06:38.040
get down and dirty,

01:06:38.360 --> 01:06:39.760
how does that compare to maybe,

01:06:40.110 --> 01:06:40.960
I know obviously you guys,

01:06:40.960 --> 01:06:42.220
I don't think do any kind of

01:06:42.740 --> 01:06:44.420
privacy-based blocking on Quad9,

01:06:45.400 --> 01:06:48.220
but how would you compare those approaches?

01:06:48.560 --> 01:06:50.160
What's actually going on behind the scenes?

01:06:50.310 --> 01:06:52.020
What do you normally recommend to most people?

01:06:52.110 --> 01:06:54.260
And why do you guys not have a service like that?

01:06:54.440 --> 01:06:56.120
Well, let me ask the last question first.

01:06:56.660 --> 01:06:58.020
We don't have a service like that

01:06:58.020 --> 01:07:03.040
it's very expensive to do that. There's a lot of user interface. There's a lot of construction of

01:07:04.300 --> 01:07:09.580
a tooling set that would allow people to get that flexibility. And again, we focused primarily on,

01:07:09.720 --> 01:07:14.720
again, privacy and baseline cybersecurity. For people who want more advanced services,

01:07:15.080 --> 01:07:19.160
there are other things in the market. Our goal is not to take over the DNS world. That's not our

01:07:19.320 --> 01:07:23.540
goal at all. We don't want to be all things to all people. We might do further expansions in the

01:07:23.700 --> 01:07:28.000
future with different things that we're going to do, meaning that there might be some slow and

01:07:28.020 --> 01:07:34.620
steady advances in our feature set. But our mission is not to own the DNS market space. That's

01:07:34.900 --> 01:07:38.500
totally not what we're interested in. But the DIY set that are interested in doing that,

01:07:38.680 --> 01:07:45.300
there are things like NextDNS that do this as a service. How they treat privacy and security is

01:07:46.120 --> 01:07:49.980
between you and them. What we would really recommend people do is set up your own server,

01:07:50.340 --> 01:07:55.840
piehole, right? If you don't like what you see and you want to have even more advanced filtering

01:07:55.840 --> 01:07:59.760
with ad blocking and notifications and statistics,

01:08:00.460 --> 01:08:02.060
set up your own forwarding cache,

01:08:02.640 --> 01:08:03.940
embed all those rules into that,

01:08:04.100 --> 01:08:06.200
run it in your home or run it in the cloud even,

01:08:06.360 --> 01:08:08.200
run it somewhere else and point to it,

01:08:08.540 --> 01:08:10.680
and then forward the queries from that to Quad9.

01:08:11.060 --> 01:08:13.300
So in other words, you can still get all the benefits of Quad9,

01:08:13.460 --> 01:08:17.160
but you can put another layer in between your clients,

01:08:17.420 --> 01:08:20.020
your web browser or your computer and Quad9

01:08:20.160 --> 01:08:21.660
that does a whole bunch of other stuff

01:08:22.140 --> 01:08:23.720
that will get you more or less what you're getting

01:08:23.720 --> 01:08:28.920
with a commercial provider, but at no cost and with complete confidentiality, meaning you run

01:08:28.960 --> 01:08:35.400
that service yourself. That's the DIY answer. Most people can't or won't do that. And so we

01:08:35.759 --> 01:08:40.580
understand that. To date, that's not been where we've targeted our efforts.

01:08:41.779 --> 01:08:45.060
Got it. Thanks for sharing. Something I hear a lot about is VPN versus DNS.

01:08:45.700 --> 01:08:51.040
And I think the most common safe advice to give is just use your VPN's DNS resolver.

01:08:51.660 --> 01:08:53.120
If you trust them with your web traffic,

01:08:53.220 --> 01:08:55.920
it probably makes sense to trust them with your DNS traffic.

01:08:56.220 --> 01:08:57.839
I, for one, don't like doing that

01:08:57.960 --> 01:09:00.680
because I like my NextDNS filters that I've set up.

01:09:00.779 --> 01:09:03.540
I normally always try to find a way to combine both of them.

01:09:04.060 --> 01:09:05.720
But my understanding is that can add latency.

01:09:06.100 --> 01:09:07.240
That part I don't quite understand.

01:09:07.660 --> 01:09:11.000
I think somehow you have to contact a DNS server resolver

01:09:11.160 --> 01:09:13.279
and it's different from the VPN server.

01:09:13.520 --> 01:09:14.640
Anyway, this is all to say,

01:09:15.400 --> 01:09:18.380
do you ever recommend using Quad9 for VPN users?

01:09:18.520 --> 01:09:20.319
Or do you think they should use their DNS resolver?

01:09:20.880 --> 01:09:22.400
Or how do you look at this situation?

01:09:22.720 --> 01:09:23.759
There's two arguments, right?

01:09:24.040 --> 01:09:25.920
There's diversifying your trust,

01:09:26.580 --> 01:09:28.740
meaning if you trust Quad9 with your DNS

01:09:29.440 --> 01:09:31.299
and you trust your VPN with your transit data,

01:09:31.540 --> 01:09:32.640
you're basically separating

01:09:33.279 --> 01:09:34.660
two different streams of information.

01:09:34.819 --> 01:09:36.080
You're separating them apart from each other.

01:09:36.580 --> 01:09:37.520
You increase your risk

01:09:37.580 --> 01:09:40.140
that one of them might try to collect some of it.

01:09:40.540 --> 01:09:41.140
But as an example,

01:09:41.359 --> 01:09:42.920
if you're coming out of a VPN

01:09:43.940 --> 01:09:44.980
and using Quad9,

01:09:45.460 --> 01:09:47.200
we're not going to even see your home IP address.

01:09:47.420 --> 01:09:50.839
So even in the most spectacularly

01:09:50.859 --> 01:09:54.900
corrupted world where we're trying to collect information on people, we wouldn't be able to do

01:09:54.900 --> 01:09:59.680
it anyway out of a VPN. So I think that the model's broken there. I don't think there's any way that we

01:09:59.840 --> 01:10:04.460
could not, it would be really difficult for me to imagine how we would not be able to be trusted

01:10:05.180 --> 01:10:10.020
with data coming out of a VPN. However, I can see how the VPN would actually collect both

01:10:10.500 --> 01:10:14.980
data sets from you. And you have to really pick your VPN provider carefully because there are a

01:10:14.980 --> 01:10:19.480
lot of VPNs out there that are not what they seem to be. The free ones are especially concerning,

01:10:19.680 --> 01:10:27.120
But if you're paying for a reputable VPN provider, you can trust them the same way that you would trust Quad9 to some degree from a privacy perspective.

01:10:27.740 --> 01:10:29.980
But are you getting the additional benefits of the cybersecurity?

01:10:30.500 --> 01:10:31.300
Probably not.

01:10:31.490 --> 01:10:32.700
And are there latency issues?

01:10:33.000 --> 01:10:42.500
Also probably not, because wherever your VPN exit point is, I'm going to bet you that Quad9 is within two milliseconds of that exit point.

01:10:43.140 --> 01:10:47.260
We all share the same big inter-exchange locations.

01:10:47.440 --> 01:10:54.660
We're all within a few milliseconds of a big IX somewhere, whether that's Frankfurt or United States or Singapore or whatever.

01:10:55.220 --> 01:11:06.080
So even if you were to use Quad9 with your VPN, you're probably not sacrificing much from a performance perspective versus the DNS provider for your VPN.

01:11:06.500 --> 01:11:14.440
The best way to do this is actually to have a local cache sitting there in your office, even before you go into the VPN, because then you get the results instantly.

01:11:14.640 --> 01:11:18.860
Meaning you don't have to send the traffic all the way through the VPN and then all the way back.

01:11:19.260 --> 01:11:23.740
If you're getting them right there from a box that's sitting in your home network, that's faster.

01:11:24.060 --> 01:11:30.100
So I guess it's kind of a wash from a trust perspective between the two.

01:11:30.270 --> 01:11:33.660
The reason that I tell people to use Quad9 is because you're not always using your VPN.

01:11:34.560 --> 01:11:37.220
Sometimes you turn it off and you're using your native ISP.

01:11:37.840 --> 01:11:44.180
But if you've got Quad9 configured there, you're just going to connect to the closest node there where your house is versus going through the VPN tunnel.

01:11:44.400 --> 01:11:48.040
9.9.9.9 works anywhere in the world and it's really fast.

01:11:48.860 --> 01:11:53.380
Your VPN provider's DNS server, you might not even be able to get to it if you're not on the VPN.

01:11:53.520 --> 01:11:56.740
So then you have to go through and fix it or they have to have software that goes through and, you know,

01:11:57.080 --> 01:11:59.780
adds it or removes it to your DNS server list.

01:11:59.980 --> 01:12:01.100
It just adds complexity.

01:12:01.400 --> 01:12:01.980
But it's a wash.

01:12:02.260 --> 01:12:04.220
It's going to depend on your level of technical competence.

01:12:04.800 --> 01:12:09.080
But from a privacy perspective, as long as you have a trustworthy VPN provider, not a big deal.

01:12:10.040 --> 01:12:12.600
Yeah, the two VPNs I think of that are doing some interesting stuff.

01:12:13.040 --> 01:12:14.260
I know that IVPN has a feature,

01:12:14.440 --> 01:12:15.680
and I'm not saying they're the only one.

01:12:16.080 --> 01:12:19.820
I know IVPN has a feature where you can keep your DNS

01:12:19.980 --> 01:12:21.720
that you set in IVPN enabled,

01:12:21.900 --> 01:12:23.940
even if you're disconnected from IVPN.

01:12:24.000 --> 01:12:25.920
So let's say you set Quad9 in IVPN,

01:12:25.960 --> 01:12:27.140
but it's like, oh, I want to turn it off.

01:12:27.420 --> 01:12:29.080
Quad9 is still set as the DNS resolver,

01:12:29.240 --> 01:12:30.780
which I think is a really good fallback.

01:12:31.040 --> 01:12:34.100
And then Mulvad, they do host their own filters,

01:12:34.400 --> 01:12:36.420
kind of like what you guys do for 9.9.9.9.

01:12:36.920 --> 01:12:38.980
So I don't know if you have any opinions on those

01:12:39.100 --> 01:12:40.360
for people who like Mulvad.

01:12:40.700 --> 01:12:41.620
I don't know if you've played with those.

01:12:41.760 --> 01:12:44.820
They have more of privacy-based filters as well.

01:12:45.020 --> 01:12:46.340
I've seen Molvad's filters.

01:12:46.460 --> 01:12:48.140
They actually post them on, I think it's GitHub.

01:12:48.500 --> 01:12:51.600
And so, yeah, they're giving some added benefit.

01:12:51.920 --> 01:12:53.400
Is it as extensive as Quad9?

01:12:53.560 --> 01:12:54.500
No, it definitely is not.

01:12:54.620 --> 01:12:56.200
But it's still, from a privacy perspective,

01:12:56.400 --> 01:12:57.600
I'm sure that they're doing the right thing.

01:12:58.600 --> 01:13:01.800
In general, I've heard good things about Molvad's dedication to privacy.

01:13:01.960 --> 01:13:04.400
So I really have not a lot of insight there,

01:13:04.640 --> 01:13:07.840
but I'm sure it's useful for whatever context you are looking for.

01:13:08.200 --> 01:13:09.100
Have you looked at PyHole?

01:13:09.320 --> 01:13:09.740
I have.

01:13:09.840 --> 01:13:11.320
And it's one of those things that it's like,

01:13:11.400 --> 01:13:12.700
is it worth the complexity for me?

01:13:12.740 --> 01:13:13.620
And I just haven't done it yet.

01:13:13.820 --> 01:13:16.220
But honestly, even for content and for an experiment,

01:13:16.290 --> 01:13:17.500
I really should have done it by now.

01:13:17.740 --> 01:13:20.260
I mean, so many people in my life have recommended it to me.

01:13:20.540 --> 01:13:22.040
Yeah, it's pretty nice.

01:13:22.220 --> 01:13:23.840
There's some extensions that they've got in there

01:13:24.000 --> 01:13:25.740
that actually are custom for Quad9.

01:13:25.850 --> 01:13:28.680
So if there's a block event that we hand back to you,

01:13:29.220 --> 01:13:32.700
they actually tag it as a malicious activity in their logs.

01:13:32.920 --> 01:13:34.840
Whereas if we block something for you

01:13:35.060 --> 01:13:36.300
and you're just looking at it in your browser,

01:13:36.350 --> 01:13:39.200
you're just going to see a 404 not found.

01:13:39.490 --> 01:13:40.620
Or actually, that's not even true.

01:13:40.760 --> 01:13:47.000
It'll just say host not found, whereas the pie hole actually, you know, a little red box will appear and say, hey, this was a block by quad nine.

01:13:47.860 --> 01:13:50.660
Nice. Does it have to intercept the SSL cert to do that?

01:13:51.140 --> 01:13:53.680
Nope. No, it's actually looking at the DNS response.

01:13:53.820 --> 01:14:02.340
We actually tag the DNS response with a flag so that if you really know what you're looking at, like there's a bit set in the DNS response that says this is a not natural response.

01:14:03.280 --> 01:14:05.460
And so pie hole has the ability to look at that.

01:14:05.600 --> 01:14:07.820
We don't actually ever hand back an IP address.

01:14:08.460 --> 01:14:10.060
That's what you're talking about when you're talking about SSL.

01:14:10.480 --> 01:14:15.720
Like some blocking DNS providers will actually hand back an IP address when it's a block.

01:14:16.290 --> 01:14:19.160
And that means your browser has to go to some other site.

01:14:19.270 --> 01:14:20.940
And of course, the cert is never going to match.

01:14:21.040 --> 01:14:23.560
So you're going to get a pop up that says your connection is being intercepted.

01:14:23.600 --> 01:14:24.620
And that's terrible.

01:14:24.920 --> 01:14:26.120
That's a terrible, terrible model.

01:14:26.540 --> 01:14:27.040
Don't do that.

01:14:27.210 --> 01:14:30.840
Because it teaches people to click through the warnings, which is a bad idea.

01:14:31.090 --> 01:14:36.000
The other way around that is that you load a root certificate on your laptop or your device

01:14:36.320 --> 01:14:39.560
that has every certificate known or every possible certificate.

01:14:39.740 --> 01:14:43.360
So when you click on the link, it takes you there and it shows you the warning page.

01:14:43.390 --> 01:14:47.260
But now you've created a condition where if anybody has that certificate, they can spoof

01:14:47.580 --> 01:14:49.140
any website to you.

01:14:49.830 --> 01:14:52.280
So that seems like an additional security nightmare.

01:14:52.490 --> 01:14:53.940
So we've done neither of those two things.

01:14:53.990 --> 01:14:55.080
We just don't answer the question.

01:14:55.200 --> 01:14:58.540
We're like, nope, there's no response if something is bogus.

01:14:58.670 --> 01:15:02.040
But we do tag the response so that if you really know what you're doing, you can see it.

01:15:03.020 --> 01:15:03.240
Got it.

01:15:03.500 --> 01:15:04.720
Yeah, that's the end of all my questions.

01:15:05.000 --> 01:15:06.220
Thanks for entertaining me.

01:15:06.420 --> 01:15:07.400
You're brilliant to have on.

01:15:07.560 --> 01:15:11.120
And it's great to hear someone who just works in this and lives and breathes this.

01:15:11.290 --> 01:15:14.260
Is there anything you're excited about for the future that you'd like to share with people

01:15:14.440 --> 01:15:15.320
that you're following closely?

01:15:15.640 --> 01:15:16.880
I'm, again, sort of selfish.

01:15:17.080 --> 01:15:18.860
I'm looking at like our cases in France, right?

01:15:19.020 --> 01:15:22.160
Like we're really trying to figure out like what's the end goal?

01:15:22.280 --> 01:15:23.380
What's going to happen with the DNS?

01:15:23.640 --> 01:15:26.240
Is it going to be a controlled environment or is it not?

01:15:26.580 --> 01:15:28.980
And how do we make contingency plans?

01:15:29.070 --> 01:15:29.940
What if the answer is no?

01:15:30.560 --> 01:15:31.960
What if it becomes a controlled environment?

01:15:32.030 --> 01:15:32.940
How do we get around that?

01:15:33.000 --> 01:15:39.020
I went to a conference, I guess, two weeks or three weeks ago called D-Web Camp, the distributed web.

01:15:39.420 --> 01:15:47.200
And that is a really interesting group of people who are dedicated to figuring out ways of decentralizing the Internet again and making it more open.

01:15:47.540 --> 01:15:49.100
And so that gives me some hope.

01:15:49.320 --> 01:15:54.620
I think that there are some things that we can do in the DNS that create a more decentralized model.

01:15:55.100 --> 01:16:00.480
And I speak with a guilty look on my face because Quad9 is becoming a more centralized service, right?

01:16:00.550 --> 01:16:01.760
More people are using Quad9.

01:16:01.840 --> 01:16:28.580
It used to be that everybody ran their own recursive resolver. That's becoming really hard to do with encryption and some of the new relatively sophisticated things that DNS recursive resolvers should do or that they can do. It's harder to ask people around, like, you don't want to run a pie hole. People are becoming more resistant to that and they just want to outsource it. And with that, there are some risks. And so I'm really hoping that we can, again, there are ways that we can decentralize this and there are ways that hopefully we can remove the threat.

01:16:28.760 --> 01:16:33.460
I mean, what am I excited about from a technology perspective? I'm pretty hardcore nerd on the stuff

01:16:33.580 --> 01:16:38.380
that I get interested in. So I'm not, probably not a good, a good sample set, but, um, you know,

01:16:38.400 --> 01:16:43.440
I'm, I'm really into the, you know, how we're doing our backend telemetry. And like, for me,

01:16:43.520 --> 01:16:47.900
it's exciting to look at this massive network that quad nine has built and being able to,

01:16:48.020 --> 01:16:53.240
to see and use that data, like, you know, hundreds and hundreds of billions of messages a day,

01:16:53.720 --> 01:16:57.619
being able to process all of it and be able to get meaningful results out of it. That's actually

01:16:57.640 --> 01:17:01.520
what really excites me because that's sort of where we've gone. The fact that we can make money

01:17:01.640 --> 01:17:05.200
on it is kind of like a side benefit. Like, is that, Ooh, you mean we can, someone will pay us

01:17:05.200 --> 01:17:10.420
for this? This is interesting data, but I'm spending more time with policy and politics,

01:17:11.240 --> 01:17:16.320
which is not where I wanted to be. But it turns out that, you know, being the last unencrypted

01:17:17.640 --> 01:17:24.840
place where people can try to control content puts you in a vulnerable position. And so we need to

01:17:24.860 --> 01:17:29.840
make the protocol and the network more invulnerable to that kind of interception. We're working on it.

01:17:30.820 --> 01:17:34.080
Yeah. And I know it's a tough fight and I know a lot of people appreciate it, even if

01:17:34.560 --> 01:17:38.200
they're not always there to say so. I know a lot of people support you guys.

01:17:38.500 --> 01:17:42.700
We're desperately cash strapped as always. Donations are welcome. We're really looking

01:17:42.730 --> 01:17:48.160
for companies to step up and nations to step up who have belief in what we're doing because we

01:17:48.340 --> 01:17:53.400
can't keep doing this on, you know, I love everybody's individual donations. Donate what

01:17:53.420 --> 01:17:58.700
you can, but we really need to have large donors who believe in what this is and what it represents

01:17:59.360 --> 01:18:04.880
step up and help us fight to keep the internet open. Yeah. Well, thank you so much, John. You're

01:18:04.920 --> 01:18:08.340
always welcome back and it's great to have you back. I know we probably waited a little too long

01:18:08.380 --> 01:18:12.980
to bring you back, but if anyone has any questions, leave them down below. And how would you recommend

01:18:13.200 --> 01:18:19.260
people connect with Quad9? So I'll try to keep a look out on the comments and answer what I can for

01:18:19.320 --> 01:18:24.460
a bit. I would say take a look at our blog, quad9.net. We'll be revamping the website here

01:18:24.600 --> 01:18:28.820
shortly, but we'll be keeping things up to date on the blog. Great. Thank you so much, John.

01:18:29.160 --> 01:18:36.120
Thank you. And that is the interview with John Todd from Quad9. Again, this was a really good one,

01:18:36.120 --> 01:18:39.820
and I had a lot of fun getting into the little details there, if you guys couldn't tell.

01:18:40.160 --> 01:18:44.240
And so if you also enjoyed this, definitely make sure to give this podcast a rating.

01:18:44.720 --> 01:18:49.240
Try to leave a review if you can. Those really do help Discovery, as well as sharing it with

01:18:49.260 --> 01:18:53.940
people you know. And if you want to keep up with the latest threats and news without needing to

01:18:54.120 --> 01:18:57.920
create your own RSS feeds and keep up with all the stuff and making it a part-time job,

01:18:58.420 --> 01:19:02.740
that's my job to give to you. I'm supposed to be curating this stuff and keeping you all in the

01:19:02.800 --> 01:19:07.000
loop. And so if you want to follow what that looks like, you can just follow our newsletter,

01:19:07.360 --> 01:19:11.480
Surveillance Support, down in the description. And that's how you get just a weekly five-minute

01:19:11.680 --> 01:19:15.640
read of everything you need to know about around the world. And that also has an accompanying

01:19:16.020 --> 01:19:18.920
podcast if you want to just listen to our sister podcast, Surveillance Support.

01:19:19.360 --> 01:19:22.200
Thank you all for listening and I'll see you next time on TechCore.