CresignSys Learn

CresignSys Learn — Lesson 050

Written by

cresignsys

in

DNS Deep Internals — From Domain Name to Your VPS

We now go deeper into the system that connects:

learn.cresignsys.com
        ↓
     IP address
        ↓
   Your VPS

DNS looks simple:

domain → IP

But underneath it is a distributed global database system.

1. What Is DNS?

DNS means:

Domain Name System

Its basic purpose is:

Name
 ↓
Address

For example:

example.com
     ↓
203.0.113.25

But DNS does much more than IP lookup.

It also stores information about:

Websites
Mail
Subdomains
Verification
Service discovery
Domain delegation

2. Why Do We Need DNS?

Computers can communicate using IP addresses.

You could theoretically type:

https://203.0.113.25

But humans prefer:

https://example.com

DNS provides the mapping.

3. Domain Name Structure

Take:

learn.cresignsys.com

Break it down:

learn
  .
cresignsys
  .
com

Conceptually:

learn
=
hostname/subdomain

cresignsys
=
domain name

com
=
top-level domain

4. Root of DNS

There is actually an invisible root at the end.

This:

example.com

can technically be represented as:

example.com.

The final:

.

represents the DNS root.

5. DNS Hierarchy

Think of DNS as a tree:

.
│
├── com
│    │
│    └── cresignsys
│          │
│          ├── www
│          ├── learn
│          └── shop
│
└── org

The root is at the top.

6. Root DNS

At the top are the:

Root Servers

They don’t normally contain the IP address for every website.

Instead, they know where to find the authoritative servers for top-level domains.

For example:

Root
 ↓
.com

7. TLD

TLD means:

Top-Level Domain

Examples:

.com
.org
.net
.in

So:

cresignsys.com

belongs under:

.com

8. Root → TLD

Suppose a resolver needs:

example.com

It can conceptually ask:

Root:
Who handles .com?

The root responds with information about the .com nameservers.

9. TLD → Domain

Then the resolver asks the .com DNS infrastructure:

Who is authoritative for example.com?

The TLD system responds with the authoritative nameserver information for that domain.

10. Authoritative DNS

Now we reach:

Authoritative Nameserver

This server is responsible for the actual DNS records for the domain.

For example:

example.com
 ↓
authoritative DNS
 ↓
A record
 ↓
203.0.113.25

11. Three Important DNS Roles

Remember:

Root
 ↓
TLD
 ↓
Authoritative

But there is another important participant:

Recursive Resolver

12. Recursive Resolver

Your computer usually does not walk the entire DNS hierarchy itself.

Instead, it asks a recursive resolver.

For example:

Browser
 ↓
Operating system
 ↓
DNS resolver

The resolver performs the work of finding the answer.

13. Example Resolvers

Common public DNS resolvers include:

8.8.8.8
1.1.1.1

These are examples, not requirements.

Your ISP, organization, router, or device can use other resolvers.

14. Full DNS Journey

Suppose you enter:

https://learn.cresignsys.com

Conceptually:

Browser
 ↓
Local DNS cache
 ↓
Recursive resolver
 ↓
Root
 ↓
.com
 ↓
cresignsys.com authoritative DNS
 ↓
learn.cresignsys.com record
 ↓
IP address

15. But There Is Usually Caching

The resolver may already know the answer.

For example:

Resolver
 ↓
Cache
 ↓
IP found

Then it doesn’t need to ask root/TLD/authoritative servers again.

This is why DNS is scalable.

16. TTL

DNS records have:

TTL

Time To Live.

For example:

TTL = 3600

means the record can generally be cached for about:

3600 seconds
=
1 hour

before the cache should consider it expired and obtain fresh information.

17. Why TTL Matters

Suppose:

learn.cresignsys.com

currently points to:

IP A

You change it to:

IP B

Some recursive resolvers may still have:

IP A

cached until the TTL expires.

18. DNS Propagation

People often say:

DNS propagation takes time.

More precisely, DNS changes become visible as cached records expire and resolvers retrieve the updated authoritative information.

So it isn’t usually a single global “propagation event.”

19. Example

Initially:

TTL = 3600

Record:

example.com → IP A

You change it:

example.com → IP B

A resolver that cached IP A shortly before the change might continue returning IP A until its cached TTL expires.

Another resolver whose cache has already expired may immediately retrieve IP B.

Therefore different users can temporarily receive different answers.

20. Lower TTL Before Migration

Suppose you know:

