Course: From Basic Science to Web Hosting

Module 05 — Networking Fundamentals

DNS — From Domain Name to IP Address

Difficulty: Beginner → Intermediate
Prerequisites: Lesson 024 — DNS → TCP → TLS → HTTPS
Estimated time: 45–60 minutes

We now study the first major step in opening:

https://templates.cresignsys.com

The question is:

How does a computer turn templates.cresignsys.com into an address that networking can use?

The answer is:

DNS — Domain Name System

1. The Basic Problem

Computers communicate using network addresses.

Humans prefer names.

You remember:

templates.cresignsys.com

rather than:

some IP address

DNS connects the two.

Domain name
     ↓
    DNS
     ↓
IP address

2. DNS Is a Distributed Database

A common beginner explanation is:

DNS is a phone book.

That is useful initially, but incomplete.

DNS is better understood as:

A globally distributed, hierarchical naming system and database.

It is distributed across many servers.

It is hierarchical.

And it contains many types of records.

3. The Domain Name

Consider:

templates.cresignsys.com

This name contains multiple labels:

templates
   .
cresignsys
   .
com

Read from right to left:

com
 ↓
cresignsys
 ↓
templates

4. The Root

At the top of DNS is:

the root.

The complete conceptual name is:

templates.cresignsys.com.

The final dot is normally hidden from users.

So:

templates.cresignsys.com

is shorthand for:

templates.cresignsys.com.

5. DNS Hierarchy

The hierarchy looks like:

                         .
                         │
              ┌──────────┼──────────┐
              │          │          │
             com        org        net
              │
         cresignsys
              │
          templates

So:

.
 ↓
com
 ↓
cresignsys
 ↓
templates

6. Root DNS

The root is the top of the DNS hierarchy.

The root system knows where to find information about top-level domains.

For example:

.
├── com
├── org
├── net
├── in
└── ...

The root doesn’t normally contain the final IP address of your website.

Instead, it helps direct DNS resolution toward the appropriate TLD.

7. TLD

TLD means:

Top-Level Domain

Examples:

.com
.org
.net
.in

For:

templates.cresignsys.com

the TLD is:

.com

8. Second-Level Domain

Inside:

.com

you have:

cresignsys

So:

cresignsys.com

is the domain name under the .com TLD.

9. Subdomain

Then:

templates

is a subdomain label.

Therefore:

templates.cresignsys.com

can be viewed as:

templates
    ↓
subdomain

cresignsys.com
    ↓
domain

com
    ↓
TLD

10. DNS Does Not Care That It Is a Website

DNS does not inherently know:

“This is a WordPress website.”

DNS simply stores information associated with names.

For example, DNS can contain:

A
AAAA
CNAME
MX
TXT
NS
CAA

and many other record types.

11. A Record

The most important record for basic IPv4 web hosting is:

A

An A record maps a hostname to an IPv4 address.

Conceptually:

templates.cresignsys.com
          ↓
        A record
          ↓
      IPv4 address

Example:

templates.cresignsys.com
A
203.0.113.10

The IP above is only an example.

12. AAAA Record

For IPv6, DNS commonly uses:

AAAA

Conceptually:

templates.cresignsys.com
          ↓
       AAAA
          ↓
       IPv6 address

Example:

2001:db8::10

Again, this is a documentation/example address.

13. A vs AAAA

Remember:

A
 ↓
IPv4

AAAA
 ↓
IPv6

A domain can have both.

templates.cresignsys.com
 ├── A
 │    └── IPv4
 │
 └── AAAA
      └── IPv6

14. CNAME

Another important record is:

CNAME

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

Conceptually:

www.example.com
       ↓
     CNAME
       ↓
example.com

Then DNS can continue resolving:

example.com
 ↓
A / AAAA
 ↓
IP address

15. Important CNAME Rule

A CNAME points to a name, not directly to an IP address.

Conceptually:

CNAME
 ↓
hostname

whereas:

A
 ↓
IPv4 address

16. NS Record

NS means:

Name Server

An NS record identifies the authoritative DNS servers for a domain/zone.

Conceptually:

cresignsys.com
      ↓
NS
      ↓
Authoritative DNS server

For example, conceptually:

ns1.example-dns.com
ns2.example-dns.com

The actual nameservers for your domain depend on your DNS provider.

17. Authoritative DNS Server

An authoritative DNS server contains the actual DNS records for a zone.

For example:

templates.cresignsys.com
A
203.0.113.10

If that record is authoritative, that server is providing the definitive DNS data for that zone.

18. Recursive DNS Resolver

