What It Takes to Run a Free & Private DNS Service with John Todd from Quad9

DNS quietly reveals everywhere you go online - even on encrypted sites. In this interview, John Todd (CTO at Quad9) provides a DNS masterclass: how DNS works, the privacy implications, how to change your DNS, why Quad9 collects nothing on you, why they are being sued, DNS vs. VPNs, and how a nonprofit can fund itself without compromising privacy.

🔗 SOURCES & LINKS
• Quad9: https://quad9.net

⏱️ TIMESTAMPS

• (00:00) - INTRO
• (01:00) - WHAT IS QUAD9?
• (01:30) - HOW IS IT FREE?
• (02:48) - WHAT'S RECURSIVE DNS?
• (04:11) - DNS PRIVACY CONCERNS
• (07:19) - DEFAULT DNS PROVIDER + OPTIONS
• (09:15) - DNS ON iOS
• (11:02) - WHERE TO SET YOUR DNS
• (13:47) - CYBERSECURITY & PRIVACY
• (16:16) - WHAT'S BLOCKED
• (18:55) - CUSTOM DNS ON A ROUTER
• (20:11) - COMMON MISCONCEPTIONS
• (21:50) - HTTPS VS. TLS VS. QUIC
• (25:56) - RECOMMENDATIONS
• (27:20) - CENSORSHIP CIRCUMVENTION
• (30:01) - SNI & ECH
• (33:49) - LAWSUITS
• (40:45) - THE NUANCE BEHIND BLOCKING
• (42:23) - FOLLOW THE FIGHT
• (42:52) - THE QUAD9 TEAM
• (43:39) - OPERATION COSTS
• (45:34) - MONETIZING DATA?
• (50:25) - OTHER REVENUE MODELS
• (57:53) - WHY TRUST QUAD9?
• (01:00:39) - SPEED DIFFERENCES
• (01:06:32) - QUAD9 VS. DIY FILTERING
• (01:08:42) - VPN VS. DNS
• (01:13:08) - PI-HOLE
• (01:15:11) - LOOKING FORWARD
• (01:18:10) - HOW TO FOLLOW

🎥 VIDEO
Watch on YouTube

🧡 SUPPORT TECHLORE
Keep Techlore Talks independent & growing: ★ Support this podcast ★

Creators and Guests

Host

Henry Fisher

Runner, artist, musician and digital rights activist. Owner of Techlore

Guest

John Todd

Quad9

Editor

Tori

Techlore

What is Techlore Talks?

Techlore Talks brings you in-depth conversations with the experts at the forefront of privacy, security, and digital rights. Hosted by Henry Fisher, founder of Techlore and long-time digital rights educator, each episode features meaningful discussions with the people building, researching, and advocating for digital freedom.

From cybersecurity researchers and privacy tool developers to open-source advocates and digital rights activists—if they're shaping how we protect ourselves online, they're on this show.

Topics include: privacy tools and technologies, cybersecurity threats and defenses, open-source software, surveillance and digital rights, encryption, tech policy, and digital sovereignty.

New episodes released regularly. Subscribe and join the community at techlore.tech.

Whatever you're giving them, every single click, every page, every object on the web page,

they don't even need to know what websites you're going to.

They can actually figure it out through them.

How much can your ISP see about your web traffic?

Does encrypted DNS even mean anything if there are still parts of it that aren't quite as encrypted as they should be?

What's the difference between DNS over HTTPS versus DNS over TLS versus the brand new DNS over Quick?

What does a privacy-respecting DNS mean?

What even is a DNS?

Today, we are going to have pretty much a masterclass with Quad9 on DNS.

Now, this isn't actually necessarily structured as a formal masterclass,

but I think this interview itself really gets to the core of pretty much every major question right now in 2026

regarding privacy, security, DNS, censorship, circumvention, and really everything else you need to know all in one place.

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.

And now let's get to the interview.

Why don't you just intro Quad9 a little bit for people who don't know who you guys are?

So Quad9 is a nonprofit.

We're based in Switzerland.

And our mission is to give a basic cybersecurity and privacy protection to as many people as possible at no cost.

And so we do that by running a recursive DNS resolver located at 9.9.9.9, hence the name Quad9.

And we give that service away to everybody for free.

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?

Well, actually, the first question people ask is, what's recursive DNS? Because the tech folks know what that is.

Got it. So how do we give that away for free? So Quad9 has been around for about 10 years.

And we were founded and we've been essentially kept running by a combination of grants, sponsorships.

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.

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.

People think that we're doing the right thing and they give us money to do the right thing.

Not as many people as I would like, but we are still continuing on.

We've been going strong for 10 years and continue to expand.

Yeah, that's great.

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.

So we'll make sure we can dig into that more and what that looks like.

Now, if somebody is kind of new to this and kind of like what you were saying, what's recursive DNS?

Where do you normally start in explaining this to people?

I know you used a bit of a different analogy last time we had you on than what most people are used to.

Well, now you've put me on the spot.

I'm not sure if I'm going to use the same analogy or not.

So I'm going to go with what I think is most useful.

So basically the DNS is the equivalent of the phone book of the internet.

And that's kind of the most common analogy where your computer doesn't actually understand how to use names.

So when you type in www.amazon.com, your computer doesn't actually know what that means.

It doesn't know how to get to that server.

So what it does is that the first thing your computer does is it talks to a recursive resolver.

It takes that name, gives it to the recursive resolver, and what it's expecting back is an IP address.

And you've probably seen those or at least references to those, even if you're not a computer person at all.

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.

And so Quad9 replaces what typically is provided by your ISP or your school or whatever your organization is.

Usually there's a recursive resolver somewhere inside that organization that does this very simple job.

It's actually not very simple, but it does this mapping of names to numbers.

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.

We replace that.

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

You mentioned that you are trying to give people privacy through this service.

So what is typically the concern with maybe a default DNS?

And we'll talk about how people can maybe see what their default is.

But what's actually being collected?

What's the real concern here?

Right.

There have been great advances in the last 15 years or so with the encryption of web pages,

right? You see HTTPS encryption has been really, really moving forward quickly. And that's great

where people can't snoop on the actual content that you're looking at. For the most part,

there still are some unencrypted things, but for the most part, things are encrypted. However,

DNS has not been encrypted and that's actually been much slower to convert.

So if someone can actually look at the pointers you're doing, like in other words, if they're

looking at the names you're looking up, they don't even need to see the content. They can kind of

figure out where you're going and what you're doing. So whoever runs the recursive resolver,

you need to trust them a lot because whatever you're giving them, every single click, every

page, every object on the webpage you're looking at creates a name to number mapping. And if

someone's looking at all those and can associate that with you as a person, then they don't even

need to know what websites you're going to through looking at the content. They can actually figure

it out through the metadata. And so when Quad9 does that, when we do that as a service, we do not

collect any information about you, the individual. In fact, we don't even want to know who you are.

There's no signup. There's no username required. There's no identification that we ask for. So you

basically just change the resolver on your laptop or on your phone to Quad9, and that's all you have

to do. There's nothing else. There's no software. We don't track any unique identifiers. We are a

Swiss organization. And so we are bounded by extremely strict laws around what we can do with

data. So we don't simply say we don't collect your data. There are legal constraints about what we can

do with your data and we can't change our mind. Unlike a US corporation, which can at any time

basically say, well, you know what, we're doing something different with your data today and

good luck. We can't do that. And interestingly in Switzerland, and this is kind of the reason

And people ask, why Switzerland?

The penalties for us changing our mind and not doing what we say we're going to do, those

are actually criminal penalties.

They're not civil penalties.

In the United States or even in Europe, if you violate someone's privacy, there's civil

constraints, right?

There's a fine that you pay and maybe there's something that your company has to do to remediate

the problem.

In Switzerland, actually, our foundation council and potentially me and other directors, or

not directors, but other people in the company, we might go to jail.

So we have to do what we say we're going to do.

