Subscribe to GEN
Login to GEN
Every website, every service on the Internet is 'addressed' by an IP Address. This IP Address is the phone
number
for that server or service. An example could be 207.36.11.250
, or 2001:db8:3c4d:1234:5678:9abc:deff:fedc
.
You could
try and remember these and what they are for, and indeed some NetOps engineers can remember a large number
of these
but most people want something easier. This is what DNS does, it takes a hard to remember IP Address and
gives it an easy
to remember name.
DNS is like the internet phonebook, so you don't have to remember that duckduckgo.com
is 52.142.124.215
, you
just need
to remember 'duckduckgo.com'. The system that translates the memorable name into its IP Address is the
Domain Name System.
You can't have any name as your domain name, it has to be correctly structured and unique. Since there are a 'lot' of domains the management of these domains needs to be handled by an 'authority' or 'registry'. Because the Internet spans so many countries, each country has its own registry, and each registry is responsible for their 'part' of DNS.
As an example, in the UK, the registry is Nominet, and they are responsible for registration of all the domains ending .uk, but they are not responsible for all the domains ending .com. So who is, and how do we know?
The domain name system, is a decentralised system, so there is no one authority responsible for ALL domain names, this is GREAT because no one country or company should be responsible for everything, especially not in the world that is governed by polititions.
When you look at a domain name, duckduckgo.com, you can see that it has two parts, duckduckgo and com. This is important because duckduckgo is the domain name, and com is the registry.
When we put duckduckgo.com into our browser, the domain name system on our computer first, goes to a 'root' server. This 'root' server tells the domain name system, where its going to find the server responsible for 'com'. 'com' is a 'top level' domain, meaning that there is nothing above it in the hierarchy. Once our computer has the address of the server responsible for 'com', it then goes and asks that server where is 'duckduckgo'. That server then returns an IP Address and your browser sends its request there.
So what about www.gen.net.uk? Well, Your computer first goes to the 'root' and asks, who is responsible for 'uk'. This is of course nominet, and their server is at nic.net.uk. Then your browser goes to nic.net.uk and asks, who is responsible for 'gen.net', and nominet replies, ns0.gen.net.uk. Finally, our browser asks ns0.gen.net.uk, where is 'www'. ns0.gen.net.uk replies with 62.31.206.180, and that's where we send our request.
Its the same for every domain on the internet, ask the root who's responsible for the top level (.uk, .pl, .ie, .com, .network, etc) and then we go ask that server, operated by the country's registry, where can we find the domain.
Although 'most' domain names contain two, or three parts, like duckduckgo.com (2), or
www.gen.uk (3), this not at all required, and
actually there is no limit on how many parts a domain can have, as long as we can identify the server
responsible for giving us
an ip address. E.g. this.is.a.really.long.domain.gen.uk is a perfectly valid domain, its not easy to
remember, but its valid, and we
employ the same lookup strategy as before:
Domain Name Servers, store the information for each domain that they are responsible for in simple text files, and its been this way since the start of the Internet. In these text files, called Zones, we store information about the domain, in a very simple format.
There are many different types of Records, each having a specific meaning and use. The
most
common record is the 'A' record, which stands for 'Address'. This is the record that gives an IP Address.
Here's an example:
duckduckgo.com. 11 IN A 52.142.124.215
In this example, we can see that the IP address for duckduckgo.com is 52.142.124.215. Its that simple.
The first few lines of the Zone, contain the header and this is the SOA record, and the
format of the SOA records is:
gen.co.uk. IN SOA ns0.gen.net.uk. hostmaster.gen.net.uk. (23 86400 180 2419200 10800)
In this example, gen.co.uk IS the domain, and this is its Zone.
'IN SOA' is the record type.
hostmaster.gen.net.uk is the email address responsible for this Zone. Its pretty much obselete now, and we
exchange
the first . from the left with @ to get a proper address since @ means somthing special in Zone files.
The numbers mean, in order from left to right; Serial, Refresh, Retry, Expire, Minimum TTL. You don't need
to know
what all of these are for, and should leave them at defaults unless you're a network admin, in which case
this
article probably ins't the best source of information.
There are many different record types, but only a few are really useful, and actually many of them are now obsolete. We're going to cover the top 5 records here, and their meaning.
The most simple, and yet the most important record in DNS is the A Record, with it, we
give a domain name
its IP Address. Remember, our computer can only work in IP Addresses, and domain names are just so we can
remember them. The A Record
contains 3 main parts:
duckduckgo.com. - This is the domain name, in full, followed by a .
11 - This is the TTL, or time to live. This indicates how long our computer should remember this A record
before it has
to look it up again. Common settings are 3600 which is 1 hour, 86400 which is 1 day, and 300 which is 5
minutes.
IN A - This is the class, which is always IN followed by the Record Type, A, in our case.
52.142.124.215 - this is the answer, the IP Address.
All the records follow this format, so as we proceed we're just going to be talking about the first part,
the domain, and the last part, the answer.
When the Internet was created, we had IP Addresses in the format of a.b.c.d, with each
part being from 0 to 255.
This provides for a total of 4,294,967,296 different IP Addresses, which was super-massive at the start, but
now we're running out.
To fix this, a new IP Address format was invented called IPv6, and since there's no point going low on this,
the new format allows
for 340282366920938463463374607431768211456 different IP Addresses, so there's room for expansion.
This new format, ipv6
has been slowly adopted, but its not still widely used. The main reasons for this is that much of the
Internet doesn't understand
ipv6, and many service providers don't provide it. Regardless, it has its own record type and we need to
know what it is.
bing.com. 1872 IN AAAA 2620:1ec:c11::200
So here we see, bing.com, with a TTL of 1872, 'IN AAAA' and an IP Address of 2620:1ec:c11::200. We suppress
the leading 0's, but if
wanted to write this out fully, it would be 2620:01ec:0c11:0000:0200. You may never need to use IPv6, but if
you do, now you know.
The NS Record tells a computer who is querying a specific group of records (the Zone) who is reponsible for that Zone. This is because in a proper setup, there will always be more than one DNS Server responsbile for any given Zone, BUT, there can be many copies of the Zone cached at various servers. By looking at the NS records, and seeing if the server we're asking is listed, who know that we're getting the correct information. For example, if we're looking for www.gen.co.uk, and Nominet has given us ns0.gen.net.uk, and we go there and we get the zone, but the NS records show that the server responsible is actually ns2.gen.net.uk, then what do we do? we go ask ns2.gen.net.uk instead, and if ns2.gen.net.uk isn't available, we'll stick with what we got from ns0.gen.net.uk. This is called 'lame' deligation, where there server we're directed to, isn't 'authoritive' for the domain, but it has a copy. In high load environments this may be the case, but it should be avoided.
Sometimes, to make things easier we may want to have a domain name that points to another
domain name. An example of this
might be in a hosting environment, where we have a domain name for a a hosting cluster, let's say
aurora.gen.network, and that
cluster has a selection of ip addresses. We might not want to have to copy all those addresses to each
domain hosted there, so we'll use
a CNAME record.
www.gen.net.uk. 3600 IN CNAME aurora.gen.network.
aurora.gen.network. 86400 IN A 62.31.206.180
So super easy to understand, www.gen.net.uk is the same as aurora.gen.network, and we can then ask for
aurora.gen.network and be
given its IP Address of 62.31.206.180. CNAME records are really useful to keep large zones tidy.
Email, is a fairly important component of the Internet, but have you ever wondered how
the Internet figures out where to send your email? No, well neighter have I, but actually its very simple.
For any
domain name that needs to receive email, we need to have an MX record. This record tells a mail server,
what ip address is responsible for receiving email for that domain.
gen.net.uk. 3600 IN MX 10 mail.gen.net.uk.
In this example, if we're sending email to fluffy@gen.net.uk, then our mail server needs to talk to
mail.gen.net.uk to get it done.
MX records have an additional parameter after the class, in this example 10. This is the priority of the MX
record, and becomes
important when you have more than one mail server that can receive email for a given domain. Let's look at
GEN's mail setup;
gen.net.uk. 3600 IN MX 10 reliance2.gen.network.
gen.net.uk. 3600 IN MX 10 reliance1.gen.network.
Here we can see that two mail servers are responsible for receiving email for gen.net.uk, and in this
example, the priority
is the same, 10. In this scenario, there is no favourable server so they will both be used randomly. This is
because we 'load balance'
or share the load between them. If one is down, use the other one. If on the other hand we had;
gen.net.uk. 3600 IN MX 20 reliance2.gen.network.
gen.net.uk. 3600 IN MX 10 reliance1.gen.network.
Then we would always use reliance1.gen.network. if its available, only using reliance2.gen.network when its
down.
As the name suggests, TXT Records are just that, arbitrary text. You can create a record
in your Zone as:
mydomain.com. 86400 IN TXT "I Really Like Weetabix"
Its not very useful, but you can absolutely do it. However, TXT records are used for a variety of real
reasons, and I'll give you a few examples...
SPF, DMARC and DKIM
If you're sending email from your domain, then having valid SPF (Sender Policy Framework), DMARC
(Domain-based Message Authentication, Reporting & Conformance) and DKIM (DomainKeys Identified Mail) are a
must.
These records define important information related to sending email, SPF provides a list of IP addresses
that are allowed to send email
from your domain, DKIM provides the public part of a key pair that is used to validate your email's are
legitimate, and DMARC
tells the receiving server what to do when things don't match up. These records are beyond the scope of this
article, but
we do cover them elsewhere on the site. Check out the support.gen.uk Knowledge Base for more specific
definitions.
We've already figured out that DNS takes a domain name, and returns 'something' depending
on what we're asking for.
For an 'A' record, we want an IP address back (or more than one potentially), and that's super, but what if
we have an IP address,
and need to know what domain name its for? Well, we can use a PTR record.
The PTR record system is a bit different to the other 'forward' records, PTR's are 'reverse' records becaues
we're doing it backwards.
180.206.31.62.in-addr.arpa. 86400 PTR aurora.gen.network.
PTR records are stored in their own special zone, which is called the 'in-addr.arpa' zone, and in this zone
we have the reverse records. Above we can see that 180.206.31.62.in-addr.arpa = aurora.gen.network... say
what?
PTR Records are stored in a special 'reverse' format. That is, 180.206.31.62.in-addr.arpa is actually
62.31.206.180. Its backwards like this, because it has always been backwards, and in-addr.arpa is a special
domain that
indicates its reversed. Fun fact, the Internet was origially called the arpanet (Advanced Research Projects
Agency Network), and you can see some of this glorious legacy at work here.
You will probably never need to create PTR records yourself, and indeed most people cannot since your ISP
will create them for you, but at least you now know what they are and what they mean. One IMPORTANT use of
PTR records
is mail servers, any mail server on the Internet that wants to have its mail accepted needs to have both
foward DNS (A records) and reverse DNS (PTR records) that match.
reliance1.gen.network IN 3600 A 149.255.124.2
2.124.255.149.in-addr.arpa IN 3600 PTR reliance1.gen.network
We can see here that reliance1.gen.network resolves to an IP, and that IP resolves back to that domain. If
this doesn't match, quite often email will be rejected. The reason for this is spam reduction, remember that
I said only your
ISP can create these records? then this stops anyone with a broadband connection running their own mail
server to spam the planet. Mail servers *should* be run by your ISP, and if you want to run your own, then
you should be spooling your
mail to and from your ISP's mail server, this is the right way to do it for a business domain.
GEN aren't like many providers, we won't ask you to handle DNS Records yourself, you simply need to tell our HelpDesk what you want and we'll check the request and then make it so. This is the difference between a service provider and a DIY provider. If you're looking for a better class of service, consider asking what we offer and why its better.