IPsec Framework

IPSEC, short for IP Security, is a suite of protocols, standards, and algorithms to secure traffic over an untrusted network, such as the Internet. IPSEC is supported on both Cisco IOS devices and PIX Firewalls.
IPsec is not a single protocol, but a framework for securing IP communications.

IPsec Overview

• We can add IPsec to IPv4 or IPv6 by using additional headers.
• IPsec can then both encrypt and authenticate each IP packet of a session between hosts on a LAN or across the internet.
• If we look at security tools in the TCP/IP stack, we see that IPsec provides security at the network layer and can protect a much wider range of application than SSL.

IPsec has four main components:

• Security protocols:
• The security protocols include the Authentication Header (AH). Now this provides support for data integrity and authentication of IP packets.
• And the Encapsulating Security Payload (ESP) provides a combination encryption and authentication of IP packets.
• Key Management:
• Key management can either use manual, which is practical for small static environments, or automated using the Internet Key Exchange (IKE) in an enterprise network.
• Security Associations:
• Security Associations is a relationship between two entities and describes the components for the entities including the security protocols, algorithms, and keys required for the services requested for either the Encapsulating Security Payload protocol or the Authentication Header process.
• Algorithms:
• Now, within the security association, you see several different algorithms.
• Algorithms are essential in providing the following: Key exchange, integrity, encryption, and authentication.

IPsec Benefits

• IPsec provides flexibility in how it’s set up and what level of security is required.
• IPsec can protect one or more paths that include host to host, gateway to gateway, and outside host to the gateway.
• Services IPsec can provide include access control, integrity, authentication, preventing replay attacks, and confidentiality.
• IPsec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services.
• IPsec can be used to protect one or more "paths" between a pair of hosts, between a pair of security gateways, or between a security gateway and a host.

IPsec Framework

• On the left-hand side, we see the encapsulating security payload protocol which includes encryption algorithms such as AES cipher-block chaining mode.
• On the right, we see the authentication header protocol, which includes authentication algorithms such as SHA-256.
• And because cryptographic techniques and algorithms rely on keys, encompassing all of this thing is key management.

IPsec is an internet exchange taskforce standard that outlines how we can configure a VPN to secure traffic across an insecure network.
Because IPsec works at the network layer, it can then protect upper layer traffic.

The IPSEC standard is outlined in RFC 2401.

IPsec services

IPsec provides many services. IPSEC provides below four core services:

• Confidentiality – prevents the theft of data, using encryption. By encrypting our data, nobody except the sender and receiver will be able to read our data.
• Integrity – ensures that data is not tampered or altered, using a hashing algorithm. We want to make sure that nobody changes the data in our packets. By calculating a hash value, the sender and receiver will be able to check if changes have been made to the packet.
• Authentication – confirms the identity of the host sending data, using pre-shared keys or a Certificate Authority (CA). The sender and receiver will authenticate each other to make sure that we are really talking with the device we intend to.
• Anti-replay – prevents duplication of encrypted packets, by assigning a unique sequencing number. Even if a packet is encrypted and authenticated, an attacker could try to capture these packets and send them again. By using sequence numbers, IPsec will not transmit any duplicate packets.

It provides:

• Confidentiality using encryption
• Integrity using hash algorithms
• Authentication using key exchange
• Secure key exchange using Diffie-Hellman.

Confidentiality and Encryption

Data sent in clear text across the Internet can easily be intercepted and stolen. Because of this, sensitive data should be encrypted when sent across an untrusted network or domain. Keys are generated values used to both encrypt and decrypt data. The longer the key, the more secure that key is. The length of a key is measured in bits.

Two types of keys exist:

• Symmetric keys can be used to both encrypt and decrypt data. More specifically, the same key is used to both encrypt a packet (at the sending device) and then decrypt that packet (at the receiving device). 
• Symmetric key encryption is efficient but does not scale well in large environments.
• Symmetric keys are not openly shared during data transmit and must instead be installed on each machine prior to the transfer of data. 
• This can be accomplished using a variety of (inefficient and insecure) methods: email, sneaker-net, and even snail-mail. 
• Each device on a network would require every other device’s symmetric key, and thus the lack of scalability.
• Asymmetric keys require a separate key for encryption (the public key) and decryption (the private key). 
• Public keys are openly exchanged between devices to encrypt data during transfer. 
• Private keys are never exchanged. Only the private keys can decrypt the data.
• Thus, even if the data and the public keys were intercepted, confidentiality is ensured.

Diffie-Hellman (D-H) Public Key Exchange is the most common standard used to create and exchange keys across insecure mediums. D-H is not used to encrypt data, but rather to generate the keys that are used to encrypt and decrypt data.
A variety of popular standards and protocols utilize D-H key exchange, including SSL (Secure Socket Layer), SSH (Secure Shell), and IPSEC.
The generated public keys encrypt data payload using one of several available encryption algorithms:

