CresignSys Learn

CresignSys Learn — Lesson 027

Written by

cresignsys

in

DNS Resolution — What Actually Happens Inside DNS?

We now know DNS records.

The next deeper question is:

When you type templates.cresignsys.com, what exactly happens between your computer and the DNS system?

1. The Complete DNS Journey

A simplified journey is:

Browser
   ↓
Operating System
   ↓
Stub Resolver
   ↓
Recursive DNS Resolver
   ↓
Root DNS
   ↓
.com TLD DNS
   ↓
cresignsys.com Authoritative DNS
   ↓
A / AAAA Record
   ↓
IP Address
   ↓
Back to Browser

But there is an important optimization:

CACHE

At almost every practical stage, cached information can prevent the entire journey.

2. Start With the Browser

You enter:

https://templates.cresignsys.com

The browser needs to know:

Where is templates.cresignsys.com?

It needs an IP address before it can normally establish the connection.

So it initiates hostname resolution.

3. Browser DNS Cache

The browser may have previously resolved the hostname.

Conceptually:

Browser
   ↓
DNS cache
   ↓
Found?

If yes:

Browser
   ↓
Cached IP

No external DNS query may be necessary at this point.

4. If Browser Cache Misses

The request proceeds to the operating system’s name-resolution mechanism.

Conceptually:

Browser
 ↓
OS resolver

The exact implementation varies by operating system.

5. Stub Resolver

A client machine commonly has a:

Stub Resolver

The stub resolver is the client-side component that sends DNS queries to a configured recursive resolver.

Conceptually:

Browser
   ↓
Stub resolver
   ↓
Recursive resolver

The stub usually does not perform the complete root → TLD → authoritative lookup itself.

6. Recursive Resolver

The recursive resolver performs the larger DNS lookup when necessary.

Examples of resolver services include:

ISP DNS
Enterprise DNS
Cloud DNS resolver
Public DNS resolver

The client simply asks:

What is the address of:
templates.cresignsys.com?

The recursive resolver does the difficult work.

7. Resolver Cache

The first thing a recursive resolver may check is its cache.

Query
 ↓
Resolver
 ↓
Cache

If the resolver already has:

templates.cresignsys.com
        ↓
203.0.113.10

and the cached information is still valid:

Cache HIT

The resolver returns the answer immediately.

8. Cache Miss

If it doesn’t have a usable cached answer:

Cache MISS

the resolver must find the authoritative answer.

Conceptually:

Recursive Resolver
       ↓
Root
       ↓
TLD
       ↓
Authoritative DNS

9. Root DNS

The DNS hierarchy begins at:

.

The root.

The recursive resolver knows how to reach the root DNS infrastructure through root-server information/root hints.

It asks essentially:

Where should I look for .com?

10. Root Does Not Usually Give the Website IP

This is extremely important.

The root does not normally answer:

templates.cresignsys.com
        ↓
203.0.113.10

Instead it provides information about:

.com

Conceptually:

Resolver
   ↓
Root
   ↓
".com is handled by these TLD nameservers."

11. Root Delegation

The response directs the resolver toward the .com TLD nameservers.

So:

Root
 ↓
.com nameservers

The resolver now knows where to ask next.

12. .com TLD

The resolver asks the .com TLD infrastructure:

Where are the authoritative nameservers for cresignsys.com?

Conceptually:

Recursive Resolver
       ↓
     .com
       ↓
cresignsys.com nameserver information

13. TLD Doesn’t Usually Give the Final IP

Again:

Root
 ↓
find .com

.com
 ↓
find cresignsys.com authoritative DNS

The TLD’s main role here is delegation.

The authoritative server contains the actual zone data.

14. Authoritative DNS

Now the resolver has discovered the authoritative nameserver for:

cresignsys.com

It asks:

A templates.cresignsys.com?

The authoritative DNS server responds with the authoritative record if one exists.

Conceptually:

templates.cresignsys.com
        ↓
A
        ↓
SERVER IP

15. The Answer Returns

Now the journey reverses:

Authoritative DNS
       ↓
Recursive Resolver
       ↓
Stub Resolver
       ↓
Operating System
       ↓
Browser

The browser now has the IP address.

16. The Whole Process

Put everything together:

                    DNS RESOLUTION

Browser
   │
   ▼
Browser Cache
   │
   │ miss
   ▼
OS Resolver
   │
   ▼
Stub Resolver
   │
   ▼
Recursive Resolver
   │
   │ cache miss
   ▼
Root
   │
   ▼