Your computer often doesn’t directly ask the authoritative server.

Instead it asks a:

Recursive Resolver

Conceptually:

Your computer
      ↓
Recursive resolver
      ↓
DNS hierarchy
      ↓
Authoritative server

The recursive resolver performs the lookup on behalf of the client and usually caches the result.

19. Why Use a Recursive Resolver?

Imagine every computer had to understand the entire DNS hierarchy.

That would be inefficient.

Instead:

Computer
   ↓
Resolver
   ↓
Does DNS work
   ↓
Returns answer

Your computer only needs to communicate with the resolver.

20. The Complete DNS Lookup

Suppose your browser wants:

templates.cresignsys.com

Conceptually:

Browser
  ↓
Operating system
  ↓
Recursive resolver
  ↓
Root
  ↓
.com
  ↓
cresignsys.com authoritative DNS
  ↓
templates.cresignsys.com
  ↓
A / AAAA
  ↓
IP address

But this is simplified because caching may eliminate many of these steps.

21. First Query: Root

The recursive resolver may ask a root server:

Where can I find information about .com?

The root responds with information directing the resolver toward .com nameservers.

Conceptually:

Resolver
   │
   │ Where is .com?
   ▼
Root
   │
   │ .com nameserver information
   ▼
Resolver

22. Second Query: TLD

The resolver then asks the .com TLD infrastructure:

Where are the authoritative nameservers for cresignsys.com?

Conceptually:

Resolver
   │
   │ Where is cresignsys.com?
   ▼
.com TLD
   │
   │ Authoritative nameserver information
   ▼
Resolver

23. Third Query: Authoritative Server

The resolver asks the authoritative server:

What is the A record for templates.cresignsys.com?

Conceptually:

Resolver
   │
   │ A templates.cresignsys.com?
   ▼
Authoritative DNS
   │
   │ IP address
   ▼
Resolver

24. Resolver Returns Answer

Finally:

Authoritative DNS
      ↓
Recursive resolver
      ↓
Your computer
      ↓
Browser

The browser now has the IP address.

Then DNS is mostly finished for this particular connection.

25. DNS Is Before TCP

This connects directly to the previous lesson.

Domain
 ↓
DNS
 ↓
IP address
 ↓
TCP
 ↓
TLS
 ↓
HTTP

Therefore:

If DNS fails, TCP connection establishment may never even begin because the client may not know where to connect.

26. DNS Caching

DNS lookups can be expensive if every request must travel through the whole hierarchy.

So DNS uses:

Caching

Suppose the resolver previously learned:

templates.cresignsys.com
 →
203.0.113.10

It can temporarily remember that answer.

Then another user asks:

templates.cresignsys.com

The resolver may already know the answer.

Client
 ↓
Resolver
 ↓
Cache HIT
 ↓
IP address

No root/TLD/authoritative lookup is necessary at that moment.

27. Cache Hit

DNS query
   ↓
Resolver cache
   ↓
Found
   ↓
Return answer

Fast.

28. Cache Miss

DNS query
   ↓
Resolver cache
   ↓
Not found
   ↓
Perform DNS resolution
   ↓
Cache result
   ↓
Return answer

29. TTL

DNS records commonly have a:

TTL

Time To Live.

It tells caching resolvers how long the information can be cached before it should be considered expired and re-queried.

Example:

A record
TTL = 3600

Conceptually:

3600 seconds
=
1 hour

The actual caching behavior can involve additional details, but this is the basic idea.

30. Why TTL Matters

Suppose you change:

templates.cresignsys.com

from:

Old IP

to:

New IP

Some resolvers may still have the old answer cached until its TTL expires.

Therefore:

DNS change
 ↓
not necessarily instant everywhere

31. DNS Propagation

People often say:

“DNS propagation takes 24–48 hours.”

This is an oversimplification.

More precisely:

Different resolvers
 ↓
may have cached different answers
 ↓
until TTL-related caching expires

Changes can become visible at different times depending on caching, resolver behavior, and configuration.

32. DNS Zone

DNS Zone

is an administratively managed portion of the DNS namespace.

For your domain:

cresignsys.com

the zone may contain records such as:

A
AAAA
CNAME
MX
TXT
NS
CAA

The exact records depend on your DNS configuration.

33. Zone vs Domain

These concepts are related but not identical.

A domain is part of the DNS namespace.

A zone is an administratively managed portion of that namespace.

For example:

cresignsys.com

could be one DNS zone.

A delegated subdomain could potentially be managed as a separate zone.

34. SOA Record

Another important DNS record is:

SOA

Start of Authority.

