Domain Name System (DNS) plays an important role in the internet. It converts canonical names to ip addresses and is vital in traffic routing on the net. DNS Resolution is a vast topic and that will not be able to be covered completely in this article. Instead I will mention the most important steps to make a website live from a server where you have bought a hosting account.

DNS Resolution

You need to register a Website like newdomain.com, newdomain.org, newdomain.biz, newdomain.hosting, etc. Nowadays there are a lot of new TLD like .work, .hosting etc. from any of the Domain registrars. Most common ones are like Godday.com, Domain.com, NameCheap.com, Bluehost.com
Once you purchase the domain name from the above registrar , now we need to find a Hosting account (either it can be a shared hosting/ reseller hosting or a VPS/dedicated server) . If you are having a shared/reseller account, then mostly they will provide us with a pair of name servers which should be used to point the domain to their servers. IF you are purchasing a vps/dedicated servers, then we may have to setup the server with DNS server for which we mainly use Named or Bind Packages.
If you are using registrar name servers itself, then you need to create all dns records manually in that panel. If you are using a cpanel / plesk shared hosting, mostly they will have all dns records created while creating the account and you just need to point the name servers of the hosting provider at the registrar end.
Once pointed it may take upto 24 - 72 hours to get the changes propagated throughout the internet.

Understanding the DNS Records

DNS records are settings which help us to point a domain and it variety of services to those proper servers or IP address. Dns records act as a instructor like that domain is pointing to that ip, that subdomain is pointing to another ip etc. Without proper DNS records humans will have to remember the IP address and remembering an ipaddress will be a tedious tasks an thats how the importance of DNS comes in to play.

We dont have to remember a IP address as it will be always be an issue for humans to use IP address to go to website. Thats why we register the domain name and use dns to have it pointed correctly to the hosting server. Before DNS servers or packages were created , one will have to type the IP address in the browser and have to remember the same as well. With the introduction of IPV6 it is literally impossible to remember the IP address even for those who have the best memory capacity.

There are more than 70 + dns records and you can read the below link for all possible DNS records and its details

https://www.iana.org/assignments/dns-parameters/dns-parameters.xml

I am discussing the below records which are most needed for a layman to get his site hosted and email flow smoothly.

SOA Record
TTL Value
A Record
AAAA Record
NS Record
MX Record
TXT Record
SPF Record
DKIM Record
DMARC Record
PTR Record
CNAME Record
SRV Record
RP Record
DNSKEY Records

1. SOA (START OF AUTHORITY ) Record

SOA record is the most important and yet not so popular record. It is a must record for a DNS zone file to work and give results to us. This particular record will have the name of the zone , email address of the responsible person handling the domain's Zone file, Current Serial number , primary or main nameserver for the zone, and some time elements which are measured and displayed in seconds.

Below is a sample SOA Record

domain.com. 86400 IN SOA ns1.domain.com. owneremail.domain.com. (
2017100505 ;Serial Number
3600 ;refresh
7200 ;retry
1209600 ;expire
86400 )
Exact format for this is the below
@ IN SOA primary-name-server hostmaster-email (
serial-number
time-to-refresh
time-to-retry
time-to-expire
minimum-TTL )

Primary-name-server : It shows the nameserver which contains the original dns records.

Hostmaster-email : Email address of the owner who is responsible for the domain. A Period “.” will be used replacing a @ symbol. For email address which have a “.” already in that will be escaped with a “/”.

Serial-number : It is the version number of the Zone and it will keep on increasing with each update of the Zone file.

Time-to-refresh : This value shows the time to wait for checking for a serial number update. This is mainly needed when you are having a secondary dns or dns cluster which needs to check for an update on master file and needs to be copied the latest one to the other servers in cluster. Only applies to those who have secondary dns or cluster setup.

Time-to-retry : It determines how long should a nameserver wait for retrying the refresh if the last attempt failed.Only applies to those who have secondary dns or cluster setup.

Time-to-expire : it determines how long should we need to wait before considering the data from the secondary or other cluster nameservers invalid and stop responding to the queries for the respective zone.

minimum-TTL : How long should a nameserver or resolvers should cache a negative response.

2. TTL (Time to Live) Value

TTL value is the time in seconds that a dns records will be cached by an outside dns server or nameserver and after that it should refresh it cache and have the latest value . Main importance of this is while you are planning a migration, and needs dns changes without any dns down time. Changes to nameservers can always cause downtime as we do not have control on those. So before migration we normally change the TTL value to 300 sec 1 - 2 days prior itself so that after migration we will change the nameserver ip 's in the registrar end and also will change the IP's of all zone files in old server to new ip's so that it will start resolving to new server in both cases that is if the dns gets to old server, then it will point the domain from that server to new server and if the newly updated nameservers are taken, then also it will start loading from new server.

If no ttl value is not mentioned, then this will be the main default value for all dns records unless we have another value specified in the records.

Sample entry
$TTL 14400

3. A Record

A record is also known as Address Records or Host Records. This is mainly used to point the domain/Subdomain etc to the server ip address. A record only resolves to a ip address and no other arguments /variables are there in the A record. A records are used only to point to a IPV4 address.

Sample A Record is the below one
domain.com. 14400 IN A 192.168.1.1

Also we can use a wildcard dns record which will load all subdomains to one ip

*.domain.com 14400 IN A 192.168.1.1

4. AAAA Record

AAAA record is same as the above Record and purpose and use of this record is all same. Only difference is this is used to point the domain to a IPV6 IP and if the domain is having a IPv6 version as well, then we need to have this A record as well pointed .

Sample AAAA Record is the below

domain.com 14400 IN AAAA 0133:4237:89bc:cddf:0123:4267:89ab:cddf

5. NS (Name Server) Record

Ideal situation will be both Nameserver at registrar level and dns zone file are same and mismatched ns records can cause some issues with some ISP but normally that mismatch is not that an issue. So Primary nameserver records should be there in both registrar and dns zone file in the server which is mentioned in registrar.

Sample Entry
domain.com. 86400 IN NS ns1.maindomain.com.
domain.com. 86400 IN NS ns2.maindomain.com.

When you are having the nameservers for the same domain, then make sure you add A records for these nameservers .In the above example it is using some other registerd nameserver like ns1.maindomain.com. But if you wish to use ns1.domain.com itself as nameeserver in registrar and server, you need to setup HOST records in the registar (which is the GLUE Record) and need to Add the below A records as well

ns1 14400 IN A 192.168.1.1
ns2 14400 IN A 192.168.1.1

6. MX (Mail Exchange ) Record

This is another important dns record which determines the fate of your incoming mails to a domain. When someone send a mail to an email account under a domain, the remote server will be sending mails to the server which is mentioned in the MX records and that to with the lowest value in priority which in fact is having the highest priority

Sample MX records

domain.com      14400      IN MX      10 mail_1.domain.com
domain.com      14400      IN MX      20 mail_2.domain.com
domain.com      14400      IN MX      30 mail_3.domain.com

In this example, if mail_1.domain.com is down, mail will be delivered to mail_2.domain.com. If mail_2.example.com is also down, mail will be delivered to mail_3.domain.com.This is mainly used when you have domain added in multiple servers and have mail configured in those. But those mails will get scattered to those servers and you may have to manually check those.

If you are using the MX records having the same domain name, then you need to add proper dns A records. Like the below . But if you are using google apps, outlook etc, then no need to add additional A record for those as you dont have the control on those and those should be added by those providers.

mail_1      14400 IN     A      192.168.1.1
mail_2      14400 IN     A      192.168.1.2
mail_3      14400 IN     A      192.168.1.3

7. TXT (Text) Record

A TXT record or text record actually do not have any role on domains functionality and it is usually used for displaying some info or used for some verifications like when you sign up with google apps or Outlook Mail service, then they will ask you to add a TXT record which they ask (a unique code) so that they can verify the domain ownership. SPF/DKIM records also is based on TXT but they have a functionality to perform. These may be also be used as an option to authenticate your ownership while adding to google webmaster account and other google related services as well.

