What is DNS Records? - Definition from Codetextpro


What is DNS Records?


What are DNS Records?


DNS records or Zone files are used for mapping URLs to an IPs. Located on servers called the DNS servers, these records are typically the connection of your website with the outside world. Requests for your website are forwarded to your DNS servers and then get pointed to the WebServers that serve the website or to Email servers that handle the incoming email.


Different Types of DNS Records With Syntax and Examples
Types of DNS Records/ DNS records types
DNS zone types
A
AAAA
CNAME
MX
PTR
NS
SOA
SRV

The above DNS records are mostly used in all DNS Configurations. Now we will see each one with examples.

A Record

An A record or address record.

Address Record assigns an IP address to a domain or subdomain name. When the domain name system was designed it was recommended that no two A records refer to the same IP address.
Suppose you have some domain.TLD domain and want to assign 10.10.0.1 IP address to your web server, then you should create an A record with "www.somedomain.tld" as Fully Qualified Domain Name and "10.10.0.1" in the Value field.

From now on, all the requests for www.somedomain.tld will be sent to a server with that IP.

Basically is useful to use an A record when you have subdomains residing on various systems.

Useful tip: you might use a "*.somedomain.TLD" A record to allow WHATEVER.somedomain.tld to be resolved to your IP, though a wildcard CNAME record is often better than a wildcard A record.


Example of A Record with Syntax

example.com. IN A 69.9.64.11




Where

IN indicates Internet

A indicates the Address record.

The above example indicates that the IP Address for the domain example.com is 69.9.64.11

AAAA Record

An AAAA record or IPv6 address record maps a hostname to a 128-bit IPv6 address.

The regular DNS Address resource record is defined for a 32-bit IPv4 address, so a new one was created to allow a domain name to be associated with a 128-bit IPv6 address. The four “A”s (“AAAA”) are a mnemonic to indicate that the IPv6 address is four times the size of the IPv4 address. The AAAA record is structured in very much the same way as the A record in both binary and master file formats; it is just much larger. The DNS resource record Type value for AAAA is 28.

Example of AAAA Record with Syntax

The AAAA record is to help transition and coexistence between IPv4 and IPv6 networks.An IPv4 nameserver can provide IPv6 addresses:

linux aaaa 3ffe:1900:4545:2:02d0:09ff:fef7:6d2c

CNAME Record

A CNAME record or canonical name record makes one domain name an alias of another. The aliased domain gets all the subdomains and DNS records of the original.

You should use a CNAME record whenever you want to associate a new subdomain to an already existing A record; i.e. you can make "www.somedomain.tld" to "somedomain.tld", which should already have been assigned an IP with an A record.

This allows you to have as many subdomains as you wish without having to specify the IP for every record. Use a CNAME if you have more services pointing to the same IP. This way you will have to update only one record in the convenience of a change of IP address.

Example of a CNAME record: "stuff.everybox.com CNAME www.everybox.com" where 'www.everybox.com' is an A record listing an IP address, and 'stuff.everybox.com' points to 'www.everybox.com'. It will NOT allow you to forward a domain to a specific web page. Use a webshop for that. Port numbers can be changed with webshops, as well; CNAMEs cannot change the HTTP default of 80 to any other port number.

Do not use CNAME defined hostnames in MX records. For example, this is not recommended

Example Of CNAME With syntax
mail.example.com IN CNAME mail.example.net

where

IN indicates Internet

CNAME indicates a CNAME record.

MX Record

An MX record or mail exchange record maps a domain name to a list of mail exchange servers for that domain.

Example with MX Record Syntax - Single mail servers

mydomain.com. 14400 IN MX 0 mydomain.com.

The MX record shows that all emails @ mydomain.com should be routed to the mail server at mydomain.com. The DNS record shows that mydomain.com is located at 26.34.9.14. This means that email meant for test@mydomain.com will be routed to the email server at 26.34.9.14. This finishes the task of the MX record. The email server on that server then takes over, collects the email and then proceeds to distribute it to the user ``test''.