It contains important information about the DNS zone, including administrative and serial/timing information.

Conceptually:

Zone
 ↓
SOA
 ↓
Zone metadata

You don’t normally modify this manually when using a managed DNS provider.

35. MX Record

MX means:

Mail Exchange

It specifies mail servers for a domain.

Example conceptually:

cresignsys.com
   ↓
MX
   ↓
mail server

This is for email routing, not website hosting.

36. TXT Record

TXT records can store text data used by many systems.

Common uses include:

Domain verification
SPF-related email policy
DKIM-related information
DMARC-related information
Certificate/CA policy
Service verification

TXT records are extremely important in modern Internet infrastructure.

37. CAA Record

CAA means:

Certification Authority Authorization

It can specify which certificate authorities are authorized to issue certificates for a domain.

Conceptually:

cresignsys.com
      ↓
CAA
      ↓
Authorized CA(s)

This becomes directly relevant to your Let’s Encrypt learning.

38. DNS and Let’s Encrypt

When Let’s Encrypt issues a certificate, domain control must be validated.

One possible validation method is:

DNS-01

The ACME client creates a special TXT record.

Conceptually:

Let's Encrypt
      ↓
Challenge
      ↓
DNS TXT record
      ↓
Let's Encrypt checks DNS
      ↓
Domain control verified

Another common method is:

HTTP-01

Let’s Encrypt checks a special HTTP resource served by the domain.

Conceptually:

Let's Encrypt
      ↓
HTTP request
      ↓
your server
      ↓
challenge response
      ↓
domain control verified

We will study ACME and these challenges later.

39. DNS Is Not Certificate Validation

Another important distinction:

DNS
 ↓
Name resolution

while:

TLS certificate validation
 ↓
Server identity/authentication

They interact in some scenarios, but they solve different problems.

40. DNS Does Not Encrypt Your Website

DNS can tell you:

templates.cresignsys.com
 ↓
IP address

It does not automatically make:

HTTP

secure.

Security comes from mechanisms such as:

TLS

So:

DNS
 ↓
Find server

TLS
 ↓
Secure communication

41. DNS Record Example

Imagine your DNS zone contains:

templates.cresignsys.com.    A       203.0.113.10

Then:

templates.cresignsys.com
        ↓
A record
        ↓
203.0.113.10

Your browser can then attempt:

203.0.113.10:443

Again, this IP is only illustrative.

42. What Happens If the A Record Is Wrong?

Suppose DNS points to:

Old server

while your website is actually on:

New server

Then:

Browser
 ↓
DNS
 ↓
Wrong IP
 ↓
Wrong server

Your Nginx configuration can be perfect and the website can still fail.

This is why DNS must be understood separately from Nginx.

43. What Happens If DNS Works but Port 443 Is Closed?

Then:

DNS
 ↓
works
 ↓
IP address
 ↓
TCP 443
 ↓
fails

The browser cannot reach the HTTPS service.

Again:

DNS problem ≠ TCP problem

44. What Happens If TCP Works but Certificate Is Wrong?

Then:

DNS
 ↓
works

TCP
 ↓
works

TLS
 ↓
fails

For example, the certificate may:

not match hostname
be expired
have an untrusted chain
be incorrectly configured

So the website can have a perfectly working IP and TCP port but still fail HTTPS validation.

45. DNS + TCP + TLS

We can now distinguish three different questions:

DNS

Where is the server?

TCP

Can I establish a transport connection?

TLS

Can I establish a secure authenticated session?

HTTP

What web resource do I want?

This layered thinking is extremely important.

46. DNS Command: `dig`

One of the best DNS learning tools is:

dig

For example:

dig templates.cresignsys.com

It can show the DNS answer and other information.

47. Ask Specifically for A

dig templates.cresignsys.com A

This asks for:

A record

48. Ask for AAAA

dig templates.cresignsys.com AAAA

This asks for:

AAAA record

49. Ask for NS

dig cresignsys.com NS

This asks:

Which nameservers are authoritative for the domain?

50. Ask for MX

dig cresignsys.com MX

This asks about mail-exchange records.

51. Ask for TXT

dig cresignsys.com TXT

This displays TXT records.

This can be useful when learning:

SPF
DKIM
DMARC
verification
ACME DNS challenges

52. `dig +trace`

A particularly educational command is:

dig +trace templates.cresignsys.com

This can show the iterative DNS resolution path from the root toward the authoritative answer.

Conceptually:

Root
 ↓
.com
 ↓
cresignsys.com
 ↓
templates.cresignsys.com