• DES (Data Encryption Standard) – 56-bit key
• 3DES (Triple Data Encryption Standard) – 168-bit key
• AES (Advanced Encryption Standard) - 128, 192, or 256-bit key
• Blowfish – up to a 448-bit key

Additionally, the strength of a key is determined by the D-H group used to generate that key. There are several D-H groups:

• Group 1 – 768 bits
• Group 2 – 1024 bits
• Group 5 – 2048 bits

Data Integrity and Hashing

Data sent across the Internet can not only be stolen but can also be maliciously altered.
To combat this, a hashing algorithm computes and appends a specific hash value as each packet is sent. Once the data is received, it is run through the hashing algorithm again. If the hash value is different, the packet was altered in transit.
Hashed Message Authentication Code (HMAC) is used to perform this hashing function. HMAC utilizes a secret key when computing the hash value, thus preventing an attacker from altering the packet and then recomputing the correct hash.
Two HMAC algorithms are commonly used:

• HMAC-MD5 (Message-Digest 5) – 128-bit hashed key
• HMAC-SHA1 (Secure Hash Algorithm) – 160-bit hashed key

Authentication using key exchange

Another concern when sending data across the Internet is the source or origin of that data. 

It is possible to masquerade or spoof one’s identity or address.
For an IPSEC VPN tunnel to be established, both sides of the tunnel must be authenticated. 
To accomplish this, either pre-shared keys or RSA digital signatures are used.

• When using pre-shared keys, a secret string of text is used on each device to authenticate each other. This string must be pre-agreed upon and identical on each device. This string is then hashed into a digital signature.
• When using RSA Digital signatures, a Certificate Authority (CA) is used to apply a verified digital signature. 

One of the above options must be correctly configured before the VPN tunnel will become active.

Certificate Authorities

Remember, two methods exist to authenticate an IPSEC tunnel:

• When using pre-shared keys, a secret string of text is used on each device to authenticate each other. This string must be pre-agreed upon and identical on each device. This string is then hashed into a digital signature.
• When using RSA Digital signatures, a Certificate Authority (CA) is used to apply a verified digital signature. This provides a more scalable solution than pre-shared keys.

The certificate process works as follows:

1. First, a client creates a “blank” or unsigned certificate, and sends it to the CA. Included on this blank certificate is the client’s ID. This communication is secured using a D-H private/public key exchange.
2. Next, the CA computes an encrypted hash, which is applied to the blank certificate. Thus, the certificate is now signed with the CA’s digital signature. The signed certificate is sent back to the client, where it is stored until it is deleted or expires.
3. The client then sends the signed certificate, along with its keys, to any VPN peers, “authenticating” its origin.

REMEMBER: Digital signatures, and Certificate Authority servers, are not used to encrypt data. Instead, the digital signatures are used to authenticate a device’s keys. Essentially, the digital signature gives the key a stamp of authenticity.

Obviously, one must “trust” the CA that signs these digital certificates. This is why third-party CAs are often used, such as VeriSign or Entrust.
Cisco IOS devices can function with several CA vendors:

• Microsoft Windows Certificate Services
• Entrust
• VeriSign

Regardless of the vendor chosen, the CA must support the Simple Certificate Enrollment Protocol (SCEP) to work with Cisco IOS devices.
This is available on the server Resource Kit for Windows Certificate Servers.

Configure IPsec

• The network administrator has flexibility in the way they can configure IPsec.
• During configuration, when preparing the site for IPsec, the device will list the most current options. And then once the network administrator has made the selection, IPsec will then create the security association.
• A security association is a relationship between two entities and describes the components for the entities, including the security protocols, algorithms and key required for the services requested.
• And then both sides must share the same security association.

Final IPsec Frameworks

As a framework, IPsec uses a variety of protocols to implement the features as described above. Here’s an final overview:

IPsec can be used on many different devices, it’s used on routers, firewalls, hosts and servers. Here are some examples how you can use it:

• Between two routers to create a site-to-site VPN that “bridges” two LANs together.
• Between a firewall and windows host for remote access VPN.
• Between two linux servers to protect an insecure protocol like telnet.

Key Management

Now, key management is also another consideration, and, in most cases, the network administrator will opt for dynamic key exchange, and this allows the VPN servers on each end of the connection to negotiate new keys at specified intervals using internet key exchange.
Now, Internet Key Exchange (IKE) is a protocol used to setup security association in IPsec.
This provides a standard method for dynamically authenticating IPsec peers, negotiating security services and generating shared keys.

IKE Functions
Internet Key Exchange (IKE) has two distinct functions.

