DNS for Developers
DNS is the backbone of the internet and as such I believe every developer should know something about the basics and not just leave it for the sysadmin to sort.
DNS or Domain Name System is what translates Domain names to IP addresses and vice versa.
You do realise this is a developer blog? An IP address is a unique address on the internet and a domain name is a user friendly label for one or more of these.
An example might be google.com which for me resolves to 184.108.40.206
In more detail your ISPs DNS server will forward the DNS query to another DNS server and will cache the results for a set amount of time. This is the TTL or Time To Live. Next time the ISP DNS Server will be able to reply directly without needing to forward requests.
This forwarding and caching is what makes making a DNS change not instantaneous. The TTL needs to be reached so that no results are still being fetched from the cache of DNS servers across the globe.
Now we know roughly how DNS works let’s look at the most common type of records
A (Host) records are the most simple records which translate domain names to IPs
eg www.google.com to 220.127.116.11
A CNAME (Canonical Name) record is different to an A record in that it maps a domain name to another domain name when no A record exists.
eg www.google.com to somethingelse.google.com
Typically Azure makes use of CNAMEs for many of its services especially adding a custom domain name
MX stands for Mail Exchange and is used for configuring email
Every domain has a number of Name Servers which tells you what servers control the DNS settings for that domain. If you change your Name Servers then the new Name servers will be where you can change your DNS settings.
Like A record but for ipv6
Want to put some different DNS records into practise? Buy a domain name and publish some content to it. Check out my previous post about programmatically adding records. Want an SSL certificate? Get a wildcard one and then you can apply it to any subdomain you add to your domain.
If you have a new website you want to publish consider which of the following is better:
I much prefer the second option, it looks cleaner, there is no potential conflict with the parent site, no subfolder issues between production and development.