Below is a sample dns entry for google verification

domain.com. 300 IN TXT google-site-verification=gBmnBtGTIz_esMKJBKT-PxLH50M

8. SPF ( Sender Policy Framework ) Record

SPF record is basically a TXT record, which normally publish all it designated mail servers for a domain or subdomain. Main use of this record is to prove the legitimacy of the mails and prevent spoofed mails. A destination mail server can reject mails if those are not from the registered or mentioned mail servers based on this record.

Sample Entry
domain.com. IN TXT "v=spf1 +a +mx +ip4:192.168.1.5 -all"

This says this domain will be sending legitimate mails only from A record, MX record servers, and also from ip 192.168.1.5 and all others can be rejected . With the above SPF record, the receving server will be checking all servers and ipaddress which is mentioned in the SPF. If ip address match, the check will be passed, and if not it will hard fail (message will be rejected automatically) and if we use “~all” which is a soft fail which is message will be marked as FAIL but will not be rejected.

You can refer more sytanx from this link.

9. DKIM (DomainKeys Identified Mail)Record

This is also a TXT record which is a email authentication protocol as well which is a bit more complicated than SPF. This record is created a for a subdomain which have a unique selector for the key and then will have a “.” By adding such a record, it will add a digital signature to the headers of the email message. This signature is validated using the DKIM record published public key. This a bit complicated and if you are in cpanel, they provde an option to get this done easily using one click enable option.

Sample Entry
default._domainkey 14400 IN TXT "v=DKIM1; k=rsa;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmDb9e2q41oLc0ZDtSNo2Ik4khVMUMkv98N1Y0
FehUCcFUIUIUIUIUIuiuicfhdyeytrytrryuytytfyfyfytrytrytrtyrytrytrytrytrytdyBQ3XatuaEj
qGR0zfaY6RSU++gqGF8ZRpjJd+O3AcqRZT4ZT8d7Uhye6Ctgcv3kQEd5I2dTSpodIzWey8reysHJMdCvulRJYdP"
UWj5PrHfkwY7ec0ZNggTOpmlByXIPRx0Q/oBS9TLlAs785XJMNWjubyyjC6V5JUQ+tRyhwa28TWM/l6/EIcYNBZE
fWx8oHQsBFLT0dNsRhq9ExX0UDMmbddD0zWoKtx+Wb7ItG0HPPVqne8jWkeXQIDAQAB\;

10. DMARC Record

DMARC record works only if there is proper SPF and SKIM records. It is a policy of its mail authentication process and how the receiving server should handle the mail if this violates the policy. When an incoming mail comes in the remote server, it will query for its DMARC record and make sure they query the below questions

> Is the incoming mails DKIM signature proper ones ?
> Did the message came from an authorized ip/server hostname as mentioned by the SPF record.
> Whether the header of the incoming mails have prpoper alignment as per the RFC 5322.

Sample Entry

_dmarc.domain.com. IN TXT "v=DMARC1\; p=none\; rua=mailto:[email protected]\;
ruf=mailto:[email protected]\; pct=100"

_dmarc.domain.com : Subdomain which is setup for authentication of DMARC Alone.

v=DMARC1 : Dmarc Version in use.

p=none : mentions about the preferred treatment of the policy

rua=mailto:[email protected] : Aggregrate reports are send to this one

ruf=mailto:[email protected] : Foreincsic reports should be sent to this email account

pct=100: this is the percentage of mails which the owner wish to have the record checked and used for policy updates

DMARC/SPF/DKIM is all needed for a proper authentication for mail services

11. PTR (Pointer) Record

PTR records are also known as Reverse DNS for the ip. PTR records are normally setup at the Hosting Provider or Server Provider level. PTR records helps us to match an ip address to a domain or a subdomain (normally to a FQDN fully qualified domain name) which will help to function the reverse dns queries to work properly.