• ISAKMP (Internet Security Association and Key Management Protocol, defines procedures for authenticating a communicating peer, and the creation and management of security association key generation techniques.
• Oakley is a key distribution process that supports perfect forward secrecy. Oakley allows the devices to exchange keys using Diffie-Hellman key exchange algorithm.

Now you have an idea of the basics of IPsec.
Now, in later section will take a closer look at each of the different components.

DNS Security

DNS Cache Poisoning Attack

DNS cache poisoning attack, which is also known as DNS spoofing attack.

• If you recall from our previous lesson on caching in the name resolution section, caching is used extensively in the DNS, with the aim to save network bandwidth and reduce lookup latency.
• The purpose of the DNS cache poisoning attack is to abuse the way DNS caches work by poisoning the resolver’s cache with the goal of achieving DNS spoofing.
• So that name lookups originated from a client, answered by a malicious actor who redirects, then use it to a fraudulent web page.
• That website would typically be a mirror of a legitimate site so that once the end users are redirected that they are tricked into taking a specific set of actions engineered by the attacker.
• Some of those actions could involve presenting authentication problems, encouraging the victim to supply their credentials, or luring the user into downloading files infected with malware.
• The impact of this attack can be substantial, since it can lead to stolen credentials, data theft, critical data encrypted with ransomware, compromised hosts that become bots as part of a botnet and much more.
• If done correctly, not only the attacker would be able to accomplish their aims, but also the end user would remain completely unaware of the fact that they fell victim to this cyber-attack.

The DNS cache poisoning attack has four main threat vectors.

• Man in the middle attack: Whereby the attacker places themselves between the client and the server by using tools such as OPS tool and can modify the Mac addresses in the DNS resolvers table, causing it to think that the attacker's computer belongs to the client.
• At the same time, by utilizing the same tool, the client is also tricked into thinking that the system controlled by the attacker is the DNS server.
• At the end of this process, the attacker can then use a tool, such as DNS spoof to direct all DNS requests to the fake sites designed by the attacker.
• DNS server hijacking: This entails compromising the DNS resolver directly with a goal of injecting false data into its cache to achieve DNS spoofing and redirect the client to the attacker's site.
• Client machine hijacking: Just like with DNS server hijacking, this factor involves compromising the client directly. Once the attacker has gained access to the client, they can proceed to injecting false DNS data in the host's file, which, as you remember from the local name resolution section, is consulted by the operating system before DNS kicks in by poisoning the host file. Therefore, the attacker can accomplish DNS spoofing again without even having to worry about the DNS resolver.
• Birthday attack: This is when the attacker tries to get the transaction id of the client's DNS request, so that it can respond to it with a false response of their own, thus poisoning the cache of the DNS resolver, which from that point on will be saving the attacker's IP address.

Mitigation measures:

• DNSSEC: The DNSSEC is short for Domain name system security extensions, and it is a means of verifying DNS data integrity and origin. DNS uses public key signature to verify and authenticate data, thus preventing forgery. The downside to using DNSSEC, is that when the DNS resolver needs to verify the signature with the authoritative DNS server, the entire process of name resolution slows down. This is the reason why a DNSSEC is still not widely adopted.
• DNS over HTTPs (DoH) and DNS over TLS (DoT): These standards are competing specifications designed to keep DNS requests secure without sacrificing speed like DNSSEC.
• Unlike DNSSEC, which verifies the identity of the DNS root service, an authoritative name service in communication with DNS resolvers, the DoH and DoT encrypt DNS traffic, making it harder for attackers to tamper with DNS requests and responses while in transit.
• The most important difference between the two standards is that DoH chooses Port 443, whereas DoT uses Port 853.
• Patching DNS software: So, if, for example, you have configured your DNS resolver with bind, make sure that you're using bind latest version and that you keep up to date with all the latest security patches.
• Applying endpoint security: Do not forget to harden your client systems by applying appropriate endpoint security to reduce the attack surface to prevent client machine hijacking attacks.

NXDOMAIN Attack

The NXDOMAIN attack is a DNS based denial of service attack, which aims at disrupting the availability of the DNS server by flooding it with requests for invalid or non-existent records.

• Using a tool, the attacker can generate and transmit large volumes of unique subdomains for each request sent to the DNS resolver. As a result, the DNS resolvers continued attempts to resolve the fake domains in the attacker's name lookup requests lead to high resource utilization on the DNS resolver itself, which finds it more difficult to respond to legitimate requests.
• On top of that, since the records queried by the attacker do not exist, the DNS resolvers’ cache is being filled up with an NXdomain replies, slowing down the service response time for legitimate requests even further. When the cache gets filled up with an NXDOMAIN response, valid. cache entries get pushed out, resulting in further service degradation.

The two main symptoms of an NXDOMAIN attack.

• The cache of the DNS server gets filled with NXDomain records, while at the same time resource utilization increases, which makes it more difficult for legitimate regime requests to be answered by the same server.

Mitigation Measures

• Restrict DNS queries to trusted clients.
• Block the offending source IP addresses.
• Flush the cache on the DNS resolver.
• Use dedicated solutions by specialized vendors.

DNS Query Flood Attack

The DNS Query flood attack is another DNS based denial of service attack, which aims at disrupting the availability of the DNS server by flooding it with name requests.

Mitigation Measures

• Restrict DNS queries to trusted clients
• Block the offending source IP addresses
• Rate limiting
• Deploy a Cache-only DNS server
• Overprovision bandwidth on the name server

Phantom Domain Attack

But what about attacks that take the form of requests against real domains whose name servers simply do not respond?
Well, there is just such an attack that is known as phantom domain attack.

• In a phantom domain attack, the malicious actor lays the groundwork by first configuring several domains. Then they configure the authoritative name servers of those domains to either respond to requests very slowly or not respond at all.
• Once they have done this work, the attacker then proceeds to sending a huge number of queries to the victim DNS resolver, which must spend time and resources doing the recursion against the records of the phantom domains, whose name servers will simply not respond.
• As such, the phantom domain attack is yet another type of DNS based denial of service attack, since its goal is to exhaust the resources of the DNS resolver and disrupt its availability for legitimate uses.

Mitigation Measures

• Rate limiting
• Restricting recursive queries per server and per zone
• Using dedicated solutions by specialized vendors
• So, for example, if F5 Big IP is designed to time out the connection and release the requests in the queue so that the resolver doesn't need to wait for responses that will never come.

DNS Protocol Analysis

DNS Messages

We know that the core function of name resolution is carried out by two different messages.

• Query: Sent by the client
• Response: Sent by the server

Each exchange of these messages is referred to as a transaction, and it is assigned a transaction ID by DNS.

• Thanks to the Transaction ID, if a client sends three different name requests to three different servers, we can easily find out which query initiated which response.
• This is an extremely useful feature that can be used when troubleshooting DNS issues or when conducting a forensic network analysis.

As a layer seven application, DNS must rely on a transport protocol layer four to transfer DNS messages from client to server and vice versa.
Most network protocols residing at the application layer usually rely on either TCP or UDP.
But DNS is interestingly one of the few protocols they use both depending on the operation taking place.

• For name resolution, where speed is of the essence, UDP is used as a transport protocol to carry both requests and responses, since UDP does not offer a reliable method of delivering messages. It is up to the client to keep track of the request sent so that if a response is not received at a specific time interval, the corresponding request can be retransmitted. In the interest of preventing excessive DNS traffic on the network, retransmissions are usually sent at an interval ranging from 2 to 5 seconds.
• TCP, on the other hand, is used when data must be delivered reliably, as is the case in scenarios such as zone transfers or when a DNS response requires more than 512 bytes of space.

In terms of size, all UDP DNS messages are limited to a payload of 512 bytes, though if a response message is larger than that, the message is then truncated and a special pin in the header is sent to indicate this outcome.
In such an event, the client would then be expected to retry the query over TCP instead, which doesn't have the same size limitation as UDP.
Transactions taking place over TCP remain a very small fraction of overall DNS traffic, regardless of which transport protocol is used.
The standard port of the server listens on by default is 53, while the port used by the client will always be an ephemeral one.

Other types of DNS messages outside the area of name resolution are:

• Notify: Allows master server to inform slave servers when the zone has changed code over UDP
• Update: Used to add or delete resource records or resource record sets from a specified zone, and it can be carried over either UDP or TCP depending on the size of the request.

DNS Response Codes (RCODES)

In an ideal world, we would like to see every single query that we make to result in a successful translation. Sometimes, however, we're not lucky, and DNS requests can fail to resolve for several reasons.
Whenever that happens, we want to get a first hint behind the failure encountered so that we can troubleshoot the problem effectively, identify the root cause of the issue and eventually fix it.
That's where rcodes come in.
Rcodes indicate whether a narrow condition exists in the response, and each code corresponds to a numeric value.

Most common RCODES that can be found in response messages:

• 0 NoError – No Error
• 1 FormErr – Format Error - which means that the name server was unable to interpret the query.
• 2 ServFail – Server Failure - means that the name server was unable to process this query due to a problem with the name server.
• 3 NXDomain – Non-Existent Domain - which signifies other domain name reference in the query does not exist.
• 4 NotImp – Not Implemented – which means is that the name server does not support the request, that kind of query.
• 5 Refused – Query Refused - which means that the query was refused since the nameserver refused to perform the specified operation for policy reasons.

The full list of RCODES can be found on the flip charts.
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6

DNS Header

The DNS header consists of a series of field, and we are going to inspect each one in turn.

• The first field in the DNS header is the transaction ID field that we talked about earlier on, in the section once again. Its purpose is to associate DNS queries with their corresponding responses.
• Then we have several flags, starting with a:
• QR bit, which indicates whether the header is for a query represented by a zero or a response represented by one.
• OPCODE - Specify. the query type, each DNS OPCODE is assigned a name.
• AA stands for authoritative answer, and it is valid in responses. Its specifies that the responding nameserver is an authority for the domain name being requested.
• TC stands for truncation, which is said when a message is truncated due to its length being greater. than the maximum size, which is 512 bytes.
• RD stands for Recursion Desired, which is a bait that is said in the query upon the client sending a recursive request to the DNS resolver.
• RA stands for Recursion Available, which denotes whether the name server that is responding. Indeed, supports recursive queries.
• Z reserved for future use, and it must be zero in all queries and responses.
• AD stands for authentic data, while CD stands for checking disabled, both flags are relevant to the DNS mechanism.
• Response codes abbreviated as RCODES. And like we've discussed earlier; they indicate whether an error condition exists in the response.
• Then we have an unsigned integer field:
•  query count that represents the number of questions.
• Then we have the answer count field that represents the number of answers
• NSCount or upcount, which represents the number of authoritative resources records
• ARCOUNT which represents the number of additional records.

DNS Data Storage

Early in the course, we talked about name resolution and how it resolved can find the authoritative answer to a query via a series of iterative requests against servers down for domain name hierarchy.
Obviously, those servers must store that kind of information somewhere to be able to respond to the DNS queries.
And so, in this section, we will study the way the DNS data is stored and organized in name servers.
Again and again throughout the course, we have been referring to the DNS as a globally distributed. collection of databases.
This principle extends to DNA storage as well, since the DNS data is stored in a database that is known as a Zone.

There are two types of zones:

• Forward Lookup Zone: Used for resolving names to IP addresses, and it's the zone where most of the DNS data is stored.
• Reverse Lookup Zone: The reverse lookup Zone, on the other hand, mainly stores information used for reverse name resolution.

Each of these zones is a collection of what we called as Resource records (RRs), and just like the records of any database, various sets of fields organized in rows.
There are many types of resource records and DNS, and each resource record type contains a specific set of data.

Common RR Format

• Name of the Record
• Type of the Record
• Class of the Record
• TTL value
• Resource data length
• Resource data

Types of Resource Record

State of Authority (SOA)

• The SOA record indicates the beginning of his own, and it should be the first resource record specified in any zone file.
• There can be only one Start of authority record per zone.

Format

The format of the set of authority record is as follows.

<domain name> <TTL> <class> SOA <m-name> <r-name> (
                         <serial number>
                         <refresh interval>
                         <retry interval>
                         <expire interval>
                         <minimum>
)

• We have the domain name, followed by a time to live value, followed by the resource record class, which, should be in standing for internet in 99 percent of cases.
• Then we've got the resource record type start up authority in this case, then we have the m-name field, which is the name of the primary authoritative name server for the zone.
• And it is this name server that secondary DNS servers receive updates from in relation to the zone.
• I know we haven't talked about primary and secondary name servers yet, as those are concepts, we will explore in the configuration section.
• For now, just make a note of the m-name field represents the primary name server for the zone.
• Next, we have the r-name field, which signifies the email address of the administrator responsible for the zone.
• Although the value represents an email address, you will be surprised to learn that there is no @ sign in it, as far as the start of Authority rack is concerned in this case.
• Info.example.com is the same thing as info@example.com 
• And then within a pair of brackets, we have the serial number, which is the version number of the zone, and it is incremented by one, every time a change is made to the zone file.
• Then the refresh interval, the retry interval and the expire interval have to do with primary and secondary name service.
• And finally, we have the minimum field. 
• The historical purpose of this parameter was to hold the default TTL value for records without an explicit time to live value defined.
• But nowadays, the minimum parameter represents the TTL value for negative caching.
• If you remember back in our section on caching, we said that negative answers are cached with a different TTL, and that different kind of TTL is no other than this very parameter.

To query the start of authority record, we can use a tool like Dig (for Linux machine) and nslookup (for window machine).
On window machine on command prompt:

nslookup -type=soa <hostname/IP address>

Name Server (NS) Record

• The NS records point to the authoritative name server of his own, and it is these name servers that hold the actual DNS information for a domain so that domain can be accessible to internet users.
• If a domain, such as example.com doesn't have any NS records configured in its zone.
• There wouldn't be any references to that domain name servers, which means that mean the .com TLD server contacted would not be able to return a list of name server, for example .com which in turn means that nobody would be able to browse to that domain.
• In other words, it is the NS records that ensure the availability of a domain.
• Because of that reason, every zone must have at least two NS records, of which each one points to a different name server for redundancy.
• That way, if one name server goes down or becomes unavailable, DNS queries can go to a different name server.
• To that end, name servers also typically reside in topological separate networks for further resiliency.

When it comes to registering a domain, many DNS service providers by default provisioning sets of 4 name servers, and they will be listed as:

• ns1.example.com
• ns2.example.com
• ns3.example.com
• ns4.example.com

Format

<domain name> <TTL> <class> NS <nameserver’s hostname>

• Its syntax consists of a domain name such as example.com, a TTL value and resource record class, which in 99 percent of cases should be in for internet.
• And then resource record type, in these case NS record and finally the name servers hostname such as ns1.example.com

Querying the NS record with a tool like Dig or Nslookup
On a Windows machine.

nslookup -type=ns <hostname/IP address>

Address Records (A)

• A resource record that stores the association between a domain name and IP address is the address or A record.
• A record is that primary record in DNS and it is queried in forward looking requests.

Format

<domain name> <TTL> <class> A <IPv4 address>

It simply contains a domain name, TTL value, a resource record class, a resource record type, which in this case is A and an IPv4 address.

Querying the A record on a Windows machine.

nslookup -type=a <hostname/IP address>

Quad-A Record (AAAA)

• The cousin of the A record is a Quad-A record, which stores a domain name and a IPv6 address.
• The reason why it's represented by 4A is to signify that the value stored in it is four times as big as the one stored in the A record.
• Considering that an IPv4 address has 32 bits and, IPv6 address has 128 bits.

Format

<domain name> <TTL> <class> AAAA <IPv6 address>

Its format is very similar to that of the A record, as it consists of a domain name, a TTL value, resource record class, resource record type, which in this case is AAAA and finally, an IPv6 address.
It is important to note that it is perfectly possible for A record and AAAA record to point at the same domain, in cases where dual stack is required.

Querying the AAAA record on a Windows machine.

nslookup -type=aaaa <hostname/IP address>

Pointer Record (PTR)

• As we know from previous section, however, DNS also supports reverse resolution for situations where we have an IP address and want to resolve it to its associated name.
• There is also record that allowed this to happen is a Pointer record, i.e., PTR. which points an IP address to a host name.

Format

<reverse domain name> <class> PTR <domain name>

The formats of the point of record features, a reverse domain name which release the IP address we have in reverse format, followed by the .in-addr.arpa which, if you remember from our section on reverse name resolution, is a special domain representing the numerical hierarchy of DNS that covers the entire IPv4 address space.
Then we have a resource record class, a resource record type, which is PTR, pointer record in this case.
And finally, the FQDN of the domain name that the IP address points to.

• The same principles apply to PTR records storing IPv6 address as well, with the main difference is being that the domain appended to the reverse IPv6 address is not .in-addr.arpa but .IP6.arpa which is a different namespace under the dot arpa TLD.
• As they are designed to facilitate reverse name solution, pointer record is placed inside the revers lookup zone, which is something we're going to see in more detail in the configuration section.

Querying the PTR record on a Windows machine.

nslookup -type=PTR <hostname/IP address>

Canonical Name Record (CNAME)

• We are going to discuss yet another resource record type, which makes a frequent appearance in DNS configuration, troubleshooting and name resolution, and it is the CNAME record.
• C name stands for canonical name, which is a real name of an object referenced by an alias. In other words, this record basically maps one domain name to another.

Format

<alias> <class> CNAME <TTL> <canonical name>

It consists of an alias such as www.example.com, a resource record class which is in for internet in 99 percent of cases.
A resource record type, CNAME in this case, a TTL value and a canonical name or the real name that www.example.com points to, which is example.com.

Querying the CNAME record on a Windows machine.

nslookup -type=cname <alias>

Use Cases of CNAME

• Map subdomains to their apex domain such as www.example.com to example.com
• Redirect multiple TLDs to the same second level domain.
• For example, if you have mydomain.com.au and mydomain.com.nz, they both can be directed to mydomain.com
• Validate ownership or control of a domain.

Restrictions

• A CNAME record must always point to another domain name and never directly to an IP address.
• A CNAME record cannot point to an NS or MX record.
• A CNAME record cannot co-exist with another record for the same name.

Best Practice

• A CNAME can point to another CNAME, a mechanism that is known as CNAME chaining. However, this is not recommended as it requires multiple DNS lookups before the internet domain can be loaded, which slows down the name resolution process and in turn, impacts user experience. It is considered best practice, therefore, not to use the CNAME chaining, and point CNAME records directly to canonical names.

Text Record (TXT)

The DNS ‘text’ (TXT) record lets a domain administrator enter text into the Domain Name System (DNS). The TXT record was originally intended as a place for human-readable notes. However, now it is also possible to put some machine-readable data into TXT records. One domain can have many TXT records.

Example of a TXT record:

example.com	record type:	value:	TTL
@	TXT	This is an awesome domain! Not spammy.	32600

Format

<domain name> <class> TXT <TTL> <textual data>

Format of the text record is probably the easiest one to remember, as it consists of a domain name, a resource record class, a resource record type, which in these cases is TXT, and time to live value and some textual information.

• Interestingly, even though the official format for storing data in a record theoretically involves using attribute value pairs limited by an equal sign and enclosed by quotation marks.
• Domain administrators are still able to use their own formats, which is a testament to the flexibility of the text record.
• The data that can be placed inside its value could be any text that the administrator wants to associate with their domain.
• Though the value of this record was originally intended as a place for human readable notes, it is now possible to put machine readable data as well.
• It is also perfectly possible for one domain to be associated with many TXT records.

Querying the TXT record on a Windows machine.

nslookup -type=txt <domain name>

Use Cases

• Associating domains with textual data
• Proving domain ownership
• Strengthening email security

Mail Exchange Record (MX)

• We're going to have a look at yet another very common record in DNS, which is known as mail exchange record (MX).
• Just like every other record in the DNS database, the MX record, too, serves as a mapping between two values.
• More specifically, the MX record maps a domain to an email server.
• Email has always been heavily reliant on DNS, perhaps more so than any other TCP IP based application, and MX records provide the necessary infrastructure for it to work.

Format

<domain name> <class> MX <TTL> <preference-value> <email-server>

It consists of a domain name, a resource record class, a resource record type which obviously is MX, the time to live value, the preference value, and the hostname of an email server.

• The first question that comes to mind when inspecting the format of the MX record is why does it not feature the @ symbol?
• Shouldn’t it be primaryemail@www.example.com instead of primaryemail.www.example.com
• Well, as e-mail clients, whenever we send an email to any recipient, we use the @ sign as a means to separate the mail server from the domain it is meant to receive emails for.
• For instance, support@example.com.
• As well as the name servers are concerned. the names of mail servers inside their MX records are configured with dots and not @.
• Another interesting part of the MX record is the preference value.
• The preference value allows a DNS administrator to specify multiple e-mail service so that if the first server specified is down, emails will be forwarded to the backup email server, thus achieving redundancy. 
• The lower the preference value of the email server, the higher the priority of that server will be. It is also possible to specify multiple backup email servers too.
• Finally, somebody might say, okay, that is all well and good, but how can the authoritative name server know of the email server’s location?
• Shouldn't there be an additional record that in turn maps the hostname of that server to an IP address? And the answer is yes.
• A record would indeed need to be defined alongside the mixed record so that the name server can forward email to the correct endpoint.
• Additionally, A records would typically be created for as many email server the domain is associated with.

Querying the MX record on a Windows machine.

nslookup -type=mx <domain name>

Domain Name Registration

Hierarchy

As the name suggests Name registration involves the registration of domains.
A domain represents a public identity on the internet, and it's used to identify the IP address of the computer system hosting web content.
To ensure that each domain is unique, Name registration has to be processed within a globally distributed framework designed to enforce a certain set of rules.
That framework is the domain name registration hierarchy.

• At the top of the hierarchy, Rules ICANN, a non-profit, internationally organized corporation that stands for Internet Corporation for Assigned Names and Numbers.
• Its main role is to oversee the huge and complex, interconnected network of unique identifiers that allow computers on the internet to find one another.
• ICANN is responsible for managing generic TLDs or country-code TLDs, managing how root name server systems function, coordinating how IP addresses are supplied to avoid repetition or clashes, and maintaining a central repository of IP addresses.
• Below ICANN are five regional internet registries.
• And each registry is responsible for obtaining IP ranges from ICANN to allocate them to internet service providers across a specific geographic region.
• Subordinate to the registries are the registrars, which are ICANN accredited organizations responsible for processing the registration of domain names.
• Examples of registrars are GoDaddy, Namecheap and Bluehost.
• After registrars come resellers, resellers are third party companies that offer domain name registration services through registrars.
• An example of a well-known reseller is Route 53.
• The dedicated DNS and registration as a service provided by AWS.
• Route 53 is the reseller of two registrars.
• Amazon Registrar for Generic TLD and candy for all other top-level domains.
• And at the bottom of the hierarchy are the registrants, the people or organizations who register domains through a register or a reseller.

Process

The process of registering a domain name consists of the following steps:

• The registrant chooses a domain name and submits a request to registries with a reseller or a ICANN accredited registrar.
• Provided that the domain names available, the registrar registers the name and then creates who is record.
• The who is record contains the registrant’s name and contact information, the name and contact information of the registrar, the registration date, the name servers, the most recent update, and the expiration date.
• Who is records may also provide the administrative and technical contact information of the registrant.
• The registrar will then send your domain name request along with the contact and technical information of the domain name to the appropriate registry.
• And in turn, the registry will file all information provided, and it will add the names on file to the master servers, which will tell other servers on the internet where your website is located.

Considerations when choosing a TLDs

There are currently more than 1500 TLDs to choose from, which include,

• Generic TLDs
• Country-code TLDs
• Infrastructure TLDs
• Sponsor TLDs
• IDNTLDs
• Geographic TLDs

Not all TLDs will suit your requirement, so we have to take consideration, and asked below few questions to choose TLDs

• DNSSEC support? Security related feature to avoid DNS cache poisoning, and many more.
• IDNs support? IDNs mean International Domain Name
• Privacy protection? For protecting the privacy of website information     
• Target audience? Is the organization being regional specific, such as health care provider?
• Relevant field? What the field of business such as .cafe or .coffee
• Local presence requirements?

Choosing a Second-Level Domain

Name Consideration
Do:

• Use keywords that reflect your industry.
• Use localized keywords if applicable.
• Try to keep it short with less than 10 characters.
• Ensure it is easy to spell.
• Ensure it is easy to pronounce.
• Ensure it is easy to remember.

Don’t:

• Use hyphens, numbers, acronyms.

Choosing a Registrar

• First and foremost, pricing and by pricing, we mean the registrar's registration fee, the renewal fee and the other potential charges for things like the domain transfers, for example.
• Most registrars do not charge a fee, but some do.
• Any potential cost benefits, such as bulk pricing options or promotion deals like registering a domain name for several years at a cheap price.
• Add-On services such as Web hosting services, WordPress hosting services, website builders, email hosting services, brokerage services, privacy protection, SSL protection, customer service support.
• Some of the registrar offered 24-7 support. Some others do not.
• Supported TLDs that was a big one, is usually supported. Not all registrars have the license to sell all top-level domains.
• Policies such as the domain transfer.
• What is the registrar policy and the domain transfers? What is that policy on domain expiration?
• Domain names registered for a specific duration and when they expire, some registrars offer a grace period even after the expiration, to allow you to renew your expired domain name.
• Other registrars, on the other hand, can exercise predatory practices, such as buying your expired domain name as soon as it expires, so they can sell it back to you a much higher price.
• Always read customer reviews while carrying out your research on which registrar you should choose.
• Finally, remember there is a best practice.
• It is recommended that you register your domain name on the registrar but hosted on another provider simply because it is usually easier to switch hosting companies if required later on. Provided that a domain name is hosted on a platform different to the one it was registered on.

EPP Status Codes

Extensible provisioning protocol domain status codes, also known as domain name status codes, indicate the status of a domain name registration.
Every domain has at least one status code, if not more.
Each EPP code provides useful information about a domain that comes in handy for operations such as:

• Troubleshooting domain related issues
• Domain renewals
• Domain transfers between registrars.

There are two different types of EPP status:

• Client codes
• Server codes

Client status codes are set by registrars, and depending on the registrar, they are set upon registering the domain or when requesting it.
Server status codes, on the other hand, are set by registries, and they take precedence of a client code sense.
If you remember from a previous section, registries reside higher up in the domain name registration hierarchy than registrars.

Some examples of Client codes are:

• clientHold: It is a status code that tells your domains registry to not activate your domain in the DNS and therefore, it will not resolve. It is an uncommon status that is usually active during legal disputes, non-payment or when your domain subject deletion.
• clientTransferProhibited: It is a status code that tells your domains registry to reject requests to transfer the domain from your current registrar to another.
• clientUpdateProhibited: It is a status code that tells your domain registry to reject requests to update the domain.

Some examples of server codes are:

• OK: It Is the standard status for a domain, meaning that it has no pending operations or prohibitions
• autoRenewPeriod:It is a grace period provided after a domain name registration period expires and is extended or renewed automatically by the registry. If the registrar deletes the domain name during this period, the registry provides a credit to the registrar for the cost of the renewal.
• serverTransferProhibited: It is a status code that prevents your domain name from being transferred from your current registrar to another. It is an uncommon status that is usually active during legal or other disputes at your request or when a redemption period status is in place.

You can inspect the EPP codes of any domain you're interested in simply by performing a whois lookup against it.
All you need to do is to navigate to an online page: https://lookup.icann.org/