Category: Uncategorized

CresignSys Learn — Lesson 026

DNS Records Deep Dive

We now know:

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

Now we go one level deeper into what DNS actually stores.

1. DNS Is Made of Records

DNS does not simply contain:

domain → IP

It contains different types of records.

Think of a DNS zone as a database table:

NAME                         TYPE       VALUE
────────────────────────────────────────────────────
cresignsys.com               A          IP
templates.cresignsys.com    A          IP
www.cresignsys.com           CNAME      cresignsys.com
cresignsys.com               MX         mail server
cresignsys.com               TXT        verification data
cresignsys.com               NS         nameserver
cresignsys.com               SOA        zone information

Each record has a specific purpose.

2. The Most Important Records

For web hosting, learn these first:

A
AAAA
CNAME
NS
SOA
MX
TXT
CAA

Later:

PTR
SRV
NAPTR
DNSSEC records

3. A Record

The A record maps a name to an IPv4 address.

Example:

templates.cresignsys.com
        ↓
       A
        ↓
203.0.113.10

Again, 203.0.113.10 is only an example.

4. What Happens After an A Record?

Suppose:

templates.cresignsys.com
A
203.0.113.10

The browser can then attempt:

203.0.113.10:443

The path becomes:

Domain
 ↓
A record
 ↓
IPv4
 ↓
TCP 443
 ↓
TLS
 ↓
Nginx

5. AAAA Record

AAAA performs the equivalent function for IPv6.

Example:

templates.cresignsys.com
AAAA
2001:db8::10

Conceptually:

A
 ↓
IPv4

AAAA
 ↓
IPv6

6. Why Both Can Exist

A website can have:

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

A client may use IPv6 when available and appropriate, or IPv4 otherwise.

The actual connection behavior depends on the client and network.

7. CNAME

CNAME means:

Canonical Name

It creates an alias.

Example:

www.cresignsys.com
        ↓
      CNAME
        ↓
cresignsys.com

Then DNS can resolve:

cresignsys.com
 ↓
A / AAAA
 ↓
IP

8. CNAME Does Not Mean Redirect

This is a common misunderstanding.

DNS CNAME:

www.example.com
      ↓
CNAME
      ↓
example.com

is not an HTTP redirect.

It happens at the DNS level.

An HTTP redirect happens later:

Browser
 ↓
HTTP request
 ↓
Web server
 ↓
301/302
 ↓
new URL

These are completely different mechanisms.

9. CNAME Example

Suppose:

www.cresignsys.com
CNAME
cresignsys.com

The browser asks DNS:

What is www.cresignsys.com?

DNS follows the CNAME relationship and ultimately obtains the relevant address information for:

cresignsys.com

10. CNAME and IP Address

Remember:

A:
name → IPv4

while:

CNAME:
name → another name

So:

A
 ↓
192.0.2.10

but:

CNAME
 ↓
another.example.com

11. NS Record

NS means:

Name Server

It tells DNS which authoritative nameservers are responsible for a zone.

Conceptually:

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

These nameservers are responsible for serving authoritative DNS information.

12. Why NS Is Important

Imagine your domain registrar knows:

cresignsys.com

but doesn’t itself necessarily store all your DNS records.

You tell the DNS system:

Use these nameservers for cresignsys.com.

Conceptually:

Registrar / parent zone
        ↓
NS delegation
        ↓
Authoritative DNS
        ↓
A / AAAA / MX / TXT / etc.

13. Delegation

This is one of the deepest DNS concepts.

The parent zone can delegate responsibility for a child domain.

For example:

.com
 ↓
cresignsys.com

The .com infrastructure knows which nameservers are authoritative for:

cresignsys.com

Then those servers manage the records within that domain’s zone.

14. SOA Record

SOA means:

Start of Authority

It contains information about the DNS zone.

Conceptually:

cresignsys.com
      ↓
     SOA
      ↓
Zone information

It includes things such as:

Primary/authoritative server information
Administrative contact information
Serial number
Refresh-related timing
Retry-related timing
Expiration-related timing
Minimum/negative caching-related information

The exact semantics of these fields are defined by DNS standards.

15. DNS Serial Number

The SOA record contains a serial value.

It can be used by secondary DNS systems to determine whether zone data has changed.

Conceptually:

Old zone
Serial = 100

New zone
Serial = 101

The secondary can recognize that the zone has been updated.

Modern DNS providers often manage this automatically.

16. MX Record

MX means:

Mail Exchange

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

Example:

cresignsys.com
MX
mail.example.com

It also has a priority value.

Conceptually:

Priority 10 → mail1
Priority 20 → mail2

Lower numeric preference values generally have higher priority.

17. Website vs Email

Your website might use:

while email uses:

MX

Therefore:

cresignsys.com
 ├── Website → A / AAAA
 │
 └── Email   → MX

The same domain can support completely different services.

18. TXT Record

TXT records contain text data.

They are heavily used for verification and policy mechanisms.

Examples include:

Domain ownership verification
SPF
DKIM
DMARC
ACME DNS challenges
Other service verification

19. SPF

SPF means:

Sender Policy Framework

It is an email authentication mechanism that uses DNS TXT records to publish which servers are authorized to send mail for a domain.

Conceptually:

cresignsys.com
      ↓
     TXT
      ↓
SPF policy
      ↓
Mail receiver checks

SPF is about email, not web hosting.

20. DKIM

DKIM means:

DomainKeys Identified Mail

It uses cryptographic signatures to help verify that an email is associated with a domain and has not been modified in transit in ways detectable by the signature.

The public key is published in DNS.

Conceptually:

Email
 ↓
DKIM signature
 ↓
Receiver
 ↓
DNS
 ↓
Public key
 ↓
Verify signature

21. DMARC

DMARC means:

Domain-based Message Authentication, Reporting, and Conformance

It builds on email authentication mechanisms such as:

SPF
DKIM

and lets a domain publish policy/reporting instructions through DNS.

Conceptually:

SPF
 +
DKIM
 +
DMARC policy

This belongs to email security rather than website HTTPS.

22. CAA Record

CAA is particularly relevant to your SSL learning.

CAA stands for:

Certification Authority Authorization

It allows a domain to publish which certificate authorities are authorized to issue certificates for it.

Conceptually:

cresignsys.com
      ↓
     CAA
      ↓
Authorized certificate authority

23. CAA and Let’s Encrypt

Suppose your DNS policy allows:

Let's Encrypt

to issue certificates.

Conceptually:

Let's Encrypt
      ↓
Check CAA
      ↓
Is this CA authorized?
      ↓
Yes
      ↓
Continue certificate issuance

If the CAA policy prohibits that CA, issuance can fail.

CAA is an additional control; certificate authorities also perform their required domain-control validation.

24. PTR Record

PTR is essentially the reverse of an A-style mapping.

Forward DNS:

name
 ↓
IP

Reverse DNS:

IP
 ↓
name

This is called:

Reverse DNS

25. Reverse DNS

Suppose:

server.example.com
A
203.0.113.10

Reverse DNS could conceptually provide:

203.0.113.10
 ↓
server.example.com

The reverse namespace for IPv4 uses:

in-addr.arpa

IPv6 uses:

ip6.arpa

26. Why Reverse DNS Matters

Reverse DNS can be important for:

Mail servers
Server identification
Logging
Network troubleshooting
Some reputation systems

For a web server, it is not generally what makes HTTPS work.

27. SRV Record

SRV records provide information about services, including:

service
protocol
priority
weight
port
target

Conceptually:

_service._tcp.example.com
        ↓
SRV
        ↓
server + port

They are used by various network services and applications.

28. DNS Record Comparison

Record	Main purpose
A	Name → IPv4
AAAA	Name → IPv6
CNAME	Name → another name
NS	Authoritative nameserver delegation
SOA	Zone authority/metadata
MX	Mail delivery
TXT	Text/policy/verification
CAA	Certificate authority authorization
PTR	Reverse DNS
SRV	Service discovery

29. A Realistic Hosting Zone

Imagine your DNS zone contains:

cresignsys.com

A       → server IP
AAAA    → server IPv6

templates.cresignsys.com
A       → server IP

learn.cresignsys.com
A       → server IP

shop.cresignsys.com
A       → server IP

www
CNAME   → cresignsys.com

MX      → mail server

TXT     → verification/email policies

CAA     → certificate authority policy

This creates the DNS side of your hosting architecture.

30. DNS Does Not Create the Website

This is one of the most important concepts.

Suppose DNS says:

templates.cresignsys.com
A
SERVER-IP

That does not mean the website automatically exists.

You still need:

Server
 ↓
Network access
 ↓
Port 443
 ↓
Nginx
 ↓
Server block
 ↓
Website files

DNS only gets the client to the appropriate network destination.

31. DNS + Nginx

Now connect the two systems.

DNS:

templates.cresignsys.com
       ↓
     A record
       ↓
    Server IP

Nginx:

Server IP:443
       ↓
Hostname
       ↓
templates.cresignsys.com
       ↓
Website configuration
       ↓
/storage/websites/templates.cresignsys.com/public

This is the key relationship between DNS and web hosting.

32. Same IP, Multiple Websites

This is where hosting becomes interesting.

Suppose:

templates.cresignsys.com
learn.cresignsys.com
shop.cresignsys.com

all point to:

same server IP

How can Nginx know which website the visitor wants?

Because the HTTP request contains the hostname, and TLS also uses the hostname during the HTTPS connection setup through SNI.

Conceptually:

                 Same IP
                   │
          ┌────────┼────────┐
          ↓        ↓        ↓
      templates   learn    shop
          │        │        │
          ↓        ↓        ↓
        Nginx    Nginx    Nginx
          │        │        │
          ↓        ↓        ↓
       Site A    Site B   Site C

33. One Server, Many Domains

This is the foundation of shared hosting.

                    VPS
                     │
                Public IP
                     │
                    Nginx
        ┌────────────┼────────────┐
        ↓            ↓            ↓
     Site A        Site B       Site C
        │            │            │
        ↓            ↓            ↓
   WordPress      WordPress      HTML

DNS makes all those names point toward the server.

Nginx separates them.

34. Domain → DNS → Nginx

The complete chain:

templates.cresignsys.com
          ↓
         DNS
          ↓
       Server IP
          ↓
     TCP port 443
          ↓
         TLS
          ↓
        Nginx
          ↓
Hostname matching
          ↓
templates.cresignsys.com
          ↓
Website directory

35. Why the Hostname Is Important

Suppose three domains use one IP:

A → 203.0.113.10
B → 203.0.113.10
C → 203.0.113.10

The IP alone cannot tell Nginx which website is wanted.

The application-level hostname helps.

For HTTPS, TLS also has:

SNI

Server Name Indication.

36. SNI

SNI allows the client to indicate the hostname it wants during the TLS handshake.

Conceptually:

Client
 ↓
TLS ClientHello
 ↓
SNI:
templates.cresignsys.com
 ↓
Server

Nginx can then select the appropriate certificate/configuration for the requested hostname.

This is crucial for modern HTTPS hosting.

37. Certificate + SNI

Suppose one server hosts:

templates.cresignsys.com
learn.cresignsys.com
shop.cresignsys.com

It may have certificates covering these different names.

The TLS connection indicates the requested hostname through SNI.

Conceptually:

Client
 ↓
SNI = templates.cresignsys.com
 ↓
Nginx
 ↓
Select appropriate TLS configuration
 ↓
Certificate for requested hostname

38. DNS Does Not Choose the Certificate

This is subtle.

DNS says:

templates.cresignsys.com
 ↓
IP

SNI says:

TLS connection wants:
templates.cresignsys.com

Nginx then uses its configuration to select an appropriate certificate/server block.

So:

DNS
 ↓
network destination

SNI
 ↓
TLS hostname

Nginx
 ↓
virtual host

39. Practical DNS Inspection

Install/use dig if available:

dig templates.cresignsys.com A

You can inspect the answer.

For CNAME:

dig www.cresignsys.com CNAME

For nameservers:

dig cresignsys.com NS

For mail:

dig cresignsys.com MX

For TXT:

dig cresignsys.com TXT

For certificate authority policy:

dig cresignsys.com CAA

40. Short Form

You can also use:

dig +short templates.cresignsys.com A

This focuses on the answer.

For example:

203.0.113.10

if that were the actual result.

41. Follow CNAMEs

Try:

dig +short www.cresignsys.com

If www is a CNAME, the result can help show the eventual address information after resolution.

42. Check Your Nameservers

Run:

dig +short cresignsys.com NS

This tells you which nameservers are authoritative for the domain.

This is one of the first things to check when debugging DNS.

43. Check the Authoritative Answer

You can use:

dig +trace templates.cresignsys.com

This is particularly useful for understanding:

Root
 ↓
TLD
 ↓
Domain delegation
 ↓
Authoritative server
 ↓
Record

44. The DNS Hierarchy as a Tree

Think of DNS like this:

.
│
├── com
│   │
│   ├── cresignsys
│   │    │
│   │    ├── templates
│   │    ├── learn
│   │    ├── shop
│   │    └── www
│   │
│   └── other domains
│
├── org
│
├── net
│
└── in

Each label is a node in a hierarchical namespace.

45. Subdomains Are Just Labels

For example:

templates.cresignsys.com

has:

templates

as one label beneath:

cresignsys.com

You could have:

learn.cresignsys.com
shop.cresignsys.com
manage.cresignsys.com

Each is another DNS name.

46. DNS Doesn’t Require Separate Servers

These can all point to the same server:

templates.cresignsys.com
learn.cresignsys.com
shop.cresignsys.com

For example:

templates → 203.0.113.10
learn     → 203.0.113.10
shop      → 203.0.113.10

One VPS can serve all three.

47. Different Servers Are Also Possible

You could instead have:

templates → Server A
learn     → Server B
shop      → Server C

DNS makes this possible.

Therefore DNS provides a layer of infrastructure abstraction.

48. DNS and Cloud Hosting

In a cloud environment:

DNS
 ↓
Public IP
 ↓
Cloud networking
 ↓
VNIC / virtual network interface
 ↓
Security rules
 ↓
VM
 ↓
Nginx

So DNS is only the first part of the network path.

49. Security Rules

Even if DNS is correct:

templates.cresignsys.com
 ↓
correct IP

cloud security rules may still block:

TCP 80
TCP 443

Then the website will not be reachable.

So troubleshooting must continue layer by layer.

50. The Three Different Configurations

For a working HTTPS website, you can think in terms of three separate configurations:

DNS

Name
 ↓
IP

Cloud/network firewall

Internet
 ↓
TCP 443
 ↓
Allowed?

Nginx

Port 443
 ↓
Hostname
 ↓
Certificate
 ↓
Website

All three need to cooperate.

51. Example Failure

Suppose:

DNS = correct
Firewall = correct
Nginx = stopped

Result:

DNS
 ↓
works

TCP 443
 ↓
connection refused/failed

52. Another Failure

DNS = wrong
Firewall = correct
Nginx = correct

Result:

Browser
 ↓
DNS
 ↓
wrong server

Your Nginx configuration can be completely correct and the user still won’t reach it.

53. Another Failure

DNS = correct
Firewall = correct
Nginx = correct
Certificate = wrong

Result:

TCP
 ↓
works

TLS
 ↓
certificate error

This layered diagnosis is one of the most valuable skills in web hosting.

54. Your Hosting Platform

You are gradually building a hosting architecture that can be represented as:

                 INTERNET
                     │
                     ▼
                    DNS
                     │
            ┌────────┼────────┐
            ▼        ▼        ▼
        templates   learn    shop
            │        │        │
            └────────┼────────┘
                     ▼
                  Public IP
                     │
                     ▼
                Cloud Network
                     │
                     ▼
                   Ubuntu
                     │
                     ▼
                  Nginx
          ┌──────────┼──────────┐
          ▼          ▼          ▼
       Site A      Site B      Site C
          │          │          │
          ▼          ▼          ▼
      WordPress   WordPress    HTML

That is the basic architecture behind a multi-site hosting server.

55. The Next Level: DNS Resolution in Detail

We can now go deeper into exactly what happens inside a DNS lookup:

Browser
 ↓
OS resolver
 ↓
Recursive resolver
 ↓
Cache
 ↓
Root hints
 ↓
Root nameserver
 ↓
TLD nameserver
 ↓
Authoritative nameserver
 ↓
A record
 ↓
TTL
 ↓
Cache
 ↓
Browser

Then we can connect DNS directly to:

TCP
 ↓
SNI
 ↓
TLS certificate
 ↓
Nginx server block

56. Practical Exercise for Your Server

Run these and record the output:

dig +short templates.cresignsys.com A

dig +short templates.cresignsys.com AAAA

dig +short cresignsys.com NS

dig +short cresignsys.com MX

dig +short cresignsys.com TXT

dig +short cresignsys.com CAA

Then:

dig +trace templates.cresignsys.com

These commands are read-only.

Do not modify DNS yet.

Lesson 026 Summary

The most important concepts are:

A
 ↓
IPv4

AAAA
 ↓
IPv6

CNAME
 ↓
Another DNS name

NS
 ↓
Authoritative nameservers

SOA
 ↓
Zone authority information

MX
 ↓
Email

TXT
 ↓
Policies / verification

CAA
 ↓
Certificate authority authorization

PTR
 ↓
Reverse DNS

SRV
 ↓
Service discovery

And the complete hosting connection is:

DOMAIN
   ↓
DNS RECORD
   ↓
IP ADDRESS
   ↓
CLOUD NETWORK
   ↓
FIREWALL
   ↓
TCP 443
   ↓
TLS + SNI
   ↓
NGINX
   ↓
SERVER BLOCK
   ↓
WEBSITE DIRECTORY

Next Lesson — 027

DNS Resolution — What Happens Inside the Resolver?

We will go even deeper into:

Stub Resolver
 ↓
Recursive Resolver
 ↓
Root Hints
 ↓
Root Server
 ↓
TLD Server
 ↓
Authoritative Server
 ↓
Caching
 ↓
TTL
 ↓
Negative Caching
 ↓
DNS Response

Then we will use dig +trace to understand the actual journey of templates.cresignsys.com from the DNS root to your domain.

August 13, 2026

CresignSys Learn — Lesson 025
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

A:

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.
August 13, 2026

CresignSys Learn — Lesson 024

Course: From Basic Science to Web Hosting

Module 05 — Networking Fundamentals

From DNS to HTTPS: One Complete Web Request

Difficulty: Intermediate
Prerequisites: Lesson 023 — TCP
Estimated time: 45–60 minutes

Now we connect everything learned so far.

We will follow one request:

https://templates.cresignsys.com

from your computer all the way to your Ubuntu server.

1. The Big Picture

The complete journey is approximately:

Browser
   ↓
DNS
   ↓
IP address
   ↓
Routing
   ↓
TCP
   ↓
TLS
   ↓
HTTPS
   ↓
Nginx
   ↓
PHP-FPM
   ↓
WordPress
   ↓
MySQL
   ↓
Response
   ↓
Nginx
   ↓
TLS encryption
   ↓
TCP
   ↓
Internet
   ↓
Browser

The important thing is that each layer has a different job.

2. You Type the URL

You enter:

https://templates.cresignsys.com

The browser breaks the URL into concepts such as:

Scheme:
https

Hostname:
templates.cresignsys.com

Port:
443

Because HTTPS conventionally uses port:

3. What Does `https://` Mean?

