©2019 Security Unleashed | New Delhi

  • Animesh Gupta

DNS RECORDS





DNS stands for Domain Name System, which is the largest digital database in the world, containing information about every web site on the internet. Every web site online has an IP address that is its actual internet location, and this number is used to locate the web site within the database.  The data that tells the web server how to respond to your input is known as the DNS records, or zone files. These records play a vital role in the functionality of the internet, and any aspiring internet technology expert should learn the following facts about DNS records and how they are used.


DNS Records Explained


DNS records are basically mapping files that tell the DNS server which IP address each domain is associated with, and how to handle requests sent to each domain. When someone visits a web site, a request is sent to the DNS server and then forwarded to the web server provided by a web hosting company, which contain the data contained on the site.

Various strings of letters are used as commands that dictate the actions of the DNS server, and these strings of commands are called DNS syntax.  Some DNS records syntax that are commonly used in nearly all DNS record configurations are A, AAAA, CNAME, MX, PTR, NS, SOA, SRV, TXT, and NAPTR. The following paragraph details the meaning and usage of each of these syntax.


A-Records (Host address)


The A-record is the most basic and the most commonly used DNS record type.

It is used to translate human friendly domain names such as "www.example.com" into IP-addresses such as 23.211.43.53 (machine friendly numbers).

A-records are the DNS server equivalent of the hosts file - a simple domain name to IP-address mapping.

A-records are not required for all computers, but are needed for any computer that provides shared resources on a network.

To create a new A-record, right-click a zone in the left list of DNS Records window, and select "New A-record" from the pop-up menu.

This record type is defined in RFC1035.


AAAA-Records (IPv6 host address)


An AAAA-record is used to specify the IPv6 address for a host (equivalent of the A-record type for IPv4).IPv6 is the future replacement for the current IP address system (also known as IPv4).

The current IPv4 addresses are 32 bits long ( x . x . x . x = 4 bytes), and therefore "only" support a total of 4,294,967,296 addresses - less than the global population.

With this limitation there is an increasing shortage of IPv4 addresses, and to solve the problem, the whole Internet will eventually be migrated to IPv6.


IPv6 addresses are 128 bits long and are written in hexadecimal numbers separated by colons (:) at every four digits (segment).A series of zero value segments can be shortened as "::", and leading zeros in a segment can be skipped.


For example: 4C2F::1:2:3:4:567:89AB.


To create a new AAAA-record, right-click a zone in the left list in the DNS Records window, and select "New AAAA-record" from the pop-up menu.

This record type is defined in RFC3596.

AFSDB-Records (AFS Data Base location)


An AFSDB-record maps a domain name to an AFS (Andrew File System) database server.

The server name points to an A-record for the database server, and the sub-type indicates server type:

1 = AFS version 3.0 volume location server for the named AFS cell.

2 = DCE authenticated server.

To create a new AFSDB-record, right-click a zone in the left list in the DNS Records window, and select "Other new record" from the pop-up menu.

This record type is defined in RFC1183.


ALIAS-Records (Auto Resolved Alias)

ALIAS-records are virtual alias records resolved by Simple DNS Plus at at the time of each request - providing "flattened" (no CNAME-record chain) synthesized records with data from a hidden source name.

This can be used for different purposes - including solving the classic problem with CNAME-records at the domain apex (for the zone name / for "the naked domain").

To create a new ALIAS-record, right-click a zone in the left list of DNS Records window, and select "New ALIAS-record" from the pop-up menu.

ATMA-Records (Asynchronous Transfer Mode address)


An ATMA-record maps a domain name to an ATM address.


The ATM address can be specified in either E.164 format (decimal) or NSAP format (hexadecimal).

To create a new ATMA-record, right-click a zone in the left list in the DNS Records window, and select "Other new record" from the pop-up menu.

CAA-records (Certification Authority Authorization)


Allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain.