It is important that there be a dot(``.'') after the domain name in the MX record. If the dot is absent, it routes to ``mydomain.com.mydomain.com''. The number 0, indicates Preferance number. Mail is always routed to the server which has the lowest Preference number. If there is only one mail server, it is safe to mark it 0.

Using Multiple mail servers

If you want to use multiple mail servers you have to use MX record preferences. The MX record preference values indicate which mail server to use and in which order to try them when they fail or don't respond. A larger preference number is less preferred. Thus, a mail exchanger with a preference of zero (0) is always preferred over all other mail exchangers. Setting preference values to equal numbers makes mail servers equally preferred.




Example with MX Record Syntax - Multiple mail servers

mydomain.com. 14400 IN MX 0 mydomain.com.
mydomain.com. 14400 IN MX 30 server2.mydomain.com

You can have unlimited MX entries for Fallback or backup purpose. If all the MX records are equal Preference numbers, the client simply attempts all equal Preference servers in random order, and then goes to MX record with the next highest Preference number.



PTR Record

A PTR record or pointer record maps an IPv4 address to the canonical name for that host. Setting up a PTR record for a hostname in the in-addr. arpa domain that corresponds to an IP address implements reverse DNS lookup for that address. For example www.name.net has the IP address 122.0.3.16, but a PTR record maps 16.3.0.122.in-addr.arpa.


Example of PTR Record with syntax

16.3.0.122.in-addr.arpa. IN PTR name.net

Here as you see the IP Address is reversed and added within-addr.arpa and this has come to the left side while the actual domain name has gone to the right side of IN PTR.

This is mostly used as a security and an anti-spam measure wherein most of the webservers or the email servers do a reverse DNS lookup to check if the host is actually coming from where it claims to come from. It is always advisable to have a proper reverse DNS record (PTR) is been setup for your servers especially when you are running a mail / SMTP server.


NS Record

An NS record or name server record maps a domain name to a list of DNS servers authoritative for that domain. Delegations depend on NS records.

NS Record Name Server Record which indicates the Authoritative Name Servers for a particular Domain. The NS records of the Authoritative Name Server for any given Domain will be listed on the Parent Server. These are called the Delegation Records as these records on the Parent Server indicates the delegation of the domain to the Authoritative servers.

The NS record will also be listed in the Zone records of the Authoritative Name Server itself. These records are called as the Authoritative Records.


The NS records found on the Parent Server should match the NS records on the Authoritative Server as well. However, you can have NS records listed on the Authoritative server that is not listed in the Parent Server. This arrangement is normally used to configure Stealth Name Servers.

Example of NS Record With syntax
example.com. IN NS ns1.live.secure.com.

where

IN indicates the Internet

NS indicates the type of record which Name Server record

The above indicates that the ns1.live.secure.com is the authoritative server for the domain example.com


SOA Record

An SOA record or start of authority record specifies the DNS server providing authoritative information about an Internet domain, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone.

An SOA(State of Authority) Record is the most essential part of a Zone file. The SOA record is a way for the Domain Administrator to give out simple information about the domain like, how often it is updated when it was last updated when to check back for more info, what is the admins' email address and so on. A Zone file can contain only one SOA Record.

A properly optimized and updated SOA record can reduce bandwidth between nameservers, increase the speed of website access and ensure the site is alive even when the primary DNS server is down.



Example of SOA Record with syntax