.com TLD
   │
   ▼
cresignsys.com Authoritative DNS
   │
   ▼
A / AAAA record
   │
   ▼
Recursive Resolver
   │
   ▼
Stub Resolver
   │
   ▼
Browser

17. Why This Is Fast

You might think:

Browser
 ↓
Root
 ↓
TLD
 ↓
Authoritative

must happen every time.

It doesn’t.

Caching is one of the main reasons DNS can operate at global scale.

18. TTL

Suppose the authoritative DNS server returns:

A
203.0.113.10
TTL 3600

The resolver can cache that information for the appropriate TTL period.

Conceptually:

Answer
 ↓
Cache
 ↓
3600 seconds

During that period, another client asking the same resolver may receive the cached answer.

19. TTL Is a Countdown

Suppose:

TTL = 3600

The resolver caches it.

After some time:

Remaining TTL = 2500

Later:

Remaining TTL = 100

When the cached information expires, the resolver needs to obtain fresh information.

20. DNS Cache Is Not Permanent

Eventually:

TTL expires
 ↓
Cache entry expires
 ↓
New resolution

This is why DNS changes don’t necessarily become visible everywhere immediately.

21. Example DNS Change

Suppose you originally have:

templates.cresignsys.com
A
OLD-IP

You change it to:

templates.cresignsys.com
A
NEW-IP

But a resolver may already have:

OLD-IP

cached.

Therefore:

DNS authoritative data = NEW-IP

Some resolver cache = OLD-IP

temporarily.

22. Different Resolvers Can Have Different Cached Answers

Imagine:

Resolver A → OLD-IP
Resolver B → NEW-IP
Resolver C → NEW-IP

This can happen during normal DNS caching transitions.

Therefore two users can temporarily receive different answers.

23. “DNS Propagation”

The term:

DNS propagation

is commonly used for this situation.

But conceptually it is often better to think:

Authoritative data changed
        ↓
Cached data expires/revalidates
        ↓
Different resolvers update at different times

It isn’t literally a single DNS message traveling around the world.

24. Negative DNS Answers

DNS can also cache the fact that something doesn’t exist.

For example:

Does:
abc123.cresignsys.com
exist?

The authoritative system may answer negatively.

That negative result can also be cached according to DNS rules.

This is called:

Negative caching

25. Why Negative Caching Matters

Suppose you create:

newsite.cresignsys.com

A resolver may have previously learned:

newsite.cresignsys.com
does not exist

It may temporarily continue returning the negative result until the applicable negative-cache lifetime expires.

So a newly created DNS record may not immediately appear through every resolver.

26. NXDOMAIN

A common negative DNS response is:

NXDOMAIN

It means the queried domain name does not exist in the relevant DNS namespace.

Conceptually:

Query:
abc.cresignsys.com

Response:
NXDOMAIN

This is different from simply having an existing name with no particular record of the requested type.

27. NXDOMAIN vs No A Record

Suppose:

templates.cresignsys.com

exists but has no A record.

That is not necessarily the same as:

templates.cresignsys.com
doesn't exist at all

DNS distinguishes between different kinds of negative answers.

This distinction becomes important in troubleshooting.

28. DNS Query Types

When your resolver asks:

A?

it specifically requests an IPv4 address record.

For example:

dig templates.cresignsys.com A

For IPv6:

dig templates.cresignsys.com AAAA

Different questions produce different answers.

29. DNS Response Structure

A DNS response can contain several conceptual sections:

QUESTION
ANSWER
AUTHORITY
ADDITIONAL

You can see these with:

dig templates.cresignsys.com

30. QUESTION Section

This represents what was asked.

Conceptually:

QUESTION:
templates.cresignsys.com. IN A

Meaning:

Name:
templates.cresignsys.com

Class:
IN

Type:
A

31. ANSWER Section

The answer might contain:

templates.cresignsys.com. 3600 IN A 203.0.113.10

Conceptually:

Name
 ↓
TTL
 ↓
Class
 ↓
Type
 ↓
Value

32. IN Means Internet

You will often see:

IN

in DNS output.

It means:

Internet

It is the DNS class normally used for the public Internet.

So:

IN A

means:

Internet class
+
A record

33. Authority Section

The authority section can contain information relevant to the authority for the response.

For example, in some responses you may see:

NS

records.

This becomes particularly useful when following delegations and negative answers.

34. Additional Section

The additional section can contain supporting information.

For example, DNS may provide address records associated with names referenced by other DNS records.

This can reduce the number of additional lookups required.

