There was a problem loading the comments.

DNS Host Record Management

Support Portal  »  Knowledgebase  »  Viewing Article

  Print
The Domain Name System [DNS] is a distributed database, arranged hierarchically, containing records for domain names. The DNS system's main aim is to match a domain name to an IP Address. In order to fulfill this role, the DNS Server contains Records [called Resource Records] in a Zone File, which contains the domain name and IP address mappings for computers contained within that Zone. This zone file is also referred to as 'DNS Zone'.

DNS Host Record Management (ManagedDNS) is a DNS zone file containing the domain's NS, A, AAAA, CNAME, MX, MXE, TXT, URL Redirect hosted at web-hosting-independent, Anycast, Redundant nameservers. Some of reasons why DNS Host Record Management is used are to

  1. Redirect a domain to URL without setting up web hosting or a full DNS record-set
  2. Setup DNS record-set independent of the web hosting server infrastructure
    (*Advanced level - requires at a minimum replication of DNS records at web hosting server and manually updating them here whenever you make a change at the server)

  3. Cloud VPS Application hosting
    (*Advanced level - you prefer to setup DNS records here, than on your Cloud VPS to save resources or for redundancy)

  4. Dedicated Server hosting
    (*Advanced level - you prefer to setup DNS records here, than on your Cloud VPS to save resources or for redundancy)

  5. Email Hosting
    (*Advanced level - this domain only hosts my emails without a website, so I need to point domain to my GSuite or ZohoMail or Exchange Server or Business Email server)

DNS Host Record Types & Syntax

All Resource Records have a TTL [Time To Live], specifying the number of seconds other DNS servers and applications are allowed to cache the record.

IPv4 Address Record [ A Record ]
The A Record is the most basic and the most important DNS record type. They are used to translate human friendly domain names such as "domain.com" into IPV4 addresses such as "1.2.3.4" (machine friendly numbers). This results in the domain becoming a Fully Qualified Domain Name (FQDN)

example.com A 123.345.567.789
hello.example.com A 123.345.567.789



