What's in a Name? Your Guide to the Wacky World of DNS by Ashley Sullins

Yeah, I think that's a good thing. All right, hi everyone. Thanks for coming. I know this is the last session, so I'm sure you guys are excited to play some board games. Later. My name is Ashley and I'll be talking about DNS. So if you read the description in the session talk, you'll see that it said um DNS. And for some people who are new to development, you might be wondering, what is DNS? And what does it have to do with Django? That's a great question. So DNS is essentially how IP addresses are associated with domain names. And technically, you could be a Django developer and know nothing about DNS.

But the nice thing is that it helps with debugging. So say you're for some reason your website crashes and you don't know what's going on, it might be a DNS issue, not necessarily a server issue. It's also good if you're a freelancer or a consultant. You may be asked to launch a client's website. And so it's helpful for you to know how to do that and talk through those steps in the process. And then you might be wondering, why am I speaking about this topic? What do I know about DNS? So for the past six years, I've been helping launch websites. I was a software tester for several years at a self-storage company and the developers were like, oh DNS, this is so boring. We'll teach the QA girl how to do this. So that's where I got my start and I got really good at it and then I moved on to other projects and taught our account managers how to do DNS.

And then at my current company I work at a very small startup, so it just becomes part of my job. to launch all of our websites. So I would say between those two jobs I've launched about 500 different websites. Um and I bring into every single issue probably that you could encounter from uh taking down websites to breaking emails. There's all sorts of tricks and things that might come up when you're launching a website. So, what we'll do at this talk is that we'll actually pretend like we're launching a website and go through all the steps, what we need in order to launch our new website. So, just a quick review. Most of you probably know a very basic definition of the internet is basically computers that talk to each other.

And DNS is the way that they communicate. It's their common language. It's short for domain name systems, and it connects IP addresses to domains, as I mentioned earlier. I like to give this example to the account manager that I teach about DNS, that essentially a domain is like a name in your phone's address book. So we know that this is my friend's name. This was my friend Amy's phone number when she lived in Amsterdam. And so the equivalent to this for DNS is the domain name. So like google. com. So Amy's phone number is in our address book, but I don't know it. It doesn't really matter. I can change it to whatever I want, but I'll still know if I want to contact Amy

to just select her number in my address book And that is the equivalent to our IP address. I mean, technically we could go to an IP address and view the website, but who wants to remember a bunch of random uh numbers when we can just go to google. com? And something also in our address books, sometimes our phone numbers come from Google or they come from Facebook. And DNS has a similar functionality. Our numbers can come from a place called name servers. And we'll talk more about those different places that our DNS can come from. So, how does it all work? What are the technic neck technical details of DNS?

So here's a picture that I found online, but essentially what happens when you type in google. com is that you can your computer will connect with the Top-level domain DNS information. And what a top-level domain is, that's just whatever is after the dot. So with google. com, that would be the com. And so Calm has a system of computers and it says, hey, you can find Google's records at the Google name servers And then once you go to the Google's name servers, it will have an A record that will have the IP address that we are trying to hit. And that will go back to your computer, and that will happen in a matter of milliseconds.

So if you're going to launch your client's website, the first thing that you'll need is you're going to have to be able to find your um your name servers. And most clients are gonna have no idea what a domain or they know what their domain is, but they don't know where their name servers are located or where any of this information might be. But luckily we can help them out. There's a website called who. is And if you go to this website, you can type in the domain name. So like for in our example, this is a screenshot of the whois information. you can type in mydomain. com and it will show you where the registrar is. And the registrar is just where your domain is Is registered. So if you go to GoDaddy and you register your domain, then that is your registrar.

And in this case, our registrar, you can see the referral URL is domain. com. If you scroll down on this page, you'll also see information on name servers. Our name servers are where our actual DNS information lives. And a lot of the time this information will be in the same place as your registrar , but sometimes it's not. In this example, it happens to be in the same area, mydomain. com. But you know for for other websites they may be hosting them like Amazon, Route 53, or various uh other places that you can have name servers And like if you're using GoDaddy, their name servers are at secure server. net. I just know that from launching a lot of websites, but you can easily look that information up online