To create a new CAA-record, right-click a zone in the left list in the DNS Records window, and select "Other new record" from the pop-up menu.

This record type is defined in RFC6844.


CERT-Records (Certificate / CRL)


CERT-records store certificates and related revocation lists (CRL) for cryptographic keys.CERT-records have the following data elements (see RFC below for details):


Type: the type of certificate/CRL stored. Select one of the predefined values, or enter a numeric value (0-65535).

Key tag: A numeric value (0-65535) used the efficiently pick a CERT record.

Algorithm: the algorithm used .Select one of the predefined values, or enter a numeric value (0-65535).

Certificate or CRL: Base 64 encoded.


To create a new CERT-record, right-click a zone in the left list in the DNS Records window, and select "Other new record" from the pop-up menu.

This record type is defined in RFC4398.


CNAME-Records (Canonical name for an alias)


CNAME-records are domain name aliases.Computers on the Internet often performs multiple roles 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).


For example, the computer "computer1.xyz.com" may be both a web-server and an ftp-server, so two CNAME-records are defined:


"www.xyz.com" = "computer1.xyz.com" and "ftp.xyz.com" = "computer1.xyz.com".


Sometimes a single server computer hosts many different domain names (take ISPs), and so CNAME-records may be defined such as "www.abc.com" = "www.xyz.com".


The most common use of the CNAME-record type is to provide access to a web-server using both the standard "www.domain.com" and "domain.com" (with and without the www prefix).This is usually done by creating an A-record for the short name (without www), and a CNAME-record for the www name pointing to the short 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.

A CNAME-record should always point to an A-record and never to itself or another CNAME-record to avoid circular references. To create a new CNAME-record, right-click a zone in the left list in the DNS Records window, and select "New CNAME-record" from the pop-up menu.

Please note that you cannot create a CNAME-record for the zone name itself as this will always conflict with the zone's SOA-record. For more on this see https://simpledns.com/kb/158


This record type is defined in RFC1035.


DHCID-Records (DHCP Information)


DHCID-records store Dynamic Host Configuration Protocol (DHCP) Information, and can be created and used by some DHCP servers and clients.

You cannot create DHCID record through the Simple DNS Plus user interface - these records can only be added by DHCP servers/clients themselves through dynamic updates.

This record type is defined in RFC4701.


DNAME-Records (Non-Terminal DNS Name Redirection)


A DNAME-record is used to map / rename an entire sub-tree of the DNS name space to another domain.

It differs from the CNAME-record which maps only a single node of the name space.

To create a new DNAME-record, right-click a zone in the left list in the DNS Records window, and select "Other new record" from the pop-up menu.

This record type is defined in RFC2672.


DNSKEY-Records (DNSSEC Public Key)


A DNSKEY-record holds a public key that resolvers can use to verify DNSSEC signatures in RRSIG-records.


DNSKEY-records have the following data elements:


Flags: "Zone Key" (set for all DNSSEC keys) and "Secure Entry Point" (set for KSK and simple keys).


Protocol: Fixed value of 3 (for backwards compatibility)


Algorithm: The public key's cryptographic algorithm.


Public key: Public key data.


To add a DNSKEY-record to a zone, use the DNSSEC Sign Zone function.


This record type is defined in RFC4034.


DS-Records (Delegation Signer)


DS-records are used to secure delegations (DNSSEC).

A DS-record with the name of the sub-delegated zone is placed in the parent zone along with the delegating NS-records.

This DS-record references a DNSKEY-record in the sub-delegated zone.


DS-records have the following data elements:


Key Tag: A short numeric value which can help quickly identify the referenced DNSKEY-record.


Algorithm: The algorithm of the referenced DNSKEY-record.


Digest Type: Cryptographic hash algorithm used to create the Digest value.


Digest: A cryptographic hash value of the referenced DNSKEY-record.


To create a new DS-record, right-click a zone in the left list of DNS Records window, and select "Other new record" from the pop-up menu.


