Learning DNS in 10 Years

You all got this zine (How DNS Works) in your swag bags — thanks to RubyConf for printing it!

But this talk is
not really about DNS. I mean, this is a Ruby conference, right? So this talk is
really about learning hard things, and DNS is an example of something that was
hard for me to learn.

It took me maybe 16 years from the first time
that like I bought a domain name and set up my DNS records to when I really
felt like I understood how the system worked.

And one thing I want to say at the beginning of this talk, is that I think that
taking like 16 years to learn something like DNS is kind of normal. The idea
that “I should understand this already” is a bit silly. For me, I was doing
other stuff for most of the 16 years! There was other stuff I wanted to learn.

And so, this talk is not about how you should learn about any particular
thing. I don’t care if you learn how DNS works! It’s really about how to
approach learning something hard that’s a priority for you to learn.

And so what’s DNS really briefly? DNS stands for the Domain Name System. And
every time you go to a website like www.example.com, your browser
needs to look up that website’s IP address. So DNS translates
domain names into IP addresses. It looks up other information about domain
names too, but we’re mostly just going to talk about IP addresses today.

I want to briefly sell why I think DNS is cool, because we’re going to be
talking about it a lot.

One cool thing about DNS is that it’s this invisible system that controls the
entire internet.

Next I want to talk about spying on DNS, which is one of my favorite ways to
learn about things.

I’m going to talk about two spy tools for DNS: dig and wireshark.

dig is a tool for making DNS queries. We talked about you know, how your
browser needs to look up the IP address for maps.google.com. We
can do that in dig!

When we run dig maps.google.com, it prints out 5 fields. Let’s
talk about what those 5 fields are.

But I think that the funniest field in a DNS record
is this field in the middle, IN, which stands for INternet. I guess in 1987, they thought that we might be on a lot of
different networks. So they made an option for it. In reality, we’re all on the
internet. And every DNS query has class set to “internet”. There are a couple of
others query classes (CHAOS and HESIOD), which truly almost nobody uses.

We can also kind of poke around on the
internet with Dig. We’ve talked about A records to look up IP addresses.

Oh, the other thing about dig is that by default, dig’s output looks like
this, which is very ugly and unreadable. There’s a lot of nonsense here.

So dig has a configuration file, where you can put +noall +answer and
then your dig responses look much nicer (like they did in the screenshots
above) instead of having a lot of nonsense in them. Whenever possible, I try to
make my tools behave in a more human way.

The other thing I want to talk about is Wireshark, which
is my favorite computer networking tool in the universe for spying on
all things computer networks. In this case, DNS queries. So let’s go look at
Wireshark.

When we make a DNS query like this and look up example.com, Wireshark can capture it.

When you
start looking in the guts of things, I think it can be a bit scary at first. Like
what do all these numbers? It kind of seems
like a lot. So when I’m looking at something new, I try to start by looking at stuff
that I understand.

For example, I know that example.com is a domain name,
right? So we should able to use Wireshark to go find that domain name in the
DNS query. If we click into the “query” part of the DNS packet, we can see 3
fields that we recognize. First, the domain name.

We can also see the type (“A”)

And the third one is the class which
is INternet, which is always the same. What I find comforting here is that in
the query, there are really only 2 important fields: a DNS query is just saying “I want
the IP address for example.com”. There’s just two fields. And that that always
makes me feel a little bit better about understanding something.

A quick caveat: your browser might be using encrypted DNS and spying on your
DNS queries with Wireshark will not work if your DNS is encrypted. But there’s
lots of non-encrypted DNS to spy on.

The second thing I want to talk about for learning new things is to
notice when you’re confused about something.

I want to tell you a story, “the case of the mysterious caching”, of something
that happened to me with DNS that really confused me.

First, I want to talk to you a little
bit about how DNS works a little bit more. So on the left here, you have your
browser. And when your browser makes a DNS query, it asks a server called a
resolver. And all you need to know about the resolver is that it’s cache, which
as we know is like the worst thing in computer science. So the resolver is a cache,
and it gets its information from the source of truth, which has the real answers.

So your browser talks to a resolver, which is a cache.

At the time of this story, I had this mental model for like how I thought about
DNS, which is that if I set a TTL (the cache time) of 5 minutes when configuring my DNS records,
then I would never have to wait more than five minutes. Something you need to
know about me is that I’m a very impatient person. And I hate waiting. So this
model was mostly working for me at the time, though there are a few other very
important caveats that we’re not going to get into.

But one day I was setting up a new subdomain for some new project. Let’s say it
was new.jvns.ca. So I set it up. I made its DNS records, and I refreshed the
page. And it wasn’t working. So I figured, that’s fine, my model says, I only
have to wait five minutes, right? Because that’s what I was used to. But I
waited five minutes and still didn’t work.

And I was like, oh, no. My mental model was broken! I did not feel good.

And often when this happens to me, and I think for most of us, if something
weird happens with a computer, you let it go, right? You might decide okay, I
don’t have time to go into a deep investigation here. I’ll just wait longer.

But sometimes I
have a lot of energy, and maybe I’m feeling mad, like “the computer
can’t beat me today”! Because there’s a reason that this is happening, right? And I
want to find out what it is. So this day for some reason. I had a lot
of energy.

So I started Googling furiously. And I found a useful comment on Stack
Overflow.

The Stack Overflow comment talked about something called negative caching.
What’s that?

So my next question was: how long do I have to wait for the cache to expire?
This brings us to a another learning technique.

I think like maybe the
most upsetting learning technique to me is to read a very boring
technical document. I’m like very impatient. I kind of hate
reading boring things. And so when I read something very boring, I like to
bring a specific question. So in this case, I had a specific question, which is
how long do I have to wait for the cache to expire?

So I found this document called RFC 2308. In section 3, it has this very boring
sentence, the TTL of this record is set to the minimum of the minimum field of the
SOA record and the TTL of the SOA itself. It indicates how long a resolver may
cache the negative answer.

Let’s look at what happens when we run dig +all asdfasdfasdfasdfasdf.jvns.ca

It says that the domain doesn’t exist, NXDOMAIN. But it also returns this
record called the SOA record, which has some domain metadata. And there are two
fields here that are relevant.

In this case, both of those numbers are 10800. So that’s how long have to
wait. We have to wait 10,800 seconds. That’s 3 hours.

And so I waited three hours and then everything worked. And I found this
kind of fun to know because often like if you look up DNS advice it will
say something like, if something has gone wrong, you need to wait 48 hours. And I
do not want to wait 48 hours! I hate waiting. So I love it when I
can like use my brain to figure out that I can wait for less time.

I want to say briefly that there’s a solution to this negative caching problem.
We talked about how like if you visit a domain that’s nonexistent, it gets
cached. The solution is if you haven’t set up your domain’s DNS, don’t visit
the domain! Only visit it after you set it up. So I’ve learned to do that and
now I almost never have this problem anymore. It’s great.

The next thing I want to talk about is doing experiments.

So let’s say we want to do some experiments with caching.

I think most people don’t want to make experimental changes to their domain
names, because they’re worried about breaking something. Which I think is very understandable.

The way this works is you get a little subdomain. This one is
chair131.messwithdns.com. And then you can make DNS records on it and try
things out. Here we’re making a record for test.char131.messwithdns.net, with
type A, the IP 7.7.7.7, and TTL 3000 seconds.

What we would expect to see is that if we make a query to the resolver, then it
asks kind of like the source of truth, which we control. And we should expect
the resolver to make only one query, because it’s cached. So I want to do an
experiment and see if it’s true that we get only 1 query.

So I’m going to make a few queries for it, with dig @1.1.1.1 test.chair131.messwithdns.com.
I’ve queried it a bunch of times, maybe 10 or 20.

We can also do the same experiment, but ask Google’s resolver, 8.8.8.8, instead
of Cloudflare’s resolver.

And we’re seeing a similar thing here to what we saw with Cloudflare, there are
maybe 4 independent caches.

We could also do an experiment with negative caching, but no, I’m not going to
do this demo. Sorry. I could just see it going downhill. The problem is that
there’s too many different caches, and I really want there to be one cache, but
there’s like seven. That’s fine, let’s move on.

Now I’m going to talk
about my favorite strategy for learning about stuff, which is to
write my own very bad version of the thing. And I want to say that writing my
very bad implementation gives me a really unreasonable amount of confidence.

So you might think that writing DNS software is complicated, right? But it’s
easier than you might think, as long as you keep your expectations low.

To make the DNS queries, the first thing we need to do is we need to
make a network connection. Let’s do that.

These four lines of Ruby connect to 8.8.8.8, the Google DNS resolver, on UDP
port 53. Now we’re like halfway there. So after we’ve made a connection,
we need to send Google a DNS query. You might be thinking, Julia, I
don’t know how to write a DNS query.

But there’s no problem. We can copy one from something else that knows what a
DNS query looks like. AKA Wireshark.

So if I right click on this DNS query, it’s very small, but I’m clicking on
“copy”, and then “copy as hex stream”.
You might not know what this means yet, but this is a DNS query. And
you might think that like, Hey, you can’t just copy and paste something and
then send the exact same thing and it’ll reply, but you can. And it works.

Here’s what the code looks like to send this hex string we copied and pasted to 8.8.8.8.

So we take this like hex string that we copy and pasted, and paste it into our
tiny Ruby program, and use `.pack` to convert into a string of bytes and send it.

Now we run the Ruby program.

But we do want to know what this means, right? And so we’ll take this hex string and split it into 2 parts.
The first part is the header. And the second part is the
question, which contains the actual domain name we’re looking up.

Those 12 bytes correspond
six numbers, which are two bytes each. So the first number is the thing
b962 which is the query ID. The next number is the flags, which
basically in this case, means like this is a query like hello, I have a
question. And then there’s four more sections, the number of questions and then
the number of answers. We do not have any answers. We only have a question. So
we’re saying, hello, I have one question. That’s what the header means.

Now let’s talk about the question.

So we can write a little bit of code to do this. If we want to translate
example.com into seven example three column zero, can like split the domain on
a dot and then like get its length and concatenate that together and put a 0 on
the end. It’s just a little bit of Ruby. how to encode a domain name.

And then we can wrap all this up
together where we make a random query ID. And then you make
the header, encode the domain name, and then we add the type
and the class, 1 and 1, and then we can just
concatenate everything together and that’s our query.

There’s definitely more work to do here to print out the response, but I wrote
a 120-line Ruby script that parses the response too, and I want to show you a quick demo of it working.

What domain should we look up>. rubyconfmini.com. All right, let’s do it. Hey, it works!

We’re at the end! Let’s do a recap.

That’s all for me. Thank you for listening.