So as a pre requesite to set reverse dns for an ip, now a days Hosting / Server Providers ask first to SET up A record for the domain/Subdomain to that IP and once that is done, Data center will setup the RDNS (Reverse DNS record).

12.CNAME (Canonical Name) Record

CNAME record helps to point a domain or subdomain to another domain or subdomain.

Sample entry :
newdomain.com 14400 IN CNAME domain.com.
mail 14400 IN CNAME mail.domain.com.

Example 1, is pointing the newdomain.com to domain.com where as the second example is pointing mail.newdomain.com to mail.domain.com. With this records, when a request comes to newdomain.com, it will find a CNAME record to domain.com. After that it will start a new lookup for domain.com and it will send the request to domain.com and same is the case with the second record as well.

13.SRV (Service) Record

SRV record helps us to point to a particular service that is running on your domain or subdomain to a target domain. This helps us to direct traffic for particular services like Chat server or messaging services to anothr server.

Sample Entry :

_sipfederationtls._tcp. 3600 IN SRV 100 1 5061 sipfed.online.lync.com.
_service._protocol.example.com 3600 IN SRV 10 0 5060 service.example.com
_service._proto.name. TTL class SRV priority weight port target.

Service : name of the services must be started with an underscore “_” and will be followed by a “.” service could be any thing like _chat, _xmpp, _sipfederationtls (which is used for microsoft exchange servers) etc.

Protocol :Name of the protocol also should be starting with an underscore and then a “.” in this case it is “_tcp.” and it tell us it is a TCP protocol which is in use.

Name : Name or Domain name is the domain which will recieve original traffic for this service.

Priority : It is the first number mentioned in the above examples (100 and 10 respectively ) helps you to set the priority for the target server and Lower number means higher priority. This is similar to MX record priority and works similarly as we can setup another record as fall back as well with another priority.

Weight : If we create similar records with same priority then the deciding factor will this particular value. Weight is 1 and 0 respectively in the above examples.

Port : this shows the TCP or UDP port on which the service is running.

Target : this is the target subdomain or domain to which this service will be redirected and it should have a valid A / AAAA record to have this traffic redirected to there.

14. RP (Responsible Person) Record

This is normally not needed now a days as there is an email address associated with the SOA Record. But if any domain wish to have specifically need to mention apart from the default SOA record email account, then we can add a RP Record.

15. DNSKEY Record

DNSkey record contains a public key that will be used by the resolvers to verify dnssec signatures.

Sample entry

domain.com. 300 IN DNSKEY 257 3 5 Z10wdRIHGJGGIUGIUGKUOIKHpouptYRSyrsYRDfYTpoPO
ipoEUofZcndFN2aVd==
Name ttl class RRtype flags_filed Protocol Algorithm public_key

Name : it is the domain name or hostname normally

IN : Represent the record class and default one is IN (which means Internet )

Record Type : record type is the type of the record and in this case it will be DNSKEY

Flags : Flags filed is in a wired format which is a 2 byte long character. Possible values are 0, 256 and 257. If the value is 256 , it means that dnskey record holds ZSK (Zone-signing key) paid and if the value is 257, then it contains KSK (key-signing keycomponent. In short this fielf contains an ODD number when it hold a KSK key pair.

Protocol: This always has a value of 3, for DNSSEC.

Public Key : public key is the key data and in this case it is “Z10wdRIHGJGGIUGIUGKUOIKHpouptYRSyrsYRDfYTpoPOipoEUofZcndFN2aVd==”

Algorithm : Helps us to identify public_keys using different algorithms and below are the most used ones

1 = RSA/MD5
2 = Diffie-Hellman (This is not supported by BIND )
3 = DSA
4 = Reserved
5 = RSA/SHA1
6 = DSA/SHA1/NSEC3
7 = RSA/SHA1/NSEC3
8 = RSA/SHA-256
10 = RSA/SHA-512

Conclusion

I hope this really helps all of you understand DNS and ensure your hosting is setup correctly.

DNS Resolution Basics Needed for Web Hosting