DNS is a global system for translating human-readable domain names to IP addresses. When a user tries to access a web address like "example.com", their web browser or application performs a DNS Query against a DNS server, supplying the hostname. The DNS server takes the hostname and resolves it into a numeric IP address, which the web browser can connect to.
A component called a DNS Resolver is responsible for checking if the hostname is available in the local cache, and if not, contacts a series of DNS Name Servers, until eventually it receives the IP of the service the user is trying to reach and returns it to the browser or application. This usually takes less than a second.
Before anything else, it is important to know that your domain registrar is where the entire process begins. Your domain registrar is normally the place where you purchased/obtained your domain. Your registrar could be a business that only does domain registration or even your web host itself.
The registrar is the first piece of our puzzle because whenever a request for a domain is made, the registrar is the first place that gets referenced for information. As it pertains to loading a website, the most important part of the response is what set of "nameservers" the domain is pointed at.
Websites like http://who.is can help you identify your domain's registrar.
You can change your domain's registrar through a transfer process. In general, changing registrars is not necessary to modify your domain's DNS records.
A domain's nameservers are significant because they identify what set of servers any requests should reference in order to obtain a domain's DNS records. Your domain should have its nameservers pointed to wherever you are intending to manage your site's DNS records.
You can point your domain's nameservers anywhere that you can manage DNS, though. This means that if your domain's registrar allows you to manage DNS with them, then you can point nameservers at your registrar's nameservers and use their DNS management panel to set records. If you are interested in having your DNS hosted somewhere other than your web host or registrar, then hosted DNS is a good solution for you if you can find a service offering that fits your need and capacity requirements (e.g. AWS Route 53 that is a scalable cloud DNS web service).
Your domain's nameservers will likely need to change in the following cases:
You have just purchased a domain and need to point nameservers at your web host. The default nameservers when purchasing a domain are normally the ones operated by the domain registrar.
You are currently managing your DNS records at your registrar and want your host to manage them instead.
You have nameservers pointed at a web host that you are transitioning away from. It is necessary to change nameservers because closing your hosting account will also remove your DNS records at that host so you will want to point them elsewhere.
One of the most important things to note when changing nameservers is that they are a setting that can take a while to take effect across the world. In most cases, nameservers will take between 1 and 10 hours to spread across a majority of servers across the world, but you should allow as long as 36 hours for them to take fully.
This is quite a vital piece of knowledge because it is entirely possible to have two different sets of DNS records on two different sets of nameservers. If nameservers have taken effect in some parts of the world, but not others, then you may have some visitors seeing the site on old DNS records and some on new ones.
There are three types of queries in the DNS system:
Recursive Query: In a recursive query, a DNS client provides a hostname, and the DNS Resolver "must" provide an answer - it responds with either a relevant resource record or an error message if it can't be found. The resolver starts a recursive query process, starting from the DNS Root Server until it finds the Authoritative Name Server that holds the IP address and other information for the requested hostname.
Iterative Query: In an iterative query, a DNS client provides a hostname, and the DNS Resolver returns the best answer it can. If the DNS resolver has the relevant DNS records in its cache, it returns them. If not, it refers the DNS client to the Root Server or another Authoritative Name Server which is nearest to the required DNS zone. The DNS client must then repeat the query directly against the DNS server it was referred to.
Non-Recursive Query: A non-recursive query is a query in which the DNS Resolver already knows the answer. It either immediately returns a DNS record because it already stores it in the local cache, or queries a DNS Name Server which is authoritative for the record, meaning it definitely holds the correct IP for that hostname. In both cases, there is no need for additional rounds of queries (like in recursive or iterative queries). Rather, a response is immediately returned to the client.
The following are the most common DNS server types that are used to resolve hostnames into IP addresses.
A DNS resolver (recursive resolver), is designed to receive DNS queries, which include a human-readable hostname such as www.example.com, and is responsible for tracking the IP address for that hostname.
The root server is the first step in the journey from hostname to IP address. The DNS Root Server extracts the Top Level Domain (TLD) from the user's query, for example, www.example.com and provides details for the .com TLD Name Server. In turn, that server will provide details for domains with the .com DNS zone, including "example.com".
There are 13 root servers worldwide, indicated by the letters A through M, operated by organizations like the Internet Systems Consortium, Verisign, ICANN, the University of Maryland, and the U.S. Army Research Lab.
Higher-level servers in the DNS hierarchy define which DNS server is the "authoritative" name server for a specific hostname, meaning that it holds the up-to-date information for that hostname.
The Authoritative Name Server is the last stop in the name server query - it takes the hostname and returns the correct IP address to the DNS Resolver (or if it cannot find the domain, returns the message
In general, most every DNS record requires at least three pieces of information:
- Record Name
- Record Type
- Record Value/Data
- Time to Live (TTL)
A DNS Record's name is the descriptor and effective subdomain of that entry. If you were adding a blog to your domain, you would create a DNS record and assign it the name "blog". This would mean that whenever a request attempts to use blog.larapulse.com, the DNS zone is queried for information about a DNS record with the name of "blog". Although you can assign whatever name you'd like to a record, there exist a few special cases you should be aware of.
Blank Name – A record that has nothing in the name slot gets used for all requests made to the base/naked form of the domain. To refer to a previous example, larapulse.com and www.larapulse.com are two different DNS records with separate values for their name. The www.larapulse.com DNS record uses "www" as its record name and larapulse.com uses nothing/blank for its record name.
@ Symbol – Some DNS management systems use the @ symbol in the "name" slot instead of the blank name entry. This is important because it allows the use of @ as another record's value/data, meaning the other record will refer to the value of the base/naked form of the domain to know where to point.
Let's say for instance you always wanted www.larapulse.com to point at the same place as larapulse.com. You could just set them individually to point at the same place and manage them separately, but since the @ symbol represents the base/naked DNS record, you could set the www DNS record entry to have a value/data of @ and it will always refer to and use the value of the @ name record when being requested. This is useful when multiple subdomains/records need to all point at the same place as the base/naked domain.
* Symbol (Wildcard) – It isn't strange to see the * symbol be used as the name for a DNS record. This symbol is used as an indicator that the record named * should be used in place of any record that isn't specified. These can be used when you would like to direct subdomains that do not exist somewhere where they can be accounted for or handled. This means that you can specify where you would like to send all traffic for the subdomain that does not exist as a DNS record or that you might not expect people to visit. You could consider the * symbol to be the DNS record "for everything else".
DNS servers create a DNS record to provide important information about a domain or hostname, particularly its current IP address. The most common DNS record types are:
A Record: Address Mapping record: also known as a DNS host record, stores a hostname and its corresponding IPv4 address.
AAAA Record: IP Version 6 Address record: stores a hostname and its corresponding IPv6 address.
CNAME Record: Canonical Name record: specifies a domain name that has to be queried in order to resolve the original DNS query. Therefore it can be used to alias a hostname to another hostname.
MX Record: Mail exchanger record: specifies an SMTP email server for the domain a DNS domain name.
NS Record: Name Server records: specifies that a DNS Zone, such as "example.com" is delegated to a specific Authoritative Name Server, and provides the address of the name server.
SOA Record: Start of Authority: this record appears at the beginning of a DNS zone file and specifies core information about a DNS zone, such as Authoritative Name Server for the current DNS zone, contact details for the domain administrator, domain serial number, and information on how frequently DNS information for this zone should be refreshed.
TXT Record: Text Record: is used to store any text-based information that can be grabbed when necessary.
PTR Record: Reverse-lookup Pointer records: is used to look up domain names based on an IP address, and allows a DNS resolver to provide an IP address and receive a hostname (reverse DNS lookup).
CERT Record: Certificate record: store certificates and related revocation lists (CRL) for cryptographic keys.
SRV Record: Service Location: is used to specify the location of a service, like MX but for other communication protocols.
A DNS Record's value or data is the information that tells the DNS record where you want it to point, or in some cases, what you want it to do. In the case of
A Records and
CNAMEs, the data/value represents the IP or domain, respectively, that the record name is pointed at and should refer to figure out where to go next.
MX records, the value/data information indicates what mail servers email should be routed to.
SPF records use the value/data field so specify what servers are allowed to legitimately use your domain name for the sending of emails.
TTL is the numerical value, in seconds, of how long a DNS record will be cached before it needs to be refreshed. Whenever a nameserver is queried for a DNS record, it will check to see if it has delivered that same DNS record within the time period specified by the TTL and if so, will deliver the cached version of that DNS record. Once that period of time specified by the TTL passes, the nameserver will query the zone for record data and cache it once more for the specified period of time.
The most important thing to know about TTL is that any changes you make to the value/data of a DNS record are subject to that TTL in regard to how long it will take for that record to start taking effect.
TTL also applies to change the TTL itself in a record. For instance, if you are switching hosts and know you are going to need to change the IP address your domain points to, you might want to lower the TTL on your DNS records so that the switch over from your old host to new host happens as quickly as possible.
Simply changing the TTL from 3600 to 60 will not ensure that your IP change will take effect within 60 seconds, it simply indicates to your zone/nameservers that once they request a fresh set of information after the current 3600 second caching period, it should also adjust your TTL from that point on. This means that if you want to switch from a 3600 TTL to a 60 second TTL, you should make the TTL change at least 3600 seconds in advance of your IP change to ensure yourself the 60 second TTL period.
Interesting in reading more about Networks? Follow this link to find more articles 😉
Posted on Jan 13 by: