1. Mục tiêu

Sau lab này, bạn cần hiểu được:

• DNS là gì và dùng để làm gì.
• Domain được phân giải thành IP như thế nào.
• DNS Record cơ bản.
• HTTP/HTTPS hoạt động như thế nào.
• HTTP Status Code.
• Header và Body.
• Cách dùng dig, nslookup, curl.
• Debug lỗi từ Domain → DNS → Server → HTTP.
• Phân biệt lỗi DNS với lỗi Network và lỗi Application.

---

2. Tại sao cần DNS?

Ở Lab 6, chúng ta truy cập server bằng IP:

http://192.168.1.100:8080

Nhưng thực tế rất khó nhớ hàng trăm địa chỉ IP.

Thay vào đó:

http://api.example.com

DNS có nhiệm vụ biến:

api.example.com
       ↓
192.168.1.100

Có thể hiểu đơn giản:

DNS giống như danh bạ điện thoại của Internet.

Bạn nhớ:

google.com

thay vì phải nhớ IP của Google.

---

3. Request thực tế hoạt động như thế nào?

Khi bạn chạy:

curl https://api.example.com

một cách đơn giản có thể hình dung:

	Ảnh Minh hoạ

Đây là flow cực kỳ quan trọng.

Khi debug production, chúng ta thường lần lượt kiểm tra từng tầng này.

---

4. DNS hoạt động như thế nào?

Ví dụ:

api.example.com

DNS sẽ tìm record tương ứng.

Ví dụ:

api.example.com
       ↓
203.0.113.10

Sau đó client kết nối tới:

203.0.113.10:443

vì HTTPS mặc định sử dụng port:

443

---

5. DNS Record cơ bản

Bạn sẽ thường gặp:

Record	Ý nghĩa
A	Domain → IPv4
AAAA	Domain → IPv6
CNAME	Domain → Domain khác
MX	Mail server
TXT	Text/verification/configuration
NS	Name Server

Ví dụ:

api.example.com
      │
      └── A
           ↓
      203.0.113.10

Còn:

www.example.com
      │
      └── CNAME
           ↓
      example.com

Cần nhớ

Ở lab này, quan trọng nhất:

A
CNAME

---

6. Thực hành DNS với dig

Cài đặt nếu cần:

sudo apt install dnsutils

Kiểm tra:

dig example.com

Bạn sẽ thấy phần:

ANSWER SECTION

Ví dụ:

example.com.    300    IN    A    93.184.216.34

Có thể đọc:

example.com
    ↓
A record
    ↓
93.184.216.34

---

7. Chỉ lấy IP

Thay vì đọc toàn bộ output:

dig +short example.com

Ví dụ:

93.184.216.34

Đây là command rất tiện khi troubleshooting.

---

8. Kiểm tra các loại DNS Record

A record:

dig example.com A

AAAA:

dig example.com AAAA

CNAME:

dig www.example.com CNAME

MX:

dig example.com MX

TXT:

dig example.com TXT

---

9. nslookup

Một công cụ khác:

nslookup example.com

Có thể dùng:

nslookup google.com

Tuy nhiên trong môi trường DevOps/Linux:

dig thường cho output chi tiết và hữu ích hơn khi troubleshooting DNS.

---

10. DNS Resolver

Khi bạn chạy:

dig example.com

máy của bạn cần hỏi một DNS resolver.

Có thể hình dung:

	Ảnh Minh hoạ

Kiểm tra DNS resolver đang được sử dụng:

resolvectl status

Một số hệ thống cũng có:

cat /etc/resolv.conf

Bạn có thể thấy:

nameserver 192.168.1.1

hoặc một DNS resolver khác.

---

11. DNS Cache

DNS không phải lúc nào cũng hỏi lại server.

Kết quả DNS thường được cache dựa trên:

TTL

Ví dụ:

example.com
TTL = 300

có nghĩa kết quả có thể được cache trong khoảng:

300 seconds

Điều này giải thích tại sao:

Bạn vừa thay đổi DNS nhưng một số máy vẫn nhận IP cũ.

Đây là một vấn đề rất thường gặp khi migrate domain hoặc server.

---

12. Thực hành — Tạo Web Server

Bây giờ chúng ta kết hợp DNS với HTTP.

Trên server:

