 So I do web hosting, and one of the problems just in general you run into with web hosting and the way things people screw up a lot is DNS. DNS is not super complicated, but a lot of people have some trouble understanding it. Dig is one of my favorite tools to help sort out crazy DNS problems because people do weird things, and when you're trying to set up hosting, you run into this slot. So let's take a look at Dig. So Dig's a really simple tool, but has a lot of features because DNS has a lot of features. And what Dig does is it's a command line tool built into Linux, but I think there's ports you can find for other operating systems, but it's a quick way to query directly at different DNS servers to see if there are records that are showing differently from one place to another. So let's clear this. Dig Google.com. And by default, it just gives you the A record. And what the A record does is say that Google.com points to and gives the IP address the points to. Now by default, Dig uses your local DNS settings, wherever they are for your computer, but you can also dig by using the At symbol, other DNS servers. So you can see how their response is to that. And we actually can see because Google has multiple A records by doing multiple queries, we get different results, such for load balancing and the fact that Google's too big to fit on one spot. But now you can see, I can see the result from here versus the result for, let's see what Google says about this. 8.8.8.8 is Google's DNS server. So we can ask Google about their DNS and we can see a response from there. Now let's start doing like my website. So there's my website, there's the A record for that. If you put MX at the end of it, you get my mail records so you understand how the mail routing works. And you can do this for any site so you can see how routing is set up and what their servers are for this. Now, one of the things it's also telling you, let me just go back to the normal dig and use my servers for example, when you do a dig, it's gonna tell you what are the authoritative name servers for the domain you looked up. So you have the authority section here and then you have NS1, web server systems, NS2 web server systems. Those are my hosting DNS servers. Now that's real important because right now I'm working on a website for a client, I'm working for them to switch over the DNS records because we don't have control over them. And this creates sometimes a problem when you're not the one in control of DNS but you need to understand what the other person's doing. So let's clear this and show how I'm handling a transfer of their website. Now when I do a dig, I see their A record, I see where it's pointed at. Now I have it set up to, I'm waiting for it to change over to point to my servers. I know currently it's pointed there. So but if we dig at and we're gonna ask my name servers or my hosting system where this website should be, I get a different authoritative answer. So it thinks it should be here. And that's what we're waiting. We've sent a request over to the people who handle their DNS and we're waiting for it to switch over. So now it says these, if you ask these servers. Now the reason it's not resolving to mine is because their authoritative servers are still at WorldNIC and they're gonna continue to host it. So WorldNIC can be the authoritative servers and that means whenever it looks up, it's going to go to this IP address until they change the information at the authoritative servers on NS56 and NS55 at worldnic.com. Which WorldNIC, if you're not familiar, that's network solutions. So until that DNS is changed. But this also really helps with mail problems. So if we dig back to my website again and we see my NMX record. So we know who the inbound receivers are and what these are is priorities. And I'm using Google to host mine. So the first priority is priority one, try this. If that fails, priority five means try one of these two. Priority 10, try one of these two. So it just runs down the list here whenever there's a problem. It's the same reason you have two or more domain servers for your authoritative name servers. So it runs down the list. In case one goes out, it tries the next one. Now this also works for what they call CNames. And what a CName is, is a canonical name. So it says, www.laurancesystems.com is a canonical name as in it means the same thing as this. And it points back to the laurancesystems.com, A record. You can also, whenever you have subdomains of things, this is how you can dig out the IP addresses for them. So if we wanted to dig at mail.google.com and wanna know what the answer, it's a canonical name for googlemail.google.com or this, and it changes that IP address. Now let's dig a little bit deeper on the mail thing because sorting out mail problems is a whole another issue. So clear this, dig laurancesystems.com and we are gonna ask for the text records attached. Now text records are text entries that you can add to domains. And the reason they're important in this one, V equals SPF, MX, is tell me this is a SPF record. Now these are ways that you can say who's authorized to send email implicitly for my domain and this helps keep down on a spoofing. And a lot of people forget to put these in and it causes problems and it gets you on lists because other people become allowed to send out your name and mail servers don't know because you didn't implicitly allow or deny what to send things out as. So because I'm hosted with Google for my mail, Google is allowed to send on my backend domain an outbound out mail hop that is a service I pay for to allow sending of things through a service. And because I've implicitly allowed those, that keeps them out of the spam box. And if you skip having these all together, you end up with problems potentially because one, you're not verifying where these records are coming from. So you're not specifically telling mail servers that wanna go, hey, is this person allowed, am I allowed to receive email from this server coming from them, it refers to your text record and looks for the SPF record. So this is why it's really important. But dig is, it's a simple tool and it's just an easy way to dig and see how different name servers respond to different addresses. So we dig amazon.com and we can see for example, with Amazon and you're gonna get this a lot of one. If you look at the name server section, because Amazon's so big, they've got it spread across multiple name servers. And we learned pretty quickly after the dynamic DNS attack that having all of your eggs in one company, even if they have multiple servers, if that one company becomes attacked on DNS, suddenly your name stops resolving. That caused a lot of problems just a couple months ago here in early 2016. So this is why it's important to have spread out. So it looks like they've got a couple at Dinect and another one at Ultra DNS in the UK. So it's spread out. But this is just such a handy way when you're trying to sort out what's going on, you just run to dig and look up the different records. This is a quick overview of dig. Like I said, it looks complicated, but it's such a simple little tool and so handy just figuring out what's going on with DNS. And DNS is at the heart of all this because we can't remember all these numbers. So that's my quick overview of it. If you like the content here, click like and subscribe. Thank you very much.