35. DNS Iterative Resolution

Now we can understand the difference between:

Recursive

and:

Iterative

The client asks the recursive resolver:

"Find the answer for me."

The recursive resolver may perform several iterative queries:

Resolver → Root
Resolver → TLD
Resolver → Authoritative

36. Recursive Request

From the client’s perspective:

Client
   │
   │ "Find templates.cresignsys.com"
   ▼
Resolver
   │
   │ does the work
   ▼
Answer

That’s recursion from the client’s perspective.

37. Iterative Queries

The resolver may ask:

Root:
"Where is .com?"

Root answers:

"Ask these .com servers."

Then:

Resolver → .com

.com answers:

"Ask these cresignsys.com nameservers."

Then:

Resolver → authoritative DNS

Authoritative server answers:

"Here is the A record."

These are iterative steps.

38. Root Hints

How does a recursive resolver initially know where the root servers are?

It can use:

Root hints

Root hints contain information needed to locate the root DNS server infrastructure.

They are used by recursive DNS software as a starting point for iterative resolution.

39. Root Server Letters

The DNS root system is represented by:

a.root-servers.net
b.root-servers.net
...
m.root-servers.net

These represent the well-known root server identities.

There are many physical instances distributed globally using anycast.

40. Anycast

This introduces another important networking concept:

Anycast

The same service address can be announced from multiple geographic/network locations.

Conceptually:

             Root DNS
           /     |     \
          /      |      \
       Location Location Location

Your DNS query can be routed to an appropriate nearby/available instance.

This improves:

Performance
Resilience
Availability

41. Root DNS Is Distributed

There isn’t simply:

one root computer

Instead:

Root DNS service
      ↓
Many instances
      ↓
Distributed globally

This is essential for Internet-scale reliability.

42. TLD Infrastructure Is Also Distributed

Similarly:

.com

is served through distributed DNS infrastructure.

The Internet’s DNS system is therefore highly distributed.

43. Authoritative DNS Can Also Be Distributed

Your domain’s authoritative DNS provider may have multiple nameservers.

For example:

ns1.example.com
ns2.example.com

Potentially in different networks/locations.

This gives redundancy.

44. Why Multiple Nameservers?

Suppose there is only:

ns1

and it fails.

DNS resolution for the domain could become unavailable.

With:

ns1
ns2
ns3

the system can remain available if one server fails, assuming they are properly configured.

45. DNS Availability

This leads to an important hosting concept:

Your website depends on multiple systems:

DNS
Cloud network
Firewall
Server
Nginx
TLS
PHP
Database
Storage

Failure in any important layer can affect the website.

46. DNS and Your VPS

Your VPS doesn’t necessarily have to run DNS.

You can have:

DNS Provider
      ↓
Your VPS

For example:

DNS provider
A record
   ↓
VPS public IP

Your Ubuntu server then only needs to provide:

HTTP/HTTPS

It doesn’t have to be an authoritative DNS server.

47. Running Your Own DNS

You could theoretically run DNS software on your VPS:

BIND
PowerDNS
Knot DNS
NSD

Then your server could participate in authoritative DNS.

But this introduces:

DNS security
Redundancy
Zone management
DNSSEC
Nameserver infrastructure

For a hosting platform, DNS architecture needs careful planning.

48. DNS Provider vs Registrar

These are often confused.

Registrar

The company through which a domain registration is managed.

DNS provider

The service that hosts/manages DNS zones.

Sometimes one company provides both.

But they are conceptually different.

49. Domain Registration

Suppose you register:

cresignsys.com

The registrar manages the registration relationship.

The domain is delegated to authoritative nameservers.

Conceptually:

Domain registration
       ↓
Nameserver delegation
       ↓
Authoritative DNS
       ↓
DNS records

50. Why This Matters for Hosting

When you create:

templates.cresignsys.com

you generally need:

DNS record

pointing to your server.

Then on your server:

Nginx server block

must recognize the same hostname.

So:

DNS hostname
=
Nginx hostname

must be coordinated.

51. The Hosting Creation Process

When creating a new hosted domain, conceptually:

1. Create DNS record
        ↓
2. Point name to VPS
        ↓
3. Create website directory
        ↓
4. Create Nginx server block
        ↓
5. Configure PHP-FPM if needed
        ↓
6. Install SSL
        ↓
7. Deploy application

This is the architecture behind a hosting automation script.

52. Example: New Website

Suppose you want:

newsite.cresignsys.com

First:

DNS
 ↓