And so that's why the privacy guarantee with Quad9

is so much stronger than in other places.

Yeah, I think the analogy you used last time,

or it might be confusing interviews,

but it was a map that I remember.

Yep, I've used the map analogy as well.

Yeah, so I guess if people want to see that one,

the old interviews there, if they really want to view it.

And I think that's the one with Nate.

So if I'm kind of new to DNS,

and again, we'll get more technical in a second here,

but just for the people who are newer,

if I'm new to DNS,

It sounds like I already have a default DNS provider

that's being used on my computer, it's required,

and if I swap that to be yours,

I am getting better privacy

because you're not collecting all the data

my normal DNS would collect.

So how can someone see what their current DNS provider is

and what are their options?

Because I think there's you,

but do you have other DNS providers

that you think are also good to look into?

So let's start with how do you see it.

So typically in your TCP IP settings,

whether you're on Mac or Windows,

you have to kind of dig down into the settings.

Normally your DHCP service,

whether it's that your router at home

or whether it's your ISP or your enterprise router,

it's going to hand back to you

the IP address you should be using

for your temporary connection.

And when you sit down, open up your laptop,

you get an IP address, a default gateway,

and then also a DNS server.

And so those are typically automatically configured.

You can, however, statically configure it.

And the details of exactly how you do that,

we can go to our website

and we have configuration guides for Windows and Mac.

And for mobile devices,

it actually gets a little more complicated.

Android, it's actually somewhat simpler.

There's a feature in Android called Private DNS

and you can put in our settings in there.

In fact, some phones even come with Quad 9

basically as in a pull-down list.

And then iOS is the hardest one.

Interestingly, you can't actually see

what your DNS provider is in an iPhone or an iPad device.

They really hide that quite effectively

so that people don't stick their fingers in it,

which I think is unfortunate.

We have an MDM profile that you can load to override that.

And interestingly, the best way to override it is to go into your router at home.

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.

And it will then tell your iPhone to do the right thing.

So iOS is a little tougher.

And also Android, we have an app on the F-Droid store called Quad9 Connect, which you can download.

Not only will it not change the default on your Android device,

but it also gives you some stats, which is nice.

You don't have to have that app, by the way.

It'll work fine without it,

but having some statistics sometimes is nice.

Nice.

And then on the iOS side of things,

there are a few other DNS providers,

and they go inside the VPN section,

and they swap the DNS provider there.

Is there a reason you guys go for this profile approach?

Well, essentially, that's the same thing.

That is the method we're using.

So it's an XML blob that you download.

So it's more or less exactly the same model.

It's just that we distribute it as a text file.

There's nothing particularly fancy about it.

We're trying not to make other changes.

Like when you download our system as a VPN profile,

we're not trying to actually divert all your traffic.

We're just grabbing the DNS traffic

and sending that to our resolvers.

So I'm sorry that iOS is not a particularly clean method,

but Apple has not made that as easy as we would like.

Yeah, it's interesting because, you know,

Apple's done a lot of good stuff.

in some areas.

I think lockdown mode is very cool.

I think advanced data protection in iCloud is very cool.

But even with these really good features

that can prevent government-grade spyware,

Apple still hasn't documented and made it clear

when traffic actually goes through a VPN or not,

which for some threat models is pretty critical

if you think about it.

I like a lot of the stuff Apple's doing.

I give them credit for doing a lot of things the right way.

But it all still is within their sandbox.

They don't want traffic leaving their control.

There's an argument that they say, well, it's better and safer if Apple does all that.

I don't quite agree.

I think that people should have choice, more easily have choice as to where their data is

going and who protects it.

But that's a philosophical difference between Apple and my own views, I think.

And other platforms' views, too.

I think Apple is kind of the best at that right now.

A couple things to clarify, and then a couple more technical things that I know some of the

technical folks will appreciate.

So first, one of the things I get asked a ton is,

where do I set my DNS?

Now I know you kind of mentioned the system DNS,

but on the consumer end, they can change it in their browser.

The browser lets you change your DNS provider.

They can change it sometimes per program.

Some programs let you set a DNS inside just that program.

They can also set it on the operating system.

You mentioned the router even, so it would go through your router.

So it's confusing to a regular person.

So where do you normally start this conversation

to kind of ground people?

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.

We, of course, are interested in having end users use the platform.

We love having individual users figure it out, convert over, and start to use Quad9.

But quite honestly, that isn't where most of our users come from.

And the reason for that is complexity.

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?

I like Quad9.

I like what they stand for.

I like the fact that I get added security and privacy for my end users.

So I'm going to configure this on the router and everyone's going to get it.

And they're not even going to notice.

And that goes for sysadmins at small or medium sized companies and even some big companies, but not many.

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.

We're a very small shop, right?

So the smaller you are, the harder it is to make things very simple.

We don't do software.

We're not a software shipping organization.

We do services.

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.

And then the queries would use Quad9.

We have that for Android.

It works quite well.

But we don't have that for Windows.

We don't have that for Mac.

We don't have that for, you know, iOS is sort of a half measure.

And that's because of our size and the fact that we're a services company, we're not a

software company.

That said, again, most of our users are brought to us by somebody who's sophisticated, deciding

that they want to give the benefits to a group of people who aren't necessarily as sophisticated.

And those often are the people that need the protection, the cybersecurity protection,

which I haven't even talked about. They need that the most. And then privacy is sort of the second

most interesting thing that they have. So, you know, I'd say that under 10%, probably less of our

end users actually go in and configure this themselves. You know, 90% of our users, I'm going

to guess, are actually, they're using Quad9 and they don't even know it because someone is looking

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

on the cybersecurity stuff because it sounded like you wanted to get to that. Sure. Privacy is a big

reason for using Quad9. We don't collect user personal information. We don't collect IP addresses.

We never even write IP addresses to any storage mechanism ever. However, a lot of people don't

care as much about privacy. They care about sort of the opposite side of the coin, which is

cybersecurity. They don't want to be defrauded. They don't want to have botnets installed on their

laptops. They don't want to have phishing attacks. And they're trying to protect people, again,

who might be more vulnerable to this. Quad9 has the other party trick we have is that we have a

block list. On our primary service, 9999, we have a list, a rotating list of around roughly 4 million

different malicious domains that we keep rotating. These are supplied to us by about 35 or more

partners, mostly very relatively well-known cybersecurity companies who give us lists of

domain names that they know are malicious. So that's command and control systems, it's stalkerware,

it's phishing. If you try to look up one of those names on our system, we basically refuse the

lookup. We hand back what's called an NX domain. And we actually tag that with an indicator that

says, we gave you back a zero answer, a null answer, because this was a prohibited site.

This is a user choice. You can choose to use this blocking service or not. We actually have

different flavors. So 9999 has blocking enabled, 99910 does not. Most people choose the blocking

enabled service, because why not? So a lot of people, especially in, you know, not to generalize,

but in North America, as an example, and Western Europe, they're really interested in cybersecurity

component because we're giving away for free a service that typically costs quite a bit if you

were to try to build it yourself or to try to buy that service from somebody. We have what we think

is one of the best combinations of malware and other blocking that you can get. Privacy to them

is an extra. In other parts of the world, privacy is the primary reason and cybersecurity is an extra.

So it depends on who I'm talking to as to what the biggest interest is. But again, a small home,

right, where there's people who are not necessarily as technically capable, you get the benefit of if

you put that in the router, you're giving everybody in the home some protection against malicious

activity. It's not perfect, but you know what? It's free. So it's actually pretty good. The return

on investment is extremely high. And it actually is quite effective at blocking some of the more

common malware or phishing kind of activities. Do you guys have insight into like how much you

block on a daily basis? Yeah. What do you prevent? We have volumetric and geographic information

about where things are happening. And we've got a really cool map that shows that in real time on a

big globe. We call it the globe of wonder. We do around 600 million blocks a day. Now, what do they