and look at their FAQ documentation. So we have the name servers, we have our registrar , we're ready to launch, right? Like we're good to go. Okay, hold up. There's a couple of precautions that we need to take prior to launching our website. I've kind of created this pre-launch checklist that uh things that I recommend you doing prior to launching a website. The first thing that I I highly, highly re remec recommend that you do is to take a screenshot of the current DNS. And you'll see later why this is really important. Um, but it's always good to have a history of that information that you can go back in case anything goes wrong. I've had, you know, I've launched some sites and then the account manager will come back a couple minutes later and be like, actually the client didn't want to.

Launch that website yet, just getting go back to the old DNS information. So you just never know. The other thing that I recommend is doing a final smoke test of your production server. This can be in a variety of ways. You could just hit like the IP address before you launch, or you can also create a production environment that is like password protected because you don't want to run into any issues with um SEO issues with duplicate content. So we want this to be guarded away from Google and just specifically for development usage only. And then also, as I said before, make sure you have access to the correct records. Oftentimes I will get DNS information, and then it turns out the name servers are somewhere else, and it gets kind of frustrating because everyone's really excited to launch a website and we just don't.

have the correct information so make sure that you've done done your dig done your whois and you've found that information So this is an example of what DNS records look like if you've never seen DNS records before. This is how we would launch a website. This is a very typical configuration. Obviously, some many servers have different configurations, but this is our standard for all the sites that I've launched through the years. There's typically an A record, and this is the record that says, hey, this is the server that you go to when you go to this website. And then there's also a C CNAME record and a C D C name record is just a subdomain record and you can have a dub dub dub record or you can have an asterisk. And the asterisk just means catch-all.

And what how that works is if you go to anything that's not specifically defined by your DNS records, it will automatically reach or redirect you to wherever the catch-all is pointing to. So in this case, the catch-all is pointing to the A record, the twopixelswrite. com. And so anything that is not specifically defined by our DNS records will take us straight to the IP address. Alright, so we've launched our website. Exciting times. But wait, I don't know if anyone's ever heard this before, but I can't see the new website. Where is it? What's going on? Okay, it's gonna be okay. Let's take a deep breath and we will troubleshoot what's happening here.

So where's my new website? So let's talk a little bit about the different types of DNS servers. There's the authoritative DNS server. This is the server where DNS information is stored. So this is where we're changing the DNS information. This is where we were when we launched our website. And then there's recursive DNS information. And this is the DNS servers that look up information on an authoritative server. And depending on how you're looking at your website, there could be several layers of recursive DNS servers. You have your browser, you have your internet service provider, and then if there are firewalls, anything like that, there can be several other recursive details. DNS servers that you have to go through in order to see your website.

And authoritative servers tell the recursive DNS servers to look for new information Every num number of seconds. And this number of seconds is called the time to live, or TTL for short. So when you go in and you look at your DNS records, you you will see a number a number of seconds called the TTL. And the longer the TTL, the longer it will take for the recursive DNS to check for the authoritative DNS server changes. So essentially a TTL is saying like every number of seconds check for changes to this information. Best practice, in an ideal world, you would set the TTL to the smallest number of seconds allowed by the name server 24 to 48 hours to launch. Sometimes this happens. Oftentimes, you know, I'm told

we got to launch the site now. We don't really have time to set the TTL. And then that's when you'll run into issues like propagation issues where where some people will see the website or they'll still continue to see the old website. Um you don't wanna if you change the TTL, you don't want to keep this number low because you don't want the DNS servers to keep looking for this information every second or so. That's just not very efficient. And then also just remember DNS caching. So even though you may be able to see a website on your computer, perhaps the director of sales just Still won't be able to see it. So we typically tell our clients give about two

to twenty four hours to see the website. And if you're still having issues, um best My best practice is whenever whenever I'm not sure, like, is this a DNS issue or is this a um a caching issue? I'll look at a site on my mobile device. So if you turn off Wi-Fi on your mobile device, it will directly connect you to the authoritative servers. And so the changes to your DNS should all like appear pretty much in instantaneously. So if you look at it on your on your mobile device and you're still seeing an old website or it's just not redirecting, there are a couple other things that you can do in order to troubleshoot these issues Um always check the root