Website migration

is coming.

You can reduce TTL ahead of time.

For example:

3600
 ↓
300

Then cached answers expire more quickly.

But reducing TTL immediately before a change does not magically invalidate already-cached records; the old TTL remains relevant to caches that already stored the record.

21. DNS Record Types

The important ones for your hosting platform are:

A
AAAA
CNAME
MX
TXT
NS
SOA

Let’s understand each.

22. A Record

An:

A record

maps a hostname to an IPv4 address.

Example:

learn.cresignsys.com
        ↓
A
        ↓
203.0.113.25

23. AAAA Record

An:

AAAA record

maps a hostname to an IPv6 address.

Example:

learn.cresignsys.com
        ↓
AAAA
        ↓
2001:db8::25

24. A + AAAA

A domain can have both:

A
 ↓
IPv4

AAAA
 ↓
IPv6

Clients may use IPv4 or IPv6 depending on their connectivity and address-selection behavior.

25. CNAME

CNAME means:

Canonical Name

It creates an alias from one DNS name to another DNS name.

Example:

www.example.com
        ↓
CNAME
        ↓
example.com

The target is a hostname, not an IP address.

26. CNAME vs A

A:

www.example.com
 ↓
203.0.113.25

CNAME:

www.example.com
 ↓
example.com

The CNAME target is then resolved.

27. Important CNAME Rule

A CNAME generally cannot coexist with other ordinary data at the same DNS name.

For example, you normally don’t configure:

www.example.com
CNAME → example.com
A → 203.0.113.25

at the same exact name.

28. MX Record

MX means:

Mail Exchange

It tells mail systems where email for a domain should be delivered.

Example:

example.com
 ↓
MX
 ↓
mail.example.com

29. MX Has Priority

MX records have preference/priority values.

Example conceptually:

10 mail1.example.com
20 mail2.example.com

Lower preference numbers generally mean higher priority.

30. TXT Record

TXT records store text data used by many systems.

Common uses include:

Domain verification
SPF
DKIM-related data
DMARC-related policies
Other service verification

31. SPF

SPF helps specify which mail servers are authorized to send mail for a domain.

It is published using DNS TXT records.

Conceptually:

example.com
 ↓
TXT
 ↓
SPF policy

32. DKIM

DKIM uses cryptographic signatures for email authentication.

The public key is published through DNS.

Conceptually:

Email server
 ↓
DKIM signature

and:

DNS
 ↓
public DKIM key

The receiving system can use the public key to verify the signature.

33. DMARC

DMARC builds on email authentication mechanisms such as SPF and DKIM.

It lets domain owners publish policies describing how receiving mail systems should handle messages that fail authentication checks.

DMARC policies are also published through DNS TXT records.

34. NS Record

NS means:

Name Server

It identifies the authoritative nameservers for a DNS zone.

Conceptually:

cresignsys.com
 ↓
NS
 ↓
ns1.example-dns.com
ns2.example-dns.com

35. SOA Record

SOA means:

Start of Authority

It contains important information about the DNS zone, including things such as:

Primary authoritative server
Zone administrator contact representation
Serial number
Refresh
Retry
Expire
Negative caching TTL

36. What Is a DNS Zone?

A zone is an administrative portion of the DNS namespace.

For example:

cresignsys.com

could be a DNS zone containing:

cresignsys.com
www.cresignsys.com
learn.cresignsys.com
shop.cresignsys.com

The exact delegation structure determines what is included.

37. Domain vs Zone

These are related but not identical concepts.

A domain is part of the DNS namespace.

A zone is a portion of that namespace managed together by authoritative DNS servers.

This distinction becomes important when managing DNS professionally.

38. Subdomain

For:

learn.cresignsys.com

the:

learn

label is a subdomain label under:

cresignsys.com

You can create:

learn
shop
blog
api
mail

and so on.

39. Your Hosting Architecture

You could have:

cresignsys.com
│
├── www
├── learn
├── shop
├── hosting
├── api
└── blog

Each can point to:

same VPS

or:

different servers

40. Multiple Domains, One VPS

For example:

domain-a.com
        ↓
203.0.113.25

domain-b.com
        ↓
203.0.113.25

domain-c.com
        ↓
203.0.113.25

All can reach the same VPS.

Nginx then determines which website should handle the request based largely on the hostname and server configuration.

41. DNS Does Not Choose the Website

This is an important distinction.

DNS determines:

domain
 ↓
IP

