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

Domain Name Resolution

DNS Name Resolution

🎯 What You'll Learn:
Understand the complete DNS name resolution process including local name resolution with hosts files, DNS resolvers, iterative vs recursive queries, caching mechanisms, and reverse DNS lookups. Master the workflow from browser to authoritative name servers.

The process of DNS requests being resolved to their associated IP addresses is fundamental to internet communication. As we're getting into the name resolution section, it is worth stating that there is not one, but several types of name resolution of which one is Local Name Resolution.

Local Name Resolution

🔑 Key Concept:
As the name suggests, local name resolution occurs locally on the end user machine without contacting any external service or systems of any kind. This type of resolution operates with a host table, a simple text file consisting of static mappings between IP addresses and host names.

History of the Hosts File

• The host's table is the predecessor of DNS, and it was one of the earliest named systems ever created in computing.
• Back in the 1970s, when the internet, known as ARPANET at the time, was a small frontal community of a few hundred hosts, the host table was the only way of resolving hostnames.
• Owners of new hosts would send an email to Hosts master at sri-nickarpa, to request an address and a file named hosts.txt would be distributed by the Network Information Control Center and manually installed on each host on the network to provide a mapping between these names and their corresponding network addresses.
• Each machine would load the hosts table into memory upon booting and consulting it whenever a name needed to be resolved.
• No requests, referrals or servers were involved.
• Resolution was entirely local and under the direct control of the local computer's administrator.
• Due to the dominant role of the host table in this entire process, local name resolution is also known as host table name resolution.

📁 Hosts File Locations:

• Windows: C:\Windows\System32\drivers\etc\hosts
• Linux: /etc/hosts

Limitations of Host Table Name Resolution

Host table name resolution is based on the flat name architecture, which comes with significant limitations:

• Difficulty in scaling
• Difficulty in ensuring name uniqueness
• Difficulty in maintaining consistency over the file across an expanding network

As a result, the host table and its local name resolution eventually gave way to DNS and its hierarchical name resolution. So, you might ask if the host table has been replaced by DNS, how come I still have it on my computer? And why do I need to know about it?

Modern Use Cases for Hosts File

Even though the host table has been replaced by DNS, it can still be used in the following scenarios:

• Small Local Networks - Quick resolution without DNS server
• Improving Performance - Skip DNS lookups for frequently accessed sites
• Redirecting local domains for various purposes
• Implementing basic URL filtering - Block malicious sites
• Bootstrapping - Initial network configuration
• Fallback name system in case DNS fails

Best Practices for Managing Hosts File

• Create as few entries in the hosts file as possible
• Keep the content organized
• Use version control
• Enforce access control so that unauthorized users cannot modify the host's file
• Always copy the hosts file before making any changes
• Comment out undesired mapping before deleting them
• Implement a mechanism to ensure name uniqueness

Before talking about the resolution types of the domain name system, we should spend some time on the protocol's component that makes resolution possible in the first place.

DNS Resolver

As we have seen from previous section, name resolution DNS uses a client server model whereby a client sends a query to a server requesting that a specific domain be resolved into its corresponding IP address.

🔍 What is a DNS Resolver?

• The first server that receives the client request is the DNS Resolver, which sits between the client and the rest of the DNS ecosystem.
• Upon receiving the request, the resolver first sees if he can answer the request directly and if not, it assumes the role of the client and takes it upon itself to have the query resolved on behalf of the original client by contacting the root servers and progressing the name resolution process.
• After receiving the final answer from the requested domains, authoritative name server, the resolver saves the result query in its cache and forwards it to the original client.

Root Hints File

Now you might ask, how does a DNS resolver know about the root servers? Well, the resolver has knowledge of the root servers thanks to its root hints file, which is where the root servers are stored.

The root hints file (named.cache, root.ca, root.hints, ...) can be obtained via IANA's page for popular links

So long as the resolver has the information included in this file, it will be able to contact the root servers while trying to resolve a domain name for its client.

Common DNS Resolvers

• In a small office home office network, your DNS resolver is typically your router, or an IP address provided by your internet service provider.
• DNS resolver companies, on the other hand, usually have their own corporate resolver.
• Well, it is also possible to use an open DNS resolver for your environment, assuming a connection to the internet was established.
• The most well-known resolvers Google's is 8.8.8.8 and 8.8.4.4
• So, you can, of course, use any other open resolver, such as 9.9.9.9, Cloudflare's 1.1.1.1, etc.
• A simple Google search on the available open DNS resolvers should provide you with a more comprehensive list.

Differences Between DNS Resolvers

Interestingly, though, virtually all the DNS resolvers share the same function described so far, not all of them support the same features or operate in the same manner.

