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 Security Complete Guide: Attacks and Mitigation Strategies

🎯 What You'll Learn:
Understand major DNS security threats including cache poisoning, NXDOMAIN attacks, query flood attacks, and phantom domain attacks. Learn mitigation strategies including DNSSEC, DNS over HTTPS (DoH), DNS over TLS (DoT), and best practices for securing DNS infrastructure.

DNS Cache Poisoning Attack

DNS cache poisoning attack, which is also known as DNS spoofing attack, is one of the most dangerous DNS security threats.

⚠️ What is DNS Cache Poisoning?

• If you recall from our previous lesson on caching in the name resolution section, caching is used extensively in DNS 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
• Name lookups originated from a client are answered by a malicious actor who redirects users to a fraudulent web page

How the Attack Works

• The fraudulent website would typically be a mirror of a legitimate site so that once end users are redirected, they are tricked into taking a specific set of actions engineered by the attacker
• Some of those actions could involve:
  • Presenting authentication prompts, encouraging the victim to supply their credentials
  • Luring the user into downloading files infected with malware
  • Stealing sensitive information like credit card details or personal data
• 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
• If done correctly, not only would the attacker 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

Four Main Threat Vectors

The DNS cache poisoning attack has four main threat vectors:

1. Man-in-the-Middle (MITM) Attack

🎭 MITM Attack Process:

• The attacker places themselves between the client and the server by using tools such as ARP spoofing tools
• Can modify the MAC addresses in the DNS resolver's ARP 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 DNSspoof to direct all DNS requests to the fake sites designed by the attacker

2. DNS Server Hijacking

• This entails compromising the DNS resolver directly with a goal of injecting false data into its cache
• Achieves DNS spoofing and redirects the client to the attacker's site
• Once the server is compromised, all clients using that resolver are at risk

3. Client Machine Hijacking

• Just like with DNS server hijacking, this vector involves compromising the client directly
• Once the attacker has gained access to the client, they can proceed to injecting false DNS data in the hosts file
• As you remember from the local name resolution section, the hosts file is consulted by the operating system before DNS kicks in
• By poisoning the hosts file, the attacker can accomplish DNS spoofing again without even having to worry about the DNS resolver

4. Birthday Attack

🎲 Birthday Attack Mechanism:

• This is when the attacker tries to get the transaction ID of the client's DNS request
• Once obtained, they can respond to it with a false response of their own
• This poisons the cache of the DNS resolver, which from that point on will be saving the attacker's IP address
• Named after the birthday paradox in probability theory

Mitigation Measures for Cache Poisoning

1. DNSSEC (DNS Security Extensions)

🔐 DNSSEC Overview:

• DNSSEC is short for Domain Name System Security Extensions
• A means of verifying DNS data integrity and origin
• Uses public key signatures to verify and authenticate data, thus preventing forgery
• Downside: 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 DNSSEC is still not widely adopted

2. DNS over HTTPS (DoH) and DNS over TLS (DoT)

🔒 DoH and DoT Overview:

• 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 and authoritative name servers in communication with DNS resolvers, DoH and DoT encrypt DNS traffic
• Makes it harder for attackers to tamper with DNS requests and responses while in transit
• Key Difference:
  • DoH: Uses Port 443 (same as HTTPS)
  • DoT: Uses Port 853 (dedicated port)

Security Method	Port	Protection Method	Performance
DNSSEC	53	Public key signatures for authentication	Slower (signature verification)
DoH	443	Encrypts DNS traffic over HTTPS	Faster than DNSSEC
DoT	853	Encrypts DNS traffic over TLS	Faster than DNSSEC

3. Patching DNS Software

• If, for example, you have configured your DNS resolver with BIND, make sure that you're using the latest version
• Keep up to date with all the latest security patches
• Subscribe to security mailing lists for your DNS software
• Regularly check for vulnerabilities and updates

4. Applying Endpoint Security

• Do not forget to harden your client systems by applying appropriate endpoint security
• Reduce the attack surface to prevent client machine hijacking attacks
• Implement host-based firewalls and antivirus software
• Restrict modifications to hosts file

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.

⚠️ How NXDOMAIN Attack Works:

• 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 resolver's continued attempts to resolve the fake domains in the attacker's name lookup requests lead to high resource utilization on the DNS resolver itself
• The resolver finds it more difficult to respond to legitimate requests
• Since the records queried by the attacker do not exist, the DNS resolver's cache is being filled up with NXDOMAIN replies, slowing down the service response time for legitimate requests even further
• When the cache gets filled up with NXDOMAIN responses, valid cache entries get pushed out, resulting in further service degradation