Nginx determines:

HTTP Host / TLS hostname
 ↓
website configuration

So:

DNS
=
Which server?

Nginx
=
Which website on that server?

This is simplified but extremely useful.

42. Example

Suppose:

shop.cresignsys.com

and:

learn.cresignsys.com

both resolve to:

203.0.113.25

DNS doesn’t care which WordPress installation should serve the request.

The request reaches Nginx with the hostname.

Nginx can then select:

shop

or:

learn

43. Host Header

An HTTP request contains a hostname.

For HTTP/1.1, for example:

GET /
Host: learn.cresignsys.com

Nginx uses this information when matching server blocks.

44. HTTPS and SNI

For HTTPS, the hostname is also communicated during TLS through:

SNI

So for HTTPS:

TLS SNI
+
HTTP Host

both help identify the intended website.

45. DNS Is Before HTTP

Remember:

DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP

Therefore Nginx cannot receive an ordinary web request until DNS resolution and network connectivity have gotten the client to the server.

46. Recursive Resolver Cache

Suppose:

Google DNS

has:

learn.cresignsys.com
 ↓
old IP

cached.

Your computer asks Google DNS:

What is learn.cresignsys.com?

Google DNS may answer from its cache without contacting the authoritative server.

47. Browser Cache

Your browser can also cache DNS information.

So there can be multiple caching layers:

Browser
 ↓
Operating system
 ↓
Local router/ISP resolver
 ↓
Recursive DNS cache

Exact behavior varies by system and application.

48. Why nslookup Can Be Misleading

If you run:

nslookup example.com

you are asking the resolver configured for that system.

If that resolver has cached data, you may not be seeing the authoritative server directly.

49. Specify a Resolver

You previously used:

nslookup example.com 8.8.8.8

This explicitly asks Google’s public resolver.

You can also query another resolver.

For example:

nslookup example.com 1.1.1.1

50. dig

dig provides more detailed DNS information.

Basic:

dig example.com

Short answer:

dig +short example.com

Specific record:

dig example.com A

51. Query AAAA

dig example.com AAAA

This checks IPv6 records.

52. Query MX

dig example.com MX

Useful when diagnosing email delivery.

53. Query TXT

dig example.com TXT

Useful for verification and email authentication records.

54. Query NS

dig example.com NS

This shows nameserver information.

55. Query SOA

dig example.com SOA

This provides zone authority information.

56. dig +trace

One of the most educational DNS commands is:

dig +trace example.com

It walks through the DNS hierarchy.

Conceptually:

Root
 ↓
TLD
 ↓
Authoritative
 ↓
Answer

This is extremely useful for learning DNS.

57. What +trace Shows

It can demonstrate:

.
 ↓
com.
 ↓
example.com.
 ↓
authoritative server
 ↓
A record

This makes the DNS hierarchy visible.

58. Authoritative vs Recursive

This distinction is critical.

Recursive resolver

Finds answers on behalf of clients and caches them.

Authoritative server

Provides authoritative answers for zones it serves.

59. Example

Your computer:

Laptop
 ↓
8.8.8.8

Google DNS is acting as a recursive resolver.

Then:

8.8.8.8
 ↓
authoritative DNS

The authoritative server provides the domain’s authoritative record.

60. Who Controls DNS?

This depends on where you delegate your domain.

A domain registrar manages registration.

DNS hosting may be provided by:

Registrar

or:

Dedicated DNS provider

or:

Cloud provider

These are related but separate functions.

61. Registrar

A registrar is where a domain is registered.

For example:

cresignsys.com

is registered through a domain registrar.

The registrar manages registration-related information and allows you to configure nameserver delegation.

62. Nameserver Delegation

The registrar tells the DNS hierarchy:

cresignsys.com
 ↓
these nameservers are authoritative

For example:

ns1.provider.com
ns2.provider.com

63. Nameserver Flow

Conceptually:

Registrar
 ↓
delegates domain
 ↓
authoritative nameservers
 ↓
DNS records

64. Why Nameservers Matter

Suppose you edit an A record at:

DNS Provider A

but the domain is actually delegated to:

DNS Provider B

Your change won’t affect the authoritative DNS for the domain.

This is a common configuration mistake.

65. DNS Diagnostic Question

When a DNS change doesn’t work, first ask:

Which nameservers are authoritative for this domain?

Run:

dig example.com NS

Then verify you are editing DNS at the correct provider.

66. A Record Example for Your Hosting