• Some resolvers support EDNS0 (an extension to the DNS protocol we will discuss later) whereas some other do not.
• Many resolvers support negative caching but not all
• Not all resolvers use the same method in choosing which name servers to contact.
• Majority of DNS resolvers use a technique called Smooth Round Trip Time (SRTT) which is based on the lowest latency, while other resolvers select name service at random.

DNS Resolution Types

• Iterative resolution
• Recursive resolution

Iterative Resolution

Let's say we have a client that sends a DNS query to a server requesting information about a specific domain name.

• The queried server looks for the requested information in its own local data, and if it doesn't have the answer there, it returns a referral containing the names and addresses of the name servers closest to the domain name in the request to allow the resolution process to continue.
• It is worth noting that the referral includes all name server listed in its local data, and it's up to the client to choose which one to query next.
• The client must then iterate by sending a new request to this referred server, which again will return either an answer or another referral.
• The process continues until the correct server is found and an authoritative answer is given.
• The queries involved in this process are referred to as iterative, while the service responses are known as referrals.

💡 Analogy:
Think of iterative resolution as a series of rude telephone agents who simply answer your call and provide you with another number for you to ring. Passing you the responsibility of contacting one department in their organization after the other until you are given the information you're looking for.

Final Point for Iterative resolution: It is a client's responsibility to keep querying servers until the required information is obtained.

Recursive Resolution

We will use a similar scenario featuring a client sending a DNS request to a server asking for the IP address of a domain name.

• In recursive resolution, upon receiving the client's request, the server once again checks if it possesses the information requested, in which case it passes an answer back to the client.
• If it doesn't, however, something special happens.
• Instead of simply replying to the client with a referral to appoint a name server as in the case of its iterative resolution, the server instead assumes the role of the client, and he takes on the responsibility of continuing with the name resolution process by sending a series of iterative requests down the DNS tree, starting from the roots until it finds the authoritative answer for the domain name being requested and forwarded to the original client.
• In this type of resolution, the original client gets to send only a single query, which eventually returns information requested.
• That query is said to be a recursive query and recursive queries cannot be replied to with referrals. Instead, recursive queries compel the query server to find the requested information on behalf of the original client.

Final Point for recursive resolution: It is the service responsibility to obtain the DNS information requested by the original client.

Caching

The purpose of caching computing is to temporarily store previously acquired data so that future requests for that data can be served faster.

🚀 Why DNS Caching is Important:

• In the context of DNS, whenever its name is resolved, the resulting DNS information is cached so it can be used for subsequent requests that take place.
• This way, so long as the interesting DNS information remains cached, future requests against the same data which stopped the system that has cached the data in question.
• If we go back to our previous discussion on recursive resolution, we can say that there were quite a few DNS requests involved while the result of a server was trying to find the authoritative answer for the domain name requested by the client.
• It would be pointless and computationally taxing for the resolver to keep repeating the same queries for the same name that has just been resolved.
• What's more, repetitive DNS requests such as these consume network bandwidth and could result in DNS lookup latency.
• Thanks for caching. As soon as the resolver has the authoritative answer, it caches it before forwarding it to the client, which in turn places the result of data in its own cache too.

As a result, assuming that the result domain name is www.rjsnetworkcloudacademy.com for any future requests against that domain, the client will first consult with cache, which includes recently resolved DNS information as well as a mapping in the host table. If there is no information about www.rjsnetworkcloudacademy.com in the cache, the client will then contact the resolver, which will check its own cache and return the answer to the client, which then cache his information for future reference.

Negative Caching

• It is important to note that unsuccessful requests resulting in errors are also cached in what is known as negative caching.
• So, if www.youtube.com returned an error like this, domain doesn't exist. That error is cached in the same way that a successful resolution would have been.
• If the server doesn't have any relevant information in the cache at all, it will then proceed to sending the usual series of its requests until it finds the authoritative answer for www.youtube.com

💡 Cache-Only DNS Servers:
Caching is, in fact, so important in DNS that dedicated DNS servers exist for the sole purpose of providing this very caching function only without having any authority over any domains. These servers, unsurprisingly known as cache only DNS servers, and they often present in many network deployments.

Time To Live (TTL)

Now, you might ask if caching is so important in DNS, how come there is a limited time for which result names remain cached? In other words, why isn't resolved DNS information cached forever?

• Whether intentional or accidental changes do take place in the configuration of DNS name servers, and those changes can result in incorrect response to sense of queries due to cached information that is no longer valid.
• For instance, if the IP address of www.example.com changed to an IP address different to the one currently in cache, we would not be able to resolve the domain name anymore and instead we would get back error.
• Because of that reason, resolved names get cached for a finite amount of time, and the duration of that time frame is determined by a parameter known as time to live (TTL).

🔧 Viewing and Clearing DNS Cache on Windows:

• To view DNS cache: ipconfig /displaydns
• To clear the cache: ipconfig /flushdns