mean? This is a problem that we've been struggling with for 10 years. What is the value of a particular

block event. Like how much can you assign a dollar value or euro value to a prevention of someone

going to a site? It's really hard, but I know there's value there, right? And it's probably

in the hundreds of millions of dollars a year where we're preventing people from being, again,

ransomware and phishing. We're preventing people from getting those sites, but you can't prove the

negative. Prove to me the money you're saving by having antivirus software on your laptop. Well,

that's hard to do.

Ty, you know, you guys are a nonprofit.

If you were like trying to get investors,

you're like, yeah, billions.

We've saved billions of dollars.

We'd make up some really fantastic numbers.

And the good news is we don't actually have to make it up

because the numbers are there,

but we don't, like Quad9 does not do threat analysis

in the kind of in-depth way.

We do a quarterly report.

Our director of threat intelligence

produces a great quarterly or triannual report

where we look at, we kind of take a sample and say,

what are the things we're protecting people against?

But we have an agreement with our threat intelligence providers that we're not trying to compete with them.

We're creating a parallel universe where people who couldn't ordinarily pay for this kind of protection get the protection.

So we don't really dig into their data.

We just take it as it is and we say, you know what?

If you're giving us data, we probably believe that it's going to be very effective.

We don't want to try to create a comparison where one threat provider is better than the other.

Because if we started to assign values to things, we'd get in that mode.

And we don't.

We love all of our threat intelligence provider.

They all give us great information and insight to protect our users.

So we don't do the kind of analysis that you would see in a for-profit company where they're

looking into each and every block and trying to figure out what the value is.

Or even in some cases, we don't even know what the classification is.

Although we can look at things and say, right, that's a phishing domain, clearly, because

it looks like a bank.

Or this is a command and control system because we can observe how it's being accessed or

attempted to being accessed worldwide.

So we can make some guesses, but we don't spend a lot of time doing that.

There's no payoff for that.

There's no one who cares.

I mean, we care, but there's no one who's giving us money based on the outcomes of that.

I'd love to take some of his funding who would.

That'd be great, but we only have a limited amount of funds to do things, and we're really

focused on protection rather than on analysis.

Yeah, I think it's a fair trade-off.

Just one quick question.

You mentioned setting up DNS on a router.

I know a very common issue nowadays is people have routers that don't let them change their DNS.

Do you have any quick alternatives for those people?

Or you just have to do it per device?

Get a different router.

That's true.

That's not an unreasonable thing to say.

If you have devices that do not let you configure basic things like setting your DNS server, you are the product.

That's your first key.

You are being treated as cattle.

Stop it.

Replace that device with something else that lets you have control.

Because the person who's running that device is treating you as a product.

And this is common, again, in large telcos where they harvest all of your data.

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.

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.

Don't let yourself get locked into equipment that doesn't let you change it.

Yeah, good advice.

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.

What's just some common misconceptions that you'd like to clear up?

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.

So is there something that you would just point to as an easy thing to clear up that you want people to know?

The biggest one is that DNS actually matters.

It's one of the most fundamental things on the internet, and most people have no idea that it exists or how it works.

And so explaining how it works, I've sort of done a little bit of that here, but not enough probably.

Understanding where things are and that they exist is an incredibly important component of any knowledge transfer.

Just like a card catalog in a library, without it, the library is kind of useless.

Same thing with the DNS.

If the naming system doesn't work or it's imperiled, then the knowledge itself is at risk.

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.

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.

Because most people just think that it'll always keep working and there's nothing that really can stop it.

Your library analogy is, I think, kind of perfect.

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.

HTTPS versus TLS versus now Quick.

Yes.

We don't need to go like crazy deep into this,

but if you could just kind of summarize the main options,

the differences between them

and what you kind of are pushing people towards now in 2026.

DNS until roughly 2017 was an unencrypted protocol using UDP.

No encryption whatsoever.

It's super easy to read on the wire.

In 2017, we were the first standards-based encrypted resolver,

meaning that you could actually encrypt the connections now between your client and our system

so that no one could observe them in the path.

That was with DOT, DNS over TLS.

That was the first standards-based protocol that we adopted.

Then quick on its heels came DOH, DNS over HTTPS.

And this was something that browsers understood.

So instead of using your operating system, the browser started to actually do DNS lookups.

And there's still some contention of whether that's a good idea or not.

But DNS over HTTPS was TCP-based and looked like a standard HTTPS connection.

Fast forward a little bit.

Now, in the last few years, we've seen a growing adoption of QUIC protocols, QUIC.

And these are over UDP.

And they have some significant advantages as far as speed, like starting up a connection

is faster, sometimes multiplexing things over the same connection is faster.

And so we've seen an emergence.

DOT used to operate, or still operates, sorry, on TCP port 853. DOH operates on TCP 443. So the

same port as regular HTTPS. But now we're seeing the conversion of both of those protocols to use

a QUIC underpinning, which is UDP based. And so now we see DOT becoming DOQ, DNS over QUIC.

That operates over UDP on port 853. So same port as DOT. So DOT and DOQ are very, very similar.

They use the same port except one's TCP and one's UDP.

And then DOH and DOH3, technically DOH2 and DOH3.

DOH2 is TCP on 443 and then DOH3 is UDP over quick over 443.

So those are now sort of the emerging standards for how end clients communicate with recursive resolvers.

Although that said, we're barely in some places breaking 20% of our traffic being encrypted.

And that's in the most aggressive areas where people are really pro encryption.

So we're not seeing a landslide of people moving to encryption.

We should be, but we're not.

And we've really got to work on that.

Again, this is actually an area that's interesting.

Apple actually really does a good job at this.

If you give an Apple device a recursive resolver answer like 9999, the Apple devices will actually

automatically upgrade to encryption without having to do anything.

And in fact, they'll not just upgrade to encryption, they'll upgrade to DOQ encryption.

So performance is really great.

We're trying to see what we can do to encourage

and provide some examples to other operating system vendors

and then also browser operators

so that they will automatically shift over.

Because what happens is people put in 9999 into their DHCP server

and then they never think about it again.

Going back and trying to type in an encrypted URL into your browser,

honestly, most people aren't going to do that.

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?

Oh, I can support encryption.

Let's convert to encryption.

Everybody should be doing encrypted recursive resolution if they can.

Again, for their own privacy, but also for things like integrity so that no one can modify or block your connections in the path.

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.

Quad9 supports all encrypted protocols, including some non-standards-based ones as well.

Yeah, I remember I had Carl on from Obscura on this podcast,

and he did a lot of chatting about Quick, especially because Obscura uses Quick.

And it was actually inspired by Apple using it for private relay

as kind of like a really novel thing that no one had really done before with a VPN, I don't think.

Well, it's a relay. It's confusing.

But just for someone listening, you gave out a lot of technical information.

Do you want to just give like bullet list,

max two things, pros and cons of each of these protocols

so people can kind of understand them

and what it means for them?

And also, what's your kind of your go-to recommendation

if somebody has to pick,

like they have something really customizable

that lets them use any of these?

Let's start backwards then.

I'd say if you have to pick,

I would go DOQ first, DNS over quick.

Then I would fall back to DNS over HTTP3,

which is also quick-based.

And the reason I'm saying those in that order

is because DOQ is probably slightly faster.

It doesn't have the overhead of HTTP,

which is a few more bytes in that packet.

Then HTTP3 is over UDP, so that's faster.

Again, it has those restart capabilities.

Then I would move down to DOT, DNS over TLS,

because again, it's lighter weight.

And then finally at the bottom of the list, DOH, DOH2,

meaning the old TCP-based DNS over HTTPS

would be my last choice.

And again, these are all for speed and complexity.

I'll also say that I'm somewhat selfish

Those are also, from our perspective, those are the ones that have the least amount of CPU load on our side.

And that's a question that we have to be aware of when you're looking at 120 million plus users on the system.

You've got a design for large numbers of these encrypted sockets coming in.