The scheme:

https

means approximately:

HTTP
+
TLS

So:

HTTPS = HTTP carried through TLS protection

For traditional HTTPS:

HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP

4. First Problem: Where Is the Server?

Your browser knows:

templates.cresignsys.com

But networking needs an IP address.

Therefore it needs:

DNS

5. DNS Translation

Conceptually:

templates.cresignsys.com
             ↓
            DNS
             ↓
        IP address

Suppose, purely as an example, DNS returns:

203.0.113.10

That is an example address, not your actual server IP.

The browser can now attempt to reach:

203.0.113.10:443

6. DNS Does Not Create the HTTPS Connection

This distinction is important.

DNS only answers the naming question.

DNS:
"What address belongs to this hostname?"

Then networking takes over:

IP:
"How do I reach that address?"

Then TCP:

"How do I establish a reliable transport connection?"

Then TLS:

"How do I establish a secure cryptographic session?"

Then HTTP:

"What web resource do I want?"

7. DNS Caching

The browser or operating system may already know the DNS answer from a cache.

Therefore the browser does not necessarily perform a complete DNS lookup every time you type the URL.

Possible caches include:

Browser cache
 ↓
Operating-system cache
 ↓
Local resolver
 ↓
Recursive DNS resolver
 ↓
Authoritative DNS server

We will study this entire chain in a later lesson.

8. Browser Has the IP

Now suppose the browser has:

Server:
203.0.113.10

and:

Port:
443

The next goal is:

Create TCP connection

9. TCP Connection

The browser’s operating system creates a TCP connection.

Conceptually:

Client
192.0.2.20:53000

       ↓

Server
203.0.113.10:443

Again, these are illustrative addresses.

10. TCP SYN

The client sends:

SYN

Conceptually:

Browser/OS
     │
     │ SYN
     ▼
Server

This is a TCP segment carried inside an IP packet and then a link-layer frame.

11. TCP SYN-ACK

The server responds:

SYN-ACK

Client
  │
  │ SYN
  ▼
Server
  │
  │ SYN-ACK
  ▼
Client

12. TCP ACK

The client sends:

ACK

Client
  │
  │ ACK
  ▼
Server

Now:

TCP connection
=
ESTABLISHED

13. Important Point

At this moment:

TCP = working

But:

HTTPS = not yet established

TLS still needs to happen.

14. TLS Starts

The browser now begins the TLS handshake.

For modern HTTPS connections, the exact handshake details depend on the TLS version and negotiated options. TLS 1.3 is common today.

Conceptually:

TCP established
      ↓
TLS handshake
      ↓
Secure session

15. What Is TLS Trying to Achieve?

TLS provides important security properties including:

Authentication
Confidentiality
Integrity

In simpler language:

Who am I talking to?
 ↓
Can others read the data?
 ↓
Can someone secretly modify the data?

16. Your Let’s Encrypt Certificate Enters Here

You recently installed:

templates.cresignsys.com

with a Let’s Encrypt certificate.

Certbot reported:

Certificate:
 /etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem

Private key:
 /etc/letsencrypt/live/templates.cresignsys.com/privkey.pem

These files are now used by your TLS-enabled Nginx configuration.

17. Certificate vs Private Key

This distinction is critical.

You have:

fullchain.pem

and:

privkey.pem

They are not the same thing.

Certificate

Contains the server’s public identity information and public key, together with the CA’s signatures/chain information as applicable.

Private key

Secret cryptographic material that must remain protected on the server.

Conceptually:

Certificate
   ↓
Public information
   ↓
Can be sent to clients

Private key
   ↓
SECRET
   ↓
Must remain on server

18. Why Does the Browser Trust Let’s Encrypt?

Your browser/operating system has a set of trusted:

Root Certificate Authorities

Let’s Encrypt operates a certificate authority hierarchy.

Conceptually:

Trusted Root CA
      ↓
Intermediate CA
      ↓
Your server certificate
      ↓
templates.cresignsys.com

The browser checks the certificate chain against its trusted CA store.

The exact current chain can vary by certificate issuance and client environment.

19. Certificate Identity

Your certificate contains identity information for the domain, typically through:

Subject Alternative Name

For example:

DNS:
templates.cresignsys.com

The browser checks whether the hostname it requested matches the certificate’s valid names.

So:

Browser requests:

templates.cresignsys.com

and checks:

Certificate valid for:
templates.cresignsys.com

20. Certificate Validity Period

Your Certbot output said:

This certificate expires on 2026-11-11.

That means the certificate has a defined validity period.

Certbot also configured automatic renewal.

Conceptually:

Certificate
     ↓
valid
     ↓
renew before expiration
     ↓
new certificate
     ↓
Nginx uses renewed certificate

21. Certificate Does Not Encrypt Everything by Itself

This is a very important correction to a common beginner misunderstanding.

The certificate is not simply:

"the encryption"

Instead, TLS uses certificates and cryptographic protocols to authenticate the server and establish cryptographic keys.

Then symmetric encryption is normally used for the bulk data.

Conceptually:

Certificate
      ↓
Authentication / key establishment
      ↓
Session keys
      ↓
Symmetric encryption
      ↓
HTTPS data

22. Why Not Encrypt Everything With the Public Key?

Public-key cryptography is computationally more expensive than symmetric cryptography for bulk data.

So TLS uses a combination of cryptographic techniques.

Conceptually:

Asymmetric cryptography
        ↓
Securely establish/authenticate key material

Symmetric cryptography
        ↓
Encrypt large amounts of application data

This is called hybrid cryptography.

23. TLS 1.3

Modern TLS commonly uses:

TLS 1.3

It was designed to improve security and reduce unnecessary handshake complexity compared with older TLS versions.

A simplified conceptual handshake:

Client
  │
  │ ClientHello
  ▼
Server
  │
  │ ServerHello + certificate + other handshake data
  ▼
Client
  │
  │ handshake completion
  ▼
Encrypted application data

The exact messages and cryptographic details are more sophisticated than this simplified diagram.

24. ClientHello

The browser sends a:

ClientHello

It communicates information needed to negotiate TLS, including supported protocol capabilities and cryptographic parameters.

Conceptually:

Browser
   │
   │ ClientHello
   ▼
Server

25. ServerHello

The server responds with a:

ServerHello

The server selects compatible cryptographic parameters.

Conceptually:

Client
   │
   │ ClientHello
   ▼
Server
   │
   │ ServerHello
   ▼
Client

26. Server Certificate

The server provides its certificate during the TLS handshake.

Conceptually:

Nginx
 ↓
Certificate
 ↓
Browser

The browser then validates it.

27. What Does the Browser Check?

The browser performs several checks.

Conceptually:

Certificate
 ↓
Is it expired?
 ↓
Does hostname match?
 ↓
Is the chain trusted?
 ↓
Is it cryptographically valid?
 ↓
Is the certificate acceptable under current rules?

If something fails, the browser may display a certificate warning/error.

28. Certificate Chain

Your:

fullchain.pem

normally contains your server certificate together with the intermediate certificate chain needed by clients.

Conceptually:

Root
 ↓
Intermediate
 ↓
Server certificate

The exact chain presented depends on how the certificate was issued and configured.

29. Why `fullchain.pem`?

Suppose a browser knows/trusts the root but needs the intermediate certificate to build the chain.

The server can provide the necessary chain information.

Conceptually:

Server
 ↓
Server certificate
 ↓
Intermediate certificate
 ↓
Browser
 ↓
Trusted root

This helps the browser build:

Trusted Root
      ↓
Intermediate
      ↓
Server Certificate

30. The Private Key

Your:

/etc/letsencrypt/live/templates.cresignsys.com/privkey.pem

contains the private key.

It is used by the TLS implementation for cryptographic operations involved in authentication/key establishment.

It should never be publicly exposed.

Do not paste its contents into chat, websites, or support requests.

31. Important Modern TLS Detail

A common beginner explanation says:

“The browser encrypts a session key using the server’s RSA public key.”

That can describe older TLS designs, but it is not the correct general model for modern TLS 1.3.

Modern TLS commonly uses ephemeral Diffie-Hellman key exchange.

Conceptually:

Client ephemeral key
        +
Server ephemeral key
        ↓
Shared secret
        ↓
Session keys

The certificate’s public key authenticates the server’s identity and participates in authentication of the handshake rather than simply encrypting all session keys.

32. Diffie-Hellman Idea

The basic mathematical idea is:

Client secret
      +
Server information
      ↓
Shared secret

Server secret
      +
Client information
      ↓
Same shared secret

Neither side needs to send the final shared secret directly across the network.

This is one of the foundational ideas behind modern secure communications.

33. Why Is This Powerful?

An observer may see:

Client public information
Server public information

but should not be able to efficiently derive the shared secret without the required private/ephemeral secret information.

This relies on hard mathematical problems and secure cryptographic algorithms.

34. Session Keys

Once TLS establishes the required shared secret material, it derives symmetric session keys.

Conceptually:

TLS handshake
      ↓
Shared secret/key material
      ↓
Key derivation
      ↓
Session keys

Then:

HTTP data
 ↓
Symmetric encryption
 ↓
TLS records

35. Now HTTP Can Be Sent

The browser can finally send the HTTP request through the encrypted TLS connection.

Conceptually, the browser wants something like:

GET / HTTP/1.1
Host: templates.cresignsys.com

But on the network:

HTTP request
 ↓
TLS encryption
 ↓
Encrypted TLS records
 ↓
TCP
 ↓
IP
 ↓
Network

So an outside observer cannot simply read the HTTP contents from the network traffic.

36. Nginx Receives It

The encrypted data reaches:

Your server
 ↓
Network interface
 ↓
Linux kernel
 ↓
TCP
 ↓
TLS
 ↓
Nginx

Nginx’s TLS layer decrypts/authenticates the TLS records.

Then Nginx obtains the HTTP request.

37. Nginx Looks at the Hostname

The request contains the hostname:

templates.cresignsys.com

Nginx can use the hostname and its configuration to select the appropriate server block.

This is why one server can host:

site1.example.com
site2.example.com
templates.cresignsys.com

on the same IP address.

This is called:

Name-based virtual hosting

38. Nginx Configuration

You have:

/etc/nginx/sites-enabled/templates.cresignsys.com

Nginx reads its enabled configuration.

Conceptually:

Incoming request
       ↓
Port 443
       ↓
TLS
       ↓
Hostname
       ↓
matching server block
       ↓
templates.cresignsys.com configuration

39. What Does Nginx Do Next?

It determines how to handle the request.

Possibilities:

Static file

or:

PHP request

or:

Proxy request

For WordPress:

Nginx
 ↓
PHP-FPM

is common.

40. Static File Example

Suppose the browser requests:

/favicon.ico

Nginx may simply find:

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

and return it.

Path:

Browser
 ↓
Nginx
 ↓
Filesystem
 ↓
favicon.ico

PHP isn’t necessary.

41. WordPress Request

Suppose the browser requests:

Nginx may route the request to WordPress/PHP.

Conceptually:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress

42. PHP-FPM

PHP-FPM receives the PHP execution request.

Conceptually:

Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
PHP worker

The worker executes WordPress PHP code.

43. WordPress

WordPress loads components such as:

wp-config.php
Core
Theme
Plugins

Then WordPress may need information from the database.

44. MySQL

WordPress communicates with MySQL.

Conceptually:

WordPress
   ↓
Database connection
   ↓
MySQL
   ↓
Database

MySQL retrieves required information.

For example:

Posts
Pages
Settings
Users
Plugin data

45. The Response Travels Back

The result flows backward:

MySQL
 ↓
WordPress
 ↓
PHP-FPM
 ↓
Nginx

Nginx constructs the HTTP response.

For example:

HTTP/1.1 200 OK
Content-Type: text/html

plus the generated HTML.

46. Nginx Does Not Send Plain HTTP Over the Internet

Remember:

HTTP response
 ↓
TLS
 ↓
Encrypted data
 ↓
TCP
 ↓
IP
 ↓
Internet

The browser receives the encrypted TLS records.

47. Browser Decrypts

The browser’s TLS implementation processes the received records:

Encrypted TLS records
       ↓
TLS
       ↓
Plain HTTP response
       ↓
HTML
       ↓
Browser rendering

48. The Page Appears

Eventually:

HTML
 ↓
CSS
 ↓
JavaScript
 ↓
Images
 ↓
Browser rendering
 ↓
Web page

The user sees:

templates.cresignsys.com

49. One Request in One Diagram

Here is the complete conceptual flow:

                    YOUR COMPUTER
                         │
                         ▼
                      Browser
                         │
                         ▼
                        DNS
                         │
                         ▼
                     Server IP
                         │
                         ▼
                       Routing
                         │
                         ▼
                        TCP
                     SYN/ACK
                         │
                         ▼
                        TLS
                  Certificate check
                         │
                         ▼
                    Session keys
                         │
                         ▼
                 Encrypted HTTP
                         │
════════════════════════════════════════════
                     INTERNET
════════════════════════════════════════════
                         │
                         ▼
                  Cloud Network
                         │
                         ▼
                   Ubuntu VPS
                         │
                         ▼
                  Network Interface
                         │
                         ▼
                    Linux Kernel
                         │
                         ▼
                        TCP
                         │
                         ▼
                        TLS
                         │
                         ▼
                       Nginx
                         │
                  ┌──────┴──────┐
                  ▼             ▼
               Static        PHP-FPM
                               │
                               ▼
                            WordPress
                               │
                               ▼
                             MySQL
                               │
                               ▼
                            Response
                               │
                               ▼
                             Nginx
                               │
                               ▼
                         TLS encryption
                               │
                               ▼
                             TCP/IP
                               │
════════════════════════════════════════════
                     INTERNET
════════════════════════════════════════════
                               │
                               ▼
                             Browser
                               │
                               ▼
                         Render webpage

50. Where Your SSL Installation Fits

Your recent Certbot output:

Certificate is saved at:
/etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem

Key is saved at:
/etc/letsencrypt/live/templates.cresignsys.com/privkey.pem

fits here:

                  Nginx
                    │
                    ▼
               TLS configuration
                │           │
                ▼           ▼
          fullchain.pem   privkey.pem
                │           │
                └─────┬─────┘
                      ▼
                 TLS handshake
                      │
                      ▼
                Secure session
                      │
                      ▼
              Encrypted HTTPS

So the certificate files are part of the server’s TLS configuration.

They don’t independently “run SSL.”

Nginx + its TLS library + Linux networking + certificate/private key + TLS protocol together provide HTTPS.

51. Why Certbot Is Not TLS

Another important distinction:

Let's Encrypt
     ↓
Certificate Authority

and:

Certbot
     ↓
Certificate automation software

and:

Nginx
     ↓
Web server

and:

TLS
     ↓
Security protocol

These are four different things.

52. Their Relationship

Conceptually:

Let's Encrypt
      ↓
issues certificate
      ↓
Certbot obtains/renews it
      ↓
certificate installed/configured
      ↓
Nginx uses certificate
      ↓
TLS handshake
      ↓
HTTPS

This distinction will become extremely important when we study Let’s Encrypt in detail.

53. The Five Technologies You Just Connected

You now have a clear relationship between:

DNS

Name → IP information

IP

Host/network addressing and routing

TCP

Reliable ordered byte stream

TLS

Authentication + confidentiality + integrity

HTTP

Web application protocol

Together:

DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP

54. One Important Exception: HTTP/3

Do not memorize:

HTTPS always means TCP

That is not universally true.

HTTP/3 uses:

HTTP/3
 ↓
QUIC
 ↓
UDP
 ↓
IP

QUIC integrates TLS 1.3 into its connection establishment.

So:

HTTP/1.1 + TLS → commonly TCP
HTTP/2 + TLS   → commonly TCP
HTTP/3         → QUIC over UDP

We will study this later.

For your current foundational model, continue with:

HTTPS
 ↓
TLS
 ↓
TCP

as the traditional HTTPS architecture.

55. Troubleshooting Using Layers

This lesson gives you a powerful diagnostic method.

If the website doesn’t work:

Layer 1 — DNS

Does the domain resolve?

Layer 2 — IP

Is the destination reachable?

Layer 3 — Routing

Can packets reach the server?

Layer 4 — TCP

Is port 443 accepting connections?

Layer 5 — TLS

Does the TLS handshake succeed?

Layer 6 — HTTP

Does Nginx return a valid HTTP response?

Layer 7 — Application

Does WordPress/PHP/MySQL work?

This is the foundation of real-world troubleshooting.

56. Practical Tests

From your server:

sudo ss -lntp | grep ':443'

This checks whether something is listening on TCP 443.

Check Nginx:

sudo systemctl status nginx

Test Nginx configuration:

sudo nginx -t

Test HTTPS locally:

curl -I https://templates.cresignsys.com

For detailed TLS information:

curl -v https://templates.cresignsys.com

These commands are for inspection/testing; they don’t require you to modify the server.

57. What `curl -v` Helps Reveal

A verbose HTTPS request can expose the sequence at a useful level:

DNS resolution
 ↓
TCP connection
 ↓
TLS handshake
 ↓
Certificate information
 ↓
HTTP request
 ↓
HTTP response

So curl -v is an excellent bridge between theory and your actual hosting server.

58. Deep Technology Chain

We can now extend the complete chain:

Physical signals
 ↓
Network interface
 ↓
Ethernet / Wi-Fi
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
FastCGI
 ↓
PHP
 ↓
WordPress
 ↓
MySQL
 ↓
Filesystem
 ↓
Storage

This is essentially the technology stack you are building your hosting knowledge around.

59. The Core Mental Model

Do not memorize hundreds of commands yet.

Understand this:

DOMAIN
  ↓
DNS
  ↓
IP ADDRESS
  ↓
ROUTING
  ↓
PORT
  ↓
TCP
  ↓
TLS
  ↓
HTTP
  ↓
NGINX
  ↓
PHP-FPM
  ↓
WORDPRESS
  ↓
MYSQL
  ↓
FILESYSTEM
  ↓
STORAGE

Once this chain is clear, individual commands become much easier to understand.

Next Lesson — 025

DNS From the Deepest Basics

We will now go backward and study the first step in the journey in much greater depth:

Domain name
 ↓
Hostname
 ↓
DNS
 ↓
DNS hierarchy
 ↓
Root servers
 ↓
TLD servers
 ↓
Authoritative nameservers
 ↓
A record
 ↓
AAAA record
 ↓
CNAME
 ↓
NS
 ↓
MX
 ↓
TXT
 ↓
DNS caching
 ↓
TTL
 ↓
Recursive resolver
 ↓
Your domain
 ↓
templates.cresignsys.com

Then we will examine exactly how your templates.cresignsys.com DNS record points toward your server.

August 13, 2026

CresignSys Learn — Lesson 023
Course: From Basic Science to Web Hosting

Module 05 — Networking Fundamentals

TCP From the Deepest Basics

Difficulty: Beginner → Intermediate
Prerequisites: Lesson 022 — Computer Networking
Estimated time: 40–50 minutes

We now know:
```
Application
   ↓
TLS
   ↓
TCP
   ↓
IP
   ↓
Network
```
Today we will understand TCP itself, starting from the most basic idea.

1. The Problem TCP Solves

Imagine your computer wants to send:
```
HELLO
```
to another computer.

At the simplest level:
```
Computer A
     ↓
   HELLO
     ↓
Computer B
```
But real networks have problems.

