# Doing DNS Resolution Manually \# The O.G `hosts.txt` The `hosts.txt` file is a plain text file used to map hostnames to IP addresses, allowing for manual DNS resolution. It is commonly found in the `C:\Windows\System32\drivers\etc` directory on Windows systems and in `/etc` on Unix-based systems. This file can be edited to override DNS settings, redirect traffic, or block access to specific websites by associating them with invalid IP addresses. ```c 127.0.0.1 localhost 127.0.0.1 myserver.local 142.250.183.78 google.com ``` If you add `myserver.local` to the `/etc/hosts` file, it will direct to the IP address `127.0.0.1` whenever you access the site in a browser. Before querying a DNS server, the request will first check the `/etc/hosts` file. If the entry is not found, it will then proceed to query a DNS server, including any caching mechanisms in place. Using the `hosts.txt` file can lead to performance issues due to the need for manual updates and potential conflicts with DNS servers. Additionally, it lacks the dynamic capabilities of DNS, making it less efficient for managing large or frequently changing networks. # Getting [`https://www.example.com`](https://www.example.com) ```mermaid sequenceDiagram participant User as User participant Browser as Browser participant DNS as DNS Resolver participant Root as Root DNS Server participant TLD as TLD DNS Server participant Authoritative as Authoritative DNS Server participant Server as Web Server User->>Browser: Enter URL (https://www.example.com) Browser->>DNS: DNS Query for www.example.com DNS->>Root: Query for .com Root-->>DNS: Referral to TLD DNS Server DNS->>TLD: Query for www.example.com TLD-->>DNS: Referral to Authoritative DNS Server DNS->>Authoritative: Query for www.example.com Authoritative-->>DNS: IP Address of www.example.com DNS-->>Browser: IP Address of www.example.com Browser->>Server: HTTP Request to IP Address Server-->>Browser: HTTP Response Browser-->>User: Display Web Page ``` This entire process is done manually, so if I simply tell you what happens, you might not grasp it or agree with the concept. Let's go through each step manually to ensure we fully understand what's occurring behind the scenes. ## Querying the Root Server for a [example.com](http://example.com) TLD server To understand how DNS resolution works, let's walk through the process of resolving [`example.com`](http://example.com) using the `dig` command at each level of the DNS hierarchy. First, we query a **root DNS server** with: ```bash dig example.com A @a.root-servers.net ``` ```c ; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> example.com A @a.root-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55436 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;example.com. IN A ;; AUTHORITY SECTION: com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. ;; ADDITIONAL SECTION: l.gtld-servers.net. 172800 IN A 192.41.162.30 l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30 j.gtld-servers.net. 172800 IN A 192.48.79.30 j.gtld-servers.net. 172800 IN AAAA 2001:502:7094::30 h.gtld-servers.net. 172800 IN A 192.54.112.30 h.gtld-servers.net. 172800 IN AAAA 2001:502:8cc::30 d.gtld-servers.net. 172800 IN A 192.31.80.30 d.gtld-servers.net. 172800 IN AAAA 2001:500:856e::30 b.gtld-servers.net. 172800 IN A 192.33.14.30 b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30 f.gtld-servers.net. 172800 IN A 192.35.51.30 f.gtld-servers.net. 172800 IN AAAA 2001:503:d414::30 k.gtld-servers.net. 172800 IN A 192.52.178.30 k.gtld-servers.net. 172800 IN AAAA 2001:503:d2d::30 m.gtld-servers.net. 172800 IN A 192.55.83.30 m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30 i.gtld-servers.net. 172800 IN A 192.43.172.30 i.gtld-servers.net. 172800 IN AAAA 2001:503:39c1::30 g.gtld-servers.net. 172800 IN A 192.42.93.30 g.gtld-servers.net. 172800 IN AAAA 2001:503:eea3::30 a.gtld-servers.net. 172800 IN A 192.5.6.30 a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30 c.gtld-servers.net. 172800 IN A 192.26.92.30 c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30 e.gtld-servers.net. 172800 IN A 192.12.94.30 e.gtld-servers.net. 172800 IN AAAA 2001:502:1ca1::30 ;; Query time: 233 msec ;; SERVER: 2001:503:ba3e::2:30#53(a.root-servers.net) (UDP) ;; WHEN: Sat Jun 07 17:03:55 IST 2025 ;; MSG SIZE rcvd: 836 ``` This doesn't return the IP address of [`example.com`](http://example.com) but instead provides a list of `.com` TLD name servers, such as [`a.gtld-servers.net`](http://a.gtld-servers.net), [`b.gtld-servers.net`](http://b.gtld-servers.net), etc., because the root servers only know where to find Top-Level Domain (TLD) servers. Also, note the warning indicating that recursion was requested but is not available. This occurs because a root server, such as [a.root-servers.net](http://a.root-servers.net), only provides `Authoritative` responses. In other words, it will not go out of its way to assist further. A root server (like [`a.root-servers.net`](http://a.root-servers.net)) **only gives authoritative responses**. It doesn’t do the dirty work for you. It just says “go ask someone else.” But a public recursive resolver (like `1.1.1.1`) is built to go all the way and bring you the final answer. It will **do the full DNS resolution** on your behalf. ## Querying the TLD Server for [example.com](http://example.com) ```c dig example.com A @a.gtld-servers.net ``` ```c razor@beast:~$ dig example.com A @a.gtld-servers.net ; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> example.com A @a.gtld-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50147 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;example.com. IN A ;; AUTHORITY SECTION: example.com. 172800 IN NS a.iana-servers.net. example.com. 172800 IN NS b.iana-servers.net. ;; Query time: 221 msec ;; SERVER: 2001:503:a83e::2:30#53(a.gtld-servers.net) (UDP) ;; WHEN: Sat Jun 07 17:13:19 IST 2025 ;; MSG SIZE rcvd: 88 ``` This again doesn’t give us the final IP but tells us which **authoritative name servers** are responsible for [`example.com`](http://example.com), specifically [`a.iana-servers.net`](http://a.iana-servers.net) and [`b.iana-servers.net`](http://b.iana-servers.net). These servers hold the actual DNS records for the domain. Finally, we query one of these authoritative servers: ## Querying the Authoritative Server `dig` [`example.com`](http://example.com) `A @`[`a.iana-servers.net`](http://a.iana-servers.net) ```c ; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> example.com A @a.iana-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49221 ;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 300 IN A 23.192.228.80 example.com. 300 IN A 23.192.228.84 example.com. 300 IN A 23.215.0.136 example.com. 300 IN A 23.215.0.138 example.com. 300 IN A 96.7.128.175 example.com. 300 IN A 96.7.128.198 ;; Query time: 306 msec ;; SERVER: 2001:500:8f::53#53(a.iana-servers.net) (UDP) ;; WHEN: Sat Jun 07 17:34:36 IST 2025 ;; MSG SIZE rcvd: 136 ``` This time, we get the desired result: a list of A records (IPv4 addresses) such as `23.192.228.80`, `96.7.128.175`, and others. This step-by-step resolution—from root to TLD to authoritative servers—demonstrates how DNS works behind the scenes to translate human-readable domain names into machine-usable IP addresses. ## Understanding Reverse DNS Lookups Reverse DNS lookups, involve determining the domain name associated with a given IP address. This process is the opposite of a standard DNS lookup, which resolves domain names to IP addresses, and is often used for verifying the authenticity of email servers and other network communications. We can explore how to achieve this by utilizing the `-x` option with the `dig` command. This allows us to retrieve the domain names associated with the IP address 8.8.8.8, which is Google's DNS server. ```plaintext dig -x 8.8.8.8 ``` ```c ; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> -x 8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47927 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;8.8.8.8.in-addr.arpa. IN PTR ;; ANSWER SECTION: 8.8.8.8.in-addr.arpa. 7048 IN PTR dns.google. ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) ;; WHEN: Sat Jun 07 17:25:35 IST 2025 ;; MSG SIZE rcvd: 73 ``` Here is the response: as you can observe, we have obtained the [`dns.google`](http://dns.google) domain name. ### Understanding `.`[`in-addr.arpa`](http://in-addr.arpa) Queries To find reverse domain names, we perform a process similar to using `dig -x`. This involves querying the reverse DNS for a given IP address. For the address `96.7.128.175`, we use the command `dig` [`175.128.7.96.in-addr.arpa`](http://175.128.7.96.in-addr.arpa)`.`. The key step here is reversing the order of the IP address segments and appending [`in-addr.arpa`](http://in-addr.arpa)`.` to the end. This reversed format is necessary because the DNS system uses this structure to map IP addresses back to domain names. ```c ; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> 175.128.7.96.in-addr.arpa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16152 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;175.128.7.96.in-addr.arpa. IN A ;; AUTHORITY SECTION: in-addr.arpa. 1800 IN SOA ns1.reverse.deploy.akamaitechnologies.com. hostmaster.akamai.com. 1582134113 90000 90000 90000 180 ;; Query time: 101 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) ;; WHEN: Sat Jun 07 17:37:40 IST 2025 ;; MSG SIZE rcvd: 149 ``` `dig -x` command internally uses the `.`[`in-addr.arpa`](http://in-addr.arpa) queries. To confirm this, we can examine the source code of the `dig` command. ```c isc_result_t get_reverse(char *reverse, size_t len, char *value, isc_boolean_t ip6_int, isc_boolean_t strict) { int r; isc_result_t result; isc_netaddr_t addr; addr.family = AF_INET6; r = inet_pton(AF_INET6, value, &addr.type.in6); if (r > 0) { /* This is a valid IPv6 address. */ dns_fixedname_t fname; dns_name_t *name; unsigned int options = 0; if (ip6_int) options |= DNS_BYADDROPT_IPV6INT; dns_fixedname_init(&fname); name = dns_fixedname_name(&fname); result = dns_byaddr_createptrname2(&addr, options, name); if (result != ISC_R_SUCCESS) return (result); dns_name_format(name, reverse, (unsigned int)len); return (ISC_R_SUCCESS); } else { /* * Not a valid IPv6 address. Assume IPv4. * If 'strict' is not set, construct the * in-addr.arpa name by blindly reversing * octets whether or not they look like integers, * so that this can be used for RFC2317 names * and such. */ char *p = reverse; char *end = reverse + len; if (strict && inet_pton(AF_INET, value, &addr.type.in) != 1) return (DNS_R_BADDOTTEDQUAD); result = reverse_octets(value, &p, end); if (result != ISC_R_SUCCESS) return (result); /* Append .in-addr.arpa. and a terminating NUL. */ result = append(".in-addr.arpa.", 15, &p, end); if (result != ISC_R_SUCCESS) return (result); return (ISC_R_SUCCESS); } } ``` ## Understanding the Resolution of Subdomains A subdomain is a distinct section of a main domain, allowing for the creation of separate websites or web services under the primary domain name. For example, "[blog.example.com](http://blog.example.com)" is a subdomain of "[example.com](http://example.com)," enabling the hosting of a blog on a different URL while maintaining the main domain's branding. ```mermaid graph TD A[Client] -->|DNS Query| B[Local DNS Server] B -->|Recursive Query| C[Root DNS Server] C -->|Referral| D[TLD DNS Server] D -->|Referral| E[Authoritative DNS Server] E -->|DNS Response| D D -->|DNS Response| C C -->|DNS Response| B B -->|DNS Response| A style A fill:#f9f,stroke:#333,stroke-width:2px style B fill:#bbf,stroke:#f66,stroke-width:2px style C fill:#bbf,stroke:#f66,stroke-width:2px style D fill:#bbf,stroke:#f66,stroke-width:2px style E fill:#bbf,stroke:#f66,stroke-width:2px ``` #### No Delegation --- In a non-delegated subdomain, the DNS records for the subdomain are managed by the parent domain's DNS servers. For instance, if [`blog.example.com`](http://blog.example.com) is a non-delegated subdomain, the DNS records for `blog` are handled by the DNS servers responsible for [`example.com`](http://example.com). This setup simplifies management but can centralize the load on the parent domain's servers. ```c example.com → handled by ns1.dnsprovider.com blog.example.com → also handled by ns1.dnsprovider.com ``` #### Delegated Subdomain --- A delegated subdomain, on the other hand, has its own set of DNS servers. For example, if [`blog.example.com`](http://blog.example.com) is a delegated subdomain, it will have its own DNS servers that manage its records independently of [`example.com`](http://example.com). This approach distributes the DNS load and allows for more granular control over the subdomain's DNS settings, enhancing flexibility and performance. ```c example.com → handled by ns1.dnsprovider.com internal.example.com → delegated to ns1.internaldns.net ``` ## DNS Records Syntax DNS records follow a specific syntax to define various types of data. The basic structure is: * ``: The domain name for which the record is valid. * ``: Time to Live, indicating how long the record should be cached. * ``: The class of the DNS data, typically `IN` for Internet. * ``: The type of DNS record, such as `A`, `MX`, `CNAME`, etc. * ``: The length of the RDATA field in bytes. * ``: The actual data for the record, varying by type (e.g., IP address for `A` records). This syntax ensures that DNS queries and responses are correctly interpreted by DNS servers and clients. # DNS Record Types DNS (Domain Name System) records are essential for translating human-readable domain names into IP addresses and providing other critical information. Here are some of the most common types of DNS records: ## A Record * **Purpose**: Maps a domain name to an IPv4 address. * **Example**: [`example.com`](http://example.com)`. IN A 192.0.2.1` ## SOA Record * **Purpose**: Specifies the primary name server for a domain and provides administrative information. * **Example**: ```plaintext example.com. IN SOA ns1.example.com. admin.example.com. ( 2023101001 ; Serial 3600 ; Refresh 1800 ; Retry 1209600 ; Expire 3600 ; Minimum TTL ) ``` ## MX Record * **Purpose**: Specifies the mail servers responsible for receiving email on behalf of a domain. * **Example**: [`example.com`](http://example.com)`. IN MX 10` [`mail.example.com`](http://mail.example.com)`.` ## NS Record * **Purpose**: Specifies the authoritative name servers for a domain. * **Example**: [`example.com`](http://example.com)`. IN NS` [`ns1.example.com`](http://ns1.example.com)`.` ## CNAME Record * **Purpose**: Aliases one domain name to another. * **Example**: [`www.example.com`](http://www.example.com)`. IN CNAME` [`example.com`](http://example.com)`.` ## PTR Record * **Purpose**: Maps an IPv4 address to a domain name (reverse DNS lookup). * **Example**: [`1.2.0.192.in-addr.arpa`](http://1.2.0.192.in-addr.arpa)`. IN PTR` [`example.com`](http://example.com)`.` ## HINFO Record * **Purpose**: Provides information about the hardware and operating system of a host. * **Example**: [`example.com`](http://example.com)`. IN HINFO "PC" "Windows 10"` ## TXT Record * **Purpose**: Holds text information for sources outside your domain. * **Example**: [`example.com`](http://example.com)`. IN TXT "v=spf1 include:_`[`spf.google.com`](http://spf.google.com) `~all"` ## DNS Zone File A DNS zone file is a text file that contains mappings between domain names and IP addresses, facilitating the translation of human-readable domain names into numerical IP addresses that computers use to identify each other on the network. It is organized into records, each specifying a particular type of information, such as A records for IPv4 addresses, AAAA records for IPv6 addresses, and MX records for mail servers. Zone files are essential for the functioning of the Domain Name System (DNS), enabling efficient and reliable domain name resolution across the internet. ```plaintext $TTL 3600 @ IN SOA ns1.example.com. admin.example.com. ( 2025060701 ; Serial 3600 ; Refresh 1800 ; Retry 1209600 ; Expire 86400 ) ; Minimum TTL IN NS ns1.example.com. IN NS ns2.example.com. @ IN A 192.0.2.1 www IN CNAME example.com. mail IN A 192.0.2.2 @ IN MX 10 mail.example.com. ``` A DNS zone file is a text file that contains mappings between domain names and IP addresses, facilitating the translation of human-readable domain names into numerical IP addresses that computers use to identify each other on a network. It is organized into records, each specifying details like the domain name, record type (e.g., A, CNAME, MX), and corresponding values. Zone files are essential for DNS servers to resolve queries efficiently and direct traffic to the correct destinations. They are typically managed by domain administrators to ensure accurate and up-to-date DNS configurations. ## Attacks on DNS ### Denial Of Service **Denial of Service (DoS) attacks against DNS servers** aim to overwhelm the server with excessive traffic, preventing it from responding to legitimate requests. This disrupts the translation of domain names to IP addresses, causing widespread internet outages and making websites and services inaccessible. ### DNS cache poisoning DNS cache poisoning occurs when an attacker corrupts a DNS resolver's cache with false information, redirecting users to malicious websites. This manipulation can lead to various security issues, such as phishing attacks or data theft, by exploiting the trust users place in legitimate domain names. ## DNSSEC DNSSEC (Domain Name System Security Extensions) is a suite of specifications designed to enhance the security of the Domain Name System (DNS) by enabling DNS responses to be validated. It adds cryptographic signatures to DNS data, helping to protect against certain types of attacks, such as DNS spoofing and cache poisoning.