Here is the SOA record. Notice the starting bracket ``(``. This has to be on the same line, otherwise, the record gets broken.

; name TTL class rr Nameserver email-address
mydomain.com. 14400 IN SOA ns.mynameserver.com. root.ns.mynameserver.com. (
2004123001; Serial number
86000; Refresh rate in seconds
7200; Update Retry in seconds
3600000; Expiry in seconds
600; minimum in seconds )

name - mydomain.com is the main name in this zone.

TTL - 14400 - TTL defines the duration in seconds that the record may be cached by client-side programs. If it is set as 0, it indicates that the record should not be cached. The range is defined to be between 0 to 2147483647 (close to 68 years !).
Class - IN - The class shows the type of record. IN equates to the Internet. Other options are all historic. So as long as your DNS is on the Internet or Intranet, you must use IN.
Nameserver - ns.nameserver.com. - The nameserver is the server which holds the zone files. It can be either an external server in which case, the entire domain name must be specified followed by a dot. In case it is defined in this zone file, then it can be written as ``ns''.
Email address - root.ns.nameserver.com. - This is the email of the domain name administrator. Now, this is really confusing, because people expect an @ to be in an email address. However, in this case, email is sent to root@ns.nameserver.com but written as root.ns.nameserver.com. And yes, remember to put the dot behind the domain name.

Serial number - 2004123001 - This is a sort of a revision numbering system to show the changes made to the DNS Zone. This number has to increment, whenever any change is made to the Zone file. The standard convention is to use the date of update YYYYMMDDnn, where nn is a revision number in case more than one updates are done in a day. So if the first update was done today would be 2005301200 and second update would be 2005301201.
Refresh - 86000 - This is time(in seconds) when the slave DNS server will refresh from the master. This value represents how often a secondary will poll the primary server to see if the serial number for the zone has increased (so it knows to request a new copy of the data for the zone). It can be written as ``23h88M'' indicating 23 hours and 88 minutes. If you have a regular Internet server, you can keep it between 6 to 24 hours.

Retry - 7200 - Now assume that a slave tried to contact the master server and failed to contact it because it was down. The Retry value (time in seconds) will tell it when to get back. This value is not very important and can be a fraction of the refresh value.

Expiry - 3600000 - This is the time (in seconds) that a slave server will keep a cached zone file as valid if it can't contact the primary server. If this value were set to say 2 weeks ( in seconds), what it means is that a slave would still be able to give out domain information from its cached zone file for 2 weeks, without anyone knowing the difference. The recommended value is between 2 to 4 weeks.
Minimum - 600 - This is the default time(in seconds) that the slave servers should cache the Zone file. This is the most important time field in the SOA Record. If your DNS information keeps changing, keep it down to a day or less. Otherwise, if your DNS record doesn't change regularly, step it up between 1 to 5 days. The benefit of keeping this value high is that your website speeds increase drastically as a result of reduced lookups. Caching servers around the globe would cache your records and this improves site performance.


SRV Record

The theory behind SRV is that given a known domain name e.g. example.com, a given service e.g. web (Http) which runs on TCP in this case, a DNS query may be issued to find the hostname that provides such on behalf of the domain - and which may or may not be within the domain.
Example of SRV Record with syntax
srvce.prot.name TTL class rr pri weight port target
_http._tcp.example.com. IN SRV 0 5 80 www.example.com.

srvce

Defines the symbolic service name (see IANA port-numbers) prepended with a '_' (underscore). Case insensitive. Common values are:

_http - web service
_ftp - file transfer service
_ldap - LDAP service

prot

Defines the protocol name (see IANA service-names) prepended with a '_' (underscore). Case insensitive. Common values are

_tcp - TCP protocol
_udp - UDP protocol

name

Incomprehensible description in RFC 2782. Leaving the entry blank (without a dot) will substitute the current zone root (the $ORIGIN), or you can explicitly add it as in the above _http._tcp.example.com. (with a dot).

TTL

Standard TTL parameter. For more information about TTL values.



pri

The relative Priority of this service (range 0 - 65535). Lowest is the highest priority.

weight

Used when more than one service with the same priority. A 16-bit unsigned integer in the range 0 - 65535. The value 0 indicates no weighting should be applied. If the weight is 1 or greater it is a relative number in which the highest is most frequently delivered i.e. given two SRV records both with Priority = 0, one with weight = 1 the other weight = 6, the one with weight 6 will have its RR delivered the first 6 times out of 7 by the name server.

port

Normally the port number assigned to the symbolic service but does this is not a requirement e.g. it is permissible to define an _http service with a port number of 8100 rather than the more normal port 80.

target
The name of the host that will provide this service. Does not have to be in the same zone (domain). 






Post a Comment

0 Comments