Data can be:
```
Lost
Delayed
Duplicated
Received out of order
```
TCP was designed to provide a reliable, ordered byte stream between endpoints.

2. IP Alone Is Not Enough

IP mainly provides packet delivery between hosts/networks.

Imagine sending:
```
Packet 1
Packet 2
Packet 3
```
IP does not by itself provide the complete reliable-stream behavior that applications often need.

You could have:
```
Packet 1 → arrives
Packet 2 → lost
Packet 3 → arrives
```
TCP adds mechanisms to handle such situations.

3. TCP’s Main Responsibilities

TCP provides mechanisms for:
```
Connection establishment
 ↓
Reliable delivery
 ↓
Ordering
 ↓
Retransmission
 ↓
Flow control
 ↓
Congestion control
 ↓
Connection termination
```
4. TCP Is a Transport Protocol

Remember the networking layers:
```
Application
     ↓
Transport
     ↓
Internet
     ↓
Link
```
TCP belongs here:
```
Transport Layer
       ↓
      TCP
```
IP belongs here:
```
Internet Layer
       ↓
       IP
```
5. TCP Does Not Know About Your Website

TCP does not understand:
```
WordPress
HTML
CSS
JavaScript
TLS certificates
Nginx
```
TCP only provides transport behavior.

Conceptually:
```
HTTP/TLS
   ↓
TCP
   ↓
IP
```
TCP doesn’t need to know what the bytes mean.

6. Bytes

TCP provides an ordered stream of bytes.

Suppose an application wants to send:
```
HELLOWORLD
```
TCP sees data as bytes:
```
H E L L O W O R L D
```
It does not fundamentally understand this as words.

7. Byte Stream

This is important.

TCP provides:

Ordered byte stream

not a message-by-message protocol.

For example, an application might write:
```
HELLO
```
then:
```
WORLD
```
The receiving application sees an ordered stream:
```
HELLOWORLD
```
TCP itself does not preserve those application write boundaries.

8. TCP Uses Segments

TCP divides the byte stream into units called:

TCP Segments

Conceptually:
```
Application data
       ↓
TCP
       ↓
┌─────────────┐
│ TCP segment │
└─────────────┘
       ↓
      IP
```
A TCP segment contains:
```
TCP header
+
payload
```
9. TCP Header

A simplified TCP segment looks like:
```
┌──────────────────────────────┐
│ Source Port                  │
│ Destination Port             │
├──────────────────────────────┤
│ Sequence Number              │
├──────────────────────────────┤
│ Acknowledgment Number        │
├──────────────────────────────┤
│ Flags                        │
├──────────────────────────────┤
│ Window                       │
├──────────────────────────────┤
│ Other TCP information        │
├──────────────────────────────┤
│ Application Data             │
└──────────────────────────────┘
```
We will examine each important field.

10. Source Port

The source port identifies the sending application’s transport endpoint.

Example:
```
Source port:
52341
```
The client might use an automatically selected temporary port.

These are often called:

Ephemeral ports

11. Destination Port

The destination port identifies the service on the destination host.

For HTTPS:
```
Destination port = 443
```
So a connection might look conceptually like:
```
Client
192.0.2.20:52341

        ↓

Server
203.0.113.10:443
```
The addresses above are examples, not your actual server addresses.

12. IP + Port

An endpoint can be thought of conceptually as:
```
IP address + transport port
```
For example:
```
203.0.113.10:443
```
means:
```
IP = 203.0.113.10
Port = 443
```
13. What Is a Socket?

A socket is an operating-system networking abstraction used by applications.

A simplified model:
```
Nginx
  ↓
Socket
  ↓
TCP
  ↓
IP
  ↓
Network
```
Nginx can ask Linux to:
```
Create socket
Bind address/port
Listen
Accept connections
Read data
Write data
```
14. Listening

When Nginx is waiting for HTTPS connections, Linux may show something like:
```
0.0.0.0:443
```
in a listening state.

Conceptually:
```
Nginx
 ↓
socket
 ↓
TCP port 443
 ↓
WAITING
```
You can inspect this with:
```
sudo ss -lntp
```
15. What Does LISTEN Mean?

A TCP server socket in:
```
LISTEN
```
state is waiting for incoming connection attempts.

For example:
```
LISTEN 0 511 0.0.0.0:443
```
The exact values vary.

The basic idea is:
```
Internet
   ↓
TCP connection request
   ↓
Port 443
   ↓
Nginx
```
16. The TCP Connection

Before normal TCP data transfer, TCP normally establishes a connection.

This uses:

Three-Way Handshake

The three main messages are:
```
SYN
SYN-ACK
ACK
```
17. SYN

The client sends:
```
SYN
```
SYN means the client is requesting TCP connection establishment and synchronizing sequence-number state.

Conceptually:
```
Client
  │
  │ SYN
  ▼
Server
```
18. SYN-ACK

The server responds:
```
SYN-ACK
```
Conceptually:
```
Client
  │
  │ SYN
  ▼
Server
  │
  │ SYN-ACK
  ▼
Client
```
The server is acknowledging the client’s SYN while also sending its own synchronization information.

19. ACK

The client then sends:
```
ACK
```
So:
```
Client                    Server

 SYN -------------------->

     <------------------- SYN-ACK

 ACK -------------------->

      Connection established
```
20. Why Three Messages?

Both sides need to establish that:
```
Client → Server communication works

Server → Client communication works

Both sides agree on initial sequence-number state
```
This creates the foundation for reliable TCP data transfer.

21. Sequence Numbers

TCP numbers bytes in the stream.

Suppose the initial sequence number is conceptually:
```
1000
```
Then data bytes are associated with positions in the sequence space.

Simplified:
```
Byte 1000
Byte 1001
Byte 1002
Byte 1003
...
```
The real TCP protocol uses sequence numbers with specific rules and randomization considerations; this is only a conceptual illustration.

22. Why Sequence Numbers?

Suppose packets arrive:
```
Segment 1
Segment 3
Segment 2
```
TCP can use sequence numbers to determine:
```
What data arrived?
What is missing?
What order should the bytes have?
```
So:
```
Network order
may differ

TCP stream
must be ordered
```
23. Acknowledgment Numbers

TCP also uses acknowledgment numbers.

Conceptually:
```
Sender
  ↓
Data
  ↓
Receiver
  ↓
ACK
```
The receiver communicates what sequence position it expects next.

For example, conceptually:
```
Received bytes through 5000
       ↓
ACK = 5001
```
Meaning approximately:

I have received everything through byte 5000 and next expect byte 5001.

24. Lost Data

Suppose:
```
Segment 1 → arrives
Segment 2 → lost
Segment 3 → arrives
```
The receiver’s acknowledgments indicate that some expected data has not arrived.

TCP can eventually retransmit the missing data.

Conceptually:
```
Sender
  │
  ├── Segment 1 ───────► Receiver
  │
  ├── Segment 2 ──X
  │
  └── Segment 3 ───────► Receiver
             │
             ↓
        Missing data
             │
             ↓
       Retransmission
```
25. Why Retransmission?

Because IP networks can lose packets.

TCP provides reliability by detecting missing data and retransmitting when appropriate.

This is one reason TCP is useful for applications such as:
```
HTTPS
SSH
Email protocols
Database connections
```
where losing or reordering application bytes silently would be unacceptable.

26. TCP Does Not Make the Physical Network Perfect

This is important.

TCP doesn’t prevent:
```
Packet loss
Delay
Congestion
```
Instead, it reacts to these conditions using protocol mechanisms.

Think:
```
Network problems
      ↓
TCP mechanisms
      ↓
Reliable ordered stream
```
27. Flow Control

Imagine:
```
Sender = very fast
Receiver = slower
```
If the sender sends unlimited data:
```
Sender
 ↓↓↓↓↓↓↓↓↓↓↓
Receiver
```
the receiver could become overwhelmed.

TCP uses:

Receive Window

to help control how much unacknowledged data the receiver is prepared to accept.

28. Receiver Window

Conceptually:
```
Receiver says:

"I currently have room for approximately X bytes."
```
The sender should respect that advertised receive window.

So:
```
Sender
 ↓
Data
 ↓
Receiver
 ↓
Receive capacity
```
29. Congestion Control

Flow control protects the receiver.

But there is another problem:

What if the network itself is overloaded?

This is handled by:

Congestion Control

TCP estimates network conditions and adjusts its sending behavior.

Conceptually:
```
Too much traffic
      ↓
Congestion
      ↓
TCP reduces/adjusts sending
```
When conditions improve, it can increase sending appropriately.

30. Flow Control vs Congestion Control

Remember this distinction:
```
Flow control
 ↓
Protect the receiver

Congestion control
 ↓
Protect/manage the network
```
Both affect how much data can be in flight.

31. What Is RTT?

RTT means:

Round-Trip Time

It is approximately the time for a packet/message to travel to the other endpoint and for a response/acknowledgment to return.

Conceptually:
```
Client
  │
  │──────────►
  │
  │◄──────────
  │
  Server

     RTT
```
32. Why RTT Matters

Suppose:
```
RTT = 20 ms
```
versus:
```
RTT = 200 ms
```
The second connection has significantly greater network delay.

This can affect interactive applications and TCP performance, especially when data transfer depends on acknowledgments and congestion-control behavior.

33. TCP Connection States

A TCP connection moves through states.

Examples include:
```
LISTEN
SYN-SENT
SYN-RECEIVED
ESTABLISHED
FIN-WAIT
CLOSE-WAIT
TIME-WAIT
CLOSED
```
You don’t need to memorize all of them yet.

The most important now:
```
LISTEN
   ↓
SYN
   ↓
SYN-RECEIVED
   ↓
ESTABLISHED
```
34. ESTABLISHED

When a connection is established:
```
ESTABLISHED
```
means the TCP connection is active and can carry application data.

For HTTPS:
```
TCP ESTABLISHED
       ↓
TLS handshake
       ↓
Encrypted HTTPS data
```
35. TCP Is Before TLS

This connects directly to your earlier TLS lessons.

For traditional HTTPS over TCP:
```
1. DNS
2. IP routing
3. TCP handshake
4. TLS handshake
5. HTTP exchange
```
This ordering is fundamental.

36. Your Website Example

You enter:
```
https://templates.cresignsys.com
```
The conceptual sequence is:
```
Browser
   ↓
DNS lookup
   ↓
Server IP
   ↓
TCP connection to port 443
   ↓
TCP handshake
   ↓
TLS handshake
   ↓
HTTPS request
   ↓
Nginx
```
37. Step 1 — DNS

The browser needs an IP address.

Conceptually:
```
templates.cresignsys.com
          ↓
         DNS
          ↓
      IP address
```
We will study the exact DNS process later.

38. Step 2 — TCP Destination

The browser now knows the server IP.

It wants:
```
Server IP
Port 443
```
So conceptually:
```
Client
192.0.2.20:ephemeral-port

        ↓ TCP

Server
203.0.113.10:443
```
39. Step 3 — SYN

The browser’s operating system sends a TCP SYN:
```
Client
   │
   │ SYN
   │
   ▼
Server:443
```
40. Step 4 — SYN-ACK

The server’s TCP stack responds:
```
Client
   │
   │ SYN
   ▼
Server
   │
   │ SYN-ACK
   ▼
Client
```
41. Step 5 — ACK

The client responds:
```
Client
   │
   │ ACK
   ▼
Server
```
Now:
```
TCP = ESTABLISHED
```
42. But the Browser Still Hasn’t Sent HTTP Yet

This is a very important point.

For HTTPS, TCP establishment is not the end.

Now TLS begins:
```
TCP established
      ↓
TLS handshake
      ↓
Secure encrypted channel
```
43. TLS Uses TCP

For the traditional HTTPS architecture:
```
HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP
```
TLS uses the reliable byte stream provided by TCP.

44. TLS Handshake

The browser and server negotiate things such as:
```
TLS version
Cryptographic algorithms
Server identity
Keys
```
Your certificate:
```
templates.cresignsys.com
```
is involved in authenticating the server during this process.

45. Then HTTP

After the TLS handshake establishes the secure session:
```
Browser
 ↓
Encrypted HTTP request
 ↓
TLS
 ↓
TCP
 ↓
IP
 ↓
Nginx
```
Nginx receives the request after the lower networking layers process it.

46. Nginx Does Not Receive “Raw Internet”

The complete path is:
```
Network hardware
 ↓
Linux network driver
 ↓
Linux IP stack
 ↓
TCP stack
 ↓
Socket
 ↓
Nginx
```
Nginx works through the operating system’s networking APIs.

47. Nginx’s Listening Socket

Conceptually:
```
Nginx
 ↓
socket()
 ↓
bind()
 ↓
listen()
 ↓
accept()
```
These are operating-system networking interfaces/system calls.

The exact implementation involves Linux’s socket APIs and kernel networking stack.

48. bind()

Conceptually, Nginx associates a socket with an address/port.

For example:
```
0.0.0.0:443
```
means:
```
HTTPS
 ↓
TCP port 443
 ↓
Nginx
```
49. listen()

Nginx tells Linux:

This socket should accept incoming TCP connections.

Conceptually:
```
socket
 ↓
bind
 ↓
listen
```
50. accept()

When a client connection is ready, the application can accept it.

Conceptually:
```
Incoming connection
       ↓
listen socket
       ↓
accept()
       ↓
connected socket
       ↓
Nginx handles request
```
This is a very important distinction:
```
Listening socket
```
and:
```
Connected socket
```
are not the same thing.

51. One Nginx Server, Many Connections

Imagine:
```
Client A ───────►
Client B ───────► Nginx
Client C ───────►
Client D ───────►
```
Each connection has its own transport state.

Conceptually:
```
Nginx
 ├── TCP connection A
 ├── TCP connection B
 ├── TCP connection C
 └── TCP connection D
```
This is how one web server can handle many clients.

52. TCP Four-Tuple

A TCP connection can be identified by a combination of:
```
Source IP
Source port
Destination IP
Destination port
```
For example:
```
Client:
192.0.2.20:53001

Server:
203.0.113.10:443
```
Together these values identify a connection endpoint pair.

This is commonly called the TCP four-tuple.

53. Why Can Thousands of Clients Use Port 443?

Because clients use different source ports and/or source IPs.

For example:
```
Client A → 192.0.2.20:50001 → Server:443

Client B → 192.0.2.21:50002 → Server:443

Client C → 192.0.2.22:50003 → Server:443
```
The server can distinguish the connections.

54. TCP Doesn’t Mean “One Request = One Connection”

Modern HTTP behavior can reuse connections.

For example:
```
TCP connection
      ↓
TLS session
      ↓
HTTP request 1
HTTP response 1
HTTP request 2
HTTP response 2
...
```
This reduces connection-establishment overhead.

HTTP/2 goes further by multiplexing multiple streams over a single connection.

55. TCP Connection Termination

A TCP connection also needs to close cleanly.

A simplified model:
```
Client                    Server

 FIN -------------------->

      <----------------- ACK

      <----------------- FIN

 ACK -------------------->

       Connection closed
```
This is more complicated internally because each direction of a TCP connection can be closed independently.

56. FIN

FIN indicates that a side has finished sending data in that direction.

It does not necessarily mean the entire connection instantly disappears.

57. RST

TCP also has:

RST — Reset

A reset can abruptly terminate/reset a connection in situations where a normal graceful shutdown isn’t appropriate.

For example:
```
No listener
Invalid connection state
Application/network reset
```
The exact reason depends on context.

58. TIME-WAIT

You may eventually see connections in:
```
TIME-WAIT
```
This is a normal TCP state used after connection termination to help prevent delayed old segments from interfering with later connections and to ensure certain protocol requirements are satisfied.

So:
```
TIME-WAIT
```
doesn’t automatically mean something is broken.

59. Inspect TCP on Your Server

Run:
```
sudo ss -tan
```
You may see:
```
State
ESTAB
LISTEN
TIME-WAIT
```
This gives you a practical view of TCP.

60. See Listening TCP Ports

Use:
```
sudo ss -lntp
```
Meaning approximately:
```
-l = listening
-n = numeric
-t = TCP
-p = process information
```
You might find:
```
:22
:80
:443
```
depending on your configuration.

61. See HTTPS Connections

Use:
```
sudo ss -tnp '( sport = :443 )'
```
This can show TCP connections associated with port 443, depending on your ss version/filter syntax.

62. Test Port 443

From a machine with network access to the server, a tool such as:
```
nc -vz templates.cresignsys.com 443
```
can test whether a TCP connection to port 443 can be established.

This tests network connectivity to the port; it does not prove that TLS or HTTP is working correctly.

63. Important Troubleshooting Layers

Suppose:
```
https://templates.cresignsys.com
```
doesn’t open.

Do not immediately blame TLS.

Check the layers:
```
DNS
 ↓
IP
 ↓
Routing
 ↓
Firewall/security rules
 ↓
TCP port 443
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
PHP
 ↓
WordPress
```
This layered approach is fundamental to server troubleshooting.

64. Example: Port 443 Closed

Suppose:
```
DNS works
```
but:
```
TCP 443 connection fails
```
Then TLS cannot even begin.

Because:
```
TCP
 ↓
must exist first
 ↓
TLS
```
So troubleshooting TLS at this stage would be premature.

65. Example: TCP Works, TLS Fails

Suppose:
```
TCP 443
   ↓
works
```
but:
```
TLS handshake
   ↓
fails
```
Then investigate:
```
Certificate
Private key
TLS configuration
Server name
Supported protocols
Cipher configuration
Certificate chain
```
This is where your recent Let’s Encrypt installation becomes relevant.

66. Example: TLS Works, HTTP Fails

Suppose:
```
TCP
 ↓
works

TLS
 ↓
works

HTTP
 ↓
502
```
Then the problem is probably above TLS:
```
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
```
Again:

Find the lowest failing layer.

67. The Complete Architecture

You can now understand this:
```
                         USER
                           │
                           ▼
                        BROWSER
                           │
                           ▼
                         DNS
                           │
                           ▼
                      SERVER IP
                           │
                           ▼
                         ROUTING
                           │
                           ▼
                          IP
                           │
                           ▼
                         TCP
                           │
                     port 443
                           │
                           ▼
                          TLS
                           │
                           ▼
                         HTTPS
                           │
                           ▼
                         NGINX
                           │
                     ┌─────┴─────┐
                     ▼           ▼
                  Static       PHP-FPM
                                │
                                ▼
                             WordPress
                                │
                                ▼
                              MySQL
```
68. The Deepest Chain So Far

Your learning journey now looks like:
```
Matter
 ↓
Atoms
 ↓
Electrons
 ↓
Electricity
 ↓
Semiconductors
 ↓
Transistors
 ↓
Logic gates
 ↓
Binary
 ↓
CPU
 ↓
Memory
 ↓
Storage
 ↓
Operating system
 ↓
Linux kernel
 ↓
Processes
 ↓
Users
 ↓
Permissions
 ↓
Sockets
 ↓
Networking
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
PHP
 ↓
WordPress
 ↓
Web hosting
```
You are now only a few layers away from connecting the complete theory to your actual templates.cresignsys.com server.

69. Quick Check

What does TCP provide?

A reliable, ordered byte stream with mechanisms for retransmission, flow control, congestion control, and connection management.

What is a port?

A transport-layer identifier used to identify an application endpoint on a host.

What is a socket?