Yeah, another thing I've heard, it's something that Carl talked about and I've seen online.

People say that because DOH or DNS over HTTPS goes over the same port, it's a little bit harder to block.

So can you speak to the censorship circumvention of these technologies and if it matters?

Now we're getting to layer eight politics.

We took a fairly public stance in saying that DOH was not a great architectural design because it uses the same port as HTTPS.

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.

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.

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.

It makes security people's job a lot harder to have both the DNS and the content transmitted over the same port.

So yes, it is harder to filter. And our bigger concern was not necessarily even the enterprise

world, but it's the fact that if you make the people with guns very angry, they will shut off

the internet. And they have done that, right? There are many places now in the world where

internet interruptions or fragmentation is happening with a much more rapid pace because

the governments of those places have determined that they can't actually filter content.

And that's a really tough one to say what the results should be, because of course,

you want to have people get information, access to information that they wish. At the same time,

if you're accelerating the destruction of the internet by making it impossible to manage,

that's also a negative. So essentially by embedding both of these things in the same port,

you've created an inextricable linkage between the content and the metadata that makes it both

difficult to censor and it makes it difficult to censor. And so we have a slight preference

for DOT and DOQ because they operate on a different port. So you can stop the metadata

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.

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.

But it doesn't matter what we think, right?

The DOH is sort of the standard that everyone is moving to, DOH3 as well.

So that ship has sailed.

And we'll see the repercussions of that in the coming years.

And we already are seeing it in some places.

Got it.

Another technical thing.

You know, this to me has been presented as like, here's why DNS doesn't matter and you should never change it anyway.

And it's this whole concept of SNI and ECH.

Oh, yeah.

We don't need to spend a huge amount of time on this.

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.

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.

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.

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.

Well, ECH is turning that around as well.

And ECH is encrypted client hello.

And what that does is it encrypts the actual connection to the website.

So now everything is encrypted.

The DNS connection is encrypted because you're using DNS encryption.

The connection to the server itself is now encrypted because you're using ECH.

And now the content is encrypted because you're using HTTPS on top of that.

So there is no part of the transaction that is visible to an observer.

And there are some people who are getting pretty upset about that.

Yeah, I've actually seen the inverse.

there's been some videos that are like,

because of this situation,

then all your queries are getting exposed anyway,

so changing your DNS doesn't do anything,

which is kind of a take I've been seeing a lot so far this year.

Tell me, I'm not clear on that argument.

Explain that one in a little bit more detail.

I think the overall argument is,

even if you change your DNS provider to something like Quad9,

it doesn't really matter because you can't guarantee

that your SNI is actually using ECH.

Therefore, your queries are getting exposed anyway,

so it's useless. Don't bother.

That sounds like somebody

who's got an ulterior agenda.

But anyway, saying that you shouldn't encrypt anything

because at least one thing is unencrypted,

that seems pretty bogus.

I see it. It's people online,

so everyone will take things to extremes.

I don't know how many people actually have that kind of view on it,

but the internet can be a bit polarizing.

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.

We don't actually implement ECH, interestingly enough, not yet.

The reason for that is that it's obvious what you're doing when you're connecting.

There's two signals you can look at when you're looking at a packet.

You can look at the IP address of the destination,

and then you can look at the SNI to kind of figure out what's going on.

Even if we hit the SNI, you're connecting to 9.9.9.9.

Okay, there's only one thing that that IP address does, and that's DNS.

So SNI for us is not as meaningful.

We will probably implement it eventually,

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.

That's a bug and a feature at the same time.

Got it.

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.

So any site that uses Cloudflare automatically is accepting SNI encrypted.

Is that true?

I believe that's true.

I can't speak for Cloudflare, but I think that that's what's going on there.

They've been very strongly in favor of ECH.

Got it.

All right.

Now, I think we kind of have covered a lot of the basics, some of the technical things

that I know our audience is also going to want to hear as well.

Let's hear about what you guys have been up to.

I know we've kind of teased some things going on around the world.

So I'll let you kind of open this up with whatever's going on.

So in 2021, we actually moved to Switzerland in 2021.

We were previously a U.S. organization.

We moved to Switzerland in 2021.

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.

And so basically they were trying to force us to block those names.

They claimed just for Germany, but really they were effectively trying to block those names worldwide by going after us in German courts.

Long story short, but it's possible for someone in Europe to lodge civil cases against us in

Switzerland because of treaties with those nations. So it took two years and three appeals,

and we did actually win that case. It took a lot of money and a lot of our focus,

which we were very unhappy about because it really stopped a lot of things that we would

have liked to have been doing with that funding in that time. But we did win that case in Germany.

Basically, the courts eventually ruled that, no, this is an absurd thing, that blocking the DNS is

not going to actually stop the pirated site to begin with, because the DNS is an open book,

right? It's an open, you know, anybody can set up their own DNS server if they wish. They don't

need to use Quad9. Yeah, the precedent that that would set would be really bad.

And so the German courts ruled in our favor. So that's great. However, the same copyright cartel

of, you know, mostly the same people, but some new ones, they circled the wagons and they're now

going after us in France. So a number of organizations in France have lodged cases against

us where they're demanding that we block a variety, hundreds actually, of sites that they claim are

infringing on their copyrights. And we're sympathetic to the concept that copyright infringement is not

something that we encourage. It's absolutely not. We are in the business of making the internet a

more lawful place for individuals to prevent them from being defrauded or having crimes occur,

protecting both the network and the individuals. However, we also are in the mode of giving people

choice of what they do with their recursive resolution. Our goals are aligned with the end

user. And these organizations in France want to create basically a pipeline into our platform and

others. So it's not just us that's on this docket. It's a number of other DNS providers. They want

to create a pipeline that basically they can say, all right, we're going to block any site

that we feel like. We're going to tell you about it. And within a few minutes, you need to turn it

off from a recursive resolving perspective. This is really weird because it doesn't actually

prevent the site from existing. Anybody can set up a recursive resolver on their own. There's

free software. There are dozens of packages that you can download and run and let you run your own

recursive resolver. You don't need Quad9. It's just we're convenient and we're easy, but you don't

need us. So why are they going after us? Our typical thinking on this is because we're small,

we're a nonprofit, it's easy to go after us. The other companies they're going after are big US

tech companies, which in a lot of Europe are persona non grata. You know, there's definitely

a negative feeling towards large tech companies, which might be exfiltrating data about end users

to the United States. So we're getting lumped in with them because we're not big enough to really

hit them back as hard as we could, even though from a moral perspective, we're doing the right

thing. We're protecting the users of France, as an example, millions of them a day. Our goals are

aligned in some ways, trying to make a more lawful and safe internet, a more private internet. And

this doesn't make any sense. This is not going after the problem. This is going after

kind of a shadow. You're fighting the shadow on the wall of the actual events, which are that,

you know, there might be these copyright infringing sites, but don't, you can't get to them through us.

We have no relationship with them. We have no zero. We don't even know who they are.

Is a fair comparison, like if they were to go after browser vendors for letting you access these sites?

Yes. And, but, you know, careful there. That is actually exactly where I expect them to go next.

Yeah, I don't want to give them any good ideas.

Yeah.

Safe browsing does the same thing, right?

There's a block list in safe browsing.

Your Chromium and Firefox and a bunch of others have safe browsing built in.

And why would that be excluded?

It's going to be.

That's the fear here is that you're letting commercial entities decide what sites can

be seen and what sites cannot be seen.

That's a really bad precedent.

And so we're fighting these cases in France.

But again, we're not well positioned to do that except from a moral perspective.

But we certainly don't have the deep pockets that can be reached into for funding this.

We're looking for allies.

We're looking for sponsors.

You know, go to quad9.net and donate a few bucks to us if you'd like, because that's all

going towards helping us stay operational and do some basic defense in some of these

nations.

And we don't expect these problems to go away until there's a definitive ruling in Europe,