Suppose your VPS public IP is:

203.0.113.25

You could configure:

learn.cresignsys.com
A
203.0.113.25

Then:

learn.cresignsys.com
 ↓
203.0.113.25

67. Wildcard DNS

You can also create:

*.cresignsys.com

as a wildcard record.

For example:

*.cresignsys.com
A
203.0.113.25

Then many otherwise-unconfigured subdomains can resolve to that IP.

But wildcard DNS does not automatically create the website configuration in Nginx.

68. Wildcard DNS ≠ Wildcard SSL

These are separate:

Wildcard DNS
=
DNS resolution
Wildcard certificate
=
TLS certificate coverage

You can have one without the other.

69. Wildcard DNS + Nginx

Suppose:

*.cresignsys.com
 ↓
203.0.113.25

Then:

anything.cresignsys.com

may resolve to your VPS.

But Nginx still needs to know what to do with:

anything.cresignsys.com

70. Wildcard Hosting

A hosting platform could potentially implement:

*.cresignsys.com
        ↓
VPS
        ↓
Nginx
        ↓
dynamic website routing

But production hosting usually uses explicit domain/site configurations or controlled wildcard routing.

71. DNS and SSL Are Separate

A common mistake is thinking:

DNS correct
=
SSL correct

No.

You need:

DNS
 ↓
correct IP

SSL
 ↓
certificate for correct hostname

Both must be correct.

72. DNS and Nginx Are Separate

Similarly:

DNS
 ↓
correct IP

doesn’t mean:

Nginx
 ↓
correct website

Nginx needs appropriate configuration.

73. Example Failure

DNS:

learn.cresignsys.com
 ↓
correct VPS

Nginx:

server_name learn.cresignsys.com

missing.

Result:

request reaches server
 ↓
wrong/default server block

DNS is correct, but the website can still be wrong.

74. Example Another Failure

DNS:

learn.cresignsys.com
 ↓
old VPS

Nginx on the new VPS:

correct

But users still reach the old VPS.

The Nginx configuration isn’t the problem.

DNS is.

75. DNS Troubleshooting Method

When a domain doesn’t work:

1. Check authoritative nameservers
2. Check A record
3. Check AAAA record
4. Check CNAME if used
5. Check TTL
6. Check resolver results
7. Check actual VPS IP
8. Check TCP 80/443
9. Check Nginx

76. First Command

dig +short example.com

Ask:

Does this return the IP I expect?

77. Second Command

dig example.com NS

Ask:

Are these the nameservers I intended?

78. Third Command

dig example.com A

Ask:

What IPv4 address is authoritative/returned?

79. Fourth Command

dig example.com AAAA

Ask:

Is there an IPv6 address?

If you haven’t configured IPv6 correctly, an incorrect AAAA record can cause connection problems for IPv6-capable clients.

80. Fifth Command

dig +trace example.com

This helps determine where the DNS delegation/lookup path is going wrong.

81. DNS Failure Categories

NXDOMAIN

Means the queried domain name does not exist according to the responding DNS system.

SERVFAIL

Means the resolver could not successfully obtain/validate an answer.

NOERROR with no answer

The name may exist, but the requested record type may not exist.

These distinctions are useful when diagnosing DNS.

82. NXDOMAIN

Example:

learn.example.com

doesn’t exist.

The resolver can return:

NXDOMAIN

Meaning approximately:

This name does not exist.

83. SERVFAIL

Can occur due to problems such as:

DNSSEC validation failure
authoritative server failure
delegation problems
network/server issues

The exact cause requires further investigation.

84. DNSSEC

DNS can also use:

DNSSEC

DNSSEC provides cryptographic validation of DNS data.

Conceptually:

DNS
+
digital signatures
=
DNSSEC

It helps protect against certain forms of DNS data tampering.

85. DNSSEC Is Different From TLS

TLS:

protects application communication

DNSSEC:

authenticates DNS data

They solve different problems.

86. TTL and Caching Again

Suppose:

A record:
old IP
TTL:
3600

You change:

new IP

A resolver that already cached the old value can continue using it until its cached TTL expires.

So:

change DNS
≠
every device immediately changes

87. Why Different Computers Show Different IPs

Suppose:

Computer A
 ↓
Resolver A
 ↓
old IP

while:

Computer B
 ↓
Resolver B
 ↓
new IP

Both can temporarily happen during a DNS change.

88. Local Cache

Your own computer can cache DNS results.

