DNS Continued

A company internal DNS server with its own zone

This is the same setup we had before. We have a machine right here that's on the network, the company has its own DNS server, and then if it doesn't know the answer or it doesn't have it cached, it will go out to the ISP DNS server, and that DNS server will go and contact these other domains for it. It comes back with an answer which will get to your machine.

But there are times when you want to address local resources — for instance, let's say a file server, or a printer, or some sort of file share. We want to address those resources and we don't want to expose that to the outside world. So what we would do is, let's use example.com as an example. If we have our external example.com, that's our domain that's registered out there and we purchased the rights for example.com, then maybe we set up our internal infrastructure as example.local. There's a few top level domains that we can use just for private use, like .local. Those are some ones that we can use internally and have no fear that it's being used at all externally.

So we'll set up example.local on this local network for local resources. That way, if I want to address the file server, then I would address that, and it would go to my local DNS server. That DNS server would say, "Okay, that is the domain I'm in charge of, because it's example.local, and I have all the files for that, and you're looking for the file server, so here's the IP." It's going to return it, and now this machine knows how to get to the file server — it has the IP address to get to the file server.

But let's say it's example.com. Now it's trying to reach www.example.com. It gets to this local company DNS server. That DNS server says, "I'm not in charge of that domain, so what I'm going to have to do is forward that to the DNS server I know of." Maybe that's your ISP's DNS server, maybe it's OpenDNS, it's some sort of other DNS server. Then that other DNS server — it could go directly to the root server, I'm not saying it's never set up that way — it goes to the ISP's DNS server. And that ISP does a lookup for www.example.com. Example.com responds back to the DNS server on your local network, and then that DNS server responds back to you with that external IP address and how it resolved that external IP address.

So this company DNS server acts as both a caching server for any kind of external resources, but also hosts an internal domain specifically for internal resources, and it ends with something like .lo.

Choosing the internal domain

At one point in time it was always recommended, for security purposes, to only use something like a local.local domain, or some sort of resources internally that is not addressable — it is not part of any kind of external domain services that are out there. Although some more recent Microsoft documentation says use a top level domain that is accessible from the outside, and there are some advantages, some pros and cons, to choosing each one. I still to this day use the internal domains like .local for my internal domains. I still don't use what Microsoft's best practice is right now of using external top level domains.

Types of DNS records

There are actually several different types of records on a domain name server, so let's talk about a few of the different types.

Up until now, we talked about hostname to IP address. For instance, if a server has, let's say, example.com, and you're looking for www.example.com, example.com is going to, within its domain, look up the record for www, and it's going to look up the IP address and send it back. We call that an A record — or, if it's sending back an IP version 6 address, then we call that an AAAA record, a quad A record. So that is the type of record it is, and that's translating from a hostname to an IP address.

There are other types of records as well, though.

• There is a name server record, so that's an NS record. A name server record just says, when you get to example.com and you look at the name server records, those name server records are the DNS server IP addresses. So a name server just points to the domain servers that are hosting out for that domain.
• Then we have the start of authority. Look at this as like a control or a management record that lets any of the domain controllers communicate certain pieces of information.
• We've got an MX record. Let's say you are sending something. You're going to go through the domain lookup process for techknowsurge.com, and then you're going to look for the MX record. The MX record will come back and say, this is the Mail Exchange server that you're looking for. So it's going to give you a Mail Exchange server address, and then you're going to be able to get to that mail exchange server address and send that email to [email protected].

Then we have hostname to hostname. There are times when we want to reference a hostname. For instance, let's say we're hosting something on another site and we want to reference that other site and send our customers to that other site. An example might be that maybe we're hosting something in the cloud and we want to send all traffic to www.techknowsurge.com to that hosting provider. They can either give us an IP address, which could maybe change, or they give us a hostname, and that hostname is going to stay the same, and their hostname can point to any one of their servers. So we are going to say www.techknowsurge.com is going to this hosting provider — let's say it's www.example.com, and example.com is the hosting provider — and then the client is going to say, "Oh, well, now I need to resolve www.example.com to get an IP address."

Now, this gets a little tricky in that commonly people think of DNS as being able to do redirects. This is not that. All I'm saying is if you go and look up www.example.com, you are going to get an IP address that I'm trying to send you. So it's just a way to reference another resource via hostname rather than referencing an IP address. That's a CNAME record; we also call that an alias record.

And then we have an IP address to hostname, which is the reverse, right? This is not hostname to IP address, this is IP address to hostname. We call that a reverse DNS, because it's doing the opposite, or a pointer record, a PTR record. So this pointer record is pointing to a hostname, and we do that mainly for verification. There are times when certain services need to verify an IP address — did it receive the correct IP address? It goes and does this reverse DNS lookup, takes a look at the IP address, and that will come back with a hostname, and then it knows it has accurate information.

The DNS process, end to end

We talked about a lot of different things. Let's just package this up and go over it one more time, but summarize everything.

You, on your machine, look up www.techknowsurge.com — you're typing that into your browser. Your machine is first of all going to look at the host file and say, "Is this in my host file?" and it's going to determine, in this case, no, it's not in my host file. Then, "I'm going to take a look in my cache and see if it's in my cache. Have I accessed this recently and it's in my cache?" No — I've either not accessed it before, or my time to live on this record has gone and it no longer exists in my cache.

So then it's going to go to the DNS server that's set on that machine, and it very well could be that that's the DNS server of your company. Your company is going to take a look at its cache and say, "Is this somewhere in my cache? If not, is this a domain that I have, that I'm hosting?" And if not, then it's going to request it from its forwarder, or directly to the root server. We're going to say that there's some sort of forwarder, and it now is going to forward that on to — let's say this is OpenDNS right here — so it's going to send it off to OpenDNS and their domain name servers.

And so then that caching server is going to get it. It's going to look at its cache and say, "Do I have it already? If not, then I'm going to take a look at my root servers to find the information out." So it goes out and looks at one of the root servers. Usually this machine will have a lot of different root servers on it, and it will randomly choose one of those root servers, go out to that root server and say, "Who belongs to www.techknowsurge.com?"

This root server will reply back and say, "I know a dot server that can help you out." So you reach out to one of the dot servers to help you out. That com server will reply back and say, "Okay, well, I know where the domain server is for this." And so then it reaches out to the domain name server for techknowsurge.com. That one looks at its table and says, "I have the record for www for that domain, techknowsurge.com, so here is the IP address that you're looking for. And I'm going to mark that this is an authoritative answer — this is the answer you're looking for."

That makes it back to this server. The server sticks it in cache for any other customers that are accessing it as well, sends it back to the company DNS server, which sticks it in its cache for anybody else inside the company that is looking for the same thing, sends it back then to the machine itself, and that machine sticks it in its cache in case it needs to access resources again for that server. And then your machine now has that IP address. It can now reach out to that web server via that IP address.