Mail Exchanger [ MX Record ]
A MX Record identifies the mail server(s) responsible for a domain name. When sending an e-mail to user@xyz.com, your mail server must first look up the MX Record for xyz.com to see which mail server actually handles mail for xyz.com (this could be mail.xyz.com - or someone else's mail server like mail.isp.com). Then it looks up the A Record for the mail server to connect to its IP-address.

A MX Record has a Preference number indicating the order in which the mail server should be used (only relevant when multiple MX Records are defined for the same domain name). Mail servers will attempt to deliver mail to the server with the lowest preference number first, and if unsuccessful continue with the next lowest and so on.

example.com MX 10 mail_1.example.com
example.com MX 20 mail_2.example.com
example.com MX 30 mail_3.example.com



Canonical Name [Alias or CNAME Record ]

CNAME Records are domain name aliases. Often computers on the Internet have multiple functions such as Web Server, FTP Server, Chat Server, etc. To mask this, CNAME Records can be used, to give a single-computer multiple-names (aliases).

Sometimes companies register multiple brand-specific domains for a single website. In such cases, a CNAME Record maybe used to forward traffic to their actual website. For example, www.abc.in could be CNAME to abc.com.

The most popular use of the CNAME Record type, is to provide access to a Web Server using both the standard www.domain.com and domain.com (short name). This is usually done by adding a CNAME-record for the www name pointing to the short name [while creating an A Record for the short name making it a FQDN (Fully Qualified Domain Name) ].

CNAME Records can also be used when a computer or service needs to be renamed, to temporarily allow access through both the old and new name.

www.alias.com CNAME domain.com.
example.com CNAME domain.com.



Authoritative Name Server [ NS Record ]

NS Records identify authoritative nameservers responsible for a domain. Each DNS Zone should contain one NS Record for each of its own nameservers (primary and secondaries). This mostly is used for Zone Transfer purposes (notify). These NS Records have the same name as the Zone in which they are located.

But the most important function of the NS Record is Delegation. Delegation means that part of a DNS Zone is delegated to other nameservers.

You can also delegate sub-domains of your own domain name (such as subdomain.yourname.com) to other nameservers. An NS Record identifies the name of a nameserver, not the IP Address. Because of this, it is important that an A Record for the referenced nameserver exists.

If a NS Record delegates a sub-domain (subdomain.yourname.com) to a nameserver with a name in that sub-domain (ns1.subdomain.yourname.com), an A Record for that server (ns1.subdomain.yourname.com) must exist in the Parent Zone (yourname.com). This A Record is referred to as a Glue Record, because it doesn't really belong in the Parent Zone, but is necessary to locate the DNS Server for the delegated sub-domain.

example.com NS ns1.indichosts.net.
example.com NS ns2.indichosts.net.
example.com NS ns3.indichosts.net.
example.com NS ns4.indichosts.net.
example.com NS ns5.indichosts.net.



Text [ TXT Record ]

A TXT record or text record provides information about the domain in question to other resources on the internet. It’s a flexible type of DNS record that can serve many different purposes depending on the specific contents. One common use of the TXT record is to create an SPF record on nameservers that don’t natively support SPF. Another use is to create a DKIM record for mail signing.

A TXT Record can store upto 255 characters of free form text. This record is generally used to convey information about the zone. Multiple TXT records are permitted but their order is not necessarily retained.

Sender Policy Framework (SPF)
Sender Policy Framework is an extension to the Simple Mail Transfer Protocol (SMTP). SPF allows software to identify and reject forged addresses in the SMTP MAIL FROM (Return-Path), a typical nuisance in e-mail spam. SPF allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain. The technology requires two sides to work in tandem
  1. the domain owner publishes this information in an TXT Record in the domain's DNS zone, and when someone else's mail server receives a message claiming to come from that domain, then
  2. the receiving server can check whether the message complies with the domain's stated policy. If, for example, the message comes from an unknown server, it can be considered a fake.
example.com TXT "v=spf1 a ~all"

DominKeys (DKIM)
A DKIM record or DomainKeys Identified Mail record displays the public key for authenticating messages that have been signed with the DKIM protocol. This practice increases the capability to check mail authenticity. A typical DKIM record looks like the following:

selector1._domainkey.example.com TXT k=rsa;p=J8eTBu224i086iK

DKIM records are implemented as text records. The record must be created for a subdomain, which has a unique selector for that key, then a period (.), and then _domainkey.example.com. The type is TXT, and the value includes the type of key, followed by the actual key.



Start of Authority [ SOA RECORD ]

Each Zone contains one SOA Record, which holds the following parameters for the Zone -
  • Name of Primary DNS Server - The domain name of the Primary DNS Server for the Zone. The Zone should contain a matching NS Record.
  • Mailbox of the Responsible Person - The email address of the person responsible for maintenance of the Zone.
  • Serial Number - Used by Secondary DNS Servers to check if the Zone has changed. If the Serial Number is higher than what the Secondary Server has, a Zone Transfer will be initiated. This number is automatically increased by our Servers when changes to the Zone or its Records are made.
  • Refresh Interval - How often Secondary DNS Servers should check if changes are made to the zone.
  • Retry Interval - How often Secondary DNS Server should retry checking, if changes are made - if the first refresh fails.
  • Expire Interval - How long the Zone will be valid after a refresh. Secondary Servers will discard the Zone if no refresh could be made within this interval.
  • Minimum (Default) TTL - Used as the default TTL for new records created within the zone. Also used by other DNS Server to cache negative responses (such as record does not exist, etc.).
@ IN SOA ns1.indichosts.net. admin.example.com. 2013062147 14400 14400 1209600 86400


IPv6 Address Record [ AAAA Record ]
The AAAA Record is the most basic and the most important DNS record type. They are used to translate human friendly domain names such as "domain.com" into IPV6 addresses such as "2604:880:205:40:0:0:0:2" (machine friendly numbers). This results in the domain becoming a Fully Qualified Domain Name (FQDN)

example.com A 2604:880:205:40::2
hello.example.com A 2604:880:205:40::2



Service SRV
An SRV record or service record matches up a specific service that runs on your domain or subdomain to a target domain. This allows you to direct traffic for specific services, like instant messaging, to another server. A typical SRV record looks like the following:

_service._protocol.example.com SRV 10 0 5060 service.example.com

Here’s a breakdown of the elements in an SRV record:

  • Service: The name of the service must be preceded by an underscore (_) and followed by a period (.). The service could be something like _xmpp.
  • Protocol: The name of the protocol must be preceded by an underscore (_) and followed by a period (.). The protocol could be something like _tcp.
  • Domain: The name of the domain that will receive the original traffic for this service.
  • Priority: The first number (10 in the example above) allows you to set the priority for the target server. You can set different targets with different priorities, which allows you to have a fallback server (or servers) for that service. Lower numbers have a higher priority.
  • Weight: If two records have the same priority, weight is used instead.
  • Port: The TCP or UDP port on which the service runs.
  • Target: The target domain or subdomain. This domain must have an A or AAAA record that resolves to an IP address.
An example use of SRV records would be to set up VoIP.

Share via
Did you find this article useful?  

Related Articles


Comments

Add Comment

Replying to  


Self-Hosted Help Desk Software by SupportPal
© Indichosts.net