Symptoms of NXDOMAIN Attack

• The cache of the DNS server gets filled with NXDOMAIN records
• Resource utilization increases significantly (CPU, memory, network)
• Legitimate requests become difficult to answer by the server
• Response times for valid queries increase dramatically

Mitigation Measures for NXDOMAIN Attack

Mitigation Strategy	Description
Restrict DNS Queries	Limit DNS queries to trusted clients only using ACLs
Block Source IPs	Block the offending source IP addresses at firewall level
Flush Cache	Flush the cache on the DNS resolver to remove NXDOMAIN entries
Specialized Solutions	Use dedicated DDoS protection 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.

🌊 Query Flood Attack Characteristics:

• Attacker sends massive volumes of legitimate-looking DNS queries
• Unlike NXDOMAIN, queries may be for real domains
• Overwhelms the DNS server's capacity to respond
• Exhausts server resources (bandwidth, CPU, memory)
• Legitimate users cannot get their queries answered

Mitigation Measures for Query Flood Attack

Mitigation Strategy	Description
Restrict DNS Queries	Limit DNS queries to trusted clients only
Block Source IPs	Block the offending source IP addresses
Rate Limiting	Implement rate limiting to control queries per source
Cache-Only DNS Server	Deploy a cache-only DNS server to reduce authoritative server load
Overprovision Bandwidth	Overprovision bandwidth on the name server to absorb attack traffic

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.

👻 How Phantom Domain Attack Works:

• 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
• The resolver must spend time and resources doing the recursion against the records of the phantom domains, whose name servers will simply not respond
• 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 users

Attack Impact

• DNS resolver resources tied up waiting for responses that never come
• Timeouts consume CPU cycles and memory
• Legitimate queries experience delays
• Resolver queue fills up, preventing new queries from being processed

Mitigation Measures for Phantom Domain Attack

