Often I’m working with people who own a domain, but don’t really know what that means, or how it connects to the real world. Or at least the internet. Here’s a basic guide to how stuff plugs together. There are four roles involved:
- The Owner
- The Registrar
- The DNS Host
- The Server
The owner is you. Hi. The person or persons unknown who put down their credit card and said “That one” and bought a domain.
This is who you gave your credit card details to. They put a record for that domain up in the global DNS system that says “the owner for this domain is The Owner, and the DNS Host is”. This information is public, though a lot of the time Registrars will sell you the ability to use redirecting email addresses and blanked out physical addresses.
The DNS Host
Domains are text – aquarionics.com – but traffic is routed on the internet to IP addresses – 18.104.22.168. DNS, the Domain Name System, is the method by which this translation occurs. Very simply, a request for www.aquarionics.com will make a request of your DNS host as to where that means, like a taxi driver reliant on a GPS.
For most people, your DNS host will be your registrar. They host your Name Server, and that’s something you set on the domain with your Registrar. For example, Aquarionics.com is registered with Namecheap, but my DNS is hosted by Amazon’s “Route 53” DNS service. With Namecheap, I set my name server settings to point at Amazon’s service.
Generally, as I say, this is something your registrar does for free as part of your domain hosting, it’s likely you have a “host name” admin section of your registrar.
This is one of the common points where your hosting company might ask you to change your domain settings.
Very simply, a domain record is made up of four things: a name, a type, a value and a TTL or “Time to live”:
Name: The domain to match. By the point we’re here, the system already knows the “aquarionics.com” bit, but there will be seperate options for “www” and any other things underneath it, including nothing at all.
Type: “A” records link the name (www.aquarionics.com) to an IP address (22.214.171.124). “CNAME” records link it to an alias. So in the above, going to dailyphoto.aquarionics.com looks up that record, sees a CNAME for dc80vpukp1283.cloudfront.net, so it goes to find out what that means, which comes back as “126.96.36.199”. It’s worth noting that this isn’t a redirect for the user, it’s making the request of another DNS service. The answer is always eventually going to be an IP address where the full “Send me this website” request will be made. (Other record types include TXT for arbitrary text strings, AAAA for IPv6, and some others. They’re beyond the scope of this article)
Value: What comes back
TTL: How long to keep this information, in seconds. In the above, the record for www.aquarionics.com should be kept for an hour, but for dailyphoto you should ask again in five minutes.
The actual computer at the other end of this, numbered 188.8.131.52, which gives out the website.
How does this fit together?
If someone’s never visited your site before, like this: (I’m simplifying this quite a bit)
You type in “www.aquarionics.com”. Your computer asks the DNS system what IP address that means. The global DNS system goes “You should ask The DNS Host”, the DNS host goes “The answer is currently 184.108.40.206, but ask me again in an hour”, your browser sends a request to the server at 220.127.116.11 saying “Can I have the front page of www.aquarionics.com, please” and that’s the end of the DNS bit.
There is stuff that makes this more complicated. For example, at any point you can get more than one answer. If you ask for dailyphoto.aquarionics.com, for example, you get an answer like this:
;; QUESTION SECTION:
;dailyphoto.aquarionics.com. IN A
;; ANSWER SECTION: dailyphoto.aquarionics.com. 300 IN CNAME dc80vpukp1283.cloudfront.net. dc80vpukp1283.cloudfront.net. 60 IN A 18.104.22.168 dc80vpukp1283.cloudfront.net. 60 IN A 22.214.171.124 dc80vpukp1283.cloudfront.net. 60 IN A 126.96.36.199 dc80vpukp1283.cloudfront.net. 60 IN A 188.8.131.52 dc80vpukp1283.cloudfront.net. 60 IN A 184.108.40.206 dc80vpukp1283.cloudfront.net. 60 IN A 220.127.116.11 dc80vpukp1283.cloudfront.net. 60 IN A 18.104.22.168 dc80vpukp1283.cloudfront.net. 60 IN A 22.214.171.124
Which translates as:
You asked for dailyphoto.aquarionics.com. It’s aliased to dc80vpukp1283.cloudfront.net, which has these records. Multiple answers for the same question means they’re all right, and you can pick any (but usually from the top down, trying each until you get an answer)
Mail works exactly the same way, but instead of “A” records and “CNAME” records, you have “MX” or “Mail eXchange” records which dictate servers that accept mail for this domain:
aquarionics.com. 300 IN MX 10 alt1.aspmx.l.google.com. aquarionics.com. 300 IN MX 10 aspmx.l.google.com. aquarionics.com. 300 IN MX 20 alt2.aspmx.l.google.com. aquarionics.com. 300 IN MX 20 aspmx2.googlemail.com. aquarionics.com. 300 IN MX 30 aspmx3.googlemail.com.
Unlike the records above, MX records have priorities attached, so you should only go for alt2.aspmx.l.google.com if alt1.aspmx.l.google.com isn’t responding.
Changing hosting providers
This is where this usually comes up as a thing. If you’re moving where your website is hosted, your new company will almost certainly request this DNS change. This is where TTL comes in. A while (days) before this is coming, you should lower the TTL for the website’s records to 30 seconds or so. This will mean that when you do actually make the change, the rest of the internet will not try to keep the old answer for ages.
This doesn’t always work perfectly. Your computer keeps its own cache of DNS answers, and is almost certainly using your router as a DNS server. That in turn is making requests of your ISP’s DNS servers, which are probably asking the global systems. That’s a moderate number of systems that need to be honouring the times correctly for this to work properly, which is why the standard advice of “2 days for changes to flush though” is still so common. You’ll get 80% in the first half hour or so, but the remaining 20% might take a bit longer.
@ and *
@ is a little overloaded, and this is one of the places where it is. Some hosting providers will give you a record with the Value “@”, which stands for the unadorned domain itself, so just “http://aquarionics.com”. Notably, this isn’t allowed to be a CNAME, or alias, it needs to be an actual IP address.
* is a wildcard domain. So having a record for “*.aquarionics.com” pointing at 126.96.36.199 would mean that going to anything like that “fakedomain.aquarionics.com” up to “supercalifragilisticexpialidocious.aquarionics.com” would all resolve to 188.8.131.52
That’s it, I think. Slightly more tech than it should ideally be, I know, but with any luck a useful reference.