DNS and shit [WIP]
Posted: Mon Jan 25, 2016 3:32 pm
So I've been wanting to spill and share my brain about DNS as, well I have to deal with it all day.
Rusty seemed to think it was a good idea as well on IRC, so you can blame him if you want.
Hopefully this might help anyone with their hosting and overall understanding of the web, sure some of you know this already but, judging by the amount of time i have to explain things - it's hardly common knowledge.
So back in the day when there were like 5 computers in the 'internet' there was one file to rule them all, in fact this file is sort of still on your computer at /etc/hosts (we'll get back to that in a bit) lazy sysadmin quote:
So first off one has computers with numbers as their address, other computers talk to them using numbers, to be frank domains on top are a hassle, but it's a job. Instead of 216.58.198.206 we have google.com. which is a touch easier to recall.
When you register your domain normally the registrar has the Nameserver records, this is called a 'Zone' which holds the information in a text file (these days normally kept in check by a database) that sits on a name server (NS) and looks like this:
That's where the zone file is kept, only people with access to that machine can change those records, which is good.
If you change those NS and don't have a zone file (or an empty one) on the new NS, then you won't have email or a site anymore :)
Customers forget this occasionally - if you do need transfer NS then ask for a 'full zone transfer' your domains people should have access to that zone file (or the DB for that matter)
The most common DNS records are, most obvious first:
'A' record
commonly used to map hostnames to an IP address - google.com would be an A record, it is a line in a DB or bind file somewhere that looks something like this:
Which looks a bit like what you'd find in your /etc/hosts file. and in turn, changing stuff in your host file locally changes the DNS!
so in that case adding this to your hosts file:
gives you a totally different website. Very handy for testing sites out before actually changing the DNS, also for troubleshooting.
just remember to remove it after!
So that's roughly how DNS works - when you request a site in a browser it talks to these Nameservers, finds out the IP behind it and asks the webserver for the site on that IP.
Usually your NS will be the ones with your ISP. I think there is a way of finding out what ones you are using, let me know what it is if you do :)
MX (Mail eXchanger)
is the next common one, I guess. This does mail of course. without it the site will work fine.
Which are your mail servers. MX have to be a domain name, which is a bit of a change to the other records. "@" represents zone origin or in english the same as the domain.
added after are some numbers, which indicates priority, with zero as the highest priority, if one MX is down it will try the next one and so on.
normally these days, there is a primary and a backup, which spools mail until the primary is backup.
MS 365 mail thing usually has one, I hate putting these in, they only have a single MX though (something about 'elastic IP's' or something.
CNAME. which is pretty much an alias, this also has to be a domain name, otherwise it breaks stuff.
so I usually do:
Which refers to example.com so 192.0.2.1 in this case, which is good because - if you need to change the IP (host) you change one thing and all the other CNAMES change with it. Less useful if you need it on a different server entirely. In this case it's normally the same though.
Same with mail, if we have a mail A record:
we can point the MX to it as above, so change the A record and the mail server changes.
That leads to subdomains, of which www. and mail. are, of course.
one can go quite deep with subdomains, gets a bit boring really but FYI .uk is a TLD 'top level domain' things under it are technically subdomains. .co.uk etc.
These are created by whoever has the domain's nameservers, so normally only facebook.com can make "stinky.facebook.com" and point it to where they want.
thats it for now.
maybe look at some tools to poke around in all this stuff.
Rusty seemed to think it was a good idea as well on IRC, so you can blame him if you want.
Hopefully this might help anyone with their hosting and overall understanding of the web, sure some of you know this already but, judging by the amount of time i have to explain things - it's hardly common knowledge.
So back in the day when there were like 5 computers in the 'internet' there was one file to rule them all, in fact this file is sort of still on your computer at /etc/hosts (we'll get back to that in a bit) lazy sysadmin quote:
Cool eh? Right DNS:wikipedia wrote: Originally, a file named HOSTS.TXT was manually maintained and made available via file sharing by Stanford Research Institute for the ARPANET membership, containing the hostnames and address of hosts as contributed for inclusion by member organizations. The Domain Name System, first described in 1983 and implemented in 1984,[1] automated the publication process and provided instantaneous and dynamic hostname resolution in the rapidly growing network. In modern operating systems, the hosts file remains an alternative name resolution mechanism, configurable often as part of facilities such as the Name Service Switch as either the primary method or as a fallback method.
So first off one has computers with numbers as their address, other computers talk to them using numbers, to be frank domains on top are a hassle, but it's a job. Instead of 216.58.198.206 we have google.com. which is a touch easier to recall.
When you register your domain normally the registrar has the Nameserver records, this is called a 'Zone' which holds the information in a text file (these days normally kept in check by a database) that sits on a name server (NS) and looks like this:
Code: Select all
example.com. IN SOA ns.example.com. username.example.com. ( 2007120710 1d 2h 4w 1h )
example.com. IN NS ns ; ns.example.com is a nameserver for example.com
example.com. IN NS ns.somewhere.example. ; ns.somewhere.example is a backup nameserver for example.com
wiki wrote:As a minimum, the zone file must specify the Start of Authority (SOA) record with the name of the authoritative master name server for the zone and the email address of someone responsible for management of the name server.
That's where the zone file is kept, only people with access to that machine can change those records, which is good.
If you change those NS and don't have a zone file (or an empty one) on the new NS, then you won't have email or a site anymore :)
Customers forget this occasionally - if you do need transfer NS then ask for a 'full zone transfer' your domains people should have access to that zone file (or the DB for that matter)
The most common DNS records are, most obvious first:
'A' record
commonly used to map hostnames to an IP address - google.com would be an A record, it is a line in a DB or bind file somewhere that looks something like this:
Code: Select all
example.com. IN A 192.0.2.1 Which looks a bit like what you'd find in your /etc/hosts file. and in turn, changing stuff in your host file locally changes the DNS!
so in that case adding this to your hosts file:
Code: Select all
129.3.21.4 example.comjust remember to remove it after!
So that's roughly how DNS works - when you request a site in a browser it talks to these Nameservers, finds out the IP behind it and asks the webserver for the site on that IP.
Usually your NS will be the ones with your ISP. I think there is a way of finding out what ones you are using, let me know what it is if you do :)
MX (Mail eXchanger)
is the next common one, I guess. This does mail of course. without it the site will work fine.
Code: Select all
example.com. IN MX 10 mail.example.com
@ IN MX 20 mail_backup.example.com. added after are some numbers, which indicates priority, with zero as the highest priority, if one MX is down it will try the next one and so on.
normally these days, there is a primary and a backup, which spools mail until the primary is backup.
MS 365 mail thing usually has one, I hate putting these in, they only have a single MX though (something about 'elastic IP's' or something.
CNAME. which is pretty much an alias, this also has to be a domain name, otherwise it breaks stuff.
so I usually do:
Code: Select all
example.com. IN A 192.0.2.1
www.example.com IN CNAME example.comSame with mail, if we have a mail A record:
Code: Select all
mail.example.com IN A 192.0.2.3That leads to subdomains, of which www. and mail. are, of course.
one can go quite deep with subdomains, gets a bit boring really but FYI .uk is a TLD 'top level domain' things under it are technically subdomains. .co.uk etc.
These are created by whoever has the domain's nameservers, so normally only facebook.com can make "stinky.facebook.com" and point it to where they want.
thats it for now.
maybe look at some tools to poke around in all this stuff.