It is an excellent tool for understanding the DNS hierarchy.

53. `resolvectl`

On many modern Ubuntu systems:

resolvectl status

can show resolver configuration.

You may see information about:

DNS servers
Interfaces
DNS domains

The exact configuration depends on your Ubuntu/cloud setup.

54. `/etc/resolv.conf`

Linux systems also commonly expose resolver configuration through:

/etc/resolv.conf

You can inspect it:

cat /etc/resolv.conf

Depending on the system, this may be a symlink or managed by another service.

55. DNS Resolver Flow

Your computer may work approximately like:

Browser
   ↓
OS resolver
   ↓
Configured DNS resolver
   ↓
Recursive DNS server
   ↓
Cache / DNS hierarchy
   ↓
Answer

The exact implementation differs across operating systems and network environments.

56. Authoritative vs Recursive

This distinction is extremely important.

Recursive resolver

Finds answers on behalf of clients.

Client
 ↓
Recursive resolver

Authoritative server

Provides authoritative DNS data for its zone.

Recursive resolver
 ↓
Authoritative server

They perform different jobs.

57. Root Server vs Authoritative Server

The root system doesn’t normally answer:

"What is the IP of templates.cresignsys.com?"

Instead it helps answer:

"Where should I look for .com?"

Then .com helps answer:

"Where should I look for cresignsys.com?"

Then the authoritative DNS server answers:

"What is templates.cresignsys.com?"

58. Why DNS Is Hierarchical

Imagine every DNS server on Earth stored every hostname.

That would be inefficient.

Instead:

Root
 ↓
TLD
 ↓
Domain
 ↓
Subdomain

Each layer delegates responsibility.

This is one of the key ideas that allows DNS to scale globally.

59. Delegation

Suppose:

.com

delegates:

cresignsys.com

to certain authoritative nameservers.

Conceptually:

.com
 ↓
Delegation
 ↓
cresignsys.com nameservers

Those servers then manage the records for the domain/zone.

60. Your Hosting Architecture

Now connect DNS to your hosting system:

                 DNS
                  │
                  ▼
templates.cresignsys.com
                  │
                  ▼
              A record
                  │
                  ▼
             Server IP
                  │
                  ▼
             Cloud VM
                  │
                  ▼
              Ubuntu
                  │
                  ▼
                Nginx
                  │
                  ▼
/storage/websites/templates.cresignsys.com/public

DNS gets the user to the server.

Nginx gets the request to the website.

61. DNS Is Outside Your Ubuntu Server

This is important for your hosting platform.

Your server contains:

Ubuntu
Nginx
PHP
MySQL
WordPress

But DNS records are usually managed through a DNS provider or registrar’s DNS service.

Therefore:

DNS configuration

and:

Nginx configuration

are separate systems.

62. Why Your SSL Setup Needed DNS

When you ran Certbot for:

templates.cresignsys.com

Let’s Encrypt needed to establish that the requester controls the domain.

With HTTP-01, the validation path involves:

Let's Encrypt
 ↓
DNS
 ↓
templates.cresignsys.com
 ↓
Your public server
 ↓
HTTP challenge

After validation:

Let's Encrypt
 ↓
certificate
 ↓
Certbot
 ↓
Nginx

63. The Three Major DNS Uses in Your Hosting

DNS can be involved in:

1. Website routing

domain
 ↓
A/AAAA
 ↓
server

2. Email

domain
 ↓
MX
 ↓
mail server

3. Certificate validation

domain
 ↓
DNS or HTTP challenge
 ↓
Let's Encrypt

64. DNS Security

DNS itself has security challenges.

Traditional DNS queries/responses can be observed or modified depending on the network path and resolver architecture.

Technologies such as:

DNSSEC
DoH
DoT

address different parts of the DNS security/privacy problem.

We will study these later.

65. DNSSEC

DNSSEC means:

Domain Name System Security Extensions

DNSSEC adds cryptographic signatures to DNS data so resolvers can validate that DNS responses are authentic and haven’t been tampered with within the DNSSEC validation model.

Conceptually:

DNS data
 ↓
Digital signature
 ↓
Resolver validates

This is different from TLS.

66. DNSSEC vs TLS

Remember:

DNSSEC
 ↓
Authenticates DNS data

TLS
 ↓
Authenticates server identity
 + encrypts application communication
 + protects integrity

They solve different problems.

67. DoH

DoH means:

DNS over HTTPS

DNS queries are transported through HTTPS.

Conceptually:

DNS query
 ↓
HTTPS
 ↓
DNS resolver

This can help protect DNS queries from some forms of network observation or manipulation between the client and resolver.

