Sometimes you need to add a specific DNS Record in most common cases, the clients are using the Custom DNS for a test website, for a specific app, or even sometimes clients use specific servers to store images or media files. If the client has several servers, in some cases they use subdomains to identify servers. If you purchase a domain and want to use our NS servers, then this "How to" also will be useful.
DNS records serve to facilitate domain name translation and help visitors reach your website online. When a domain is created, all the necessary DNS records are added automatically. However, Amber IT also enables you to add custom DNS records, as explained below.
To add a custom DNS record to the domain’s DNS zone, go to Websites & Domains > DNS Settings > Add Record.
Once you click Add Record. then you can choose the record type. A, AAAA, NS, CNAME, MX, PTR, TXT, SRV, DS, and CA.
About the records:
An A record maps a domain name to the IP address (Version 4) of the computer hosting the domain. An A record uses a domain name to find the IP address of a computer connected to the internet
The A in A record stands for Address. Whenever you visit a web site, send an email, connect to Twitter or Facebook, or do almost anything on the Internet, the address you enter is a series of words connected with dots.
For example, to access the Amber IT GIT website you enter
www.amberit.in. At our hosting name server, there’s an A record that points to the IP address
22.214.171.124. This means that a request from your browser to
www.amberit.i is directed to the server with IP address
A Records are the simplest type of DNS records, and one of the primary records used in DNS servers.
You can do a lot with A records, including using multiple A records for the same domain in order to provide redundancy and fallbacks. Additionally, multiple names could point to the same address, in which case each would have its own A record pointing to that same IP address.
An AAAA record maps a domain name to the IP address (Version 6) of the computer hosting the domain. An AAAA record is used to find the IP address of a computer connected to the internet from a name.
The AAAA record is conceptually similar to the A record, but it allows you to specify the IPv6 address of the server, rather than the IPv4.
AAAA records are less common than A records, however, their popularity is rising along with the increased adoption of IPv6 addresses. For example, all the DNSimple name servers are assigned to an IPv6 address and can be queried via either IPv4 or IPv6.
As with the A records, you can use multiple AAAA records for the same domain in order to provide redundancy. Multiple names could point to the same address, in which case each would have its own AAAA record pointing to that same IP address.
An NS Record delegates a subdomain to a set of name servers. Whenever you delegate a domain to www.amberit.in, the TLD authorities place NS records for your domain in the TLD name servers pointing to us. For example, there are the following entries delegating amberit.in to our name servers in the .in name servers:
amberit.in. 172800 IN NS aron.ns.cloudflare.com. amberit.in. 172800 IN NS sid.ns.cloudflare.com.
Amber IT automatically publish NS records in our authoritative name servers for each domain we’re authoritative for. These NS records will appear in the System Records section of each domain’s Manage page.
CNAME records can be used to alias one name to another. CNAME stands for Canonical Name.
A common example is when you have both
www.example.com pointing to the same application and hosted by the same server. To avoid maintaining two different records, it’s common to create:
example.compointing to the server IP address
As a result,
example.com points to the server IP address, and
www.example.com points to the same address via
example.com. If the IP address changes, you only need to update it in one place: just edit the A record for
www.example.com automatically inherits the changes.
MX stands for Mail eXchange. MX Records tell email delivery agents where they should deliver your email. You can have many MX records for a domain. They provide a way to have redundancy and ensure email will always be delivered.
Google Apps provides a common example of using MX Records to deliver email. When you create a Google Apps account and you want your email to be delivered to your Google Apps mail account, Google provides a set of MX records you need to add to Amber IT. Here are the default MX records Google suggests:
Google provides you with 5 different servers that can accept your email. Each MX record includes a priority value, which is a relative value compared to the other priorities of MX records for your domain. Addresses with lower values will be used first. Therefore, when a mail agent wants to deliver an email to you, it would first attempt to deliver to
aspmx.l.google.com. If that server can’t handle the delivery, it would move onto
alt1.aspmx.l.google.com. If that server can’t handle the delivery, it would move onto
alt2.aspmx.l.google.com, and so on.
MX records make it easy to define what servers should handle email delivery. They allow you to provide multiple servers for maximum redundancy and ensured delivery.
Domain Name System Security Extensions (DNSSEC) add digital signatures to a domain name's DNS (Domain Name System) to determine the authenticity of the source domain name. It's designed to protect Internet users from forged DNS data, such as a misleading or malicious address instead of the legitimate address that was requested.
When DNSSEC is enabled, DNS lookups use a digital signature to verify that the source of your site's DNS is valid. This helps prevent certain types of attacks; if the digital signature does not match, browsers will not display the site. Click Here to read more
A Certificate Authority (CA) (or Certification Authority) is an entity that issues digital certificates.
The digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or assertions made by the private key that corresponds to the public key that is certified.
In this model of trust relationships, a CA is a trusted third party that is trusted by both the subject (owner) of the certificate and the party relying upon the certificate.
In the context of a website, when we use the term digital certificate we often refer to SSL certificates. The CA is the authority responsible for issuing SSL certificates publicly trusted by web browsers.
Anyone can issue SSL certificates, but those certificates would not be trusted automatically by web browsers. Certificates such as these are called self-signed. The CA has the responsibility to validate the entity behind an SSL certificate request and, upon successful validation, the ability to issue publicly trusted SSL certificates that will be accepted by web browsers. Essentially, the browser vendors rely on CAs to validate the entity behind a web site.