An OS networking abstraction used by applications to communicate.

What is SYN?

A TCP flag used during connection establishment to synchronize sequence-number state.

What is SYN-ACK?

The server’s response acknowledging the client’s SYN while synchronizing its own sequence-number state.

What is ACK?

An acknowledgment mechanism used by TCP.

What is ESTABLISHED?

A TCP state representing an active connection.

What is LISTEN?

A server socket state waiting for incoming connections.

What comes first: TCP or TLS?

For traditional HTTPS over TCP:
```
TCP
 ↓
TLS
```
What comes before TCP?

Usually:
```
IP
```
and below IP:
```
Link layer
```
Next Lesson — 024

TCP → TLS → HTTPS: One Real Connection

We will now combine the last three major subjects:
```
DNS
 ↓
IP
 ↓
TCP 3-Way Handshake
 ↓
TLS Handshake
 ↓
Certificate
 ↓
Public Key
 ↓
Private Key
 ↓
Session Keys
 ↓
Encrypted HTTP
 ↓
Nginx
```
We will trace one actual HTTPS request to templates.cresignsys.com packet-by-packet conceptually, including exactly where the Let’s Encrypt certificate you installed enters the process.
August 13, 2026
CresignSys Learn — Lesson 022
Course: From Basic Science to Web Hosting

Module 05 — Networking Fundamentals

What Is a Computer Network?

Difficulty: Beginner → Intermediate
Prerequisites: Lesson 021 — Linux Storage
Estimated time: 40–50 minutes

We now move from:
```
INSIDE THE SERVER
CPU
 ↓
RAM
 ↓
Storage
 ↓
Processes
 ↓
Linux
```
to:
```
OUTSIDE THE SERVER
Network
 ↓
Internet
 ↓
Other computers
```
This is the beginning of understanding how:
```
https://templates.cresignsys.com
```
actually reaches your server.

1. The Most Basic Definition

A network is a system that allows devices to exchange data.

For example:
```
Computer A
    │
    │ data
    ↓
Computer B
```
A larger network:
```
Computer
   ↓
Switch
   ↓
Router
   ↓
Internet
   ↓
Server
```
2. Why Do We Need Networking?

Your server may be physically located somewhere else.

Your browser may be on your computer.

You need a communication system connecting them:
```
Your computer
      ↓
     LAN
      ↓
   Router
      ↓
   Internet
      ↓
Cloud network
      ↓
Your VPS
```
3. Data Is Just Bits

At the deepest level, computers exchange:
```
0
1
```
For example:
```
10110100
```
But networking doesn’t simply send one enormous stream of random bits.

It organizes data into structured units.

4. Network Data Has Layers

A useful simplified model is:
```
Application
     ↓
Transport
     ↓
Internet
     ↓
Link
     ↓
Physical
```
For example, when loading a website:
```
HTTP
 ↓
TCP
 ↓
IP
 ↓
Ethernet/Wi-Fi
 ↓
Electrical/radio signals
```
For HTTPS:
```
HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP
 ↓
Ethernet/Wi-Fi
```
And HTTP/3 uses a different transport architecture:
```
HTTP/3
 ↓
QUIC
 ↓
UDP
 ↓
IP
 ↓
Link
```
5. Why Layers?

Imagine one giant networking program had to understand:
```
Browser
TLS
TCP
IP
Ethernet
Wi-Fi
Fiber
Radio
```
It would become extremely complicated.

Instead, networking uses layers.

Each layer has a particular responsibility.

6. Application Layer

At the top are application protocols.

Examples:
```
HTTP
HTTPS
DNS
SSH
SMTP
IMAP
```
For your website:
```
Browser
 ↓
HTTPS
```
7. Transport Layer

The transport layer provides communication between applications/processes.

Important protocols include:
```
TCP
UDP
```
Later we’ll study them deeply.

8. Internet Layer

The Internet Protocol:
```
IP
```
provides addressing and packet delivery between networks.

Common versions:
```
IPv4
IPv6
```
9. Link Layer

This deals with communication over a particular local network technology.

Examples:
```
Ethernet
Wi-Fi
```
It includes concepts such as:
```
MAC addresses
Frames
Switching
```
10. Physical Layer

At the physical level, data becomes physical signals.

Depending on the technology:
```
Copper
 ↓
Electrical signals

Fiber
 ↓
Light

Wi-Fi
 ↓
Radio waves
```
So the complete concept is:
```
Bits
 ↓
Signals
 ↓
Network hardware
 ↓
Other network hardware
 ↓
Bits
```
11. The Network Interface

Your Ubuntu server needs a network interface.

You can inspect interfaces with:
```
ip link
```
You may see something like:
```
lo
ens3
```
The exact interface name depends on the system.

12. lo — Loopback

You will often see:
```
lo
```
This is the:

Loopback Interface

It allows a computer to communicate with itself.

Its common IPv4 address is:
```
127.0.0.1
```
13. What Is 127.0.0.1?

Suppose Nginx is listening locally.

You could access:
```
http://127.0.0.1
```
from the server itself.

The path is essentially:
```
Application
 ↓
loopback
 ↓
Linux network stack
 ↓
another local application
```
The traffic does not need to leave the machine through the physical network.

14. localhost

The hostname:
```
localhost
```
usually refers to the local system.

It commonly resolves to loopback addresses such as:
```
127.0.0.1
```
and/or:
```
::1
```
depending on configuration.

15. Network Interface Example

Your server might have an interface such as:
```
ens3
```
This represents a network interface exposed to the operating system.

Conceptually:
```
Linux
 ↓
ens3
 ↓
Virtual network
 ↓
Cloud network
 ↓
Internet
```
16. MAC Address

Network interfaces commonly have a:

MAC Address

MAC means:

Media Access Control

A MAC address is a link-layer identifier associated with a network interface.

Example format:
```
02:42:ac:11:00:02
```
The actual address on your server will be different.

17. MAC vs IP

These are different concepts.

MAC

Primarily used at the local link layer.

IP

Used for logical network addressing and routing between networks.

Simplified:
```
MAC
 ↓
Local network delivery

IP
 ↓
Network-to-network delivery
```
18. IPv4 Address

An IPv4 address looks like:
```
192.168.1.10
```
It contains four decimal numbers called octets.

Each ranges from:
```
0–255
```
because IPv4 uses:
```
32 bits
```
19. Binary Representation

For example:
```
192
```
in binary is:
```
11000000
```
So:
```
192.168.1.10
```
is ultimately:
```
11000000.10101000.00000001.00001010
```
This connects networking back to binary computing.

20. Private IP Addresses

Some IPv4 ranges are designated for private networks.

Common ranges include:
```
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
```
For example:
```
192.168.1.20
```
is typically a private IPv4 address.

It is not directly routable across the public Internet.

21. Public IP Address

A public IP address can be used for Internet routing, subject to network/provider configuration.

A VPS commonly has an Internet-reachable public IP or an external network path involving NAT/load balancing.

Conceptually:
```
Internet
   ↓
Public IP
   ↓
Cloud networking
   ↓
VPS
```
22. Your Domain Does Not Equal Your IP

This is extremely important.

You have:
```
templates.cresignsys.com
```
and your server has an IP address.

These are not the same thing.

DNS connects them.

Conceptually:
```
Domain name
      ↓
DNS
      ↓
IP address
```
23. What Is DNS?

DNS means:

Domain Name System

Its basic purpose is to translate names into network information.

For example:
```
templates.cresignsys.com
        ↓
DNS
        ↓
IP address
```
This allows humans to use names instead of memorizing IP addresses.

24. Why Not Just Use the IP?

You could theoretically visit:
```
https://203.0.113.10
```
instead of:
```
https://templates.cresignsys.com
```
But domain names provide:
```
Human-readable identity
Flexible infrastructure
Multiple services
Virtual hosting
TLS certificate identity
```
25. DNS Is Not the Internet

DNS is a naming system.

It does not carry your entire website.

Think:
```
DNS
 ↓
"What IP address belongs to this name?"
```
Then:
```
IP
 ↓
"Where should the network packets go?"
```
Then:
```
TCP/TLS/HTTP
 ↓
"What communication should happen?"
```
26. Subnet

An IP address normally needs to be interpreted together with a:

Subnet prefix

For example:
```
192.168.1.10/24
```
The /24 means the first 24 bits form the network prefix.

27. What Does /24 Mean?

IPv4 has:
```
32 bits
```
So:
```
/24
```
means:
```
24 bits = network prefix
8 bits  = remaining host portion
```
Conceptually:
```
11111111.11111111.11111111.00000000
```
This corresponds to:
```
255.255.255.0
```
for a conventional IPv4 subnet mask representation.

28. Why Subnets?

Subnets divide networks into logical groups.

For example:
```
Network
 ↓
Subnet A
 ├── Computer 1
 ├── Computer 2
 └── Computer 3

Subnet B
 ├── Server 1
 └── Server 2
```
This helps with:
```
Routing
Address management
Security
Network organization
```
29. Default Gateway

Suppose your server wants to communicate with a destination outside its local subnet.

It normally sends the traffic toward a:

Default Gateway

Conceptually:
```
Server
 ↓
Default Gateway
 ↓
Other network
 ↓
Internet
```
30. Local vs Remote Destination

Suppose:
```
Server:
192.168.1.10/24
```
and wants:
```
192.168.1.20
```
The destination may be on the same local subnet.

But:
```
8.8.8.8
```
is outside that subnet.

So traffic goes toward the configured gateway.

31. Routing

Routing answers:

Where should this packet go next?

Conceptually:
```
Source
 ↓
Router
 ↓
Router
 ↓
Router
 ↓
Destination
```
Each router makes a forwarding decision based on its routing information.

32. Linux Has a Routing Table

You can inspect it with:
```
ip route
```
You may see something like:
```
default via 10.0.0.1 dev ens3
10.0.0.0/24 dev ens3 proto kernel scope link src 10.0.0.10
```
The exact output on your VPS will be different.

33. Understanding default

A route such as:
```
default via 10.0.0.1
```
means roughly:

For destinations that don’t match a more specific route, send traffic toward this gateway.

34. The Network Interface Has an IP

Use:
```
ip addr
```
You might see:
```
inet 10.0.0.10/24
```
This tells Linux:
```
IP address = 10.0.0.10
Prefix = /24
Interface = ens3
```
35. The Basic Linux Networking Commands

Start learning these:
```
ip link
```
Shows network interfaces.
```
ip addr
```
Shows IP addresses.
```
ip route
```
Shows routes.
```
ping
```
Tests IP reachability using ICMP, where permitted.
```
ss
```
Shows sockets and listening connections.

36. What Is a Packet?

When data travels across an IP network, it is typically divided into packets.

Conceptually:
```
Large data
   ↓
Packets
 ├── Packet 1
 ├── Packet 2
 ├── Packet 3
 └── ...
```
Each packet contains control information and payload.

37. IP Packet

An IP packet contains information such as:
```
Source IP
Destination IP
Protocol
Payload
```
Conceptually:
```
┌────────────────────────────┐
│ IP Header                  │
│                            │
│ Source                     │
│ Destination                │
│ Protocol                   │
├────────────────────────────┤
│ Payload                    │
└────────────────────────────┘
```
38. Ethernet Frame

At the local-link level, the packet is carried inside a frame.

Conceptually:
```
Ethernet Frame
 ├── MAC destination
 ├── MAC source
 ├── payload
 └── error-detection information
```
So:
```
Application data
 ↓
Transport segment/datagram
 ↓
IP packet
 ↓
Link-layer frame
 ↓
Physical signals
```
39. This Is Encapsulation

This is a major networking concept.

Suppose your browser sends HTTPS data.

Conceptually:
```
HTTP data
 ↓
TLS
 ↓
TCP
 ↓
IP
 ↓
Ethernet
 ↓
Electrical/radio/optical signals
```
Each layer adds its own control information.

This is called:

Encapsulation

40. At the Destination

The reverse happens.
```
Physical signal
 ↓
Ethernet
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Application
```
This is often called:

Decapsulation

41. Your Website Request

Now let’s connect everything to:
```
https://templates.cresignsys.com
```
The browser first needs to discover the server’s IP address.

So:
```
Browser
 ↓
DNS
 ↓
IP address
```
Then:
```
Browser
 ↓
IP network
 ↓
Server
```
Then:
```
TCP
 ↓
TLS
 ↓
HTTP
```
Then:
```
Nginx
```
42. Full Website Journey
```
You type:

https://templates.cresignsys.com
              │
              ▼
           Browser
              │
              ▼
             DNS
              │
              ▼
         Server IP
              │
              ▼
          IP routing
              │
              ▼
             TCP
              │
              ▼
             TLS
              │
              ▼
            HTTPS
              │
              ▼
            Nginx
              │
       ┌──────┴──────┐
       ▼             ▼
   Static file     PHP-FPM
                     │
                     ▼
                  WordPress
                     │
                     ▼
                   MySQL
```
You have now reached the boundary between Linux administration and web hosting.

43. Network Interface to Internet

The physical/virtual path can be visualized as:
```
Application
 ↓
Linux socket
 ↓
TCP
 ↓
IP
 ↓
Network interface
 ↓
Cloud virtual network
 ↓
Internet gateway/router
 ↓
Internet
 ↓
Other routers
 ↓
Destination network
 ↓
Server
```
44. What Is a Socket?

A socket is an operating-system interface through which applications communicate over networks.

Conceptually:
```
Application
 ↓
Socket
 ↓
TCP/UDP
 ↓
IP
```
For example, Nginx creates listening sockets.

45. Port

An IP address identifies a network endpoint at the host level.

A:

Port

helps identify the application/service endpoint.

For example:
```
HTTP  → 80
HTTPS → 443
SSH   → 22
```
These are conventional/default ports.

46. IP + Port

You can think of:
```
IP address + port
```
as identifying a network endpoint.

For example:
```
203.0.113.10:443
```
means:
```
IP = 203.0.113.10
Port = 443
```
This is not the actual IP of your server; it is an illustrative example.

47. Why Does Nginx Listen on 443?

Your SSL/TLS-enabled Nginx configuration commonly contains a listener conceptually equivalent to:
```
listen 443 ssl;
```
That means:
```
Incoming TCP connection
       ↓
Port 443
       ↓
Nginx
       ↓
TLS
```
48. What About Port 80?

HTTP traditionally uses:
```
80
```
HTTPS traditionally uses:
```
443
```
A common configuration is:
```
HTTP :80
   ↓
redirect
   ↓
HTTPS :443
```
For example:
```
http://templates.cresignsys.com
              ↓
      HTTPS redirect
              ↓
https://templates.cresignsys.com
```
49. Listening Ports

You can see listening sockets with:
```
sudo ss -lntup
```
You may see entries such as:
```
LISTEN
0.0.0.0:80
0.0.0.0:443
0.0.0.0:22
```
The exact output depends on your server.

50. What Does 0.0.0.0 Mean?

When used as a listening address:
```
0.0.0.0:443
```
generally means:

Listen on all available IPv4 interfaces.

It does not mean that 0.0.0.0 is the server’s actual public IP.

51. IPv6

Modern networking also uses:

IPv6

IPv6 addresses are 128 bits.

Example:
```
2001:db8::1
```
This is an example/documentation address.

IPv6 solves the address-space limitations of IPv4 and introduces additional architectural features.

52. IPv4 vs IPv6
```
IPv4
 ↓
32-bit address

IPv6
 ↓
128-bit address
```
Examples:
```
IPv4:
192.168.1.10

IPv6:
2001:db8::10
```
53. The Next Important Layer: TCP

We have now reached the transport layer.

For your traditional HTTPS connection:
```
HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP
```
TCP answers a different question from IP.

IP

Which host/network should this packet reach?

TCP

How do two application endpoints establish and maintain a reliable byte stream?

54. Why TCP?

TCP provides mechanisms for:
```
Connection establishment
Reliable delivery
Ordering
Retransmission
Flow control
Congestion control
```
It does not simply mean “the Internet is reliable.” TCP implements reliability mechanisms between endpoints.

55. TCP Connection

A simplified TCP connection begins with a:

Three-Way Handshake

Conceptually:
```
Client                    Server

  SYN  -------------------->

       <------------------- SYN-ACK

  ACK  -------------------->

        Connection ready
```
This is one of the most important things we will study next.

56. Where TLS Comes In

After TCP establishes the connection for a traditional HTTPS connection:
```
TCP connection
      ↓
TLS handshake
      ↓
Encrypted application data
```
So your earlier SSL/TLS lessons now fit into the networking architecture:
```
DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
```
57. The Complete Learning Map

You have now covered:
```
1. Hardware
   ↓
2. CPU
   ↓
3. RAM
   ↓
4. Storage
   ↓
5. Linux
   ↓
6. Filesystem
   ↓
7. Users
   ↓
8. Permissions
   ↓
9. Processes
   ↓
10. Services
   ↓
11. Networking
```
Next:
```
12. Ethernet
13. IP
14. Routing
15. TCP
16. UDP
17. Ports
18. Sockets
19. DNS
20. HTTP
21. TLS
22. Nginx
23. PHP-FPM
24. MySQL
25. WordPress
26. Web hosting
```
58. Practical Exercise

On your Ubuntu server, run these read-only commands:
```
ip link
```
Then:
```
ip addr
```
Then:
```
ip route
```
Then:
```
sudo ss -lntup
```
Then:
```
ping -c 4 127.0.0.1
```
These five commands begin to reveal:
```
Network interfaces
      ↓
IP addresses
      ↓
Routes
      ↓
Listening services
      ↓
Local network-stack connectivity
```
Do not change anything yet. The goal is observation.

Next Lesson — 023

TCP From the Deepest Basics

We will start from the physical meaning of communication and build upward:
```
Bits
 ↓
Bytes
 ↓
Frames
 ↓
Packets
 ↓
Ports
 ↓
Sockets
 ↓
TCP
 ↓
SYN
 ↓
SYN-ACK
 ↓
ACK
 ↓
TCP connection
 ↓
Data
 ↓
ACKs
 ↓
Retransmission
 ↓
Connection termination
```
Then we will trace what happens when your browser connects to:
```
templates.cresignsys.com:443
```
from the first network packet all the way to Nginx.
August 13, 2026
CresignSys Learn — Lesson 021
Course: From Basic Science to Web Hosting

Module 04 — Linux Fundamentals

How Linux Uses Storage

Difficulty: Beginner → Intermediate
Prerequisites: Lesson 020 — Linux Memory
Estimated time: 40 minutes

We now understand:
```
CPU
 ↓
RAM
 ↓
Processes
```
But your WordPress files must survive a reboot.

That requires:

Persistent Storage

1. The Basic Storage Chain

A simplified path is:
```
Website
 ↓
File
 ↓
Filesystem
 ↓
Mount point
 ↓
Storage device
 ↓
SSD / virtual disk
```
For your server:
```
WordPress
 ↓
/storage/websites/
 ↓
Filesystem
 ↓
Mounted storage
 ↓
Virtual disk / physical storage
```
2. RAM vs Storage

Remember:
```
RAM
= temporary working memory
```
while:
```
Storage
= persistent data
```
Example:
```
WordPress files
       ↓
Storage

Running WordPress
       ↓
RAM
```
3. Why Storage Is Needed

Suppose you install WordPress.

You have files such as:
```
wp-admin/
wp-content/
wp-includes/
index.php
wp-config.php
```
If these existed only in RAM:
```
Power off
 ↓
RAM contents disappear
 ↓
WordPress disappears
```
Instead:
```
WordPress files
 ↓
SSD
 ↓
Power off
 ↓
Files remain
```
4. What Is a Storage Device?

At the hardware level, a computer may have:
```
HDD
SSD
NVMe SSD
Flash storage
```
A cloud VPS normally exposes a virtual block storage device to the guest operating system, backed by the provider’s physical infrastructure.

So your Ubuntu VM may see something like:
```
/dev/sda
```
or:
```
/dev/vda
```
or:
```
/dev/nvme0n1
```
The exact device name depends on the virtualization/cloud platform.

5. What Is /dev?

We learned previously:
```
/dev
```
is a special filesystem containing device interfaces.

Storage devices can appear there.

For example:
```
/dev/sda
```
could represent an entire disk.

And:
```
/dev/sda1
```
could represent a partition on that disk.

6. Disk vs Partition

Imagine a disk:
```
┌──────────────────────────────┐
│          DISK                │
│                              │
│ ┌──────────┐ ┌─────────────┐ │
│ │Partition1│ │ Partition 2 │ │
│ └──────────┘ └─────────────┘ │
└──────────────────────────────┘
```
A partition is a defined region of a disk.

For example:
```
/dev/sda
```
might be the disk.
```
/dev/sda1
```
might be its first partition.

7. Why Partition?

Partitions allow a disk to be divided into separate logical regions.

For example:
```
Disk
 ├── EFI partition
 ├── Root partition
 └── Data partition
```
Modern systems can use different partitioning schemes and layouts.

8. GPT

A common modern partitioning scheme is:

GPT

GUID Partition Table.

It is commonly used with UEFI systems and supports large disks and many partitions.

Conceptually:
```
Disk
 ↓
GPT partition table
 ↓
Partitions
```
9. Filesystem

A partition or block device is not automatically a directory tree.

You normally create a:

Filesystem

on a storage device or partition.

Common Linux filesystems include:
```
ext4
XFS
Btrfs
```
Ubuntu commonly uses:
```
ext4
```
in many installations, though other filesystems are possible.

10. Filesystem’s Job

A filesystem organizes raw storage into structures that Linux can use as:
```
Files
Directories
Metadata
Permissions
Timestamps
```
Conceptually:
```
Raw storage
 ↓
Filesystem
 ↓
Files/directories
```
11. Raw Block Storage

A disk fundamentally provides blocks of storage.

Conceptually:
```
Block
Block
Block
Block
Block
...
```
The filesystem turns this low-level storage into a structured hierarchy.
```
Blocks
 ↓
Filesystem structures
 ↓
Files
 ↓
Directories
```
12. What Is ext4?

ext4 is a Linux filesystem.

It manages things such as:
```
Files
Directories
Inodes
Blocks
Metadata
Free space
Journaling
```
We will study these individually.

13. What Is a Mount?

This is one of the most important Linux concepts.

Suppose you have:
```
/dev/sdb1
```
containing an ext4 filesystem.

Linux can attach it to:
```
/storage
```
This is called:

Mounting

Conceptually:
```
/dev/sdb1
     ↓
  ext4 filesystem
     ↓
   mount
     ↓
/storage
```
14. Why Is Mounting Needed?

Linux uses a single unified filesystem hierarchy.

You don’t normally access storage as:
```
C:
D:
E:
```
as in traditional Windows drive-letter notation.

Instead:
```
/
├── etc
├── var
├── home
└── storage
```
A separate filesystem can be mounted into this tree.

15. Example

Suppose:
```
/dev/sdb1
```
is mounted at:
```
/storage
```
Then:
```
/storage/websites/
```
is actually stored on the filesystem provided by /dev/sdb1.

Conceptually:
```
/dev/sdb1
     ↓
   mount
     ↓
/storage
     ↓
/storage/websites
```
16. Your /storage Directory

Your hosting architecture uses:
```
/storage/websites/
```
There are two possibilities:

Case A

/storage is simply a directory inside your root filesystem.

Case B

/storage is a separate filesystem mounted there.

These are very different at the storage level.

17. How Do We Find Out?

Use:
```
df -h
```
You might see:
```
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        80G   30G   46G  40% /
```
Or you might see a separate entry:
```
/dev/sdb1       200G   50G  150G  25% /storage
```
Then you know /storage is a separate mounted filesystem.

18. df

df means:

Disk Free

Use:
```
df -h
```
It shows filesystem capacity and usage.

Important columns:
```
Filesystem
Size
Used
Avail
Use%
Mounted on
```
19. df -h /storage

You can directly check the filesystem containing /storage:
```
df -h /storage
```
This is useful because the directory itself doesn’t tell you which device backs it.

20. lsblk

Another important command:
```
lsblk
```
This displays block devices and their relationships.

Example:
```
sda
├─sda1
└─sda2
```
A more useful version:
```
lsblk -f
```
It can show:
```
NAME
FSTYPE
LABEL
UUID
MOUNTPOINTS
```
21. Block Device

A block device is a device that provides storage in addressable blocks.

Examples:
```
SSD
HDD
Virtual disk
```
Linux exposes these through device nodes such as:
```
/dev/sda
/dev/nvme0n1
```
22. NVMe

Modern SSDs often use NVMe.

You may see:
```
/dev/nvme0n1
```
and partitions:
```
/dev/nvme0n1p1
/dev/nvme0n1p2
```
The naming differs from traditional SCSI-style names such as /dev/sda1.

23. Cloud VPS Storage

Your server is running as a virtual machine.

Therefore:
```
Your VM
 ↓
Virtual block device
 ↓
Cloud infrastructure
 ↓
Physical storage
```
You normally interact with the virtual device, not directly with the provider’s physical SSD.

24. Storage Abstraction

This is another important computer-science concept.

You see:
```
/storage/websites/
```
but underneath:
```
Directory
 ↓
Filesystem
 ↓
Block device
 ↓
Virtualization
 ↓
Cloud storage infrastructure
 ↓
Physical hardware
```
Each layer hides details from the layer above it.

25. Inodes

A filesystem needs to keep metadata about files.

One important structure is an:

Inode

An inode can contain information such as:
```
File type
Permissions
Owner
Group
Timestamps
File size
Pointers/references to file data
```
The exact internal structure depends on the filesystem.

26. Filename vs Inode

A useful conceptual distinction:
```
Filename
   ↓
Directory entry
   ↓
Inode
   ↓
File data
```
The filename is not the complete identity of the file’s underlying filesystem metadata.

This explains several Linux filesystem behaviors.

27. Hard Links

A hard link allows multiple directory entries to refer to the same inode.

Conceptually:
```
fileA
   \
    → inode → data
   /
fileB
```
Therefore:
```
fileA
```
and:
```
fileB
```
can refer to the same underlying file data.

This is a deeper filesystem concept.

28. Symbolic Links

A symbolic link is different.

It contains a path reference to another file/directory.

Example:
```
link
 ↓
/some/other/path
```
You can create one with:
```
ln -s /source /destination
```
29. Why Symlinks Matter for Nginx

Linux server configurations often use symbolic links.

For example, Nginx commonly uses:
```
/etc/nginx/sites-available/
```
and:
```
/etc/nginx/sites-enabled/
```
A site configuration can be stored in one location and linked into the enabled directory.

Conceptually:
```
sites-available
       ↓
configuration file
       ↑
       │ symlink
       │
sites-enabled
       ↓
Nginx loads enabled configuration
```
Your:
```
/etc/nginx/sites-enabled/templates.cresignsys.com
```
is part of this style of configuration organization.

30. File Size vs Disk Usage

These are not always identical concepts.

A file may have:
```
Logical size
```
and:
```
Actual allocated blocks
```
Sparse files are one example where these can differ significantly.

For ordinary beginner use, ls -lh shows the logical file size, while du shows disk usage.

31. du

Use:
```
du -sh /storage/websites/
```
This estimates the amount of disk space consumed by that directory.

Compare:
```
df -h
```
with:
```
du -sh
```
df

Filesystem-level free/used space.

du

Space consumed by files/directories.

This distinction is extremely important.

32. Example

Suppose:
```
df -h /
```
shows:
```
80G total
60G used
20G available
```
But:
```
du -sh /storage/websites/
```
shows:
```
25G
```
The other space may be used by:
```
Operating system
Logs
Databases
Caches
Other files
Filesystem metadata
```
33. Finding Large Directories

You can inspect:
```
du -h --max-depth=1 /storage
```
This can show which directories consume space.

For example:
```
2G   /storage/websites/site1
10G  /storage/websites/site2
5G   /storage/websites/site3
```
34. Why Disk Space Matters for WordPress

A WordPress site may accumulate:
```
Images
Videos
Plugins
Themes
Backups
Logs
Cache
Database files
Temporary files
```
Therefore:
```
Disk usage
```
can grow over time.

35. Database Storage

MySQL also stores persistent data on disk.

Conceptually:
```
WordPress
 ↓
MySQL
 ↓
Database files
 ↓
Storage
```
The exact internal storage layout depends on MySQL/InnoDB configuration.

36. Disk I/O

Reading/writing storage requires:

I/O

Input/Output.

For example:
```
Read:
SSD → RAM

Write:
RAM/application → filesystem → SSD
```
37. Why Disk I/O Can Slow a Server

Suppose MySQL performs many disk operations.

Then:
```
MySQL
 ↓
Storage requests
 ↓
SSD
 ↓
waiting
```
The CPU may have little work to do while the process waits for I/O.

This can contribute to:
```
High I/O wait
Slow applications
Slow database queries
Slow websites
```
38. CPU Utilization vs I/O Wait

This distinction is important.

A server can feel slow even if:
```
CPU usage = 20%
```
because processes may be waiting for:
```
Disk I/O
Network I/O
Other resources
```
So server performance isn’t just:
```
CPU percentage
```
39. iostat

A useful tool for storage monitoring is:
```
iostat
```
It may be provided by the sysstat package.

A more detailed command:
```
iostat -xz 1
```
can show storage-device performance statistics.

You may need to install sysstat if it isn’t already installed.

40. Storage Performance

Storage has several important characteristics:
```
Capacity
Latency
IOPS
Throughput
```
41. Capacity

How much data can be stored?

Example:
```
100 GB
500 GB
1 TB
```
42. Latency

How long does an operation take?

Conceptually:
```
Request
 ↓
Wait
 ↓
Response
```
Lower latency generally means faster response for individual operations.

43. IOPS

IOPS means:

Input/Output Operations Per Second

It measures how many I/O operations a storage system can handle under specified conditions.

Database workloads can be sensitive to IOPS and latency.

44. Throughput

Throughput measures how much data can be transferred per unit time.

For example:
```
500 MB/s
```
A large sequential file transfer may care strongly about throughput.

A database performing many small random operations may care more about latency and IOPS.

45. Sequential vs Random I/O

Sequential
```
Block 1
Block 2
Block 3
Block 4
```
Random
```
Block 900
Block 12
Block 5000
Block 77
```
Different workloads produce different performance characteristics.

46. Mount Points

Let’s return to the key concept.

Suppose:
```
/dev/sdb1
```
contains a filesystem.

You mount it:
```
/storage
```
Then:
```
/storage
```
becomes the entry point into that filesystem.

Conceptually:
```
/dev/sdb1
      ↓
   filesystem
      ↓
    mount
      ↓
  /storage
```
47. /etc/fstab

Linux can define persistent mounts in:
```
/etc/fstab
```
This file describes filesystems that should be mounted automatically according to system configuration.

A conceptual entry might contain:
```
UUID=...
/storage
ext4
defaults
0 2
```
The exact syntax and options depend on the filesystem and desired configuration.

48. Why UUID?

Instead of relying only on:
```
/dev/sdb1
```
Linux can identify a filesystem using a:

UUID

Universally Unique Identifier.

For example:
```
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
```
This can be more stable across device enumeration changes.

You can inspect filesystem UUIDs with:
```
lsblk -f
```
49. Check Your Mounts

Useful commands:
```
findmnt
```
and:
```
df -h
```
and:
```
lsblk -f
```
Together they help answer:
```
What storage devices exist?
 ↓
What filesystems exist?
 ↓
Where are they mounted?
 ↓
How much space is available?
```
50. Your Hosting Storage Architecture

Your system may look conceptually like:
```
Cloud VM
   ↓
Virtual disk
   ↓
Partition / volume
   ↓
Filesystem
   ↓
Mount point
   ↓
/storage
   ↓
/storage/websites
   ↓
templates.cresignsys.com
   ↓
public
   ↓
WordPress
```
The exact device/partition structure should be discovered from your server using:
```
lsblk -f
df -h
findmnt
```
rather than assumed.

51. Website Files vs Storage Device

This is an important distinction.

When you run:
```
cd /storage/websites/templates.cresignsys.com/public
```
you are navigating the filesystem namespace.

You are not directly navigating:
```
SSD sectors
```
The filesystem and kernel translate your path into storage operations.

Conceptually:
```
Path
 ↓
Directory entry
 ↓
Inode
 ↓
Filesystem
 ↓
Block device
 ↓
Storage
```
52. The Complete Storage Chain

Now connect everything:
```
WordPress
 ↓
PHP
 ↓
Filesystem API
 ↓
Linux kernel
 ↓
Virtual filesystem
 ↓
Filesystem driver
 ↓
Block layer
 ↓
Device driver
 ↓
Virtual disk
 ↓
Cloud storage
 ↓
Physical storage
```
This is the deep connection between:
```
wp-config.php
```
and:
```
physical storage hardware
```
53. Storage + Memory + CPU

A running application continuously moves through these resources:
```
              CPU
               ↑
               │
               ↓
              RAM
               ↑
               │
               ↓
            Storage
```
For example:
```
WordPress file
 ↓
Storage
 ↓
RAM
 ↓
CPU
 ↓
execution
```
Results may then be:
```
CPU
 ↓
RAM
 ↓
Network
 ↓
Browser
```
54. Full Web Hosting Resource Model

Your server is now understandable as four major resource areas:
```
                SERVER
                  │
      ┌───────────┼───────────┐
      ↓           ↓           ↓
     CPU          RAM       Storage
      │            │           │
      └────────────┼───────────┘
                   ↓
                Network
```
Web hosting performance depends on all of them.

55. Practical Commands to Learn

Run these on your Ubuntu server:
```
lsblk -f
```
```
df -h
```
```
df -h /storage
```
```
findmnt
```
```
du -sh /storage/websites/
```
```
du -h --max-depth=1 /storage/websites/
```
These commands let you begin understanding your actual storage architecture rather than just memorizing theory.

56. Quick Check

What is persistent storage?

Storage that retains data when power is removed.

What is a filesystem?

A system that organizes persistent storage into files, directories, and metadata.

What is a mount point?

A directory in the filesystem hierarchy where another filesystem is attached.

What does df -h show?

Filesystem capacity and space usage.

What does du -sh show?

Approximate disk space consumed by a file/directory tree.

What does lsblk -f show?

Block devices and filesystem information such as filesystem type, UUID, and mount points.

What is an inode?

A filesystem structure containing metadata about a file and references to its data.

What is I/O?

Input/output operations such as reading and writing storage.

Next Lesson — 022

Linux Networking Fundamentals

Now we have completed the major local-server foundations:
```
CPU
 ↓
RAM
 ↓
Processes
 ↓
Storage
 ↓
Filesystem
 ↓
Users
 ↓
Permissions
 ↓
Services
```
Now we can finally move outside the computer:
```
Server
 ↓
Network Interface
 ↓
Ethernet
 ↓
MAC Address
 ↓
IP Address
 ↓
Subnet
 ↓
Gateway
 ↓
Router
 ↓
Internet
```
Then we will build progressively toward:
```
IP
 ↓
TCP
 ↓
UDP
 ↓
DNS
 ↓
HTTP
 ↓
TLS
 ↓
HTTPS
 ↓
Nginx
 ↓
Domain
 ↓
Web Hosting
```
This will connect directly to how templates.cresignsys.com reaches your Ubuntu server.
August 13, 2026

CresignSys Learn — Lesson 020

Course: From Basic Science to Web Hosting

Module 04 — Linux Fundamentals

How Linux Uses Memory

Difficulty: Beginner → Intermediate
Prerequisites: Lesson 019 — Linux Processes
Estimated time: 35–45 minutes

The next fundamental question is:

When Nginx, PHP, MySQL and WordPress are running, where do their instructions and data actually live?

The answer begins with memory.

1. The Basic Memory Chain

We previously learned:

Program
 ↓
Process
 ↓
CPU

But the CPU needs somewhere to obtain instructions and data.

So:

Storage
 ↓
RAM
 ↓
CPU

A simplified computer looks like:

2. Storage vs RAM

Consider your WordPress installation.

The files physically exist on persistent storage:

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

But when WordPress is running, the CPU does not normally execute PHP directly from the SSD.

The operating system loads needed code/data into memory.

Conceptually:

SSD
 ↓
Filesystem
 ↓
RAM
 ↓
CPU

3. Why Not Run Everything Directly From SSD?

Storage is persistent, but RAM is designed for much faster access.

A simplified hierarchy is:

CPU registers
      ↓
CPU cache
      ↓
RAM
      ↓
SSD
      ↓
Long-term storage

Generally:

Higher
 ↑
Speed

Lower
 ↓
Capacity

There are many technical details, but this hierarchy is the important starting point.

4. What Is RAM?

RAM means:

Random Access Memory

It is the computer’s main working memory.

When programs are running, they need memory for:

Instructions
Variables
Buffers
Stacks
Heaps
Libraries
Operating-system data

5. A Simple Example

Suppose a program contains:

5
+
3

The program’s instructions are stored persistently somewhere.

When executing:

SSD
 ↓
RAM
 ↓
CPU

The CPU fetches instructions/data through the memory system.

6. RAM Is Volatile

Normal RAM is generally volatile.

If power disappears:

RAM
 ↓
contents lost

Storage such as SSD is non-volatile:

Power OFF
 ↓
Data remains on SSD

Therefore:

RAM
= working state

SSD
= persistent state

7. What Does a Process See?

A process doesn’t normally work directly with raw physical RAM addresses.

Instead, it receives a:

Virtual Address Space

Conceptually:

Process
   ↓
Virtual addresses
   ↓
Memory-management hardware + kernel
   ↓
Physical memory

This is one of the most important concepts in modern operating systems.

8. Why Virtual Memory?

Imagine two processes:

Nginx
PHP

Both could theoretically use a virtual address such as:

0x1000

But Linux can map those virtual addresses to different physical memory locations.

Conceptually:

Nginx
0x1000
   ↓
Physical RAM location A


PHP
0x1000
   ↓
Physical RAM location B

So processes can have isolated address spaces.

9. Memory Isolation

This helps prevent:

PHP
 ↓
directly modifying
 ↓
Nginx's memory

or:

WordPress
 ↓
directly modifying
 ↓
kernel memory

The CPU’s memory-management mechanisms enforce access restrictions.

10. Virtual Address Space

A simplified process memory layout might look like:

High addresses
┌──────────────────┐
│      Stack       │
├──────────────────┤
│                  │
│       ...        │
│                  │
├──────────────────┤
│       Heap       │
├──────────────────┤
│ Data             │
├──────────────────┤
│ Program code     │
└──────────────────┘
Low addresses

This is a conceptual model; actual layouts vary by architecture, operating system, executable format, security features, and process.

11. Program Code

The executable instructions occupy memory mappings associated with the program.

Conceptually:

Program file
 ↓
Code mapping
 ↓
CPU executes instructions

For example:

Nginx executable
 ↓
memory mapping
 ↓
CPU

12. Data

Programs need storage for data.

For example:

configuration
global variables
program state

Conceptually:

Code
+
Data
 ↓
Running program

13. Stack

The stack is used for function-call-related data and automatic/local variables.

Imagine:

main()
 ↓
functionA()
 ↓
functionB()

The stack helps maintain information about these calls.

Conceptually:

Function B
 ↓
Function A
 ↓
main()

When a function returns, its stack frame can be removed.

14. Simple Stack Example

Imagine:

function add(a, b)

When called:

add(5, 3)

the execution may need memory for:

a
b
return information
temporary state

Some of this can be associated with stack frames, depending on the compiler and architecture.

15. Heap

The heap is used for dynamically allocated memory.

Conceptually:

Program
 ↓
"Give me more memory"
 ↓
Allocator
 ↓
Heap

For example, applications may dynamically allocate memory while processing requests.

Languages and runtimes manage this differently.

PHP has its own memory-management behavior on top of the operating system’s memory facilities.

16. Stack vs Heap

A simplified comparison:

Stack	Heap
Function-call data	Dynamic allocations
Automatic lifetime	Flexible lifetime
Usually fast	More complex management
Limited per-thread region	Can grow substantially
Thread-specific	Process-wide in general

Do not treat this table as an exact physical RAM layout; it is a conceptual model of process virtual memory.

17. Shared Libraries

Applications often use shared libraries.

For example:

Program
 ↓
Shared library
 ↓
Functions

Instead of every program containing its own copy of common libraries, the operating system can map shared library code into processes.

This can reduce duplication.

18. What Is a Page?

Virtual memory is commonly managed in units called:

Pages

Instead of managing every byte independently, memory systems manage chunks.

A common page size is:

4 KB

but other page sizes can exist.

Conceptually:

Virtual memory
 ├── Page
 ├── Page
 ├── Page
 ├── Page
 └── ...

19. Page Tables

The CPU’s memory-management hardware uses structures called:

Page tables

They help translate:

Virtual address
      ↓
Physical address

Conceptually:

Process
 ↓
Virtual address
 ↓
Page table
 ↓
Physical RAM

The Linux kernel manages these mappings and the relevant memory structures.

20. TLB

Doing a page-table lookup for every memory access would be expensive.

Modern CPUs therefore use a cache called the:

TLB

Translation Lookaside Buffer.

It caches recent virtual-to-physical address translations.

Conceptually:

Virtual address
 ↓
TLB
 ├── hit → fast translation
 └── miss → page-table lookup

This is a deeper CPU/memory concept, but it explains why virtual memory can be efficient.

21. What Happens When RAM Is Full?

Suppose your server has:

8 GB RAM

and running processes demand more memory.

Linux has several mechanisms for handling memory pressure.

One is:

Swap

22. What Is Swap?

Swap is storage space used as an extension of memory management.

Conceptually:

RAM
 ↓
memory pressure
 ↓
some pages may be moved to swap
 ↓
SSD

This allows the system to keep operating under some memory-pressure situations.

But:

Swap is not equivalent to RAM.

Storage is much slower than RAM.

23. Why Heavy Swap Is Bad

Imagine PHP-FPM repeatedly needs a memory page that has been moved to storage.

Then:

CPU
 ↓
needs memory
 ↓
page not in RAM
 ↓
storage access
 ↓
page brought back
 ↓
CPU continues

If this happens excessively, performance can collapse.

This behavior is often associated with:

Thrashing

24. Swap Is Not Always Bad

A common misconception is:

“Any swap usage means the server is broken.”

Not necessarily.

Linux may use swap for various reasons, and some inactive pages can be swapped out while plenty of useful RAM remains available.

The important question is:

Is the system experiencing harmful memory pressure?

25. OOM

If memory pressure becomes severe and the system cannot satisfy memory demands, Linux has an:

Out-Of-Memory mechanism

commonly called:

OOM

The kernel’s OOM killer may terminate selected processes to recover memory.

Conceptually:

Memory demand
      ↓
Available memory insufficient
      ↓
Severe pressure
      ↓
OOM handling
      ↓
Process may be terminated

26. Why This Matters to Web Hosting

Imagine:

Server RAM = 4 GB

and you run:

Nginx
PHP-FPM
MySQL
WordPress
Other services

Now PHP creates many workers.

Conceptually:

PHP-FPM
 ├── Worker 1 → 100 MB
 ├── Worker 2 → 100 MB
 ├── Worker 3 → 100 MB
 ├── Worker 4 → 100 MB
 └── ...

Memory consumption can grow substantially.

27. PHP-FPM and Memory

Suppose each worker uses approximately:

100 MB

and there are:

20 workers

A rough upper-bound-style estimate would be:

20 × 100 MB
= 2000 MB
≈ 2 GB

This is only a simplified illustration. Real PHP-FPM memory behavior varies, and shared memory/code can complicate simple multiplication.

But the principle is important:

More concurrent workers can mean more memory consumption.

28. MySQL and Memory

MySQL also uses memory for:

Buffers
Caches
Connections
Temporary structures
Internal data

So:

RAM
 ├── Linux
 ├── Nginx
 ├── PHP-FPM
 ├── MySQL
 └── Other services

All compete for available memory.

29. Linux Page Cache

Linux also uses otherwise-available RAM for filesystem caching.

Conceptually:

SSD
 ↓
File
 ↓
Linux page cache
 ↓
RAM

If a frequently accessed file is cached in RAM, future reads can be faster.

This means:

RAM shown as “used” is not necessarily a problem.

Some memory is being productively used for cache.

30. Free vs Available

When checking Linux memory, don’t look only at:

free

A more useful concept is:

available

because Linux can reclaim some caches when applications need memory.

Use:

free -h

You might see:

               total   used   free   shared   buff/cache   available
Mem:            ...     ...    ...      ...       ...         ...
Swap:           ...     ...    ...      ...       ...         ...

The exact values depend on your server.

31. `free -h`

The -h means human-readable.

Use:

free -h

This is one of the first commands to run when investigating memory problems.

32. `top`

You can also use:

top

Look at:

%Cpu
MiB Mem
MiB Swap

Then inspect which processes are consuming memory.

33. `ps` Memory Usage

You can sort processes by memory usage:

ps aux --sort=-%mem | head

This can help identify processes using the most memory.

For CPU:

ps aux --sort=-%cpu | head

34. Memory and WordPress

A WordPress request can involve:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
Plugins
 ↓
Theme
 ↓
MySQL

Each layer can consume resources.

Therefore a slow website might be caused by:

CPU
RAM
Database
PHP
Disk I/O
Network
External API
Plugin
Theme

Not necessarily Nginx.

35. PHP Memory Limit

PHP itself can impose memory limits.

For example, PHP may have a configuration value:

memory_limit

This limits memory available to a PHP request under PHP’s own memory-management rules.

It is different from:

Server RAM

For example:

Server RAM = 8 GB

PHP memory_limit = 256M

These are completely different concepts.

36. Server RAM vs PHP Memory Limit

Think:

Physical/virtual server
       ↓
8 GB RAM

PHP process/request
       ↓
PHP memory_limit

The PHP limit applies within PHP’s execution environment; it doesn’t mean the entire server has only that amount of memory.

37. MySQL Memory vs Server RAM

Similarly:

MySQL configuration
       ↓
buffers / caches / connections
       ↓
RAM

If MySQL is configured too aggressively for a small VPS, it can compete heavily with PHP and the operating system.

38. The Memory Flow

A simplified request:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

Memory involvement:

RAM
 ├── Nginx process memory
 ├── PHP-FPM worker memory
 ├── WordPress/PHP memory
 ├── MySQL memory
 ├── Linux kernel memory
 └── filesystem cache

39. Why More Websites Require More Planning

Suppose you host:

1 website

versus:

50 websites

Each additional site may add:

PHP workload
Database workload
Nginx configuration
Cache
Background jobs
Cron tasks
Traffic

Therefore hosting capacity is not determined by disk space alone.

You must consider:

CPU
RAM
Storage I/O
Network
Database workload
Concurrent requests

40. Memory and VPS Hosting

A virtual private server may give you a defined amount of virtual CPU and RAM.

Conceptually:

Physical server
 ├── VM A
 ├── VM B
 ├── VM C
 └── VM D

Your VM sees its allocated resources according to the virtualization/cloud platform.

Inside your VM:

Ubuntu
 ↓
Linux
 ↓
Processes
 ↓
Memory management

41. The Deepest Connection

Remember the original chain:

Electron
 ↓
Transistor
 ↓
Logic
 ↓
CPU

Now:

CPU
 ↓
Memory-management hardware
 ↓
RAM
 ↓
Linux kernel
 ↓
Processes
 ↓
Applications

So even a simple command such as:

free -h

ultimately depends on:

Hardware
 ↓
Memory controller
 ↓
CPU
 ↓
Linux kernel
 ↓
/proc and memory-management interfaces
 ↓
free
 ↓
Terminal output

42. A Useful Mental Model

Think of RAM as a working area, not as permanent storage.

                 COMPUTER
                     │
          ┌──────────┴──────────┐
          ↓                     ↓
       Storage                 RAM
     "Keep data"           "Work on data"
          │                     │
          └──────────┬──────────┘
                     ↓
                    CPU

43. Practical Commands

Start learning these:

Memory summary

free -h

Live system view

top

Memory-heavy processes

ps aux --sort=-%mem | head

CPU-heavy processes

ps aux --sort=-%cpu | head

Kernel memory information

cat /proc/meminfo

System uptime/load

uptime

44. What Does `uptime` Tell You?

For example:

uptime

might show:

up 10 days, 3:15
load average: 0.20, 0.18, 0.15

This introduces another important concept:

Load Average

We will study it properly later.

It is related to how much work is runnable or waiting for certain resources over time.

It is not simply CPU percentage.

45. What You Should Remember

The key chain is:

Program
 ↓
Process
 ↓
Virtual memory
 ↓
Pages
 ↓
Physical RAM
 ↓
CPU

And for your server:

Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
RAM

All of these compete for system resources.

46. Quick Check

Is a program the same as a process?

No.

Program = stored code
Process = running instance

Is RAM persistent?

Normally no.

Is SSD persistent?

Yes, normally.

What is virtual memory?

An abstraction that gives processes virtual address spaces, with mappings managed by the OS and hardware.

What is a page?

A fixed-size unit used in virtual-memory management.

What is swap?

Storage used as part of the system’s virtual-memory management.

Is swap as fast as RAM?

No.

What can happen under extreme memory pressure?

The system can invoke OOM handling and may terminate processes.

Next Lesson — 021

Linux Storage and Disk I/O

Before we move into networking, we need to understand the other major resource your hosting server depends on:

RAM
 ↓
Storage
 ↓
Disk
 ↓
Partitions
 ↓
Filesystems
 ↓
Mount points
 ↓
SSD
 ↓
I/O
 ↓
I/O wait
 ↓
Disk usage
 ↓
Storage performance

Then we will connect it directly to your:

/storage/websites/

architecture and learn how Linux knows which physical/virtual storage device contains your websites.

August 13, 2026

CresignSys Learn — Lesson 019
Course: From Basic Science to Web Hosting

Module 04 — Linux Fundamentals

What Is a Linux Process?

Difficulty: Beginner → Intermediate
Prerequisites: Lesson 018 — Users, Groups & Permissions
Estimated time: 35–40 minutes

The next foundation is understanding what is actually running inside your server.

You have files such as:
```
/usr/sbin/nginx
/usr/sbin/mysqld
```
But a file sitting on the SSD is not the same thing as a running program.

The important distinction is:
```
Program
   ↓
Process
   ↓
CPU + RAM + operating-system resources
```
1. What Is a Program?

A program is stored code.

For example:
```
/usr/sbin/nginx
```
is an executable program.

It exists as data on storage.

Conceptually:
```
SSD
 │
 └── nginx executable
```
Nothing is necessarily running merely because the file exists.

2. What Is a Process?

When the operating system starts a program, it creates a process.

So:
```
Program
   ↓
OS starts it
   ↓
Process
```
For example:
```
nginx program
      ↓
Nginx process
```
A process is a running instance managed by the operating system.

3. Program vs Process

Remember this distinction:

Program Process
Stored code Running instance
Exists on storage Uses RAM
Passive Active
Executable file OS-managed execution
Can be started Is already running

Example:
```
/usr/sbin/nginx
```
is a program.
```
nginx process
```
is a running instance.

4. What Happens When a Program Starts?

Very simplified:
```
Executable file
      ↓
Linux loads program
      ↓
Creates process
      ↓
Allocates virtual memory
      ↓
Sets process state
      ↓
Schedules it
      ↓
CPU executes instructions
```
Now the program is running.

5. Every Process Has a PID

Linux gives every process an identifier:

PID

Process ID

For example:
```
PID = 1234
```
This lets the operating system and administrators identify the process.

6. See Running Processes

Use:
```
ps
```
You might see:
```
PID TTY          TIME CMD
1234 pts/0    00:00:00 bash
```
The important part:
```
1234
```
is the PID.

7. ps aux

A more comprehensive view:
```
ps aux
```
You may see something like:
```
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1  ...   ... ?        Ss   ...      /sbin/init
www-data  2100  0.0  0.5  ...   ... ?        S    ...      nginx
mysql     2200  0.5  2.0  ...   ... ?        S    ...      mysqld
```
The exact output will differ on your server.

8. Important ps Columns

For example:
```
USER
PID
%CPU
%MEM
STAT
COMMAND
```
USER

The user identity running the process.

PID

Process ID.

%CPU

Recent CPU utilization.

%MEM

Memory utilization.

STAT

Process state/status information.

COMMAND

The executable/command associated with the process.

9. The First Process

On a typical modern Linux system, the first userspace process is commonly:
```
systemd
```
and often has:
```
PID 1
```
Conceptually:
```
Linux kernel
      ↓
PID 1
      ↓
systemd
      ↓
Services
```
The exact boot architecture can vary, but PID 1 is a crucial concept in Linux.

10. Why Is PID 1 Special?

PID 1 has important responsibilities in userspace.

On Ubuntu systems using systemd:
```
PID 1
 ↓
systemd
```
It manages system services and participates in process lifecycle management.

For example:
```
systemd
 ├── nginx
 ├── ssh
 ├── mysql
 └── other services
```
11. Parent and Child Processes

Processes can have relationships.

A process can create another process.

For example:
```
Parent
  ↓
Child
```
This creates a process hierarchy.

Conceptually:
```
systemd
   ↓
service manager
   ↓
nginx
```
The exact process tree depends on how the service is launched.

12. PPID

A process also has a:

Parent Process ID

called:
```
PPID
```
Suppose:
```
PID 2000
PPID 1000
```
It means process 2000 has process 1000 as its parent.

13. Process Tree

Use:
```
pstree
```
You might see a structure resembling:
```
systemd
 ├─ sshd
 │   └─ bash
 ├─ nginx
 │   ├─ nginx
 │   └─ nginx
 └─ mysqld
```
The exact tree varies.

This is much easier to understand than a flat process list.

14. Why Do We Have Multiple Nginx Processes?

Nginx commonly uses a master/worker architecture.

Conceptually:
```
nginx master
   ├── worker
   ├── worker
   └── worker
```
The master manages the workers.

The workers handle connections and requests.

The exact architecture and worker count depend on configuration and version.

15. Nginx Master and Worker

Conceptually:
```
             Nginx
               │
        ┌──────┴──────┐
        ↓             ↓
      Master        Workers
                      │
             ┌────────┼────────┐
             ↓        ↓        ↓
           Request  Request  Request
```
This allows Nginx to handle many connections efficiently.

16. PHP-FPM

WordPress usually needs PHP.

PHP-FPM means:

PHP FastCGI Process Manager

Instead of Nginx executing PHP code itself:
```
Nginx
 ↓
PHP-FPM
 ↓
PHP
```
PHP-FPM maintains worker processes.

Conceptually:
```
php-fpm master
      ├── worker
      ├── worker
      └── worker
```
Again, the exact model depends on configuration.

17. MySQL

Your database server also runs as a process or process group managed by the operating system.

Conceptually:
```
MySQL
  ↓
mysqld
  ↓
CPU + RAM + storage
```
So your hosting server might contain:
```
systemd
 ├── nginx
 ├── php-fpm
 ├── mysqld
 └── sshd
```
18. CPU and Processes

The CPU executes instructions from runnable processes/threads.

Imagine:
```
Nginx → needs CPU
PHP   → needs CPU
MySQL → needs CPU
SSH   → needs CPU
```
The operating system scheduler decides which runnable threads get CPU time on available cores.

Conceptually:
```
Processes / threads
       ↓
Scheduler
       ↓
CPU cores
```
19. One CPU Core

With one core, only one instruction stream can execute at a given instant on that core.

The OS rapidly switches among runnable work.

Simplified:
```
Nginx
 ↓
CPU
 ↓
PHP
 ↓
CPU
 ↓
MySQL
 ↓
CPU
```
This switching happens extremely quickly.

20. Multiple CPU Cores

Modern CPUs have multiple cores.

For example:
```
CPU
 ├── Core 1
 ├── Core 2
 ├── Core 3
 └── Core 4
```
Multiple threads can execute simultaneously across different cores.

The operating system schedules work across them.

21. What Is a Thread?

A thread is an execution path within a process.

Conceptually:
```
Process
 ├── Thread 1
 ├── Thread 2
 └── Thread 3
```
Threads usually share the process’s address space and many resources.

22. Process vs Thread

A simplified comparison:
```
Process
 ↓
Independent execution environment
 ↓
Own virtual address space

Thread
 ↓
Execution path inside a process
 ↓
Shares much of process memory/resources
```
Threads are generally cheaper to create/switch than separate processes, but the details depend on the operating system and workload.

23. Process Memory

A process needs memory.

Conceptually:
```
Process
 ├── Code
 ├── Data
 ├── Heap
 ├── Stack
 └── Shared libraries
```
The process sees a virtual address space.

The CPU’s memory-management hardware and Linux map virtual addresses to physical memory as appropriate.

24. Virtual Memory

Suppose two processes both use an address such as:
```
0x1000
```
That does not mean they necessarily refer to the same physical RAM location.

Conceptually:
```
Process A
virtual address
     ↓
physical memory A


Process B
virtual address
     ↓
physical memory B
```
The memory-management unit and kernel establish these mappings.

25. Why Virtual Memory Matters

It provides:
```
Isolation
Protection
Flexible memory management
Shared libraries
Memory mapping
```
It is one of the foundations of modern operating systems.

26. Process States

A process/thread isn’t always executing.

It can be:
```
Running
Ready/runnable
Sleeping/waiting
Stopped
Zombie
```
The exact state notation depends on the tool.

27. Running

A runnable thread may be executing on a CPU.

Conceptually:
```
Thread
 ↓
CPU
 ↓
Instructions executing
```
28. Sleeping / Waiting

A process may be waiting for something.

For example:
```
Nginx
 ↓
Waiting for network connection
```
or:
```
MySQL
 ↓
Waiting for disk I/O
```
A waiting process may consume very little CPU.

29. Zombie Process

A zombie is a process that has terminated but still has a process-table entry containing its exit status until its parent collects that status.

Conceptually:
```
Child finishes
     ↓
Zombie entry
     ↓
Parent collects exit status
     ↓
Entry removed
```
A small number of transient zombies can be normal.

A large accumulation can indicate a parent-process problem.

30. top

Use:
```
top
```
This provides a live view of system activity.

You can observe:
```
CPU usage
Memory usage
Load
Processes
PIDs
```
It is one of the most useful basic server-monitoring tools.

31. htop

If installed:
```
htop
```
provides a more interactive process viewer.

It can help you see:
```
CPU cores
Processes
Memory
Process tree
```
32. pgrep

Suppose you want to find Nginx processes:
```
pgrep nginx
```
It returns matching PIDs.

For example:
```
2100
2101
2102
```
The actual PIDs on your server will be different.

33. Find the Process

You can combine:
```
ps aux | grep nginx
```
But be aware that grep nginx itself can sometimes appear in the output.

A cleaner approach is often:
```
pgrep -a nginx
```
which can show matching process IDs and command lines.

34. Inspect a Specific Process

Suppose:
```
PID = 2100
```
You can inspect:
```
ps -p 2100 -f
```
This can show details such as:
```
UID
PID
PPID
START
TIME
COMMAND
```
35. /proc/PID

Remember Lesson 017.

If Nginx has:
```
PID = 2100
```
Linux exposes process information under:
```
/proc/2100/
```
For example:
```
cat /proc/2100/status
```
can show information about that process.

This demonstrates the connection:
```
Process
 ↓
Kernel
 ↓
/proc
 ↓
User-space inspection
```
36. Who Is Running Nginx?

You can use:
```
ps aux | grep nginx
```
or:
```
ps -eo user,pid,ppid,cmd | grep nginx
```
You may see different users for master and worker processes depending on configuration.

For example, conceptually:
```
root      nginx master
www-data  nginx worker
www-data  nginx worker
```
This is a common security architecture.

37. Why Would Nginx Have a Root Master?

The master process may need privileged operations such as binding to a low-numbered port, while worker processes can run with reduced privileges.

For example:
```
root
 ↓
Nginx master
 ↓
www-data
 ↓
Nginx workers
```
This reduces the privileges of the request-processing workers.

The exact configuration can differ.

38. PHP-FPM Workers

Similarly, PHP-FPM may have:
```
php-fpm master
      ↓
workers
      ↓
www-data
```
The workers execute PHP application code.

This is especially important for WordPress security.

39. MySQL Process

You can inspect the database process:
```
pgrep -a mysqld
```
or:
```
ps aux | grep mysqld
```
You can then ask:
```
Who owns the process?
How much RAM is it using?
How much CPU?
What is its PID?
```
40. Process and Service Are Different

This distinction is important.

Service

A managed system function.

Example:
```
nginx.service
```
Process

A running execution instance.

Example:
```
nginx PID 2100
```
So:
```
systemd
 ↓
service
 ↓
process
```
A service may involve multiple processes.

41. systemctl status

Run:
```
sudo systemctl status nginx
```
You may see information such as:
```
Active: active (running)
Main PID: ...
```
This connects:
```
systemd
 ↓
nginx.service
 ↓
Nginx process
 ↓
PID
```
42. Restart vs Reload

This is important for web hosting.

Restart
```
sudo systemctl restart nginx
```
Typically stops and starts the service.

Reload
```
sudo systemctl reload nginx
```
asks Nginx to reload its configuration without a full service restart, when supported.

For configuration changes, reload is often preferable because it can avoid unnecessarily interrupting existing connections.

But always test the configuration first:
```
sudo nginx -t
```
43. nginx -t

Before reloading after changing Nginx configuration:
```
sudo nginx -t
```
Nginx checks the configuration syntax and related configuration validity.

Conceptually:
```
Edit configuration
       ↓
nginx -t
       ↓
Valid?
 ┌─────┴─────┐
No          Yes
 ↓            ↓
Fix         reload
```
This is an excellent operational habit.

44. Process Failure

Suppose PHP-FPM crashes.

Then:
```
Nginx
 ↓
tries to communicate with PHP-FPM
 ↓
PHP-FPM unavailable
 ↓
request fails
```
You may see:
```
502 Bad Gateway
```
This is why process knowledge is essential for web-hosting troubleshooting.

45. CPU High

Suppose:
```
top
```
shows:
```
mysqld
 ↓
95% CPU
```
You now know the problem may be related to database workload rather than Nginx.

You can investigate:
```
CPU
 ↓
Process
 ↓
Application
 ↓
Specific workload
```
46. Memory High

Suppose:
```
php-fpm
 ↓
large memory usage
```
Then investigate:
```
PHP workers
 ↓
WordPress
 ↓
Plugin/theme
 ↓
Request workload
```
This is much better than randomly restarting the server.

47. The Troubleshooting Model

When something fails:
```
Symptom
  ↓
Which process?
  ↓
Which service?
  ↓
Which user?
  ↓
Which resource?
  ↓
CPU?
RAM?
Disk?
Network?
Permissions?
Configuration?
```
This is the beginning of professional server administration.

48. Your Web Hosting Process Architecture

Your server can be visualized as:
```
                     Linux Kernel
                          │
                       systemd
                          │
        ┌─────────────────┼─────────────────┐
        ↓                 ↓                 ↓
      Nginx            PHP-FPM            MySQL
        │                 │                 │
    Workers           Workers            Threads
        │                 │                 │
        └─────────────────┼─────────────────┘
                          ↓
                       Resources
                    CPU / RAM / Disk
```
49. One Website Request

A request for:
```
https://templates.cresignsys.com
```
may produce:
```
Browser
 ↓
Network
 ↓
Nginx worker
 ↓
PHP-FPM worker
 ↓
WordPress
 ↓
MySQL
 ↓
PHP-FPM
 ↓
Nginx
 ↓
TLS
 ↓
Browser
```
Multiple processes and threads can be involved.

50. The Deep Technology Chain

Your course has now reached:
```
Atom
 ↓
Electron
 ↓
Electricity
 ↓
Semiconductor
 ↓
Transistor
 ↓
Logic gate
 ↓
Binary
 ↓
CPU
 ↓
Computer
 ↓
Operating System
 ↓
Linux Kernel
 ↓
Filesystem
 ↓
Users
 ↓
Permissions
 ↓
Processes
 ↓
Services
 ↓
Nginx / PHP-FPM / MySQL
```
The next major layer is:
```
Network
```
But before jumping into the Internet, we need one more Linux foundation:

Lesson 020 — Linux Memory

We will go deeply into:
```
RAM
 ↓
Virtual memory
 ↓
Pages
 ↓
Memory addresses
 ↓
Stack
 ↓
Heap
 ↓
Shared libraries
 ↓
Cache
 ↓
Swap
 ↓
OOM
 ↓
Why a web server becomes slow
```
Then we will connect memory directly to your Ubuntu VPS, PHP-FPM, MySQL and WordPress.
August 13, 2026
CresignSys Learn — Lesson 018
Course: From Basic Science to Web Hosting

Module 04 — Linux Fundamentals

Linux Users, Groups, Ownership & Permissions

Difficulty: Beginner → Intermediate
Prerequisites: Lesson 017 — Linux Filesystem
Estimated time: 35–40 minutes

1. The Big Question

You have seen commands such as:
```
sudo -u www-data wp core download --allow-root
```
and you have worked with directories such as:
```
/storage/websites/templates.cresignsys.com/public/
```
A fundamental question is:

Who is allowed to read, modify, or execute these files?

Linux answers this using:
```
Users
Groups
Ownership
Permissions
```
These four concepts are essential for secure web hosting.

2. Why Permissions Exist

Imagine every program could modify every file.

A compromised website could potentially modify:
```
/etc/
```
or:
```
/root/
```
or another customer’s website.

That would be dangerous.

Linux therefore follows a basic principle:
```
Program
   ↓
Request access
   ↓
Kernel checks permissions
   ↓
Allow / deny
```
3. Users

A Linux system can have many users.

For example:
```
root
ubuntu
www-data
```
Each user has an identity recognized by the operating system.

The identity is represented internally by a:

UID

UID means:

User ID

For example:
```
root
 ↓
UID 0
```
The exact UID values of other users depend on the system.

4. Root User

root is the traditional privileged Linux user.

Its UID is:
```
0
```
Root can perform operations that ordinary users cannot.

For example:
```
sudo systemctl restart nginx
```
may execute the service-management operation with elevated privileges.

5. Normal User

Your login account might be something such as:
```
ubuntu
```
It normally does not have unrestricted access to the entire system.

When it needs administrative privileges, it can use:
```
sudo
```
if authorized.

6. What Is www-data?

On Ubuntu/Debian systems, web-server software commonly uses a restricted service account such as:
```
www-data
```
The exact service user depends on configuration.

For example:
```
Nginx
 ↓
www-data
```
or PHP-FPM workers may run as:
```
www-data
```
The purpose is security.

If a web application is compromised, restricting it to a low-privilege account can reduce the damage it can cause.

7. User vs Process

A user is an identity.

A process is a running program.

For example:
```
User:
www-data

Process:
php-fpm worker
```
The process runs with a user identity.

Conceptually:
```
PHP-FPM process
      ↓
runs as
      ↓
www-data
```
The Linux kernel uses that identity when checking access to resources.

8. Groups

Linux also has groups.

A group is a collection of users.

For example:
```
developers
webadmins
www-data
```
A user can belong to one or more groups.

Conceptually:
```
Users
 │
 ├── ubuntu
 ├── admin
 └── developer

Group
 │
 └── webadmins
```
Groups make permission management easier.

9. Group ID

Like users, groups have numerical identifiers.

This is called:
```
GID
```
meaning:

Group ID

The system internally uses UIDs and GIDs rather than relying only on names.

10. File Ownership

Every ordinary Linux file has ownership information.

At a basic level:
```
File
 ├── Owner
 └── Group
```
For example:
```
index.php
Owner: www-data
Group: www-data
```
11. View Ownership

Use:
```
ls -l
```
Example:
```
-rw-r--r-- 1 www-data www-data 1234 index.php
```
The important part is:
```
www-data www-data
```
which represents:
```
Owner = www-data
Group = www-data
```
12. Understanding ls -l

Consider:
```
-rw-r--r-- 1 www-data www-data 1234 index.php
```
Break it down:
```
-rw-r--r--
│
├── file type
│
├── owner permissions
├── group permissions
└── other permissions
```
The first character:
```
-
```
means it is a regular file.

A directory usually begins with:
```
d
```
For example:
```
drwxr-xr-x
```
13. Three Permission Categories

Linux traditionally evaluates three basic permission classes:
```
Owner
Group
Others
```
For example:
```
-rwxr-x---
```
can be separated into:
```
Owner  → rwx
Group  → r-x
Others → ---
```
14. Three Basic Permissions

The three basic permissions are:
```
r
w
x
```
They mean:
```
r = read
w = write
x = execute
```
15. Read Permission

For a regular file:
```
r
```
generally means the process can read the file’s contents.

For example:
```
cat index.php
```
requires appropriate read permission.

16. Write Permission

For a regular file:
```
w
```
means the process can modify the file contents, subject to other filesystem/security mechanisms.

For example:
```
nano test.txt
```
requires write access to save modifications.

17. Execute Permission

For a regular file:
```
x
```
allows it to be executed as a program/script when the other requirements for execution are satisfied.

For example:
```
./script.sh
```
requires execute permission on the script.

But for directories, x has a different meaning.

18. Execute Permission on Directories

This is extremely important.

For a directory:
```
x
```
generally means:

You can traverse/search the directory.

So directory permissions behave differently from file permissions.

19. Directory Read vs Execute

Suppose:
```
drwxr-x---
```
For a directory:
```
r
```
allows listing directory entries, subject to other permissions.
```
x
```
allows traversal/search.

Therefore:
```
Read directory
```
and:
```
Enter/traverse directory
```
are not exactly the same permission.

20. Example

Suppose:
```
/storage/websites/
```
has:
```
drwxr-x---
```
A user may be able to traverse the directory but not necessarily list its contents, depending on the exact permission combination and ownership/group membership.

This distinction becomes important when securing hosting directories.

21. Permission Numbers

Linux permissions can also be represented numerically.

The basic mapping is:
```
r = 4
w = 2
x = 1
```
Add them together.

22. Examples

Read only:
```
r--
```
means:
```
4
```
Write only:
```
-w-
```
means:
```
2
```
Execute only:
```
--x
```
means:
```
1
```
Read + write:
```
rw-
```
means:
```
4 + 2 = 6
```
Read + execute:
```
r-x
```
means:
```
4 + 1 = 5
```
Read + write + execute:
```
rwx
```
means:
```
4 + 2 + 1 = 7
```
23. Three Permission Numbers

Consider:
```
755
```
Separate it:
```
7 5 5
```
Meaning:
```
Owner → 7
Group → 5
Others → 5
```
And:
```
7 = rwx
5 = r-x
5 = r-x
```
Therefore:
```
755
=
rwxr-xr-x
```
24. Another Example: 644
```
644
```
means:
```
Owner → 6 = rw-
Group → 4 = r--
Others → 4 = r--
```
So:
```
644
=
rw-r--r--
```
This is commonly used for ordinary web files, depending on the hosting architecture.

25. chmod

The command used to change permissions is:
```
chmod
```
For example:
```
chmod 644 index.php
```
This sets:
```
Owner → read/write
Group → read
Others → read
```
26. chmod 755

For a directory:
```
chmod 755 public
```
means:
```
Owner → rwx
Group → r-x
Others → r-x
```
This is a common directory permission pattern.

But:

Do not blindly apply 755 or 777 everywhere.

Permissions should reflect what the service actually needs.

27. chmod 777

You may see:
```
chmod 777
```
This gives:
```
Owner  → rwx
Group  → rwx
Others → rwx
```
This is often overly permissive.

For a web server, it can create serious security problems.

Avoid using 777 as a generic solution to permission errors.

28. Ownership: chown

The command:
```
chown
```
means:

change owner

Example:
```
sudo chown www-data index.php
```
changes the owner to:
```
www-data
```
29. Owner + Group

You can specify both:
```
sudo chown www-data:www-data index.php
```
Meaning:
```
Owner = www-data
Group = www-data
```
30. Recursive Ownership

You can apply ownership to a directory and its contents:
```
sudo chown -R www-data:www-data /storage/websites/example.com/
```
The -R means:
```
recursive
```
But use recursive ownership changes carefully.

A mistake can affect thousands of files.

31. chgrp

The command:
```
chgrp
```
changes the group ownership.

Example:
```
sudo chgrp www-data index.php
```
Now:
```
Group = www-data
```
32. Why Ownership Matters for WordPress

Suppose WordPress wants to modify:
```
wp-content/
```
The PHP-FPM process might be running as:
```
www-data
```
Linux checks:
```
Who is requesting access?
        ↓
www-data
        ↓
Who owns the file?
        ↓
What are the permissions?
```
Then the kernel decides whether access is allowed.

33. The Permission Decision

Conceptually:
```
PHP-FPM
   ↓
www-data
   ↓
requests write access
   ↓
Linux kernel
   ↓
Check file owner/group/permissions
   ↓
ALLOW or DENY
```
This is why permissions matter so much in WordPress hosting.

34. Why Nginx Can Read a File

Suppose:
```
index.php
```
has:
```
-rw-r--r--
```
and is owned by:
```
ubuntu
```
The owner has:
```
rw-
```
Group:
```
r--
```
Others:
```
r--
```
If Nginx/PHP runs as an account that falls under “others”, it can read the file but cannot modify it.

35. Why WordPress May Not Be Able to Write

Suppose:
```
wp-content/
```
doesn’t provide write access to the PHP process’s identity.

WordPress might fail to:
```
Upload media
Install plugin
Update plugin
Create cache
Write generated files
```
The browser might show an error such as:
```
Unable to create directory
```
or:
```
Could not create temporary file
```
The correct solution is to understand ownership and required permissions—not automatically use chmod 777.

36. A Better Hosting Model

A more controlled architecture might be:
```
Website files
      ↓
Owner: deployment/admin user
Group: web group
      ↓
Nginx/PHP
      ↓
only required access
```
The exact model depends on your deployment workflow.

The important principle is:

Give each service only the permissions it actually needs.

37. The Principle of Least Privilege

This is a major security principle.

Instead of:
```
Everyone → Everything
```
use:
```
Each process
    ↓
Minimum required permissions
```
For example:
```
Nginx
 ↓
Read website files

PHP
 ↓
Read application files
 ↓
Write only where necessary
```
38. Why sudo Is Powerful

Suppose normal user:
```
ubuntu
```
runs:
```
sudo systemctl restart nginx
```
The system temporarily gives the command elevated privileges according to sudo policy.

Conceptually:
```
ubuntu
 ↓
sudo
 ↓
authorized elevated operation
```
Without sudo:
```
systemctl restart nginx
```
may fail because managing the service requires privileges the normal user doesn’t have.

39. sudo Does Not Mean “Make Everything Root Forever”

This is an important distinction.

When you run:
```
sudo command
```
you are asking the system to execute that particular command with elevated privileges according to the sudo configuration.

It does not permanently turn your account into root.

40. sudo -u

You have used:
```
sudo -u www-data ...
```
The -u option specifies another user identity.

For example:
```
sudo -u www-data whoami
```
can produce:
```
www-data
```
Conceptually:
```
ubuntu
 ↓
sudo
 ↓
execute as www-data
 ↓
program
```
41. Why This Is Useful for WordPress

Suppose WordPress should operate as:
```
www-data
```
You can execute a command as that user:
```
sudo -u www-data wp ...
```
This helps test whether the web-service user actually has access to the files.

42. --allow-root

You have also seen:
```
--allow-root
```
with WP-CLI.

This is a WP-CLI-specific option, not a Linux permission command.

It tells WP-CLI to permit execution as the root user when the command is otherwise being blocked for safety.

This is different from:
```
sudo
```
and different from:
```
chmod
```
43. Three Different Concepts

Keep these separate:
```
sudo
 ↓
Who executes a command?

chown
 ↓
Who owns a file?

chmod
 ↓
What permissions does the file have?
```
This simple distinction will prevent many Linux mistakes.

44. Practical Example

Suppose:
```
ls -ld /storage/websites/templates.cresignsys.com/public
```
returns something like:
```
drwxr-xr-x  www-data www-data ...
```
You can interpret it as:
```
Directory
Owner = www-data
Group = www-data

Owner:
rwx

Group:
r-x

Others:
r-x
```
45. Inspect a File

Use:
```
ls -l /storage/websites/templates.cresignsys.com/public/index.php
```
You might see:
```
-rw-r--r-- www-data www-data ...
```
Then:
```
Owner = www-data
Group = www-data
```
and:
```
Owner → rw-
Group → r--
Others → r--
```
46. Inspect the Whole Path

There is a subtle problem.

A file may have correct permissions while one of its parent directories prevents traversal.

For example:
```
/storage
   ↓
/websites
   ↓
/example.com
   ↓
/public
   ↓
index.php
```
The process needs appropriate traversal permissions on the directory path.

So troubleshooting permissions means checking:
```
File
+
Parent directories
```
not just the final file.

47. namei