This record type is defined in RFC4034.


HINFO-Records (Host information)


A HINFO-record specifies the host / server's type of CPU and operating system.

This information can be used by application protocols such as FTP, which use special procedures when communicating with computers of a known CPU and operating system type.

Standard CPU and operating system types are defined in RFC1700 (Page 206 / 214).The standard for a Windows PC is "INTEL-386" / "WIN32".


To create a new HINFO-record, right-click a zone in the left list in the DNS Records window, and select "Other new record" from the pop-up menu.


This record type is defined in RFC1035.

ISDN-Records (ISDN address)


The ISDN-record maps a domain name to an ISDN (Integrated Services Digital Network) telephone number.


The ISDN phone numbers / DDI (Direct Dial In) used should follow ITU-T E.163/E.164 international telephone numbering standards.


For example: 12121234567 ( 1=USA, 212=Manhattan New York area code, 1234567=number)


The ISDN sub-address is an optional hexadecimal number.


To create a new ISDN-record, right-click a zone in the left list in the DNS Records window, and select "Other new record" from the pop-up menu.


This record type is defined in RFC1183.


LOC-Records (Location Information)


This record type is used to specify geographical location information about hosts, networks, and subnets.


A LOC-record describes a location with the following properties:


Latitude / Longitude.


Altitude.


Size (diameter of the location described).


Horizontal / Vertical precision of the data.


Because of the binary storage format used, only the first digit of the size and precision properties can be non-zero.

To create a new LOC-record, right-click a zone in the left list in the DNS Records window, and select "Other new record" from the pop-up menu.


This record type is defined in RFC1876.


MB, MG, MINFO, MR Records (Mailbox Records)


IMPORTANT: Most Internet e-mail servers only support MX-records.

Only use MB, MG, MINFO and MR records if you have specific requirements for these.


MB-records (Mailbox)


Maps a mailbox to a host (server).

The host must be a valid A-record already defined (in the same zone or elsewhere).


MG-records (Mail group member)


Used to specify mail group members (one MG-record per member).

Each member mailbox must be identical to a valid mailbox (MB-record).

MINFO-records (Mailbox or mail list information)

Specifies the mailbox of the responsible person and optionally a mailbox for errors for this mailbox or list.

Each mailbox must be the same as a valid mailbox (MB-record) that already exist in the zone.


MR-records (Renamed mailbox)


Specifies a renamed mailbox.

An MR-record can be used as a forwarding entry for a user who has moved to a different mailbox.


To create a new mailbox record, right-click a zone in the left list in the DNS

Records window, and select "Other new record" from the pop-up menu.


These record types are defined in RFC1035.

MX-Records (Mail exchange)


MX-records are used to specify the e-mail server(s) responsible for a domain name.


Each MX-record points to the name of an e-mail server and holds a preference number for that server.


If a domain name is handled by multiple e-mail servers (for backup/redundancy), a separate MX-record is used for each e-mail server, and the preference numbers then determine in which order (lower numbers first) these servers should be used by other e-mail servers.


If a domain name is handled by a single e-mail server, only one MX-record is needed and the preference number does not matter.

When sending an e-mail to "user@example.com", your e-mail server must first look up any MX-records for "example.com" to see which e-mail servers handles incoming e-mail for "example.com".

This could be "mail.example.com" or someone else's mail server like "mail.isp.com".


After this it looks up the A-record for that e-mail server name to connect to its IP-address. Do not point an MX-record to a CNAME-record. Many e-mail servers don't understand this. Add another A-record instead.

To create a new MX-record, right-click a zone in the left list in the DNS Records window, and select "New MX-record" from the pop-up menu.


This record type is defined in RFC1035.


NAPTR-Records (Naming Authority Pointer)


NAPTR-records are used to store rules used by DDDS (Dynamic Delegation Discovery System) applications.