Mitigation Strategy	Description
Rate Limiting	Implement rate limiting to control query volume
Restrict Recursive Queries	Restricting recursive queries per server and per zone
Specialized Vendor Solutions	Use dedicated solutions by specialized vendors (e.g., F5 BIG-IP is designed to time out connections and release requests in the queue so the resolver doesn't need to wait for responses that will never come)

🎓 Key Takeaways:

• DNS Cache Poisoning: Poisons resolver cache to redirect users to malicious sites
  • Four vectors: MITM, DNS server hijacking, client hijacking, birthday attack
  • Mitigation: DNSSEC, DoH/DoT, patching, endpoint security
• NXDOMAIN Attack: Floods DNS with queries for non-existent domains
  • Fills cache with NXDOMAIN responses
  • Mitigation: Restrict queries, block IPs, flush cache, specialized solutions
• DNS Query Flood: Overwhelms DNS server with massive query volume
  • Exhausts bandwidth and server resources
  • Mitigation: Rate limiting, cache-only servers, overprovision bandwidth
• Phantom Domain Attack: Queries domains with non-responsive name servers
  • Ties up resolver resources waiting for responses
  • Mitigation: Rate limiting, restrict recursion, timeout management
• Security Technologies:
  • DNSSEC uses signatures (slower but authenticates)
  • DoH uses port 443 (encrypted, faster)
  • DoT uses port 853 (encrypted, faster)
• All DNS DoS attacks aim to exhaust resources and disrupt availability
• Layered defense approach recommended: combine multiple mitigation strategies

📚 Practice Exercises

1. Research and explain the difference between DNS cache poisoning and DNS hijacking
2. Set up a test environment and demonstrate how the hosts file can be used for local DNS poisoning
3. Compare DNSSEC, DoH, and DoT - which would you recommend for a corporate environment and why?
4. Analyze DNS logs to identify potential NXDOMAIN attack patterns
5. Calculate the impact: If a DNS server can handle 10,000 queries/second, how many attacking hosts sending 100 queries/second each would it take to overwhelm it?
6. Design a multi-layered DNS security architecture for a large organization
7. Explain why DoH uses port 443 instead of a dedicated port like DoT
8. Create an incident response plan for a detected DNS cache poisoning attack
9. Research the birthday attack - why is it called that and how does transaction ID randomization help?
10. Compare the resource consumption of NXDOMAIN attacks vs Phantom Domain attacks

🛡️ Security Best Practices Summary:

• Prevention: Implement DNSSEC, DoH, or DoT for secure DNS communication
• Access Control: Restrict DNS queries to trusted clients using ACLs
• Rate Limiting: Control query volume per source to prevent flooding
• Monitoring: Continuously monitor for unusual query patterns and NXDOMAIN spikes
• Patching: Keep DNS software up to date with latest security patches
• Redundancy: Deploy multiple DNS servers in different locations
• Caching Strategy: Use cache-only servers to reduce authoritative server load
• Endpoint Security: Harden client systems to prevent hosts file poisoning
• Bandwidth: Overprovision network capacity to absorb attack traffic
• Specialized Solutions: Consider dedicated DNS security appliances for large deployments

DNS Protocol Analysis

DNS Messages and Protocol Complete Guide

🎯 What You'll Learn:
Understand DNS messaging including queries and responses, TCP vs UDP transport protocols, DNS transactions, header structure with all flags, and response codes (RCODES) for effective troubleshooting.

DNS Messages

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

💬 DNS Message Types:

• Query: Sent by the client requesting domain name resolution
• Response: Sent by the server providing the answer to the query

DNS Transactions and Transaction ID

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 forensic network analysis
• Transaction IDs enable proper matching of responses to their corresponding queries

Transport Protocol: TCP vs UDP

As a layer seven application, DNS must rely on a transport protocol at 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 that use both depending on the operation taking place.

UDP for DNS - Default Protocol

🚀 UDP Usage:

• For name resolution, where speed is of the essence, UDP is used as a transport protocol
• Carries both DNS requests and responses
• No connection setup overhead - faster than TCP
• Since UDP does not offer a reliable method of delivering messages, it is up to the client to keep track of requests sent
• 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 for DNS - Reliable Delivery

🔒 TCP Usage:

• Used when data must be delivered reliably
• Zone Transfers: Replicating DNS data from primary to secondary servers
• Large Responses: When a DNS response requires more than 512 bytes of space
• Provides reliable, connection-oriented delivery
• Handles retransmissions automatically

DNS Message Size Limitations

• All UDP DNS messages are limited to a payload of 512 bytes
• If a response message is larger than 512 bytes:
  • The message is truncated
  • A special flag (TC bit) in the header is set to indicate this outcome
  • The client is expected to retry the query over TCP instead
  • TCP doesn't have the same 512-byte 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

DNS Port Numbers

Component	Port Number	Description
DNS Server	53	Standard port that servers listen on by default (both TCP and UDP)
DNS Client	Ephemeral Port	Random high-numbered port (typically 49152-65535)

Other DNS Message Types

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
  • Carried over UDP
  • Enables efficient zone synchronization
• Update: Used to add or delete resource records or resource record sets from a specified zone
  • Can be carried over either UDP or TCP depending on the size of the request
  • Supports dynamic DNS updates

DNS Response Codes (RCODES)

In an ideal world, we would like to see every single query that we make 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.

🔍 What are RCODES?
RCODES (Response Codes) indicate whether an error condition exists in the response. Each code corresponds to a numeric value and provides information about the status of the DNS query.

Most Common RCODES

Code	Name	Description
0	NoError	No Error - The query completed successfully
1	FormErr	Format Error - The name server was unable to interpret the query (malformed query)
2	ServFail	Server Failure - The name server was unable to process this query due to a problem with the name server
3	NXDomain	Non-Existent Domain - The domain name referenced in the query does not exist
4	NotImp	Not Implemented - The name server does not support the requested kind of query
5	Refused	Query Refused - The query was refused since the nameserver refused to perform the specified operation for policy reasons

📚 Complete RCODE Reference:
The full list of RCODES can be found on the IANA page:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6

DNS Header

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

DNS Header Fields

1. Transaction ID (16 bits)

• The first field in the DNS header
• Purpose: Associate DNS queries with their corresponding responses
• Enables proper matching when multiple queries are in flight
• Critical for troubleshooting and network analysis

2. Flags (16 bits total)

🚩 DNS Header Flags:

Flag	Bits	Description
QR	1 bit	Query/Response: Indicates whether the header is for a query (0) or a response (1)
OPCODE	4 bits	Operation Code: Specifies the query type (standard query, inverse query, status request, etc.)
AA	1 bit	Authoritative Answer: Valid in responses. Specifies that the responding nameserver is an authority for the domain name being requested
TC	1 bit	Truncation: Set when a message is truncated due to its length being greater than the maximum size (512 bytes for UDP)
RD	1 bit	Recursion Desired: Set in the query when the client is sending a recursive request to the DNS resolver
RA	1 bit	Recursion Available: Denotes whether the name server that is responding supports recursive queries
Z	1 bit	Reserved: Reserved for future use. Must be zero in all queries and responses
AD	1 bit	Authentic Data: Relevant to DNSSEC - indicates authenticated data
CD	1 bit	Checking Disabled: Relevant to DNSSEC - disables security checking
RCODE	4 bits	Response Code: Indicates whether an error condition exists in the response (0-15)

3. Count Fields (Unsigned Integers - 16 bits each)

Field	Name	Description
QDCOUNT	Query Count	Represents the number of questions in the query section
ANCOUNT	Answer Count	Represents the number of resource records in the answer section
NSCOUNT	Authority Count	Represents the number of authoritative resource records in the authority section
ARCOUNT	Additional Count	Represents the number of resource records in the additional records section

💡 DNS Header Structure Summary:
The DNS header is fixed at 12 bytes and contains:

• Transaction ID - 16 bits
• Flags - 16 bits (QR, OPCODE, AA, TC, RD, RA, Z, AD, CD, RCODE)
• Question Count - 16 bits
• Answer Count - 16 bits
• Authority Count - 16 bits
• Additional Count - 16 bits

These fields appear in every DNS message whether query or response.

🎓 Key Takeaways:

• DNS Messages: Queries (client) and Responses (server) with Transaction IDs for matching
• UDP for Speed: Default protocol for DNS queries/responses, 512-byte limit, port 53
• TCP for Reliability: Used for zone transfers and large responses (>512 bytes)
• UDP retransmissions occur at 2-5 second intervals to prevent network congestion
• When UDP message exceeds 512 bytes, TC flag is set and client retries over TCP
• Transaction ID: Critical for matching responses to queries in troubleshooting
• RCODES: Response codes indicate query status (NoError, FormErr, ServFail, NXDomain, NotImp, Refused)
• DNS Header: Fixed 12 bytes with Transaction ID, Flags, and 4 count fields
• Key Flags: QR (query/response), RD (recursion desired), RA (recursion available), AA (authoritative)
• TC Flag: Indicates truncation when response exceeds 512 bytes
• AD/CD Flags: Related to DNSSEC authentication
• Notify Messages: Master informs slaves of zone changes (UDP)
• Update Messages: Dynamic DNS updates (UDP or TCP based on size)
• DNS server port: 53 | Client port: ephemeral (high-numbered)

📚 Practice Exercises

1. Capture DNS traffic using Wireshark and identify the Transaction ID in a query/response pair
2. Perform a DNS query and note whether UDP or TCP was used - explain why
3. Trigger a large DNS response and observe the TC flag being set and TCP fallback
4. Use nslookup or dig to query a non-existent domain and identify the RCODE returned (NXDomain)
5. Examine DNS header flags in a recursive query - which flags are set (RD)?
6. Compare the DNS header of a query vs response - what differences do you observe?
7. Calculate the total size of a DNS header (in bytes)
8. Query a domain's SOA record and check if the AA (Authoritative Answer) flag is set
9. Explain when ServFail (RCODE 2) vs NXDomain (RCODE 3) would be returned
10. Describe a scenario where DNS would switch from UDP to TCP during resolution

⚠️ Troubleshooting Tips:

• NXDomain errors: Check for typos in domain name or verify domain exists
• ServFail errors: Name server issues - check server logs and configuration
• FormErr errors: Malformed query - check client DNS software version
• Refused errors: Policy restrictions - verify ACLs and firewall rules
• TC flag set: Response truncated - client should automatically retry over TCP
• No RA flag: Server doesn't support recursion - may need to query different server

DNS Zones and Resource Records

🎯 What You'll Learn:
Understand DNS zones (forward and reverse lookup) and master all major DNS resource records including SOA, NS, A, AAAA, PTR, CNAME, TXT, and MX records. Learn their formats, use cases, and how to query them using nslookup.

Early in the course, we talked about name resolution and how resolvers can find the authoritative answer to a query via a series of iterative requests against servers down the 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 DNS storage as well, since the DNS data is stored in a database that is known as a Zone.

Types of DNS Zones

There are two types of zones:

📦 DNS Zone Types:

• 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: Mainly stores information used for reverse name resolution (IP address to domain name)

Each of these zones is a collection of what we call 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 in DNS, and each resource record type contains a specific set of data.

Common Resource Record Format

Most DNS resource records follow a common structure with the following fields:

• Name of the Record - The domain name this record applies to
• Type of the Record - The record type (SOA, NS, A, AAAA, PTR, CNAME, TXT, MX, etc.)
• Class of the Record - Usually "IN" for Internet (99% of cases)
• TTL value - Time To Live, how long the record should be cached
• Resource Data Length - Length of the resource data field
• Resource Data - The actual data (IP address, domain name, text, etc.)

Types of Resource Records

Start of Authority (SOA)

🔐 SOA Record Purpose:

• The SOA record indicates the beginning of a zone, and it should be the first resource record specified in any zone file
• There can be only one Start of Authority record per zone
• Contains critical zone management information including serial numbers, refresh intervals, and administrator contact

SOA Record Format

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

SOA Record Fields Explained

• Domain Name: The name of the domain this zone represents
• TTL: Time to live value for the SOA record
• Class: Resource record class, should be "IN" (Internet) in 99% of cases
• m-name: The name of the primary authoritative name server for the zone
  • This is the name server that secondary DNS servers receive updates from in relation to the zone
  • Primary name servers hold the master copy of the zone data
• r-name: Email address of the administrator responsible for the zone
  • Note: There is no @ sign - dots replace the @ symbol
  • Example: info.example.com represents info@example.com
• Serial Number: Version number of the zone, incremented by one every time a change is made to the zone file
  • Secondary servers use this to determine if they need to update their zone data
• Refresh Interval: How often secondary name servers should check with the primary for updates
• Retry Interval: How long to wait before retrying a failed refresh
• Expire Interval: How long secondary servers should keep serving zone data if they can't reach the primary
• Minimum: TTL value for negative caching
  • Historical purpose: Default TTL for records without explicit TTL
  • Modern use: TTL value for negative answers (domain doesn't exist)

Querying SOA Records

💻 Windows Command (nslookup):
nslookup -type=soa <hostname/IP address>

Linux Command (dig):
dig SOA <domain name>

Name Server (NS) Record

🌐 NS Record Purpose:

• NS records point to the authoritative name servers of a zone
• These name servers hold the actual DNS information for a domain so that domain can be accessible to internet users
• Without NS records, there would be no references to a domain's name servers, making the domain unreachable
• NS records ensure the availability of a domain

NS Record Requirements

• Every zone must have at least two NS records for redundancy
• Each NS record points to a different name server
• If one name server goes down or becomes unavailable, DNS queries can go to a different name server
• Name servers typically reside in topologically separate networks for further resiliency

When registering a domain, many DNS service providers by default provision sets of 4 name servers listed as:

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

NS Record Format

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

Syntax consists of a domain name such as example.com, a TTL value, resource record class (IN for internet in 99% of cases), resource record type (NS), and finally the name server's hostname such as ns1.example.com.

Querying NS Records

💻 Windows Command:
nslookup -type=ns <hostname/IP address>

Address Record (A)

🎯 A Record Purpose:

• A resource record that stores the association between a domain name and an IPv4 address
• The primary record in DNS - the most commonly used record type
• Queried in forward lookup requests (domain name → IP address)

A Record Format

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

It simply contains a domain name, TTL value, resource record class (IN), resource record type (A), and an IPv4 address.

Querying A Records

💻 Windows Command:
nslookup -type=a <hostname/IP address>

Quad-A Record (AAAA)

📡 AAAA Record Purpose:

• The cousin of the A record - stores a domain name and an IPv6 address
• Represented by 4 A's to signify that the value stored is four times as big as an A record
• IPv4 address: 32 bits | IPv6 address: 128 bits (4× larger)

AAAA Record Format

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

Format is very similar to the A record: domain name, TTL value, resource record class (IN), resource record type (AAAA), and finally an IPv6 address.

💡 Dual Stack Support:
It is perfectly possible for an A record and AAAA record to point to the same domain in cases where dual stack (IPv4 + IPv6) is required. This allows clients to connect using either protocol.

Querying AAAA Records

💻 Windows Command:
nslookup -type=aaaa <hostname/IP address>

Pointer Record (PTR)

🔄 PTR Record Purpose:

• DNS supports reverse resolution where we have an IP address and want to resolve it to its associated name
• PTR records allow this to happen by pointing an IP address to a hostname
• Essential for reverse DNS lookups (IP → domain name)

PTR Record Format

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

The format of the pointer record features a reverse domain name (the IP address in reverse format), followed by .in-addr.arpa (a special domain representing the numerical hierarchy of DNS covering the entire IPv4 address space), resource record class (IN), resource record type (PTR), and finally the FQDN of the domain name that the IP address points to.

IPv4 vs IPv6 PTR Records

• IPv4: Uses .in-addr.arpa domain
• IPv6: Uses .IP6.arpa domain (different namespace under the .arpa TLD)
• Pointer records are placed inside the reverse lookup zone

Querying PTR Records

💻 Windows Command:
nslookup -type=PTR <hostname/IP address>

Canonical Name Record (CNAME)

🔗 CNAME Record Purpose:

• CNAME stands for Canonical Name - the real name of an object referenced by an alias
• Maps one domain name to another domain name
• Makes frequent appearances in DNS configuration, troubleshooting, and name resolution

CNAME Record Format

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

Consists of an alias (e.g., www.example.com), resource record class (IN), resource record type (CNAME), TTL value, and a canonical name (the real name that www.example.com points to, which is example.com).

CNAME Use Cases

• Map subdomains to their apex domain (www.example.com → example.com)
• Redirect multiple TLDs to the same second-level domain
  • Example: mydomain.com.au and mydomain.com.nz both redirect to mydomain.com
• Validate ownership or control of a domain

CNAME Restrictions

⚠️ Important 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

CNAME Best Practice

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

Querying CNAME Records

💻 Windows Command:
nslookup -type=cname <alias>

Text Record (TXT)

📝 TXT Record Purpose:

• The DNS Text (TXT) record lets a domain administrator enter text into the Domain Name System
• Originally intended as a place for human-readable notes
• Now also possible to put machine-readable data into TXT records
• One domain can have many TXT records

Example TXT Record

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

TXT Record Format

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

Format of the text record is probably the easiest to remember: domain name, resource record class (IN), resource record type (TXT), TTL value, and textual information.

TXT Record Characteristics

• Official format involves using attribute-value pairs limited by an equal sign and enclosed by quotation marks
• Domain administrators can use their own formats - testament to TXT record flexibility
• Data can be any text the administrator wants to associate with their domain
• Originally intended for human-readable notes, now supports machine-readable data
• One domain can be associated with many TXT records

TXT Record Use Cases

• Associating domains with textual data
• Proving domain ownership - Used by services like Google, Microsoft to verify you own a domain
• Strengthening email security - SPF, DKIM, and DMARC records are TXT records

Querying TXT Records

💻 Windows Command:
nslookup -type=txt <domain name>

Mail Exchange Record (MX)

📧 MX Record Purpose:

• Mail Exchange (MX) record is a very common record in DNS
• 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
• MX records provide the necessary infrastructure for email to work

MX Record Format

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

Consists of: domain name, resource record class (IN), resource record type (MX), TTL value, preference value, and the hostname of an email server.

MX Record Details

• Why no @ symbol?
  • As email clients, we use the @ sign to separate the mail server from the domain (support@example.com)
  • For name servers, mail servers in MX records are configured with dots, not @
  • Example: primaryemail.example.com instead of primaryemail@example.com
• Preference Value:
  • Allows a DNS administrator to specify multiple email servers
  • If the first server is down, emails are forwarded to the backup email server (redundancy)
  • Lower preference value = Higher priority
  • Possible to specify multiple backup email servers
• Companion A Records Required:
  • MX records only specify the hostname of the email server
  • A records must be defined alongside MX records to map the email server hostname to an IP address
  • Without A records, name servers cannot forward email to the correct endpoint
  • A records should be created for as many email servers as the domain is associated with

Querying MX Records

💻 Windows Command:
nslookup -type=mx <domain name>

🎓 Key Takeaways:

• DNS Zones: Forward Lookup (name → IP) and Reverse Lookup (IP → name)
• SOA Record: First record in zone file, contains zone management info (serial, refresh, retry, expire)
• NS Record: Points to authoritative name servers, minimum 2 required for redundancy
• A Record: Maps domain name to IPv4 address - most common DNS record
• AAAA Record: Maps domain name to IPv6 address (4× larger than IPv4)
• PTR Record: Enables reverse DNS - maps IP to domain name using .in-addr.arpa (IPv4) or .IP6.arpa (IPv6)
• CNAME Record: Creates alias - maps one domain to another (avoid chaining)
• TXT Record: Stores text data - used for domain verification, SPF, DKIM, DMARC
• MX Record: Maps domain to email server with preference values (lower = higher priority)
• All records share common format: name, TTL, class (IN), type, data
• Query records using nslookup (Windows) or dig (Linux)

📚 Practice Exercises

1. Query the SOA record for google.com and identify the primary name server
2. Find all NS records for your favorite website - how many name servers do they have?
3. Perform a reverse DNS lookup on 8.8.8.8 using PTR records
4. Check if www.example.com uses a CNAME record pointing to example.com
5. Query TXT records for a domain and identify any SPF or DKIM records
6. Find the MX records for gmail.com and identify which has the highest priority
7. Create a sample zone file with SOA, NS, A, and MX records for a fictional domain
8. Explain why MX records require companion A records
9. Describe the difference between A and AAAA records and when you'd use both
10. Explain why CNAME chaining is not recommended

Domain Name Registration

DNS Name Registration

🎯 What You'll Learn:
Understand the complete DNS domain registration framework including ICANN hierarchy, registries, registrars, and resellers. Learn how to choose TLDs, select second-level domains, pick the right registrar, and understand EPP status codes for domain management.

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.

Hierarchy

🏛️ Domain Registration Hierarchy:
The domain name registration hierarchy is a globally distributed framework that ensures domain uniqueness and enforces registration rules across the internet.

ICANN - Internet Corporation for Assigned Names and Numbers

At the top of the hierarchy rules ICANN, a non-profit, internationally organized corporation.

• Main Role: Oversee the huge and complex, interconnected network of unique identifiers that allow computers on the internet to find one another
• Responsibilities:
  • 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
  • Maintaining a central repository of IP addresses

Regional Internet Registries (RIRs)

Below ICANN are five regional internet registries.

• Each registry is responsible for obtaining IP ranges from ICANN to allocate them to internet service providers across a specific geographic region
• These registries manage IP address distribution for their respective regions (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC)

Registrars

Subordinate to the registries are the registrars, which are ICANN-accredited organizations responsible for processing the registration of domain names.

📋 Examples of Registrars:

• GoDaddy
• Namecheap
• Bluehost

Resellers

After registrars come resellers - third-party companies that offer domain name registration services through registrars.

• Example: 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 TLDs
  • Gandi for all other top-level domains

Registrants

At the bottom of the hierarchy are the registrants - the people or organizations who register domains through a registrar or a reseller.

🔄 Registration Hierarchy Flow:
ICANN → Regional Internet Registries → Registrars → Resellers → Registrants

Process

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

1. Step 1 - Domain Selection: The registrant chooses a domain name and submits a request to a registrar or reseller
2. Step 2 - Availability Check: Provided that the domain name is available, the registrar registers the name and then creates a WHOIS record
3. Step 3 - WHOIS Record Creation: The WHOIS 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
   • The expiration date
   • Administrative and technical contact information (optional)
4. Step 4 - Registry Submission: The registrar sends the domain name request along with the contact and technical information to the appropriate registry
5. Step 5 - Master Server Update: The registry files all information provided and adds the names on file to the master servers, which will tell other servers on the internet where your website is located

📝 What is a WHOIS Record?
A WHOIS record is a public database entry that contains registration and contact information about a domain name. It serves as a directory of domain ownership and technical details.

Considerations When Choosing a TLD

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

• Generic TLDs (gTLD) - .com, .net, .org
• Country-code TLDs (ccTLD) - .uk, .de, .jp
• Infrastructure TLDs - .arpa
• Sponsored TLDs (sTLD) - .gov, .edu, .mil
• Internationalized Domain Name TLDs (IDN TLD) - Non-Latin characters
• Geographic TLDs - .london, .nyc, .tokyo

Not all TLDs will suit your requirement, so we have to take these considerations into account and ask the following questions:

Consideration	Description
DNSSEC Support	Security-related feature to avoid DNS cache poisoning and other attacks
IDNs Support	International Domain Names - support for non-ASCII characters
Privacy Protection	For protecting the privacy of website owner information
Target Audience	Is the organization region-specific? (e.g., healthcare provider)
Relevant Field	What is the field of business? (e.g., .cafe, .coffee, .tech)
Local Presence Requirements	Some TLDs require local presence or registration

Choosing a Second-Level Domain

Name Considerations

✅ 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, or acronyms
• Make it too long or complicated
• Use trademarked names

Choosing a Registrar

When selecting a domain registrar, consider the following factors:

1. Pricing

• Registration fee - Initial cost to register the domain
• Renewal fee - Annual or multi-year renewal costs
• Other potential charges - Domain transfers, privacy protection, etc.
• Most registrars do not charge transfer fees, but some do

2. Cost Benefits

• Bulk pricing options for multiple domains
• Promotional deals - Registering a domain name for several years at a discounted price
• Bundle discounts when combined with other services

3. Add-On Services

• Web hosting services
• WordPress hosting services
• Website builders
• Email hosting services
• Brokerage services
• Privacy protection (WHOIS privacy)
• SSL certificates
• Customer service support (24/7 vs business hours)

4. Supported TLDs

• Not all registrars have the license to sell all top-level domains
• Verify the registrar supports your desired TLD before committing
• Some registrars specialize in specific TLD categories

5. Policies

⚠️ Critical Policies to Review:

• Domain Transfer Policy: What is the registrar's policy on domain transfers? Are there fees or waiting periods?
• Domain Expiration Policy: What happens when your domain expires?
  • Domain names are registered for a specific duration
  • Some registrars offer a grace period after expiration to allow renewal
  • Other registrars can exercise predatory practices, such as buying your expired domain name as soon as it expires to sell it back to you at a much higher price
• Auto-Renewal Settings: Is auto-renewal enabled by default? Can you disable it?
• Domain Lock: Does the registrar provide domain locking to prevent unauthorized transfers?

6. Customer Reviews

• Always read customer reviews while carrying out your research on which registrar you should choose
• Check for reviews about customer service responsiveness
• Look for feedback on renewal pricing and hidden fees
• Verify the registrar's reputation for security and reliability

7. Best Practice

💡 Pro Tip:
It is recommended that you register your domain name with one registrar but host it with another provider. This approach makes it easier to switch hosting companies if required later on, provided that the domain name is hosted on a platform different from the one it was registered on. This separation of concerns gives you more flexibility and control.

EPP Status Codes

Extensible Provisioning Protocol (EPP) 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

Types of EPP Status Codes

There are two different types of EPP status:

🔐 Client vs Server Status Codes:

• Client Status Codes: Set by registrars, and depending on the registrar, they are set upon registering the domain or when requested by the domain owner
• Server Status Codes: Set by registries, and they take precedence over client codes. If you remember from the previous section, registries reside higher up in the domain name registration hierarchy than registrars

Common Client Status Codes

Status Code	Description
clientHold	Tells your domain's registry to not activate your domain in the DNS and therefore it will not resolve. An uncommon status that is usually active during legal disputes, non-payment, or when your domain is subject to deletion.
clientTransferProhibited	Tells your domain's registry to reject requests to transfer the domain from your current registrar to another. Often used as a security measure to prevent unauthorized transfers.
clientUpdateProhibited	Tells your domain registry to reject requests to update the domain information. Provides protection against unauthorized changes.

Common Server Status Codes

Status Code	Description
OK	The standard status for a domain, meaning that it has no pending operations or prohibitions. The domain is active and can be modified or transferred.
autoRenewPeriod	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	Prevents your domain name from being transferred from your current registrar to another. An uncommon status that is usually active during legal or other disputes, at your request, or when a redemption period status is in place.

Checking EPP Status Codes

🔍 How to Check EPP Status:
You can inspect the EPP codes of any domain you're interested in simply by performing a WHOIS lookup against it. Navigate to: https://lookup.icann.org/

Enter the domain name and view the "Domain Status" section in the WHOIS record to see all active EPP codes.

🎓 Key Takeaways:

• Registration Hierarchy: ICANN → Regional Registries → Registrars → Resellers → Registrants
• ICANN manages the entire DNS ecosystem including TLDs, root servers, and IP address coordination
• WHOIS records contain all registration and contact information for domains
• Over 1500 TLDs available - consider DNSSEC, IDN support, target audience, and field relevance
• Second-level domains should be short (under 10 characters), easy to spell, pronounce, and remember
• Avoid hyphens, numbers, and acronyms in domain names
• Choose registrars based on pricing, supported TLDs, add-on services, policies, and customer reviews
• Best Practice: Register domain with one provider, host with another for flexibility
• EPP status codes indicate domain status - two types: Client (registrar-set) and Server (registry-set)
• Server codes take precedence over client codes
• Check EPP status using ICANN WHOIS lookup tool
• Common statuses: OK (standard), clientHold (not activated), clientTransferProhibited (transfer blocked)

📚 Practice Exercises

1. Perform a WHOIS lookup on your favorite website and identify its EPP status codes
2. Research three different registrars and compare their pricing for a .com domain
3. Identify which TLD category would be most appropriate for:
   • A local London bakery
   • An international tech startup
   • A government agency
   • An educational institution
4. List three domain names for a fictional coffee shop business following the naming best practices
5. Explain the difference between a registrar and a reseller with examples