Windows can display/clear its DNS cache using:

ipconfig /displaydns

and:

ipconfig /flushdns

Use flushing for troubleshooting; it does not change authoritative DNS.

89. DNS Is Distributed

The Internet doesn’t have:

one giant DNS server

Instead:

Root
 ↓
TLD
 ↓
Authoritative servers
 ↓
Recursive resolvers
 ↓
Caches

This distributed architecture allows DNS to scale globally.

90. Your Hosting Platform

For every website created on your hosting platform, you ultimately need:

Domain
 ↓
DNS
 ↓
VPS IP
 ↓
Nginx server_name
 ↓
Website directory
 ↓
PHP-FPM
 ↓
WordPress
 ↓
Database

DNS is the first major external connection to the hosting system.

91. Automated Hosting Workflow

A future CresignSys hosting system could do:

Create Website
      ↓
Domain entered
      ↓
DNS record created
      ↓
A record → VPS
      ↓
Nginx configuration
      ↓
Website directory
      ↓
Database
      ↓
WordPress
      ↓
SSL
      ↓
HTTPS

This is essentially the foundation of a simplified hosting control panel.

92. The Complete Internet-to-Database Journey

You can now see the entire journey:

USER
 │
 ▼
DOMAIN
 │
 ▼
DNS
 │
 ▼
IP ADDRESS
 │
 ▼
ROUTING
 │
 ▼
TCP
 │
 ▼
TLS
 │
 ▼
HTTP
 │
 ▼
NGINX
 │
 ▼
PHP-FPM
 │
 ▼
WORDPRESS
 │
 ▼
MYSQL
 │
 ▼
INNODB
 │
 ▼
BUFFER POOL
 │
 ▼
DISK

That is the foundation of your web-hosting infrastructure.

93. The Most Important DNS Commands

Start practicing these:

dig +short example.com
dig example.com A
dig example.com AAAA
dig example.com NS
dig example.com MX
dig example.com TXT
dig example.com SOA
dig +trace example.com

94. Windows Commands

Since you also manage your server from Windows:

nslookup example.com

Specific resolver:

nslookup example.com 8.8.8.8

IPv4/IPv6 and other details can be queried interactively with nslookup.

95. One Important Difference

Remember:

nslookup
=
simple DNS diagnostic

while:

dig
=
more detailed DNS analysis

For serious server administration, learn dig.

96. Lesson 050 Core Model

Memorize:

Domain
 ↓
Recursive Resolver
 ↓
Root
 ↓
TLD
 ↓
Authoritative DNS
 ↓
DNS Record
 ↓
IP

But if cached:

Domain
 ↓
Recursive Resolver
 ↓
Cache
 ↓
IP

97. DNS Record Cheat Sheet

RecordPurpose
AIPv4 address
AAAAIPv6 address
CNAMEAlias to another hostname
MXMail server
TXTText/verification/authentication data
NSAuthoritative nameserver
SOAZone authority information

98. Three Things to Never Confuse

DNS

domain → IP

Nginx

hostname → website configuration

TLS

hostname → certificate/security

Together:

DNS
 ↓
server
 ↓
Nginx
 ↓
TLS
 ↓
website

Lesson 050 Complete

Your basic web-hosting architecture is now:

                     INTERNET
                         │
                         ▼
                      DOMAIN
                         │
                         ▼
                        DNS
                         │
                         ▼
                    PUBLIC IP
                         │
                         ▼
                    OCI NETWORK
                         │
                         ▼
                       VNIC
                         │
                         ▼
                      UBUNTU
                         │
                         ▼
                      TCP 443
                         │
                         ▼
                        TLS
                         │
                         ▼
                       NGINX
                         │
                         ▼
                     PHP-FPM
                         │
                         ▼
                     WORDPRESS
                         │
                         ▼
                       MYSQL
                         │
                         ▼
                      INNODB
                         │
                         ▼
                        DISK

Next Lesson — 051

Linux Process Management — What Actually Runs on Your VPS?

We will go underneath the services and understand:

Program
 ↓
Process
 ↓
PID
 ↓
Parent process
 ↓
Child process
 ↓
Thread
 ↓
CPU
 ↓
RAM
 ↓
systemd
 ↓
service

Then we will connect it directly to:

nginx
php-fpm
mysqld
sshd
cron
certbot

and learn why a service can be installed, enabled, running, listening, or crashed—and why those are all different states.

Comments

Leave a Reply

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

More posts