at least, that says the DNS is not an effective or useful place to do content filtering against

the wishes of the end user.

That was going to be my next question, so you beat me to it.

It's like, what's the upstream thing that you could tackle to make it so someone can't sue

over this kind of situation?

But you just kind of covered that there.

Has there been any progress on that?

Well, there was actually an interesting case earlier this, or I guess late last week that

I saw that I've not really digested entirely, which was interesting.

There's a VPN provider who was being sued because they were not blocking access to the

diary of Anne Frank.

Oh yes, I read this one. Yeah.

This is actually an interesting case and I really need to look at it more and talk to our legal team about it

because it does touch on some of the same aspects as DNS does, even though it doesn't sound like it.

So I have some hope that we will be able to get this decided at a higher level.

The DSA in Europe, which is kind of the overarching legislation,

my reading of it does actually explicitly say that DNS service providers are exempt from this.

However, you have to get to the European courts.

Right now we're in the courts in France.

We were in the courts in Germany.

And it may have been the case that we actually won that case.

And that was a strategic failure.

Like if we had been able to actually argue out of Germany and go up to the European courts,

maybe we could have had a result that would have been effective across all of the EU.

But we didn't.

We won the case in Germany.

I'm not saying I'm not, I'll take the win, right?

But like being able to get this up to the courts in the EU might be a useful thing.

I don't know.

We'll also take a win in France if we can get it.

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.

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.

We really do need to have this happen at the EU level.

And I'm not sure that we will ever be able to impress upon legislatures or courts that this is a bad idea.

It needs to have some legal teeth in it somehow.

Like just the court of public opinion is not enough here.

Right.

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.

But what's actually the nuance here and why some things are blocked and not others?

The nuance is that Quad9 provides choice.

We provide malware blocking as an optional setting.

You can decide that you want malware blocking or not.

We provide 99910, which has no blocking of any kind for users who want to experience the whole internet, malware and all.

When you're working in opposition to the end user, that's the problem.

When you are doing something that the end user does not want, what they're going to do is

they're going to simply say, you know what, quad nine doesn't do the thing I want.

I'm going to change to my own resolver.

Whatever minor effect you thought you were going to have by applying a block to quad nine,

that is going to be instantly lost as soon as it happens because the user can choose

other ways to do it.

So we try to work with the best wishes of the end user.

We try to work with their expectations and to their benefit.

I've not met anybody who said, I want to get ransomware on my computer. But there are people

who said, you know, I don't want your blocking service. And that's fine. 99910 is your choice.

Go ahead and make the decision. Giving the end user the ability to make the decision on their

own is where we create that distinction. When we have mandatory actions on a per nation basis,

which are incredibly expensive and difficult for us to apply, that becomes a real problem

where our mission does not, we're not achieving our mission.

And if people want to follow that fight, where would you send them to keep up with it?

Take a look at our blog. We're going to post things every once in a while. There are a number

of other plaintiffs in that case. Cloudflare and Google and Whalebone, I think, are typically

named in those. So all of us are trying to figure out how we're going to do this independently.

So no, I don't have a central source for that. There's been some discussion about how do we

create a centralized clearinghouse of information or public appeal, but none of that's in place yet.

Yeah, so in terms of you guys, you mentioned that you're a small organization.

How small? How many people are back there?

Less than 10.

And quite a few of those are contractors, so part-time.

Nice. And what's the setup there?

Is it mostly engineers? I assume some customer support?

Full-time, there's only one customer support.

Mostly, we've got, including myself, four engineers.

We've got GM. I'm the CTO officially now, which is great.

I have a general manager that's one of our foundation council members is acting as a general manager for a while.

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.

We've got some folks doing grants and fundraising as well, kind of paperwork on that side.

Yeah, you know, there's another, and I want to ask a little bit more about the business model here.

But this question is inspired by the free Firefox VPN they released that came with 50 gigabytes of free bandwidth.

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?

Is it more expensive?

And I figured I'd kind of throw you the same question.

You probably want as many people to be using Quad9, but does that increase costs for you guys?

It does.

My saying is, we lose money on every user, but we make it up in volume.

Yes, it does increase our costs.

But the incremental costs of new users coming onto the network is relatively low.

Here's why.

Quad 9 is a nonprofit, which gives us some really interesting magic powers.

And the magic powers are that people like what we do.

And so we have now roughly 200 locations worldwide where we actually have physical equipment installed or servers running.

And we don't pay for any of those.

So the space, the power, the internet bandwidth, that all gets to us at no cost.

That's because we bring protections both to the end user, but also to the network.

And so people are anxious to have Quad9 in their facilities where their end users can use us.

So what we have to pay for, though, is servers and people.

Those are the big costs from an operational perspective.

You know, how do we deploy more and more servers to more and more locations?

And then how do we pay for the people to maintain those?

And that's where our costs come in.

But the ongoing costs for the network are relatively small.

DNS, even over these new protocols, is relatively small.

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.

And so that's not in the relative scope of things today.

That's not much across 200 sites.

So the cost of bandwidth, unlike the VPN products where the bandwidth itself is the product, that's a different story.

But we don't, bandwidth is not our product.

It's really it's CPU and memory and staffing.

That's kind of it.

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.

Aggregate data, no, bad.

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.

Let me actually reference people to our privacy policy. We have one of the most extensive and

fully explained privacy policies that I've ever seen, and because we spend a lot of time on it.

So take a look at that. It explains what we cannot do. Now, let me give you some of the

things that we're trying to actually figure out how we'd monetize some of this. Because again,

we have massive user population now. We've got a lot of queries every day. Is there some way that

we can create a sustainable model that people are interested in some of the data outcomes,

some of the exhaust from this massive DNS network? And the answer is yes, and I don't think any of

them are objectionable. Let me give you the most obvious one that we talk about, and that's newly

observed domains. This is something that cybersecurity folks find really, really interesting.

When a new domain name starts to get used, basically when it first is registered,

somebody somewhere in our network is going to look it up, whether that's part of a threat campaign or

accidentally or whatever, there's going to be some event where we've never seen this domain name ever

before, you know, foo.com has just been registered and it's just admitted. That data, we don't think

is, it's really difficult to argue that that somehow is personally associatable with some

person. But what threat intelligence providers are interested in is when that exact moment happens,

like as soon as you see the new domain, they want to go out and look at it to make sure that it's

not malicious. Or does it even fit it? They don't even need to look at it. Just does it fit a pattern

of something? Does it have another, is it a brand impersonation? Is it somebody trying to

create a phishing domain with embedded host names somewhere in there?

Just to interrupt for a second, is what you're implying here that new domains are riskier than

maybe more established domains? Yes, they are definitely more risky. Definitely more risky.

Many, many, many domains, I don't know what the percentage is, but they'll appear and disappear

within a day or two. They get registered, they get used for phishing, or they get registered for

some other purpose, command and control systems, and then they're deregistered.

So having very, very rapid knowledge of new domain names as they come online is something

that threat intelligence providers are really interested in because they're going to then use

that to protect their customers. In many cases, they feed that back to quad nine. Basically,

as soon as they notice a new domain, they feed it back to us and we block it. So that we're trying

to monetize. That's basically, that's an aggregate data set that we have that people are interested

in that gives not just benefit to the companies that are buying it, but indirectly, and in some

cases directly, gives benefit back to our end users because new threats are identified much

more quickly. Yeah, my DNS resolver that I use, I want to ask about kind of the differences later.

But the way they deal with this problem is they just have an option like block all NRDs. So it

actually happens a lot on my end where someone sends me something that's brand new. They're like,

look how cool this is. And then I have to go see why it was blocked. And it's normally the NRD

filter that does it. The newly registered domains are newly observed domains is what we call them.

You're probably getting that list from a 24 hour filter. There's a, you can actually download some

of those things from some of the people that operate TLDs. And those are available in a 24

hour cycle. Some of these domains don't even make it to the 24 hour cycle. They get registered and

they get pulled within three hours because they get noticed as doing malicious activity. However,

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.

So names get registered, a bunch of people look them up, they get put into caches, the name gets deregistered,

but it still gets to be used as spam or as phishing for as long as those recursive resolvers keep it in their cache.

I thought they did it the inverted way.

I thought that they would look, oh, is this domain already in our systems?

Oh, it's not, therefore it is an NRD.

but you're saying they actually have to verify if it's an NRD on a different list?

There's a CZDS, I think.

I'm sorry, I'm not going to remember the acronym well.

But basically, you can get the newly registered domains delivered to you as a downloadable file every day if you qualify.

Basically, if you have a reason to get that.

And so a lot of threat providers get that data, but it's every day.

Then they look at those names, and then they decide whether they're going to block on them or not.

And probably the lists you're getting are, I'm going to guess, an outcome of those daily lists.

When a newly observed domain happens on our network, we can transmit that to our threat intelligence partners within about 15 seconds.

So the loop is really, really tight.

And you have to have that because these guys are getting much better.

The threats are getting much, much, much shorter in cycle.

So the faster, the better.

Yeah, sorry, I didn't mean to go on kind of a side trail there.

I was curious.

You mentioned a couple other revenue models that you might be exploring.

Yeah, so there's newly observed domains.

We basically can also provide to threat intelligence providers an idea of how bad something is going to be if they block it.

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.

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.

And a lot of that cycles through.

There's a lot of churn there.

You know, we've worked really hard with our threat intelligence providers trying to figure

out ways that they can improve the data that they give us.

Instead of just giving us a list without testing it, like, can they figure out, you know, are

there any false positives in here?

False positives are usually indicated by a couple of different metrics.

One is volume, like something gets a lot of queries.

It's okay.

You should probably look at that first.

But then also there are things like geographic distribution, host name distribution.

There are ways that you can look at a block and say, oh, whoops, we've blocked the wrong thing.

But it's too late at that point.

If you block it, we actually give insight to the threat intelligence provider.

When they give us a name to block, we actually give them telemetry back on every blocking event.

It's very rough data.

It's metropolitan area and then the FQDN.

And so this helps them improve their feeds, right?

So that's a sort of a virtuous loop here.

But the problem is that when they give us a block, it's too late.

The false positives are already in the system and we're already causing people pain.

And what we said, is there any way we can do this, which doesn't cause pain?

And so we have a model which allows threat intelligence providers to kind of do a virtual

block for a very short period of time, which allows them to see what would happen if they

committed this block to us or they submitted this to us as a block.

And so that's a product basically that we, that we offer.

And that's a, that's a four fee because it's actually improving their threat feed.

They're in turn reselling that threat feed to their downstream customers.

And that's great.

That's what we want.

We're actually fully encouraging that because it helps everybody's security.

But what we're trying to do is decrease the false positive rates and give them better insights.

Got it.

Are there any other things you're exploring or is it mostly those two?

The one last one that we have is the most powerful one.

And it's the most difficult one to describe.

We've had a lot of interest in people who are looking for brand protection kind of issues.

And this was the sort of the core of when we started to think about this.

They said, well, you know, I see in all the way in the left-hand side, we've got these

like domain names with 10 different zone cuts.

You know, it's foo.blah.bankofamerica.blah, blah, blah, blah.

Like there's a whole bunch of different zone cuts in here.

They want to know what's happening in the far left-hand side of the zone.

And they want to see when there's brand impersonation there, because that's the thing that catches

people, right?

They see a long host name that basically they only see the first part of it and it looks

like a legitimate site and they click on it and too late, you're trapped.

And so we have a model which allows people to put in strings that they're interested

in anywhere in the zone to be able to get back host names that look like brand impersonation

or domain impersonation.

And we've got actually a fairly powerful set of open source software we developed to do

just that.

If you go to our GitHub page, we have a platform called String Simile.

And what that is, is it's a combination of a whole bunch of different string matching

algorithms all combined into one big code base.

So you can say, I want to look for the string Netflix, but instead of eyes, let's say the

number one.

So in other words, it has confusables.

It has Cyrillic and IDN lettering so that if someone tries to make a name that looks

like something else, it catches that.

we have phonetic matching there's all kinds of different matching you can do

so that you can see when a new host name appears if it matches your brand and again this is in the

same model as the newly observed domains except that you're matching for a very specific set of

strings and you're doing it for all host names you're not just doing it for the domain name

you're actually matching anything in the dns that we see on a new basis we have like a 10 10 second

latency on that. So when a new name appears, or when a name changes, we can run that through the

filter and get a result within a few seconds. So to summarize that is what you're saying,

if I am a well-equipped organization, I care a lot about like, let's say I'm Apple, I'm Google,

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

E. These are the most basic versions of these. I know these get very sophisticated. They would

pretty much become your clients. And then you would pretty much have individualized brand protection

for them. Right. They tell us what the strings are that they're looking for, you know, roughly.

And then we can match on that against this giant fire hose of changes that we see and give them

the insights when those domains are matched or when those strings are matched. This allows them

to understand what's happening in a brand lookalike. In this same vein, there's another interesting

product that we've been kicking around that we actually haven't named yet. I'll pull the veil

back a little bit. But there's another one that we've actually found is quite interesting. And

that is that most big domain name operators don't actually know what's in their zone.

They have no idea. Big Fortune 500 companies subdelegate out everything inside their zone

down to regional offices. And then that regional office dedicates some out to a lab.

And then the lab might use a commercial provider to do a CDN test. And so the people at the very

bottom of the network of the namespace, they actually don't know all the things that's in

their own zone, especially if you're allocating out to CDNs or third parties. We do. We can actually

tell you what's in your zone because chances are high that almost everything in your zone has been

looked up on quad nine somewhere. So that's a product we've been kicking around in the same

space, but it's actually basically telling you what's in your own zone. It sounds like a ludicrous

thing, but it actually is quite interesting because the larger you get, the less, you know,

DNS is a decentralized protocol and you don't know what's going on. And so there are really

interesting compliance issues there, cybersecurity issues there that we can help those zone operators

answer, especially in the bigger zones. You know, all of these so far that you shared,

like the first three, to me, again, correct this if I'm wrong, they all seemed like technology that

you guys have developed to fix a problem. But that fourth one almost sounds like it could be a scale

because you've gotten large enough, you can then supply that service? Or am I misunderstanding?

No, no. Well, you're right on both counts. The NOD is definitely a scale question because you need

to have fast response. You need to have a lot of people on the network to get those newly observed

domains quickly resolved. Same thing. You have to have scale and you have to have the technology for

being able to test for false positives. And this last one is both, again, scale and technology.

You need to have lots and lots of users on the network to churn through all the names in the namespace.

And then you have to have the ability to be able to process that at scale is also quite significant.

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.

And we've actually developed some code for that that we've, again, contributed back to various open source repositories.

So we think we're doing the right thing with both the data and the methods that we're collecting it.

Very cool.

I feel like the way that I see DNS talked about a lot,

and even I sometimes say this too,

is it's in a way kind of like a VPN

in the sense that you're shifting trust.

Instead of trusting your ISP's DNS,

you now trust Quag9 or whatever other DNS provider.

So what do you normally say when people ask,

why should I trust you?

I know we've kind of covered a lot of the reasons why in the interview,

but how do you signal trust to people?

Totally reasonable question.

First one is kind of a non-event.

Why would you trust us?

We don't actually know who you are.

Meaning that there's no signup, there's no association that we have with you as a person

with the lookups you're doing. Even if we didn't do anything we said we were going to do,

there's no mapping of your IP address to you. And we don't collect the IP address either.

So, but that's the second reason you should trust us. Reason number two to trust us is again,

because of the constraints that we have put upon ourselves. The legal constraints by being in

Switzerland, really the ironclad guarantee of privacy that we have that's not backed up

just by fines. It's backed up by going to jail if we don't do what we say we're going to do.

And that was the whole reason that we chose Switzerland as a destination to move to,

because we had to put our money where our mouth was. The third reason you should trust us is that

we have no incentive for you not to trust us. There is nothing that we have other than your trust.

There is no, I mean, we have cybersecurity, right? We do give away that really nice service,

but that would be nothing if people thought that we were collecting their data.

So really, we have to have people's trust because the friction of leaving Quad9 is the same as coming in.

Zero.

If you don't like what you get, there is nothing keeping you here.

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.

We're a nonprofit.

We're not a CDN.

We're not a marketing company.

We don't do any of those things.

So the only thing we have to barter with is your trust and the safety we give to our end users.

So we're very, very concerned that people understand that we do value privacy.

Like I can't speak for the rest of my staff, but most of us are privacy zealots here.

We're not doing this for money.

We're not getting paid particularly well.

Working for a nonprofit, it pays the bills, but there's no stock options.

There are no Ferraris and driveways here.

We're doing this because we believe in what it is that we do.

Everybody in the team believes in what we do.

And we think we're making the world a slightly better place.

Yeah, period.

I'm going to call this the for Henry's interest only section

just because I had a few questions come up

that I think are very much for me.

But I know that other people listening are going to have them too.

So I know it's helping others.

But this is a very bare bones question.

I think I've actually heard the answer before,

but maybe it's different how you guys do it

or maybe my understanding is wrong.

Let's say someone's deciding between getting malware blocking or 9.9.9.10 without the malware protection.

Is there a speed difference there?

Does the filtering itself have a difference on latency and speed?

Weirdly enough, well, no, I'm sorry.

No, there is no difference.

There is no noticeable difference.

There is a noticeable difference with 9.9.9.11.

I almost got the wrong question there.

So 9999 and 99910, you will not notice a difference because it's relatively short.

We actually notice a difference because there's less CPU usage and less memory usage.

But from the end user's perspective, no.

For 99910, there's a slightly lower memory and CPU use, but there is no easily measurable difference between the two of them.

99911 is a different service, which does have blocking.

but it also includes what's called ECS, which is EDNS client subnet. And that is a slightly

different service because there are, do you know about ECS? Do you want to do the whole? Okay.

Excellent. So 9999 is exceptionally private. We pass no information about the end user

to the authoritative server that we're asking the questions to. So if you look up amazon.com,

we ask Amazon servers for the IP address that they're giving and you get it back.

Now, we have 200 locations around the world.

That means that relatively close to you, there's a Quad 9 location.

And you're going to connect to that and you're going to ask it for www.amazon.com.

Amazon is going to give you back a different answer based on where they think you are.

So if you're in San Diego, you're going to get back probably on a Los Angeles-based cluster of Amazon servers.

In other words, the IP address that Amazon gives back to you or gives back to Quad9 that we then

give back to you is going to be an LA-based cluster of systems. Let's say for some reason,

and this does happen on occasion, you're in an island nation where Quad9 does not have a server.

You're coming from Kiribati. So the closest Quad9 known to Kiribati, let's say that's Los Angeles,

even though from a distance perspective, Sydney would be much closer to you to get an Amazon node.

there's a problem here. So you're going to be in Kiribati. You're asking for amazon.com from a

Quad9 cluster in LA. You're going to get back the LA number, IP address. But in fact, that's going

to give you a really terrible performance based on what you could be getting otherwise. So Amazon

would prefer it if Quad9 sent information about you, the individual, to Amazon when we make the

question to them. We, however, would prefer not to send you that information or send them the

information. So in other words, Quad9 is extremely private. We don't send anything about the end user

to the authoritative server. That's our default service, 9999 and 99910. In some cases, it does

make sense for us to leak information about the end user to the authoritative server in order to get a

more performant end result. This is what ECS does. So services like Google, even though you don't

know it, every time, if you're to use Google's recursive resolver, 8888, when you make queries

to it, they send the first three octets of your IP address to the authoritative server.

We don't think that's a good idea. And so we don't do that, but Google does. And so to their credit,

they get back probably more geographically accurate results more of the time than we do,

but they also have a privacy leak. We provide 99911 to provide that exact service.

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.

But you can choose to get more geographically proximate addresses by giving up some of that privacy to the authoritative server.

That is slightly slower.

The reason for that is that every slash 24 has to keep its own little version of the cache.

Like you in San Diego are going to have, you're going to get answers back for the same Amazon

network, but everyone in your slash 24 is going to get the same answer.

So that means we have to fragment our cache into a million different little tiny shards.

So just by kind of by default, the answers are going to be slower because there are lower

chances of those being cached.

The chances of someone asking for amazon.com in your same slash 24 are much, much lower

than on a citywide basis, which is what we have with 9999.

So you kind of mentioned the reason to do this is it could be faster for you, but then you mentioned it's slower.

So where is this slower?

Where is it faster?

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.

Correct.

That's right.

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.

But if they're using Quad9 and we don't have a node in that nation, they're basically going to be mismatched.

They're going to be querying a location that doesn't have the CDN facilities.

So this is kind of our push.

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.

We're not big fans of ECS because, again, we're more privacy focused than we are performance focused, quite honestly.

I mean, there are places you can make lots of tradeoffs if you're willing to give up privacy.

we're not but we give the users the option in that the dns query might be slightly slower but the

streaming video or the download of the website might be a lot faster so that trade-off might

be okay to them and we let them make that decision themselves makes sense yeah i think that's that's

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

sharing uh i guess something about me so i'm still like doing filtering with next dns i really like

customizing things in my own portal a lot.

And that's what I use personally.

How does that DIY,

I want to filter everything,

get down and dirty,

how does that compare to maybe,

I know obviously you guys,

I don't think do any kind of

privacy-based blocking on Quad9,

but how would you compare those approaches?

What's actually going on behind the scenes?

What do you normally recommend to most people?

And why do you guys not have a service like that?

Well, let me ask the last question first.

We don't have a service like that

it's very expensive to do that. There's a lot of user interface. There's a lot of construction of

a tooling set that would allow people to get that flexibility. And again, we focused primarily on,

again, privacy and baseline cybersecurity. For people who want more advanced services,

there are other things in the market. Our goal is not to take over the DNS world. That's not our

goal at all. We don't want to be all things to all people. We might do further expansions in the

future with different things that we're going to do, meaning that there might be some slow and

steady advances in our feature set. But our mission is not to own the DNS market space. That's

totally not what we're interested in. But the DIY set that are interested in doing that,

there are things like NextDNS that do this as a service. How they treat privacy and security is

between you and them. What we would really recommend people do is set up your own server,

piehole, right? If you don't like what you see and you want to have even more advanced filtering

with ad blocking and notifications and statistics,

set up your own forwarding cache,

embed all those rules into that,

run it in your home or run it in the cloud even,

run it somewhere else and point to it,

and then forward the queries from that to Quad9.

So in other words, you can still get all the benefits of Quad9,

but you can put another layer in between your clients,

your web browser or your computer and Quad9

that does a whole bunch of other stuff

that will get you more or less what you're getting

with a commercial provider, but at no cost and with complete confidentiality, meaning you run

that service yourself. That's the DIY answer. Most people can't or won't do that. And so we

understand that. To date, that's not been where we've targeted our efforts.

Got it. Thanks for sharing. Something I hear a lot about is VPN versus DNS.

And I think the most common safe advice to give is just use your VPN's DNS resolver.

If you trust them with your web traffic,

it probably makes sense to trust them with your DNS traffic.

I, for one, don't like doing that

because I like my NextDNS filters that I've set up.

I normally always try to find a way to combine both of them.

But my understanding is that can add latency.

That part I don't quite understand.

I think somehow you have to contact a DNS server resolver

and it's different from the VPN server.

Anyway, this is all to say,

do you ever recommend using Quad9 for VPN users?

Or do you think they should use their DNS resolver?

Or how do you look at this situation?

There's two arguments, right?

There's diversifying your trust,

meaning if you trust Quad9 with your DNS

and you trust your VPN with your transit data,

you're basically separating

two different streams of information.

You're separating them apart from each other.

You increase your risk

that one of them might try to collect some of it.

But as an example,

if you're coming out of a VPN

and using Quad9,

we're not going to even see your home IP address.

So even in the most spectacularly

corrupted world where we're trying to collect information on people, we wouldn't be able to do

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

could not, it would be really difficult for me to imagine how we would not be able to be trusted

with data coming out of a VPN. However, I can see how the VPN would actually collect both

data sets from you. And you have to really pick your VPN provider carefully because there are a

lot of VPNs out there that are not what they seem to be. The free ones are especially concerning,

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.

But are you getting the additional benefits of the cybersecurity?

Probably not.

And are there latency issues?

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.

We all share the same big inter-exchange locations.

We're all within a few milliseconds of a big IX somewhere, whether that's Frankfurt or United States or Singapore or whatever.

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.

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.

Meaning you don't have to send the traffic all the way through the VPN and then all the way back.

If you're getting them right there from a box that's sitting in your home network, that's faster.

So I guess it's kind of a wash from a trust perspective between the two.

The reason that I tell people to use Quad9 is because you're not always using your VPN.

Sometimes you turn it off and you're using your native ISP.

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.

9.9.9.9 works anywhere in the world and it's really fast.

Your VPN provider's DNS server, you might not even be able to get to it if you're not on the VPN.

So then you have to go through and fix it or they have to have software that goes through and, you know,

adds it or removes it to your DNS server list.

It just adds complexity.

But it's a wash.

It's going to depend on your level of technical competence.

But from a privacy perspective, as long as you have a trustworthy VPN provider, not a big deal.

Yeah, the two VPNs I think of that are doing some interesting stuff.

I know that IVPN has a feature,

and I'm not saying they're the only one.

I know IVPN has a feature where you can keep your DNS

that you set in IVPN enabled,

even if you're disconnected from IVPN.

So let's say you set Quad9 in IVPN,

but it's like, oh, I want to turn it off.

Quad9 is still set as the DNS resolver,

which I think is a really good fallback.

And then Mulvad, they do host their own filters,

kind of like what you guys do for 9.9.9.9.

So I don't know if you have any opinions on those

for people who like Mulvad.

I don't know if you've played with those.

They have more of privacy-based filters as well.

I've seen Molvad's filters.

They actually post them on, I think it's GitHub.

And so, yeah, they're giving some added benefit.

Is it as extensive as Quad9?

No, it definitely is not.

But it's still, from a privacy perspective,

I'm sure that they're doing the right thing.

In general, I've heard good things about Molvad's dedication to privacy.

So I really have not a lot of insight there,

but I'm sure it's useful for whatever context you are looking for.

Have you looked at PyHole?

I have.

And it's one of those things that it's like,

is it worth the complexity for me?

And I just haven't done it yet.

But honestly, even for content and for an experiment,

I really should have done it by now.

I mean, so many people in my life have recommended it to me.

Yeah, it's pretty nice.

There's some extensions that they've got in there

that actually are custom for Quad9.

So if there's a block event that we hand back to you,

they actually tag it as a malicious activity in their logs.

Whereas if we block something for you

and you're just looking at it in your browser,

you're just going to see a 404 not found.

Or actually, that's not even true.

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.

Nice. Does it have to intercept the SSL cert to do that?

Nope. No, it's actually looking at the DNS response.

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.

And so pie hole has the ability to look at that.

We don't actually ever hand back an IP address.

That's what you're talking about when you're talking about SSL.

Like some blocking DNS providers will actually hand back an IP address when it's a block.

And that means your browser has to go to some other site.

And of course, the cert is never going to match.

So you're going to get a pop up that says your connection is being intercepted.

And that's terrible.

That's a terrible, terrible model.

Don't do that.

Because it teaches people to click through the warnings, which is a bad idea.

The other way around that is that you load a root certificate on your laptop or your device

that has every certificate known or every possible certificate.

So when you click on the link, it takes you there and it shows you the warning page.

But now you've created a condition where if anybody has that certificate, they can spoof

any website to you.

So that seems like an additional security nightmare.

So we've done neither of those two things.

We just don't answer the question.

We're like, nope, there's no response if something is bogus.

But we do tag the response so that if you really know what you're doing, you can see it.

Got it.

Yeah, that's the end of all my questions.

Thanks for entertaining me.

You're brilliant to have on.

And it's great to hear someone who just works in this and lives and breathes this.

Is there anything you're excited about for the future that you'd like to share with people

that you're following closely?

I'm, again, sort of selfish.

I'm looking at like our cases in France, right?

Like we're really trying to figure out like what's the end goal?

What's going to happen with the DNS?

Is it going to be a controlled environment or is it not?

And how do we make contingency plans?

What if the answer is no?

What if it becomes a controlled environment?

How do we get around that?

I went to a conference, I guess, two weeks or three weeks ago called D-Web Camp, the distributed web.

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.

And so that gives me some hope.

I think that there are some things that we can do in the DNS that create a more decentralized model.

And I speak with a guilty look on my face because Quad9 is becoming a more centralized service, right?

More people are using Quad9.

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.

I mean, what am I excited about from a technology perspective? I'm pretty hardcore nerd on the stuff

that I get interested in. So I'm not, probably not a good, a good sample set, but, um, you know,

I'm, I'm really into the, you know, how we're doing our backend telemetry. And like, for me,

it's exciting to look at this massive network that quad nine has built and being able to,

to see and use that data, like, you know, hundreds and hundreds of billions of messages a day,

being able to process all of it and be able to get meaningful results out of it. That's actually

what really excites me because that's sort of where we've gone. The fact that we can make money

on it is kind of like a side benefit. Like, is that, Ooh, you mean we can, someone will pay us

for this? This is interesting data, but I'm spending more time with policy and politics,

which is not where I wanted to be. But it turns out that, you know, being the last unencrypted

place where people can try to control content puts you in a vulnerable position. And so we need to

make the protocol and the network more invulnerable to that kind of interception. We're working on it.

Yeah. And I know it's a tough fight and I know a lot of people appreciate it, even if

they're not always there to say so. I know a lot of people support you guys.

We're desperately cash strapped as always. Donations are welcome. We're really looking

for companies to step up and nations to step up who have belief in what we're doing because we

can't keep doing this on, you know, I love everybody's individual donations. Donate what

you can, but we really need to have large donors who believe in what this is and what it represents

step up and help us fight to keep the internet open. Yeah. Well, thank you so much, John. You're

always welcome back and it's great to have you back. I know we probably waited a little too long

to bring you back, but if anyone has any questions, leave them down below. And how would you recommend

people connect with Quad9? So I'll try to keep a look out on the comments and answer what I can for

a bit. I would say take a look at our blog, quad9.net. We'll be revamping the website here

shortly, but we'll be keeping things up to date on the blog. Great. Thank you so much, John.

Thank you. And that is the interview with John Todd from Quad9. Again, this was a really good one,

and I had a lot of fun getting into the little details there, if you guys couldn't tell.

And so if you also enjoyed this, definitely make sure to give this podcast a rating.

Try to leave a review if you can. Those really do help Discovery, as well as sharing it with

people you know. And if you want to keep up with the latest threats and news without needing to

create your own RSS feeds and keep up with all the stuff and making it a part-time job,

that's my job to give to you. I'm supposed to be curating this stuff and keeping you all in the

loop. And so if you want to follow what that looks like, you can just follow our newsletter,

Surveillance Support, down in the description. And that's how you get just a weekly five-minute

read of everything you need to know about around the world. And that also has an accompanying

podcast if you want to just listen to our sister podcast, Surveillance Support.

Thank you all for listening and I'll see you next time on TechCore.