A useful command is:
```
namei -l /storage/websites/templates.cresignsys.com/public/index.php
```
It can show the permissions and ownership of each component of the path.

Conceptually:
```
/
 ↓
storage
 ↓
websites
 ↓
templates.cresignsys.com
 ↓
public
 ↓
index.php
```
This is extremely useful for diagnosing “Permission denied.”

48. Linux Permission Flow

When a process accesses a file:
```
Process
  ↓
User identity
  ↓
Path traversal
  ↓
Directory permissions
  ↓
File ownership
  ↓
File permissions
  ↓
Kernel decision
  ↓
Allow / deny
```
This is the foundation.

49. Web Hosting Permission Flow

Now apply it to WordPress:
```
Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
Filesystem request
 ↓
Linux kernel
 ↓
Ownership + permissions
 ↓
ALLOW / DENY
```
This explains many real hosting problems.

50. The Deeper Technology Chain

We can now extend our original chain:
```
Matter
 ↓
Electrons
 ↓
Electricity
 ↓
Electronics
 ↓
Transistors
 ↓
Digital logic
 ↓
CPU
 ↓
Computer
 ↓
Linux
 ↓
Kernel
 ↓
Filesystem
 ↓
Users
 ↓
Permissions
 ↓
Processes
 ↓
Services
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
Website
```
51. Quick Check

What is a UID?

A numerical identifier for a Linux user.

What is a GID?

A numerical identifier for a Linux group.

What does r mean?

Read.

What does w mean?

Write.

What does x mean?

Execute for files; generally traversal/search for directories.

What does chmod do?

Changes permissions.

What does chown do?

Changes ownership.

What does chgrp do?

Changes group ownership.

What does sudo -u www-data do?

Runs the specified command as www-data, subject to sudo authorization.

Why should you avoid chmod 777 as a generic fix?

Because it gives owner, group, and others read/write/execute permissions and can unnecessarily expose the website to modification.

Next Lesson — 019

Linux Processes: What Is Actually Running on Your Server?

We will go deeper into:
```
Program
 ↓
Process
 ↓
PID
 ↓
Parent process
 ↓
Child process
 ↓
Thread
 ↓
CPU
 ↓
RAM
 ↓
systemd
 ↓
Nginx
 ↓
PHP-FPM
 ↓
MySQL
```
Then we will use real commands:
```
ps
top
htop
pgrep
pstree
systemctl
```
to understand exactly what is running inside your web-hosting server.
August 13, 2026
CresignSys Learn — Lesson 017
Course: From Basic Science to Web Hosting

Module 04 — Linux Fundamentals

What Is the Linux Filesystem?

Difficulty: Beginner → Intermediate
Prerequisites: Lesson 016 — What Really Happens When You Run a Linux Command?
Estimated time: 30–40 minutes

1. The Big Question

You have already used paths such as:
```
/storage/websites/templates.cresignsys.com/public
```
and commands such as:
```
cd /storage/websites/
ls
```
But what exactly is this structure?

Why does Linux have:
```
/etc
/var
/usr
/home
/dev
/proc
/sys
```
?

To understand Linux administration properly, we first need to understand its filesystem.

2. What Is a Filesystem?

A filesystem is the software-defined structure used to organize and manage persistent data on storage.

At a simple level:
```
Storage device
      ↓
Filesystem
      ↓
Directories
      ↓
Files
```
For example:
```
SSD
 ↓
Filesystem
 ↓
/
 ├── etc
 ├── var
 ├── home
 └── storage
```
3. Linux Has One Main Directory Tree

Linux organizes its filesystem as a tree.

At the top is:
```
/
```
This is called:

Root Directory

Do not confuse:
```
/
```
with:
```
root
```
The first is the filesystem’s top directory.

The second usually refers to the administrative user account.

4. The Root of the Filesystem

Everything in the normal Linux filesystem hierarchy starts from:
```
/
```
For example:
```
/etc
```
means:
```
/
└── etc
```
And:
```
/var/log
```
means:
```
/
└── var
    └── log
```
And:
```
/storage/websites/
```
means:
```
/
└── storage
    └── websites
```
5. Absolute Paths

A path beginning with / is an absolute path.

Example:
```
cd /storage/websites/
```
It means:

Start from the filesystem root and go to storage, then websites.

6. Relative Paths

A path without / at the beginning is normally interpreted relative to the current directory.

Suppose:
```
pwd
```
returns:
```
/storage/websites/
```
Then:
```
cd templates.cresignsys.com
```
means:
```
/storage/websites/templates.cresignsys.com
```
7. pwd

The command:
```
pwd
```
means:

Print Working Directory

Example:
```
pwd
```
Output:
```
/storage/websites/templates.cresignsys.com/public
```
This tells you exactly where you currently are in the filesystem tree.

8. ls

The command:
```
ls
```
lists directory contents.

For example:
```
ls
```
might show:
```
index.php
wp-config.php
wp-content
wp-admin
wp-includes
```
9. cd

The command:
```
cd
```
means:

change directory

Example:
```
cd /storage/websites/
```
Then:
```
pwd
```
might show:
```
/storage/websites
```
10. The Linux Filesystem Tree

A simplified Linux filesystem might look like:
```
/
├── bin
├── boot
├── dev
├── etc
├── home
├── lib
├── media
├── mnt
├── opt
├── proc
├── root
├── run
├── sbin
├── srv
├── sys
├── tmp
├── usr
├── var
└── storage
```
Some modern distributions use merged directories such as /usr/bin being the effective location behind /bin; the exact filesystem layout can vary.

11. /bin

Historically:
```
/bin
```
contains essential user command binaries.

Examples conceptually include:
```
ls
cp
mv
cat
```
On modern Ubuntu systems, /bin is commonly a symbolic link into /usr/bin.

You can inspect it with:
```
ls -ld /bin
```
12. /sbin

Historically:
```
/sbin
```
contains system-administration commands.

Modern Linux distributions may similarly merge this into /usr/sbin.

Examples include tools used for:
```
System administration
Networking
Disk management
Boot/system maintenance
```
13. /usr

This is one of the most important directories.

It contains a large part of the operating system’s user-space software.

For example:
```
/usr/bin
/usr/sbin
/usr/lib
/usr/share
```
Conceptually:
```
/usr
 ├── bin
 ├── sbin
 ├── lib
 └── share
```
Many applications and utilities live here.

14. /etc

This is extremely important for a server.
```
/etc
```
primarily contains system and application configuration.

Examples:
```
/etc/nginx/
/etc/ssh/
/etc/systemd/
/etc/php/
/etc/mysql/
```
So when you modify:
```
/etc/nginx/
```
you are modifying Nginx configuration.

15. Your Nginx Configuration

You have worked with:
```
/etc/nginx/sites-enabled/
```
This is part of:
```
/etc
   ↓
nginx
   ↓
configuration
```
For example:
```
/etc/nginx/sites-enabled/templates.cresignsys.com
```
can contain the Nginx server configuration for that website.

16. /var

/var is used for variable/changing system data.

Examples:
```
/var/log
/var/lib
/var/cache
```
The word “variable” means the contents can change during normal operation.

17. /var/log

This directory contains logs.

For example:
```
/var/log/nginx/
```
may contain:
```
access.log
error.log
```
You can inspect them with:
```
sudo tail -f /var/log/nginx/error.log
```
This is extremely useful when troubleshooting websites.

18. /var/lib

This is commonly used for persistent application/system state.

For example, databases and system services may maintain data under /var/lib.

The exact location depends on the software.

19. /var/cache

This contains cache data maintained by various applications.

Caches can often be regenerated, although you should never assume every file under a cache directory is safe to delete without understanding the specific application.

20. /home

This normally contains users’ home directories.

Example:
```
/home/ubuntu
```
Inside:
```
/home/ubuntu/
```
you may have:
```
Documents
Downloads
scripts
projects
```
21. /root

This is normally the home directory of the root user:
```
/root
```
Remember the distinction:
```
/
   = filesystem root

root
   = privileged Linux user
```
and:
```
/root
   = root user's home directory
```
These are three related but different concepts.

22. /tmp

This directory is commonly used for temporary files.
```
/tmp
```
Applications can use it for temporary data.

Important:

Do not assume anything placed in /tmp will persist permanently.

Temporary-directory cleanup behavior depends on the system configuration.

23. /boot

This contains files related to booting the operating system.

For example:
```
/boot
```
may contain:
```
Linux kernel
initramfs
bootloader-related files
```
The exact arrangement depends on the boot architecture.

24. /dev

This is a very interesting directory.
```
/dev
```
contains device nodes representing devices and device interfaces.

Examples can include:
```
/dev/null
/dev/zero
/dev/random
```
and storage/device nodes.

Linux uses the filesystem interface to expose many devices to user-space programs.

25. /dev/null

One famous Linux device is:
```
/dev/null
```
Anything written to it is discarded.

For example:
```
echo "hello" > /dev/null
```
The text disappears.

Conceptually:
```
Program
 ↓
/dev/null
 ↓
discard
```
26. /dev/zero

Another special device:
```
/dev/zero
```
provides a stream of zero-valued bytes when read.

This illustrates an important Linux idea:

Many devices and kernel interfaces can be exposed through file-like interfaces.

27. /proc

Now we reach something very important.
```
/proc
```
is not an ordinary disk directory.

It is a virtual filesystem provided by the kernel.

It exposes information about:
```
Processes
CPU
Memory
Kernel state
System information
```
For example:
```
cat /proc/cpuinfo
```
can display processor information.

28. /proc/meminfo

Try:
```
cat /proc/meminfo
```
You can see information about memory.

Conceptually:
```
Linux kernel
      ↓
/proc
      ↓
Information exposed to user space
```
The data is dynamically generated by the kernel.

29. /proc/PID

Every process has a process ID, commonly called:
```
PID
```
Suppose a process has:
```
PID = 1234
```
Linux can expose information under:
```
/proc/1234/
```
Conceptually:
```
Process
  ↓
PID
  ↓
/proc/PID
```
This becomes extremely useful when learning process management.

30. /sys

Similar to /proc, Linux provides:
```
/sys
```
which is a virtual filesystem exposing information about devices, drivers, buses, and kernel device models.

Conceptually:
```
Hardware
   ↓
Kernel device model
   ↓
/sys
   ↓
User-space tools
```
31. /run
```
/run
```
contains runtime state.

It is generally temporary and is usually populated during boot.

Examples can include:
```
PID information
Sockets
Runtime service state
```
32. /media

This is commonly used as a location for automatically mounted removable media.

For example:
```
/media/username/USB
```
33. /mnt

Traditionally used as a temporary or manually managed mount point.

For example:
```
/mnt/data
```
could be used for a mounted filesystem.

34. /opt
```
/opt
```
is commonly used for optional/add-on application software.

For example, some third-party software may install under:
```
/opt/application/
```
35. /srv
```
/srv
```
is intended for data served by the system.

For example, a service could theoretically use:
```
/srv/www/
```
However, server administrators often choose other directory structures based on their architecture.

Your:
```
/storage/websites/
```
is perfectly valid as a custom hosting layout.

36. /storage

This is important for your setup.

Unlike directories such as /etc or /var, /storage is not a mandatory standard Linux directory.

You or your hosting architecture created it for your own purpose.

For example:
```
/storage
   └── websites
       ├── site1
       ├── site2
       └── site3
```
This is a good example of Linux’s flexibility.

37. Your Hosting Structure

Your architecture can be represented as:
```
/
└── storage
    └── websites
        └── templates.cresignsys.com
            └── public
                ├── index.php
                ├── wp-admin
                ├── wp-content
                ├── wp-includes
                └── wp-config.php
```
This is the physical filesystem organization of the website files.

38. Filesystem vs Website URL

This distinction is extremely important.

Your filesystem path might be:
```
/storage/websites/templates.cresignsys.com/public/
```
But the user sees:
```
https://templates.cresignsys.com/
```
These are not the same thing.

Nginx creates the connection between them.

Conceptually:
```
Browser URL
     ↓
Nginx configuration
     ↓
Filesystem path
```
39. Nginx root

A typical Nginx configuration might contain something conceptually like:
```
server {
    server_name templates.cresignsys.com;

    root /storage/websites/templates.cresignsys.com/public;
}
```
This tells Nginx:

Use this filesystem directory as the document root for this virtual host.

Therefore:
```
https://templates.cresignsys.com/
```
can map to:
```
/storage/websites/templates.cresignsys.com/public/
```
40. One URL Request

Suppose someone requests:
```
https://templates.cresignsys.com/about.html
```
Conceptually:
```
Browser
 ↓
DNS
 ↓
Server IP
 ↓
TCP 443
 ↓
TLS
 ↓
Nginx
 ↓
server_name
 ↓
root directory
 ↓
about.html
```
The physical file might be:
```
/storage/websites/templates.cresignsys.com/public/about.html
```
41. Why /etc and /storage Are Different

This distinction will become extremely useful.
```
/etc
 ↓
Configuration
```
while:
```
/storage
 ↓
Your website data
```
For example:
```
/etc/nginx/
```
contains instructions telling Nginx how to serve the site.

While:
```
/storage/websites/templates.cresignsys.com/public/
```
contains the website itself.

42. Configuration vs Data

This is a general systems principle:
```
Configuration
      ↓
How the software should behave

Data
      ↓
What the software works with
```
For your website:
```
Nginx configuration
      ↓
How requests are handled

WordPress files/database
      ↓
Website content
```
43. Logs Are Another Layer

Nginx also produces logs:
```
/var/log/nginx/
```
So we have:
```
/etc/nginx/
     ↓
Configuration

/storage/websites/
     ↓
Website data

/var/log/nginx/
     ↓
Operational records
```
These three locations have completely different purposes.

44. A Practical Example

Suppose the website gives:
```
502 Bad Gateway
```
Don’t immediately edit WordPress.

First consider:
```
Nginx
 ↓
PHP-FPM
```
Check:
```
sudo systemctl status nginx
```
Then:
```
sudo systemctl status php*-fpm
```
And inspect:
```
sudo tail -f /var/log/nginx/error.log
```
Now you are troubleshooting according to the architecture.

45. Another Example: 404

Suppose:
```
https://templates.cresignsys.com/test.html
```
returns:
```
404 Not Found
```
Possible causes include:
```
Wrong Nginx root
Wrong URL
File does not exist
Nginx location rule
WordPress routing
```
First understand which layer is responsible.

46. Filesystem Hierarchy to Remember

For your web-hosting work, memorize these first:
```
/
├── etc       → configuration
├── var       → changing data/logs
├── usr       → installed user-space software
├── home      → user home directories
├── root      → root user's home
├── tmp       → temporary data
├── dev       → device interfaces
├── proc      → kernel/process information
├── sys       → kernel/device information
├── run       → runtime state
└── storage   → your custom hosting storage
```
47. The Deeper Architecture

Now connect today’s lesson with everything before it:
```
HARDWARE
   ↓
CPU / RAM / SSD
   ↓
Linux Kernel
   ↓
Virtual Filesystem Interface
   ↓
Filesystem
   ↓
Directories
   ↓
Configuration / Data / Logs
   ↓
Applications
```
And for your hosting server:
```
Linux
 │
 ├── /etc/nginx
 │       ↓
 │   Nginx configuration
 │
 ├── /var/log/nginx
 │       ↓
 │   Nginx logs
 │
 └── /storage/websites
         ↓
     Website files
```
48. Most Important Concept

Don’t memorize directories as a random list.

Understand their purpose:
```
/etc
  = "How should the system/software behave?"

/var
  = "What changing operational data exists?"

/usr
  = "What software is installed?"

/home
  = "Where are user files?"

/dev
  = "How does user space interact with devices?"

/proc
  = "What does the kernel expose about processes/system?"

/sys
  = "What does the kernel expose about devices/system structure?"

/storage
  = "Where did we choose to keep our hosting data?"
```
49. Quick Check

What is /?

The root of the Linux filesystem hierarchy.

What is /etc?

Primarily system and application configuration.

What is /var/log?

A common location for system/application logs.

What is /usr?

A major hierarchy containing user-space programs, libraries, and shared data.

What is /proc?

A kernel-provided virtual filesystem exposing process and system information.

What is /sys?

A kernel-provided virtual filesystem exposing device/kernel information.

What is /storage?

In your server, a custom directory used for hosting data.

Where are your website files?

For example:
```
/storage/websites/templates.cresignsys.com/public/
```
Where is Nginx configuration?

Commonly under:
```
/etc/nginx/
```
Where are Nginx logs?

Commonly:
```
/var/log/nginx/
```
Next Lesson — 018

Linux Users, Groups, Ownership and Permissions

This is the next essential foundation before managing multiple websites.

We will build from the deepest basics:
```
User
 ↓
Group
 ↓
Process identity
 ↓
File owner
 ↓
Permissions
 ↓
r / w / x
 ↓
chmod
 ↓
chown
 ↓
chgrp
 ↓
sudo
 ↓
www-data
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
```
Then we will answer an important real-world question:

Why can Nginx/PHP sometimes read a WordPress file but cannot write to it?

That leads directly into secure multi-domain web hosting.
August 13, 2026

Program	Process
Stored code	Running instance
Exists on storage	Uses RAM
Passive	Active
Executable file	OS-managed execution
Can be started	Is already running

Category: Uncategorized

CresignSys Learn — Lesson 026

DNS Records Deep Dive

1. DNS Is Made of Records

2. The Most Important Records

3. A Record

4. What Happens After an A Record?

5. AAAA Record

6. Why Both Can Exist

7. CNAME

Canonical Name

8. CNAME Does Not Mean Redirect

9. CNAME Example

10. CNAME and IP Address

11. NS Record

Name Server

12. Why NS Is Important

13. Delegation

14. SOA Record

Start of Authority

15. DNS Serial Number

16. MX Record

Mail Exchange

17. Website vs Email

18. TXT Record

19. SPF

Sender Policy Framework

20. DKIM

DomainKeys Identified Mail

21. DMARC

Domain-based Message Authentication, Reporting, and Conformance

22. CAA Record

Certification Authority Authorization

23. CAA and Let’s Encrypt

24. PTR Record

Reverse DNS

25. Reverse DNS

26. Why Reverse DNS Matters

27. SRV Record

28. DNS Record Comparison

29. A Realistic Hosting Zone

30. DNS Does Not Create the Website

31. DNS + Nginx

32. Same IP, Multiple Websites

33. One Server, Many Domains

34. Domain → DNS → Nginx

35. Why the Hostname Is Important

SNI

36. SNI

37. Certificate + SNI

38. DNS Does Not Choose the Certificate

39. Practical DNS Inspection

40. Short Form

41. Follow CNAMEs

42. Check Your Nameservers

43. Check the Authoritative Answer

44. The DNS Hierarchy as a Tree

45. Subdomains Are Just Labels

46. DNS Doesn’t Require Separate Servers

47. Different Servers Are Also Possible

48. DNS and Cloud Hosting

49. Security Rules

50. The Three Different Configurations

DNS

Cloud/network firewall

Nginx

51. Example Failure

52. Another Failure

53. Another Failure

54. Your Hosting Platform

55. The Next Level: DNS Resolution in Detail

56. Practical Exercise for Your Server

Lesson 026 Summary

Next Lesson — 027

DNS Resolution — What Happens Inside the Resolver?

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

46. DNS Command: `dig`

52. `dig +trace`