68. DoT

DoT means:

DNS over TLS

Similar idea:

DNS
 ↓
TLS
 ↓
Network

Again, this concerns the transport of DNS queries, not the TLS session used by your website itself.

69. Very Important Distinction

Your website:

https://templates.cresignsys.com

uses TLS to protect:

Browser ↔ Website

DoH/DoT concern:

Client ↔ DNS resolver

These are different connections.

70. Complete DNS-to-Web Chain

Now we can make the entire chain:

Browser
   │
   │ "Where is templates.cresignsys.com?"
   ▼
DNS Resolver
   │
   ▼
DNS hierarchy
   │
   ▼
Authoritative DNS
   │
   ▼
IP address
   │
   ▼
Internet routing
   │
   ▼
TCP :443
   │
   ▼
TLS
   │
   ▼
HTTPS
   │
   ▼
Nginx

71. The Most Important Mental Model

Remember these four questions:

DNS
 ↓
WHERE?

IP
 ↓
WHICH HOST/NETWORK?

TCP
 ↓
WHICH TRANSPORT CONNECTION?

PORT
 ↓
WHICH SERVICE?

TLS
 ↓
IS THE COMMUNICATION SECURE AND THE SERVER AUTHENTICATED?

HTTP
 ↓
WHAT WEB RESOURCE?

This model will make the rest of web hosting much easier.

72. Practical Exercise

On your Ubuntu server, run:

dig templates.cresignsys.com

Then:

dig templates.cresignsys.com A

Then:

dig templates.cresignsys.com AAAA

Then:

dig cresignsys.com NS

Then:

dig +trace templates.cresignsys.com

Then:

resolvectl status

Do not change anything yet.

The purpose is to observe how DNS works.

73. Next Lesson — 026

DNS Records Deep Dive

We will go one level deeper:

A
AAAA
CNAME
NS
SOA
MX
TXT
CAA
PTR
SRV
NAPTR

Then we will specifically build the DNS structure for a hosting platform:

cresignsys.com
├── www
├── templates
├── learn
├── shop
├── manage
└── other websites

and understand:

Domain
 ↓
Subdomain
 ↓
DNS record
 ↓
IP
 ↓
Server
 ↓
Nginx server block
 ↓
Website directory

This will be the foundation for understanding how one VPS can host dozens or hundreds of domains and subdomains.

CresignSys Learn — Lesson 025

Course: From Basic Science to Web Hosting

Module 05 — Networking Fundamentals

DNS — From Domain Name to IP Address

DNS — Domain Name System

1. The Basic Problem

2. DNS Is a Distributed Database

3. The Domain Name

4. The Root

5. DNS Hierarchy

6. Root DNS

7. TLD

Top-Level Domain

8. Second-Level Domain

9. Subdomain

10. DNS Does Not Care That It Is a Website

11. A Record

A

12. AAAA Record

AAAA

13. A vs AAAA

14. CNAME

CNAME

15. Important CNAME Rule

16. NS Record

Name Server

17. Authoritative DNS Server

18. Recursive DNS Resolver

Recursive Resolver

19. Why Use a Recursive Resolver?

20. The Complete DNS Lookup

21. First Query: Root

22. Second Query: TLD

23. Third Query: Authoritative Server

24. Resolver Returns Answer

25. DNS Is Before TCP

26. DNS Caching

Caching

27. Cache Hit

28. Cache Miss

29. TTL

TTL

30. Why TTL Matters

31. DNS Propagation

32. DNS Zone

DNS Zone

33. Zone vs Domain

34. SOA Record

SOA

35. MX Record

Mail Exchange

36. TXT Record

37. CAA Record

Certification Authority Authorization

38. DNS and Let’s Encrypt

DNS-01

HTTP-01

39. DNS Is Not Certificate Validation

40. DNS Does Not Encrypt Your Website

41. DNS Record Example

42. What Happens If the A Record Is Wrong?

43. What Happens If DNS Works but Port 443 Is Closed?

44. What Happens If TCP Works but Certificate Is Wrong?

45. DNS + TCP + TLS

DNS

TCP

TLS

HTTP

46. DNS Command: dig

47. Ask Specifically for A

48. Ask for AAAA

49. Ask for NS

50. Ask for MX

51. Ask for TXT

52. dig +trace

53. resolvectl

54. /etc/resolv.conf

55. DNS Resolver Flow

56. Authoritative vs Recursive

Recursive resolver

46. DNS Command: `dig`

52. `dig +trace`

53. `resolvectl`

54. `/etc/resolv.conf`