newsite.cresignsys.com
 ↓
VPS IP

Then:

VPS
 ↓
/storage/websites/newsite.cresignsys.com/public

Then:

Nginx
 ↓
server_name newsite.cresignsys.com

Then:

TLS
 ↓
certificate

Then:

WordPress

53. Why DNS Must Come First

If the domain doesn’t resolve to the server:

Browser
 ↓
DNS
 ↓
wrong/no IP

the user never reaches:

Nginx

So your hosting automation needs to understand DNS as a separate layer.

54. DNS and Port Numbers

DNS A/AAAA records generally don’t contain:

:443

For example:

templates.cresignsys.com
A
203.0.113.10

The browser determines HTTPS’s default port:

443

from the URL scheme.

So:

DNS → IP
URL scheme → port

Conceptually:

https://templates.cresignsys.com
         │
         ├── DNS → IP
         │
         └── HTTPS → TCP 443

55. DNS Does Not Store Your Nginx Path

DNS does not know:

/storage/websites/templates.cresignsys.com/public

That information belongs to your server configuration.

So:

DNS:
hostname → IP

while:

Nginx:
hostname → website configuration/path

This distinction is fundamental.

56. DNS Does Not Store Your WordPress Database

DNS also does not know:

MySQL database
WordPress username
PHP version
Plugins
Themes

These belong to the application/server layers.

Therefore:

DNS
 ↓
Network location

Nginx
 ↓
Web routing

PHP
 ↓
Application execution

MySQL
 ↓
Application data

57. Deep Layer Map

Your web hosting system can now be visualized as:

                    USER
                     │
                     ▼
                  BROWSER
                     │
                     ▼
                    DNS
                     │
                     ▼
                 IP ADDRESS
                     │
                     ▼
                  ROUTING
                     │
                     ▼
                CLOUD NETWORK
                     │
                     ▼
                  FIREWALL
                     │
                     ▼
                   TCP 443
                     │
                     ▼
                TLS + SNI
                     │
                     ▼
                   NGINX
                     │
                     ▼
                 PHP-FPM
                     │
                     ▼
                WORDPRESS
                     │
                     ▼
                  MYSQL
                     │
                     ▼
                FILESYSTEM
                     │
                     ▼
                  STORAGE

58. One Very Important Principle

When troubleshooting:

Always identify the first layer that fails.

For example:

DNS fails

Do not start changing:

PHP
WordPress
MySQL

They haven’t even been reached.

Similarly:

DNS works
TCP works
TLS fails

Don’t immediately reinstall WordPress.

The problem is higher in the stack.

59. Practical DNS Investigation

Run:

dig templates.cresignsys.com A

Then:

dig +trace templates.cresignsys.com

Then:

dig templates.cresignsys.com A +stats

The +stats output can show timing information.

60. Test the Authoritative Server Directly

First find the authoritative nameservers:

dig +short cresignsys.com NS

Then query one of them directly.

Conceptually:

dig @AUTH_SERVER templates.cresignsys.com A

Replace AUTH_SERVER with the actual authoritative nameserver.

This is powerful because you can compare:

Authoritative answer

against:

Recursive resolver answer

61. Why Direct Authoritative Queries Are Useful

Suppose:

Authoritative DNS:
NEW-IP

but:

Recursive resolver:
OLD-IP

You immediately know:

DNS zone is updated
but cache still contains old data

This is a practical troubleshooting technique.

62. DNS Learning Milestone

You now understand:

Domain
 ↓
DNS hierarchy
 ↓
Root
 ↓
TLD
 ↓
Authoritative DNS
 ↓
Records
 ↓
Recursive resolver
 ↓
Cache
 ↓
TTL
 ↓
Client

This is enough foundation to begin studying real DNS troubleshooting.

Next Lesson — 028

DNS Troubleshooting in a Real Web Hosting Server

We will take actual situations such as:

Domain not opening
        ↓
Is DNS correct?

DNS correct
        ↓
Is IP correct?

IP correct
        ↓
Is port 443 open?

443 open
        ↓
Is Nginx listening?

Nginx listening
        ↓
Is TLS correct?

TLS correct
        ↓
Is server_name correct?

server_name correct
        ↓
Is website root correct?

Root correct
        ↓
Is PHP-FPM working?

PHP working
        ↓
Is WordPress working?

We will also learn:

dig
nslookup
host
ping
traceroute
tracepath
ss
curl
openssl s_client
nginx -t
journalctl

and how each command tests a different layer of the hosting stack.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts