đŸŽ„ Video Link

Transcript

Please excuse any grammatical errors. I used a tool to generate the transcript and haven’t had a chance to read through it yet.

So, as I’m recording this video, it’s currently 5 days before Christmas. When you’re watching this, it will be 2 days before Christmas. 5 - 2 is 3. Therefore, I want to talk about my three favorite Linux commands. These might not be my favorite Linux commands, but they are my most used ones.

The first one is dig, and what that’s useful for is resolving hostnames to IP addresses or looking up specific DNS records. So, in the basic sense, we’ll just do a dig on sideofburritos.comom.

We can see here in the answer section, we have the two IP addresses that correspond to the two A records I have assigned for my domain. If you want a cleaner output to only show the answer section, you can add +short on the end. Now, we only get the two IP addresses instead of everything else.

Another use of this, which I was reminded of yesterday when someone asked me what email provider I use for my site sideofburritos.com domain, is if we do another query and add MX on the end of it—which is short for mail exchange—it will do a query for the mail exchange records associated with my domain. So, if we run that again, here’s the response. We can see it’s mail.protonmail.ch and mx.secprotonmail.ch. Those are the mail servers that ProtonMail uses for custom domains.

Another example: if we do the same query for yellowball.fm, which is the podcast hosting platform I run (if you’re looking for hosting), we can see here mail.tutao.de. Tutanota changed their name to “Tuta” so it’s easier to say, but they haven’t changed their records. Anyways, I use Tutanota for that. But that’s a quick way to see what email provider someone might be using to send emails. You can use this to do some sleuthing and get other information about a domain, but those are the main two ways I use it for queries.

The last way that I use it commonly, and this is mostly for troubleshooting, is adding +trace. If we scroll up to see the output: fun fact—domains actually have a dot or period on the end of them. Let’s just change that to make it a bit more clear. You don’t need to type the dot; it’s just assumed, but in all reality, it is there. Domain names are read from right to left, so that’s why we can see here the first query is for . (dot), which specifies the root. That’s why we get the root name servers back in our response.

Next, we have .com, which is why we see the com. nameservers. That’s the next one that we need to query to get the response for who has cab.bos.com. So once those are queried for cab.bos.com, they reply with the authoritative nameservers for the domain, which we can see here: cab.bos.com.. We have the NS record nameservers, and we have the two authoritative nameservers that I have configured for my domain.

Then lastly, those are queried, and what those reply with are the associated A records for our initial query that was sent. So, before, when we were running a simple dig sideofburritos.comom, all this was happening in the background, but you weren’t seeing it because we didn’t include the +trace. So, you might be wondering why this is useful. Well, first off, I think it’s just cool to see this—I like DNS a lot; I think it’s a very cool protocol.

But it’s also useful for troubleshooting. Let’s say you’re trying to figure out why your domain’s not resolving. If you run +trace and you get to here but get nothing else after that, it means something’s going on with your records that are configured there. That would indicate, “Hey, go look at your nameservers. Do you have the A records configured correctly? Have they propagated?” Different things like that. So, again, you might not use this often, but when you do, it’s invaluable for troubleshooting.