mkdir ~/lab7
cd ~/lab7
echo "Hello from Lab 7" > index.html

Chạy:

python3 -m http.server 8080

Kiểm tra:

curl http://localhost:8080

Kết quả:

Hello from Lab 7

---

13. HTTP là gì?

HTTP là protocol được sử dụng để client giao tiếp với web server.

Một request đơn giản:

Client
   │
   │ GET /users
   ▼
Server
   │
   │ 200 OK
   ▼
Client

Ví dụ:

GET /users HTTP/1.1
Host: api.example.com

Server trả về:

HTTP/1.1 200 OK
Content-Type: application/json

và body:

[
  {
    "id": 1,
    "name": "John"
  }
]

---

14. HTTP Request gồm những gì?

Một request cơ bản có:

HTTP Request
│
├── Method
├── URL / Path
├── Headers
└── Body

Ví dụ:

POST /api/todos HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "title": "Learn DevOps"
}

---

15. HTTP Method

Các method thường gặp:

Method	Mục đích
GET	Lấy dữ liệu
POST	Tạo dữ liệu
PUT	Cập nhật
PATCH	Cập nhật một phần
DELETE	Xóa

Ví dụ:

GET /api/todos

→ lấy danh sách Todo.

POST /api/todos

→ tạo Todo.

---

16. HTTP Status Code

Đây là thứ DevOps gặp hàng ngày.

2xx — Thành công

200 OK
201 Created
204 No Content

3xx — Redirect

301 Moved Permanently
302 Found
304 Not Modified

4xx — Client Error

400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found

5xx — Server Error

500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

Cần nhớ:

2xx → Success
3xx → Redirect
4xx → Client/request problem
5xx → Server/upstream problem

---

17. Thực hành với curl

Kiểm tra HTTP:

curl http://localhost:8080

Xem HTTP headers:

curl -I http://localhost:8080

Ví dụ:

HTTP/1.0 200 OK
Content-type: text/html
Content-Length: 17

---

18. curl -v — Công cụ rất quan trọng

Chạy:

curl -v http://localhost:8080

Bạn có thể thấy:

* Connected to localhost
> GET / HTTP/1.1
> Host: localhost:8080
>
< HTTP/1.0 200 OK
< Content-Type: text/html

Điều này giúp bạn biết:

DNS?
 ↓
Connection?
 ↓
Request?
 ↓
Response?

Trick thực tế

Khi một API "không hoạt động", đừng chỉ mở browser.

Hãy thử:

curl -v https://api.example.com/health

Bạn sẽ nhìn thấy nhiều thông tin hơn.

---

19. Host Header

HTTP request có:

Host: api.example.com

Điều này đặc biệt quan trọng khi một server chạy nhiều domain.

Ví dụ:

Server
203.0.113.10
      │
      ├── api.example.com
      │
      └── admin.example.com

Cùng một IP nhưng web server có thể trả về application khác nhau dựa trên:

Host

Đây là nền tảng của virtual host và reverse proxy.

---

20. DNS không phải HTTP

Đây là lỗi tư duy rất phổ biến.

Nếu:

dig api.example.com

trả về IP:

203.0.113.10

thì chỉ chứng minh:

DNS hoạt động.

Nó không chứng minh:

HTTP hoạt động
Application hoạt động
Port 443 mở
Server khỏe

Phải kiểm tra tiếp:

curl -v https://api.example.com

---

21. Debug theo tầng

Giả sử:

curl https://api.example.com

bị lỗi.

Đừng đoán.

Bước 1 — DNS

dig +short api.example.com

Không có IP?

→ Debug DNS.

---

Bước 2 — Network

Có IP rồi:

ping <IP>

Hoặc:

ip route get <IP>

---

Bước 3 — Port

HTTPS:

nc -vz <IP> 443

HTTP:

nc -vz <IP> 80

---

Bước 4 — HTTP

curl -v https://api.example.com

---

Bước 5 — Application

Nếu nhận:

HTTP/1.1 500 Internal Server Error

thì:

DNS       ✓
Network   ✓
Port      ✓
HTTP      ✓
Application ✗

Lúc này hãy xem application logs.

---

22. Một lỗi thực tế rất hay gặp

Giả sử:

curl http://api.example.com

trả về:

Could not resolve host

Đừng kiểm tra:

Spring Boot
Docker
Kubernetes

ngay lập tức.

Hãy kiểm tra:

dig api.example.com

Nếu DNS không resolve được thì application có thể hoàn toàn bình thường.

---

23. Một lỗi khác

curl https://api.example.com

trả về:

Connection timed out

DNS có thể vẫn hoàn toàn bình thường.

Kiểm tra:

dig +short api.example.com

Nếu có IP:

203.0.113.10

thì DNS đã hoạt động.

Tiếp theo:

nc -vz 203.0.113.10 443

Nếu timeout:

DNS       ✓
Network   ?
Port 443  ✗

Lúc này hãy kiểm tra firewall, routing hoặc security group.

---

24. Một lỗi khác nữa

HTTP/1.1 502 Bad Gateway

Đây là lỗi rất quan trọng khi làm DevOps.

Có thể có kiến trúc:

Client
  │
  ▼
Nginx
  │
  ▼
Backend

Nếu Nginx không kết nối được Backend:

Client
  │
  ▼
Nginx
  │
  X
Backend

Nginx có thể trả:

502 Bad Gateway

Khi đó DNS và frontend proxy có thể vẫn hoạt động.

Vấn đề nằm ở upstream/backend.

---

25. Thực hành — Debug toàn bộ flow

Giả sử:

Domain:
api.example.com

IP:
192.168.1.100

Application:
Port 8080

Thực hiện:

1. DNS

dig +short api.example.com

2. Routing

ip route get 192.168.1.100

3. Port

nc -vz 192.168.1.100 8080

4. HTTP

curl -v http://192.168.1.100:8080

5. Domain

curl -v http://api.example.com

Sau đó so sánh:

curl IP
curl Domain

Nếu:

curl IP      → OK
curl Domain  → FAIL

hãy nghĩ ngay tới:

DNS
Host header
Reverse proxy

---

26. Trick — Test Domain nhưng ép IP

Một kỹ thuật rất hữu ích khi debug DNS và reverse proxy:

curl --resolve api.example.com:443:192.168.1.100 \
https://api.example.com

Điều này có thể hiểu:

api.example.com
       ↓
Bỏ qua DNS
       ↓
192.168.1.100

nhưng vẫn gửi:

Host: api.example.com

Kỹ thuật này cực kỳ hữu ích khi:

• DNS chưa cập nhật.
• Test server mới.
• Test load balancer.
• Test reverse proxy.
• Migrate production server.

---

27. Thực hành --resolve

Giả sử server:

192.168.1.100

và domain:

api.example.com

Test:

curl --resolve api.example.com:80:192.168.1.100 \
http://api.example.com

Bạn đang kiểm tra:

Domain/Host
      +
IP cụ thể
      +
HTTP

mà không cần thay đổi DNS thật.

Đây là một trong những trick rất đáng nhớ khi troubleshooting production.

---

28. HTTP và HTTPS

HTTP:

http://example.com

thường dùng:

Port 80

HTTPS:

https://example.com

thường dùng:

Port 443

HTTPS = HTTP chạy trên TLS.

Mô hình đơn giản:

HTTP
 │
 ▼
TCP
 │
 ▼
Network

HTTPS:

HTTP
 │
 ▼
TLS
 │
 ▼
TCP
 │
 ▼
Network

TLS cung cấp encryption và authentication thông qua certificate.

Phần certificate/TLS sẽ chưa đào sâu trong lab này.

---

29. Kiến trúc thực tế

Một request production thường không đơn giản:

Client
  │
  ▼
DNS
  │
  ▼
Load Balancer
  │
  ▼
Reverse Proxy
  │
  ▼
Application
  │
  ▼
Database

Ví dụ:

User
 │
 │ https://api.example.com
 ▼
DNS
 │
 ▼
203.0.113.10
 │
 ▼
Load Balancer
 │
 ▼
Nginx
 │
 ▼
Spring Boot
 │
 ▼
PostgreSQL

Mỗi tầng đều có thể gây lỗi.

Vì vậy DevOps cần có khả năng xác định:

Request đang fail ở tầng nào?

---

30. Bài tập tổng hợp

Hãy tạo một web server:

mkdir ~/lab7
cd ~/lab7
echo "Hello DevOps" > index.html
python3 -m http.server 8080

Sau đó thực hiện:

curl http://localhost:8080

curl -I http://localhost:8080

curl -v http://localhost:8080

ss -lntp | grep 8080

Tiếp theo, dùng một máy khác truy cập:

curl -v http://<server-ip>:8080

Bạn cần giải thích được:

Client
  │
  │ TCP :8080
  ▼
Server
  │
  ▼
Python
  │
  ▼
index.html

---

31. Challenge — Tạo lỗi và tự debug

Case 1

Server chạy:

python3 -m http.server 8080

Client:

curl http://server:8081

Hãy tìm nguyên nhân.

---

Case 2

Server:

python3 -m http.server --bind 127.0.0.1 8080

Client từ máy khác không truy cập được.

Tìm nguyên nhân bằng:

ss -lntp

---

Case 3

Domain không truy cập được:

curl https://api.example.com

Hãy debug theo thứ tự:

dig
 ↓
ip route
 ↓
nc
 ↓
curl -v

---

32. Những command cần nhớ

Command	Mục đích
dig example.com	Query DNS
dig +short example.com	Lấy IP nhanh
dig example.com A	Query A record
dig example.com CNAME	Query CNAME
nslookup example.com	DNS lookup
curl URL	HTTP request
curl -I URL	Xem HTTP headers
curl -v URL	Debug HTTP
curl --resolve	Ép domain → IP
nc -vz host port	Test TCP port
ss -lntp	Xem listening ports
ip route	Xem routing

---

33. Kinh nghiệm thực tế

1. Đừng nhầm DNS với Network

DNS
→ Domain có resolve được không?

Network
→ Có đi tới IP được không?

Port
→ Service có nhận connection không?

HTTP
→ Application trả response gì?

---

2. curl -v là "con dao Thụy Sĩ" khi debug HTTP

Khi gặp:

API không hoạt động
Website không mở
502
503
Redirect bất thường

hãy thử:

curl -v URL

---

3. Test IP và Domain riêng biệt

curl http://192.168.1.100

và:

curl http://api.example.com

Nếu một cái thành công, một cái thất bại thì phạm vi cần debug đã nhỏ đi rất nhiều.

---

4. DNS có cache

Nếu vừa thay đổi DNS:

DNS Record
   ↓
Resolver Cache
   ↓
Client Cache

không phải máy nào cũng thấy thay đổi ngay.

Hãy kiểm tra:

dig +short domain.com

từ nhiều network/resolver khác nhau nếu cần.

---

34. Checklist

Sau Lab 7, bạn nên tự trả lời được:

✓ DNS là gì?
✓ DNS dùng để làm gì?
✓ A record là gì?
✓ CNAME là gì?
✓ TTL là gì?
✓ DNS resolver là gì?
✓ HTTP request gồm những gì?
✓ GET/POST/PUT/DELETE khác nhau thế nào?
✓ HTTP 200/301/400/401/403/404/500/502/503 nghĩa là gì?
✓ HTTP dùng port nào?
✓ HTTPS dùng port nào?
✓ curl -v dùng để làm gì?
✓ dig dùng để làm gì?
✓ Vì sao DNS resolve được nhưng HTTP vẫn fail?
✓ Vì sao curl IP OK nhưng curl domain fail?
✓ --resolve dùng để làm gì?

35. Kết quả cần đạt

Sau Lab 6:

IP
 ↓
Port
 ↓
Service

Sau Lab 7, bạn đã thêm:

Domain
   ↓
DNS
   ↓
IP
   ↓
Port
   ↓
HTTP
   ↓
Application

Từ đây, khi gặp:

https://api.example.com
       ↓
      FAIL

bạn không còn debug theo kiểu "thử restart server" mà có thể phân tích:

DNS?
  ↓
IP?
  ↓
Routing?
  ↓
Port?
  ↓
Web Server?
  ↓
Reverse Proxy?
  ↓
Application?

Đó chính là tư duy troubleshooting mà bạn sẽ cần rất nhiều khi bước sang Firewall, Docker, Kubernetes, Azure Application Gateway và production infrastructure.

Lab 8 — Firewall & Network Troubleshooting sẽ tiếp tục từ đây: chúng ta sẽ cố tình tạo các tình huống Connection refused, Connection timed out, port bị chặn bởi firewall và học cách xác định chính xác firewall đang chặn ở đâu.