The DNS cache consists of recently resolved DNS information, as well as any mappings configured in the host table.

Important Points About DNS Caching

• Most, but not all, DNS resolvers cache recently resolved requests.
• Not all queries are cached. For example, reverse queries are not cached. The same applies to any resolutions returning data perceived as unreliable or corrupted.
• Negative answers are cashed with a different TTL.
• A cache hit refers to whenever the client finds the information it's looking for inside the cache. The opposite of that is known as Cache miss.

DNS Name Resolution Workflow

Step-by-Step Resolution Process

1. The process begins with an end user typing a domain name into their browser, such as www.example.com.
2. Assuming the browser does not have any information about that domain in its DNS cache, it asks the client's operating system.
3. The operating system checks its cache and hosts table for any data on www.example.com.
4. Assuming he doesn't find any, a recursive query is then sent to the DNS resolver, which first checks its own DNS cache.
5. If there is no relevant information there, either the DNS resolver consults its root hints file and contacts a root name server.
6. The queried root name server sends back a referral containing a list of name servers for the .com zone, along with their respective IP addresses.
7. The DNS resolver then selects one of those named servers and sends iterative query for www.example.com.
8. But queried .com name server responds with a referral containing a list of name servers which are authoritative for the example.com domain.
9. The DNS resolver selects one of those named servers and sends it and iterative query for www.example.com.
10. The authoritative name server then replies with an authoritative answer containing the IP address of the domain in question.
11. The DNS resolver then caches the information and forwards it to the client, that had transmitted the recursive query.
12. The operating system declined, then places the same data into its own cache and passes it over to the browser, which would typically put the result name in its own cache too.

✅ Key Insight:
And so, this is the famous DNS name resolution process that you are required to know for your own academic knowledge, technical interviews, and daily work.

Reverse Name Resolution

A DNS request that is looking for the IP address of a domain name is known as a forward request. The opposite of a forward request is a reverse request. In some situations, though, we might want to achieve the reverse outcome as we could have an IP address and wish to find domain name. Well, the DNS is fully capable of supporting this functionality, to which unsurprisingly is referred to as reverse resolution (rDNS).

The Challenge of Reverse DNS

• Now, at this point, some of you might say hang on a minute. In the namespace section, we talked about the hierarchical name architecture of DNS and how it is structured so that a particular devices place can be determined by looking at its name.
• You would be 100 percent correct to say so, since the inner servers are arranged by name and not by IP address.
• So, if the DNS server are set up based on names and not IP addresses, how on earth is it possible for us to find a domain name based on an IP address?
• Would we not need a parallel hierarchy based on an IP?
• The answer is a resounding yes.
• That is exactly what we need.

The in-addr.arpa Domain

To accommodate reverse resolution, DNS has a special domain called in-addr.arpa

Within that domain is a numerical hierarchy that covers the entire IP address space, and it contains four levels of numerical subdomains structured so that each IP address has its own node, and that node can contain an entry that points to the domain name mapped to that address.

After going to all the four level of numerical, we get the result as:

121.119.177.108.in-addr.arpa

How Reverse DNS Works

• The in-addr.arpa reverse name is illusion hierarchy covers the entire IPv4 address space and co-exists with a domain name hierarchy under the same root.
• The reason why we reversed the optics of the IP address contained in the reverse name is because unlike name resolution that proceeds from the list specific to the most specific element going from right to left. IP addresses have the least specific octet on the left and the most specific one on the right.
• In the interest of maintaining consistency with the DNS namespace, the octet are just flipped.
• It is worth noting that theoretically there should be a reverse entry for every IP address for the express reason of accommodating reversed name lookups.
• Reverse name lookups, though useful, are not considered critical for the function of internet so it is not mandatory for organizations to put in place reverse DNS entries for their IP addresses.

Use Cases for Reverse Name Resolution

• Troubleshooting: At times you might have an IP address and you won't find the domain name it is associated with.
• Filtering spam: Look at the IP address of an incoming email, and if no valid domain name is found, the message is blocked.
• Logging software: Reversed name lookups enable logging software to display not only IP addresses and log data, but also the human readable domain names for those IP addresses which are marked too.

🎓 Key Takeaways:

• Local name resolution uses the hosts file - predecessor of DNS from ARPANET era
• DNS resolvers sit between clients and DNS ecosystem, handling recursive queries
• Iterative resolution: Client's responsibility to keep querying servers
• Recursive resolution: Server's responsibility to obtain the information
• Caching improves performance by storing resolved names with TTL values
• Negative caching stores failed resolution attempts
• DNS resolution workflow: Browser → OS Cache → Resolver → Root → TLD → Authoritative
• Reverse DNS uses in-addr.arpa domain for IP-to-name lookups
• Common DNS resolvers: Google (8.8.8.8), Cloudflare (1.1.1.1)