A record. This is the record that tells our um tells the name servers This is where our server is at. So make sure there are no misspellings or anything weird in there. Also check that you have a dub dub dub or catch-all record. Sometimes people will launch websites and they'll forget to put this in. So if you go to wwwmydomain. com, um they're not going to see anything. It's going to say that it doesn't exist because the DNS, uh the name servers don't know what to do when you go to wwwmydomain. com. Also, like I said before, verify your name servers. We have who. is that has good data, and then you can also go onto your command line

and uh run a command called dig. So you can do dig mydomain. com and then any or actually a lot of people have stopped using any because that's hard on their server. So you can do dig mydomain. com and then just ns. And that will show you the Name servers that your computer is currently seeing. And then step four is you will check for to see if the domain is being redirected outside of DNS. So I always use GoDaddy as an example, not because I work for GoDaddy or anything, but that's how I often launch websites. A lot of people register their websites at Godaddy. com. But you can scroll past the DNS information. and you'll see where uh there's a redirect link. And sometimes like the domain will be redirecting to another domain, and you'll need to remove that in order to

actually be able to use the DNS information. information correctly. If there's an issue where the website looks fine on your computer but on mobile, you can But you can't really see anything on mobile, you're still seeing the old website. You can check for an M or a mobile record Sometimes different vendors will use M records to show a mobile version of their website. And if you don't have that kind of DNS or server configuration, um It's just not necessary. So if you have a catch-all, uh CNAME record, you can just remove those and then anytime someone goes to m. mydomain. com, it will redirect them to to the uh

the domain because that's how it's set up, or if you are using the dub dub dub for whatever reason, maybe your DNS provider doesn't allow you to put catch-alls , you'll have to set a an M or mobile record that's pointing. to your domain so that it will know to go to that IP address. And this is just an example of a dig that you can do on the command line. And then I also found a tool on over the weekend that you can go to Google and Google has a a toolbox that you can use to also do digs through the UI if you're not comfortable with uh command prompt but but this will show you this is where my company's uh DNS information is located. It's an Amazon Web Server.

So say I wanted to launch uh a new version of their website, I would have to have access to Route 53. which is Amazon Web Services um DNS provider, or I would have to at least get a screenshot of that data to make sure that I'm not um that I'm not missing any information. information. Technically you can launch a website without getting the uh the uh uh name server information you can just dig for it all but there's a chance that you could potentially break their email because you don't have all the MX records or all the CNAME records. It's not a perfect science. So make sure you get a copy of those name server records from their previous provider. Um, so the site's live, everything's looking good, but the client called

and their email's not working. Uh-oh. All right, well, we can figure this out. What's going on here? So anytime you're troubleshooting email uh issues, the first, this is where our screenshot's gonna come in really handy. We can go back to the old records that they were using and make sure that we copied all the MX records. make sure they are correct. If you're not familiar with MX records, those are just the records that whenever an email comes in, that's what server to go to in order to send that mail in to The website. So an MX record typically has a number and a URL. The number is the priority of which server, which email server the mail should be delivered to.

And then the URL is where mail servers are located. So for like Google Apps for Business, they typically have five MX records. And if one is not working for whatever reason, uh it'll always hit the one that's going to priority zero first. If that's not working for whatever reason, then it will go to the next one that's highest in priority or the lowest number If you are see are you're looking at the MX records, you realize, oh, it's going to zero at mydomain. com. And you change the IP address, so that means that their email, unless you're hosting their email, their email server is not there anymore. So what do you do? In this case you would create a CNAME record called mail

pointing to the old IP address. And what this does is it just says, hey, like the email, it lives on this old IP address. And then step two, you'll need to change the MX record from zeromydomain. com to zeromailmydomain. com. And then when email comes through, it will see the MX record and it will see that the server is located at mail at mydomain. com and the mail will hopefully start working accordingly. Alright, you did it. Your side is live. It's very exciting. The cats are very happy for you. All right, so that's a lot to go through in 20 minutes. And if you're still curious on how DNS works, um there are a lot of additional resources that you can take a look at online, and then I also have a link to the Google Apps Dig

command that you can. you can use online and my presentation can be found at this URL. And that's all I have for tonight. So thank you.