A RecordsIn order to associate a domain name with an IP address, it's usually necessary to use A records. These can be in the form of many different host names and subdomains. This is done by declaring a record - such as mail.techopedia.com or www.techopedia.com or ntp.techopedia.com. In this case, "mail", "www" or "ntp" would be the defined A records. These might point at any IPv4 IP address, such as 18.104.22.168. Looking up which IP address is associated with a domain name in this way occurs through a forward DNS lookup, or query.
AAAA RecordsAs IPv6 becomes more prevalent, the AAAA record (or "quad-A") will become more popular. This is simply the IPv6 equivalent of the IPv4 version, and it differs because IPv6 uses 128-bit addresses. This means that AAAA records are notated using eight groups of 16-bit values, such as: fe80::226:18ff:fed3:cc2a. (Learn more about the new IP infrastructure in The Trouble With IPv6.)
CNAME RecordsCanonical records (CNAMEs) are useful for pointing one host name at another. This eliminates the need for explicitly declaring an IP address and means that the IP address can be changed once rather than twice if a CNAME record simply points at an already established host name, as shown in the following example:
Here, cname.techopedia.com will also return the IP address 22.214.171.124 as it points at hostname.techopedia.com.
hostname.techopedia.com 126.96.36.199 cname.techopedia.com hostname.techopedia.com
MX RecordsMX records are those that are looked up by mail servers when email needs to be delivered. They will usually make up more than one mail server for reliability, but this is not always the case, and may be a breach of Request for Comments (RFCs). Configured using a simple hierarchy, an administrator can define which mail server should receive mail first and so on. An example might be as follows, where Priority 5 is the preferred mail delivery host with IP Address 188.8.131.52:
mail1.techopedia.com 5 184.108.40.206 mail2.techopedia.com 10 220.127.116.11 mail3.techopedia.com 20 18.104.22.168
NS RecordsAt the root server level, it's important that there is an authoritative name server configured to respond to queries against a particular domain name. Each domain name should have name server records set up in order to function; using too few name servers may breach RFCs. An example held on a WHOIS record might look like this, where ns1 returns the IP address 22.214.171.124 and so on.
ns1.techopedia.com 126.96.36.199 ns2.techopedia.com 188.8.131.52
SOA RecordsEach DNS zone (or publicly announced configuration of DNS settings) must contain some indication of how the delegated DNS entries are run. The Start of Authority (SOA) record can show the primary name server for the domain name, the serial number (this should be when the last revision was made to the DNS configuration for the zone if it's shown in the correctly specified date format), and other pertinent information relating to how the zone is run by the administrator.
RPAlso shown inside the SOA record is an email address of whom to contact, or the responsible person (RP), in the event of a misconfiguration or some other issue relating to the DNS zone. This might be something like email@example.com.
TTLWithin the SOA, it's important to announce how other machines should react when communicating with the authoritative name servers for a DNS zone. Such an example might be:
Here we see the domain name for techopedia.com's primary name server is ns10.dnsmadeeasy.com and that the human contact is firstname.lastname@example.org (note the @ sign is never shown in an SOA entry but is instead implied). Finally, we can see its serial number (suggesting in this case that salient changes haven't been made since 2009), followed by a number of time to live (TTL) values that control how long data received from a name server might be trusted before being considered stale, among other things.
techopedia.com has SOA record ns10.dnsmadeeasy.com. dns.dnsmadeeasy.com. 2009010181 43200 3600 1209600 180
SPF RecordsWith the ever problematic unsolicited mail issue on the Internet, one common method of combating it was to use DNS to declare which outbound mail servers were allowed to send mail from a domain name. A Sender Policy Framework (SPF) record might look like this for that reason:
Here we see a list of machines allowed to send email and some IP addresses as well.
techopedia.com has SPF record "v=spf1 mx ptr ip4:184.108.40.206 ip4:220.127.116.11 a:list.janalta.com a:webmail1.janalta.coma:list.technewsletters.com include:_spf.google.com ~all"
TXT RecordsThese records can be used for a number of purposes, but a good example can been seen here:
Google's site verification system has obviously needed a way to identify that a particular domain name or host name belongs to an administrator during a configuration process request. In this case, it has asked for DNS entries to be created to authenticate that request. Google most likely assumes that only the owner of the domain name will have access to the name servers responsible for running the domain name and therefore, only they will be able to makes DNS changes to the domain name.
techopedia.com descriptive text "google-site-verification=3gxUc6RH0WccwA6LNaDwENjhKlfUydMOVMtmCIOJBnE" techopedia.com descriptive text "google-site-verification=C_-veU9lL8A7lVTeFpxNDiuW4dwjhcpittNkfCa83bA"
DNSKEY RecordsBecause security is so important on the Internet, including when it comes to the pervasive DNS, DNSSEC was created to bolster the domain name system. The DNSKEY record is a cryptography method for declaring configuration for security and may look like this:
ripe.net has DNSKEY record 257 3 5 AwEAAXf2xwi4s5Q1WHpQVy/kZGyY4BMyg8eJYbROOv3YyH1U8fDwmv6k BVxWZntYtYUOU0rk+Y7vZCvSN1AcYy0/ZjL7cNlkc3Ordl2DialFHPI6 UbSQkIp3l/5fSWw5xnbnZ8KA7g3E6fkADNIEarMI4ARCWlouk8GpQHt1 1wNW1c65SWB8i958WZJ6LI0pOTNK+BIx8u98b+EVr7C08dPpr9V6Eu/7 3uiPsUqCyRqMLotRFBwK8KgvF9KO1c9MXjtmJxDT067oJoNBIK+gvSO9 QcGaRxuGEEFWvCbaTvgbK4E0OoIXRjZriJj8LXXLBEJen6N0iUzj8nqy XSCm5sNxrRk=
Regional Authorities and in-addr.arpaIn order to provide data for reverse DNS lookups (where an IP address is converted into a domain name, instead of the other way round) IPv4 uses in-addr.arpa. Separate from the root servers running the delegated forward DNS for domain names, the reverse DNS is configured by five regional Internet registries (RIRs), each of which is responsible for a certain geographic region.
An example PTR (or pointer) record delegated by an RIR to an authoritative name server that is ready to answer reverse DNS queries might be as follows. Notice that the notation is reversed:
The five global RIRs are:
- African Network Information Center (AfriNIC)
- American Registry for Internet Numbers (ARIN)
- Asia-Pacific Network Information Center (APNIC)
- Latin America and Caribbean Network Information Center (LACNIC)
- NCC Réseaux IP Européens Network Coordination Center (RIPE)