Scenario: User/server(client) machine trying to reach nike.com
- DNS client checks the cache on local machine for the IP of nike.com
- Client's machine cache doesn't have the required IP
- Client queries the DNS server which is provided/configured by the ISP
- Above new DNS server also known as recursive DNS server checks its own cache if it has the IP of nike.com
- Recursive DNS server doesn't have the IP and it begins the process to locate the IP of nike.com
Below steps are performed by the client to locate the IP
- Get list of root servers
- Root server is configured on the system by default at location /usr/share/dns/root.hints for linux systems
dig +short ns
akshay-gore:~$ dig +short ns
k.root-servers.net.
c.root-servers.net.
h.root-servers.net.
i.root-servers.net.
a.root-servers.net.
m.root-servers.net.
f.root-servers.net.
d.root-servers.net.
b.root-servers.net.
l.root-servers.net.
j.root-servers.net.
g.root-servers.net.
e.root-servers.net.
- Tracing the path of request from a system to the web server of the nike.com
dig +trace nike.com
; <<>> DiG 9.18.39-0ubuntu0.24.04.1-Ubuntu <<>> +trace nike.com
;; global options: +cmd
. 3090 IN NS h.root-servers.net.
. 3090 IN NS j.root-servers.net.
. 3090 IN NS k.root-servers.net.
. 3090 IN NS d.root-servers.net.
. 3090 IN NS m.root-servers.net.
. 3090 IN NS b.root-servers.net.
. 3090 IN NS f.root-servers.net.
. 3090 IN NS i.root-servers.net.
. 3090 IN NS c.root-servers.net.
. 3090 IN NS a.root-servers.net.
. 3090 IN NS e.root-servers.net.
. 3090 IN NS g.root-servers.net.
. 3090 IN NS l.root-servers.net.
;; Received 239 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 86400 IN DS 19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A
com. 86400 IN RRSIG DS 8 1 86400 20251119050000 20251106040000 61809 . tncdUkjC/m4gwK8aqbdYHV1ZD+WR3n5FJgvwM+xHj4kJMG6D5XuASX4x 2D0YrJG547HWwb1jAjDcHaRyBcJqeoHti/mcLrungu4mGMHzYeVPx/Td YrC7yk91EA8UDacZA2y1qK0pzziw+GPEUs5ny5wOIvgRrXKOZPZYif60 UPk2df0O2lqe4q8vrx8Ff4zKDs275tC2Er+hrJ6YrQ8hKdwpDgkOdrjO 2e62PctJlRFYVj6MWBmQZS85ZSXCxMgP4bCUo5no6S3at4z2bKFfWjpF GcB7MF0kGwArH/hPfudiEV3cpoGPEOmr3o53vfIv22fxBfcOSmPjHq1y BuDwqg==
;; Received 1168 bytes from 2001:500:2f::f#53(f.root-servers.net) in 116 ms
nike.com. 172800 IN NS ns-n1.nike.com.
nike.com. 172800 IN NS ns-n2.nike.com.
nike.com. 172800 IN NS ns-n3.nike.com.
nike.com. 172800 IN NS ns-n4.nike.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN NSEC3 1 1 0 - CK0Q3UDG8CEKKAE7RUKPGCT1DVSSH8LL NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN RRSIG NSEC3 13 2 900 20251111002637 20251103231637 46539 com. qil9G2NSHYVtUASYp5W8XlMim+ieLFJ/aWJROvBKJfsjLso2rCp+GY5N vzw13ee/+aYXc2ZmkHSCrjrqPWjmAQ==
1AUF57P261FM4PRA2UHSG8IOEQH8RRSD.com. 900 IN NSEC3 1 1 0 - 1AUFABRNB1AREK54RAOGOJUIHBQ6C10I NS DS RRSIG
1AUF57P261FM4PRA2UHSG8IOEQH8RRSD.com. 900 IN RRSIG NSEC3 13 2 900 20251112011923 20251105000923 46539 com. ACPLjyPFa7MlxXfIhQx74GciwjbCwvTCT1mmWdLfaP3LvMtWkOg5ku6V aRHkII5DI+1pL/KRP8idLxs91qwm0w==
;; Received 538 bytes from 192.54.112.30#53(h.gtld-servers.net) in 292 ms
nike.com. 60 IN A 18.172.64.109
nike.com. 60 IN A 18.172.64.17
nike.com. 60 IN A 18.172.64.37
nike.com. 60 IN A 18.172.64.97
nike.com. 3600 IN NS ns-n1.nike.com.
nike.com. 3600 IN NS ns-n2.nike.com.
nike.com. 3600 IN NS ns-n3.nike.com.
nike.com. 3600 IN NS ns-n4.nike.com.
;; Received 245 bytes from 64:ff9b::cdfb:c343#53(ns-n4.nike.com) in 240 ms
Analyzing the output of trace command
Note : Lines in output starting with ;; are comments from the output
- Line
;; Received 239 bytes from 127.0.0.53#53(127.0.0.53) in 0 msin the output and states that it received 239 bytes as a response size from local(127.0.0.1) dns service running on port 53 which is list of root servers - Line
;; Received 1168 bytes from 2001:500:2f::f#53(f.root-servers.net) in 116 msin the output and states that it received 1168 bytes as a response size from root server f.root-servers.net which is list of nameservers for com. domain - Line
;; Received 538 bytes from 192.54.112.30#53(h.gtld-servers.net) in 292 msin the output and states that it received 538 bytes as a response size from nameserver server h.gtld-servers.net which is list of nameservers for nike.com. domain - Line
;; Received 245 bytes from 64:ff9b::cdfb:c343#53(ns-n4.nike.com) in 240 msin the output and states that it received 245 bytes as a response size from nameserver server ns-n4.nike.com which is A record nike.com. which is the actual IP of website ##### Things to notice - Root server is configured on the user system by default at location /usr/share/dns/root.hints
- Root servers provide nameservers for com domain eg: a.gtld-servers.net.
- Now, the nameserver a.gtld-servers.net. is also the top level domain server for com. > The domain a.gtld-servers.net has an A record but no NS record for a simple reason: it is the nameserver itself, and nameservers typically do not delegate authority for their own name to a different set of nameservers.
- The tld server a.gtld-servers.net. provides the nameserver for nike.com as ns-n1.nike.com., ns-n3.nike.com. and so on
- The above nameserver ns-n1.nike.com. provides A record which is also IP for nike.com website
Useful commands
1.
dig A nike.com
Provides IP address of nike.com
```
; <<>> DiG 9.18.39-0ubuntu0.24.04.1-Ubuntu <<>> A nike.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36711
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;nike.com. IN A
;; ANSWER SECTION:
nike.com. 77 IN A 18.172.64.17
nike.com. 77 IN A 18.172.64.97
nike.com. 77 IN A 18.172.64.109
nike.com. 77 IN A 18.172.64.37
;; Query time: 260 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Nov 06 13:35:35 IST 2025
;; MSG SIZE rcvd: 101
```
2.
dig NS nike.com
Provides nameservers of nike.com
```
; <<>> DiG 9.18.39-0ubuntu0.24.04.1-Ubuntu <<>> NS nike.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56992
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;nike.com. IN NS
;; ANSWER SECTION:
nike.com. 4502 IN NS ns-n4.nike.com.
nike.com. 4502 IN NS ns-n1.nike.com.
nike.com. 4502 IN NS ns-n2.nike.com.
nike.com. 4502 IN NS ns-n3.nike.com.
;; Query time: 215 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Nov 06 13:37:12 IST 2025
;; MSG SIZE rcvd: 117
```
One can also do dig A nike.com @1.1.1.1 or dig NS nike.com @1.1.1.1 which means check recods against DNS 1.1.1.1
-
Trying to get NS record for tld server will give empty response as it does not have an NS record as it is nameserver itself instead it gives an SOA record
dig NS a.gtld-servers.net.
```
; <<>> DiG 9.18.39-0ubuntu0.24.04.1-Ubuntu <<>> NS a.gtld-servers.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3874
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;a.gtld-servers.net. IN NS
;; AUTHORITY SECTION:
gtld-servers.net. 3600 IN SOA av4.nstld.com. nstld.verisign-grs.com. 1762388322 3600 900 1209600 86400
;; Query time: 407 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Nov 06 13:41:09 IST 2025
;; MSG SIZE rcvd: 115
```
- The SOA record provides critical administrative information about a DNS zone. Here is the explanation of each field in the record you provided: The SOA record is one of the mandatory records in a DNS zone file. It designates the primary authoritative server and provides critical administrative details for zone transfers and caching.
| Field | Description | Purpose |
|---|---|---|
| Name | The name of the zone (e.g., example.com.). | Indicates the domain to which the SOA record applies. |
| TTL | The Time-to-Live (in seconds) for the SOA record itself. | Specifies how long other servers should cache this administrative record. |
| Class | Always IN (for Internet). | Defines the protocol family; virtually always Internet. |
| Type | Always SOA (Start of Authority). | Identifies the record type. |
| MNAME | The Primary Master Name Server (e.g., ns1.example.com.). | The authoritative server that holds the definitive copy of the zone file. |
| RNAME | The Responsible Person's Email Address (e.g., hostmaster.example.com.). | The administrative contact for the zone. The first dot in the name is replaced by an @ symbol when interpreted as an email address (e.g., hostmaster@example.com). |
| Serial | A Version Number for the zone file (often in the format YYYYMMDDSS). | Secondary name servers check this number. If it has increased, they initiate a zone transfer to update their data. |
| Refresh | The time (in seconds) secondary servers wait before checking the primary server for a zone file update. | Controls the frequency of checking for zone file changes. |
| Retry | The time (in seconds) a secondary server waits to re-try contacting the primary master after a connection failure. | Allows the secondary to try again quickly without waiting for the full Refresh time if the initial check fails. |
| Expire | The time (in seconds) after which a secondary server will stop answering queries for the zone if it has been unable to contact the primary master. | Prevents the secondary server from providing stale data indefinitely. |
| Minimum TTL | The time (in seconds) to be used for caching negative responses (e.g., when a queried record or domain does not exist). | Limits how long a resolver will remember that a particular name failed to resolve. |
Other Additional DNS related topics
- TTL : DNS records update based on a set interval defined by their Time to Live (TTL) value, which starts at the moment the record is cached, not after the last retrieval. >Here is how it works:
- Time to Live (TTL): Every DNS record has a TTL value, set by the domain administrator on the authoritative DNS server. This value tells other DNS servers (recursive resolvers and local computers) how long they should store (cache) that record before discarding it and requesting a fresh copy from the authoritative server.
- Caching and Expiration: When a DNS server or a local computer receives a DNS record, it stores the information for the duration specified by the TTL. The countdown begins immediately upon receipt.
- Update Mechanism: After the set TTL interval expires, the cached record is marked as stale. The next time a user requests that domain name, the local DNS server will not use the old cached information but will instead perform a new query to the authoritative nameserver to get the most current information
Top comments (0)