One example is "ENUM" which allows an end user to type a telephone number into e.g. a web browser and access a listing of Internet resources (URI) for that number, such as addresses for IP telephony, e-mail or web sites.


The "Order" field is a number (0 to 65535) specifying the order in which multiple NAPTR records must be processed (low to high) by the application.


The "Preference" field is equivalent to the Priority value in the DDDS algorithm. It is a number (0-65535) that specifies the order (low to high) in which NAPTR records with equal Order values should be processed.


The "Flags" field contains flags to control aspects of the rewriting and interpretation of the fields in the record. Flags are single characters from the set A-Z and 0-9. The use of this field is specified by the individual DDDS application.


The "Services" field specifies the service parameters applicable to this delegation path. The individual DDDS application specifies the possible values for this field.


The "Reg. Exp." field contains a substitution expression that is applied to the original string held by the client in order to construct the next domain name to lookup. See the DDDS algorithm specification for the syntax of this field.


The "Replacement" field specifies the next domain name (fully qualified) to query for depending on the potential values found in the flags field. This field is used when the regular expression is empty (a simple replacement operation). The "Reg.Exp." and "Replacement" fields are mutually exclusive (only one can contain a value).


To create a new NAPTR-record, right-click a zone in the left list in the DNS Records window, and select "Other new record" from the pop-up menu.


This record type is defined in RFC3403.


NS-Records (Authoritative name server)


NS-records identify the DNS servers responsible (authoritative) for a zone.

A zone should contain one NS-record for each of its own DNS servers (primary and secondaries).This is mostly used for zone transfer purposes (notify messages).These NS-records have the same name as the zone in which they are located.The more important function of the NS-record is delegation.


Delegation means that part of a domain is delegated to other DNS servers.


For example, all ".com" sub-names (such as "example.com") are delegated from the "com" zone.


The "com" zone contains NS-records for all ".com" sub-names (a lot!).


You can delegate sub-names of your own domain name (such as "subname.example.com") to other DNS servers the same way.


To delegate "subname.example.com", create NS-records for "subname.example.com" in the "example.com" zone.


These NS-records must point to the DNS server responsible for "subname.example.com", for example, "ns1.subname.example.com" - or a DNS server somewhere else like "ns1.othername.net".


An NS-record identifies the name of a DNS server - not the IP-address.Because of this, it is important that an A-record for the referenced DNS server exists (not necessarily on your DNS server, but wherever it belongs), otherwise there may not be any way to connect with that DNS server.

If an NS-record delegates a sub-name ("subname.example.com") to a DNS server with a name in that sub-name ("ns1.subname.example.com"), an A-record for that server (""ns1.subname.example.com") must exist in the parent zone ("example.com").

This A-record is called 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-name.

To create a new NS-record, right-click a zone in the left list in the DNS Records window, and select "New NS-record" from the pop-up menu.


This record type is defined in RFC1035.

NSAP-Records (NSAP address)


An NSAP-record maps a domain name to an NSAP address.

The NSAP address is entered using hexadecimal digits - any NSAP address format is allowed.

To create a new NSAP-record, right-click a zone in the left list in the DNS Records window, and select "Other new record" from the pop-up menu.

This record type is defined in RFC1706.

NSEC-Records (Next Secure)


An NSEC-record links to the next record name in the zone (in DNSSEC sorting order) and lists the record types that exist for the record's name.

These records can be used by resolvers to verify the non-existence of a record name and type as part of DNSSEC validation.


NSEC-records have the following data elements:


Next domain name: The next record name in the zone (DNSSEC sorting order)


Record types: The DNS record types that exist for the name of this NSEC-record.


To add NSEC-records to a zone, use the DNSSEC Sign Zone function.


This record type is defined in RFC4034.

NSEC3-Records (Next Secure v. 3)


An NSEC3-record links to the next record name in the zone (in hashed name sorting order) and lists the record types that exist for the name covered by the hash value in the first label of the NSEC3 -record's own name.


These records can be used by resolvers to verify the non-existence of a record name and type as part of DNSSEC validation.


NSEC3-records have the same functionality as NSEC-records, except NSEC3 uses cryptographically hashed record names to prevent enumeration of the record names in a zone.


NSEC3-records have the following data elements:


Hash Algorithm: The cryptographic hash algorithm used.


Flags: "Opt-out" (indicates if delegations are signed or not).


Iterations: How many times the hash algorithm is applied.


Salt: Salt value for the hash calculation.


Next Hashed Owner Name: The name of the next record in the zone (in hashed name sorting order).


Record Types: The record types that exist for the name covered by the hash value in the first label of the NSEC3 -record's own name.


To add NSEC3-records to a zone, use the DNSSEC Sign Zone function.


This record type is defined in RFC5155.


PTR-Records (domain name pointer)


PTR-records are primarily used as "reverse records" - to map IP addresses to domain names (reverse of A-records and AAAA-records).

For a reverse IPv4 mapping, the name of the PTR-record is the IP address with the segments reversed and with "in-addr.arpa" appended to the end.


As an example, looking up the domain name for IP address "12.23.34.45" is done with a query for the PTR-record for "45.34.23.12.in-addr.arpa".


For a reverse IPv6 mapping, the name of the PTR-record is each hex digit of the IP address in reverse order, with dots between each digit, and with "ip6.arpa" appended to the end.


As an example, looking up the domain name for IPv6 address "1234:5678:90ab:cdef:1234:5678:90ab:cdef" is done with a query for the PTR-record for "f.e.d.c.b.a.0.9.8.7.6.5.4.3.2.1.f.e.d.c.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa".


For more information see the section on Reverse DNS.


To create a PTR-record use one of the following options:


The Reverse zone IP-to-Name Mappings dialog.


The "Update Reverse Zone" check box in the Record Properties dialog for an A-record or AAAA-record.


Right-click a reverse zone in the DNS Records window, and select "New PTR-record" from the pop-up menu.


This record type is defined in RFC1035.

RP-Records (Responsible person)


An RP-record specifies the mailbox of the person responsible for a host (domain name).

A SOA-record defines the responsible person for an entire zone, but a zone may contain many individual hosts / domain names for which different people are responsible.

The RP-record type makes it possible to identify the responsible person for individual host names contained within the zone.

Optionally specify the domain name for a TXT-record with additional information (such as phone and address).

To create a new RP-record, right-click a zone in the left list in the DNS Records window, and select "Other new record" from the pop-up menu.


This record type is defined in RFC1183.

RRSIG-Records (RRset Signature)


An RRSIG-record holds a DNSSEC signature for a record set (one or more DNS records with the same name and type).Resolvers can verify the signature with a public key stored in a DNSKEY-record.


RRSIG-records have the following data elements:


Type Covered: DNS record type that this signature covers.


Algorithm: Cryptographic algorithm used to create the signature.


Labels: Number of labels in the original RRSIG-record name (used to validate wildcards).


Original TTL: TTL value of the covered record set.


Signature Expiration: When the signature expires.


Signature Inception: When the signature was created.


Key Tag: A short numeric value which can help quickly identify the DNSKEY-record which can be used to validate this signature.


Signer's Name: Name of the DNSKEY-record which can be used to validate this signature.


Signature: Cryptographic signature.


To add RRSIG-records to a zone, use the DNSSEC Sign Zone function.


This record type is defined in RFC4034.



RT-Records (Route through)


An RT-record specifies an intermediate host that provides routing to the host with the name of the RT-record.A preference value is used to set priority if multiple intermediate routing hosts are specified - lower values tried first.


For each intermediate host specified, a corresponding host (A) address resource record is needed in the current zone. To create a new RT-record, right-click a zone in the left list in the DNS Records window, and select "Other new record" from the pop-up menu.


This record type is defined in RFC1183.


SOA-Records (Start of authority)


A zone contains exactly one SOA-record, which holds the following properties for the zone:


Name of primary DNS server


The host name of the primary DNS server for the zone.


The zone should contain a matching NS-record.


NOTE: For dynamic updates from Windows clients and Active Directory to work correctly, it is important that this contains the correct host name for the primary DNS server for the zone, and also that an A-record exists for this name pointing to the correct IP address.


E-mail address of responsible person


The e-mail address of the person responsible for the zone.


The standard for this is the "hostmaster" alias - such as "hostmaster@example.com".


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 Simple DNS Plus when changes are made to the zone or its records (happens when you save the zone).


Unless you have a specific reason for changing this number, it is best to let Simple DNS Plus manage it.


You should never decrease a serial number.


Refresh Interval (see Zone Transfers)


How often secondary DNS servers should check if changes are made to the zone.


Retry Interval (see Zone Transfers)


How often secondary DNS server should retry checking if changes are made - if the first refresh fails.


Expire Interval (see Zone Transfers)


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 by other DNS servers to cache negative responses (such as record does not exist etc.).


A SOA-record is automatically created when you create a new zone.


This record type is defined in RFC1035.


SRV-Records (location of service)


SRV-records are used to specify the location of a service.


They are used in connection with different directory servers such as LDAP (Lightweight Directory Access Protocol), and Windows Active Directory, and more recently with SIP servers (see https://simpledns.com/kb/112).


They can also be used for advanced load balancing and to specify specific ports for services, for example, that a web-server is running on port 8080 instead of the usual port 80 (theoretical example - this is not yet supported by any major browsers).


This record type is however NOT supported by most programs in use today, including web-browsers.


The SRV record identification (record name) is made of of 3 parts:


Service: Most internet services are defined in RFC1700 (page 15).


Protocol: Generally TCP or UDP, but also values are also valid.


Domain name.


The "service location" is specified through a priority, weight, port and target:


Priority is a preference number used when more servers are providing the same service (lower numbers are tried first).


Weight is used for advanced load balancing.


Port is the TCP/UDP port number on the server that provides this service.


Target is the domain name of the server (referencing an A-record or AAAA-record).


To create a new SRV-record, right-click a zone in the left list in the DNS Records window, and select "Other new record" from the pop-up menu.


This record type is defined in RFC2782.


TLSA-Records (Transport Layer Security Authentication)

TLSA records are used to specify the keys used in a domain's TLS servers.

The TLSA record identification (record name) is made of of 3 parts:

  • Port number: The port number that the TLS server listens on.

  • Protocol: The protocol used (udp, tcp, sctp, or user defined).

  • Server host name: Host name of the TLS server.

TLSA-records have the following data elements (see RFC below for details):

  • Certificate usage: A numeric value (0-255).

  • Selector: A numeric value (0-255).

  • Matching type: A numeric value (0-255).

  • Certificate association data: Hexadecimal.

To create a new TLSA-record, right-click a zone in the left list in the DNS Records window, and select "Other new record" from the pop-up menu.

This record type is defined in RFC6698.


TXT-Records (Descriptive text)


TXT-records are used to hold descriptive text.


They are often used to hold general information about a domain name such as who is hosting it, contact person, phone numbers, etc.


One common use of TXT-records is for SPF (see http://www.openspf.org).


To create a new TXT-record, right-click a zone in the left list in the DNS Records window, and select "New TXT-record" from the pop-up menu.


This record type is defined in RFC1035.

X25-Records (X.25 PSDN address)

An X25-records maps a domain name to a Public Switched Data Network (PSDN) address number.

Numbers used with this record should follow the X.121 international numbering plan.


To create a new X25-record, right-click a zone in the left list in the DNS Records window, and select "Other new record" from the pop-up menu.

This record type is defined in RFC1183.

1 view