Network
DNS & HTTP
Domain to IP Resolution
เจาะลึกกระบวนการ DNS resolution ทีละขั้นตอน — ตั้งแต่พิมพ์ domain จนได้ IP และเชื่อมต่อกับ server ได้สำเร็จ
1. Core Idea: DNS Resolution คืออะไร
DNS Resolution คือกระบวนการที่เกิดขึ้นเพื่อหา IP address จาก domain name เมื่อคุณพิมพ์ชื่อเว็บ ระบบจะค้นหาทีละชั้น — จากที่ใกล้ที่สุด (cache) ไปยังที่ไกลที่สุด (authoritative server) กระบวนการนี้เกิดขึ้นในเวลาไม่กี่มิลลิวินาที แต่ถ้า cache ยังมีคำตอบอยู่จะเสร็จทันทีโดยไม่ต้องถามใคร
2. Mental Model: ค้นหาหนังสือในห้องสมุดหลายชั้น
ลองนึกถึงการหาหนังสือในห้องสมุดขนาดใหญ่: - ก่อนอื่นดูโต๊ะตัวเอง (Browser cache) - ถ้าไม่มี ถามเพื่อนข้างๆ (OS cache) - ถ้าไม่รู้ ถามบรรณารักษ์ห้องนี้ (Resolver) - บรรณารักษ์ไปถามสำนักงานกลาง (Root DNS) - สำนักงานกลางชี้ไปห้องหมวดหมู่ที่ถูก (TLD DNS) - ห้องหมวดหมู่รู้ว่าชั้นไหน (Authoritative DNS) ยิ่งค้นลึกลงไป ยิ่งใช้เวลามากขึ้น — นั่นคือเหตุผลที่ cache มีความสำคัญ
DNS Resolution ค้นหาจาก cache ใกล้ที่สุดก่อน ถ้าไม่มีค่อยถามชั้นถัดไป
3. ลำดับขั้นตอน DNS Resolution
| ขั้น | ที่ค้นหา | ความเร็ว | ถ้าพบ |
|---|---|---|---|
| 1 | Browser DNS cache | < 1ms | ใช้เลย — เร็วที่สุด |
| 2 | /etc/hosts (OS) | < 1ms | ใช้เลย — override DNS |
| 3 | OS DNS cache | < 1ms | ใช้เลย |
| 4 | Recursive Resolver cache | 1–10ms | ตอบกลับทันที |
| 5 | Root DNS Server | 10–50ms | บอก TLD server |
| 6 | TLD DNS Server (.com) | 10–50ms | บอก Authoritative NS |
| 7 | Authoritative DNS | 10–50ms | ตอบ IP จริง |
ในชีวิตจริง ขั้น 1–4 จบงานส่วนใหญ่ — ขั้น 5–7 เกิดน้อยมากเพราะ resolver cache ดูแลไว้
4. /etc/hosts — ด่านพิเศษก่อน DNS
ไฟล์ /etc/hosts (Windows: C:\Windows\System32\drivers\etc\hosts) คือ mapping แบบ static ที่ OS อ่านก่อนถาม DNS ถ้า domain ปรากฏในไฟล์นี้ — OS ใช้ IP ที่ระบุเลย ไม่ถาม DNS server เลย
ใช้ทดสอบ local development หรือ block domain
# /etc/hosts
127.0.0.1 localhost
::1 localhost
# Dev environment — ชี้ domain ไปที่ local server
127.0.0.1 myapp.local
127.0.0.1 api.myapp.local
# Block domain (redirect ไป nowhere)
0.0.0.0 ads.example.com5. Recursive vs Iterative Resolution
| แบบ | วิธีทำงาน | ใครทำงาน | ใช้ที่ |
|---|---|---|---|
| Recursive | Client ถามครั้งเดียว Resolver ทำทุกอย่างแทน | Recursive Resolver | Browser → Resolver (8.8.8.8) |
| Iterative | Resolver ถามทีละชั้น แต่ละชั้นตอบ referral | Resolver เดินเอง | Resolver → Root → TLD → Auth |
ในทางปฏิบัติ: Browser ใช้ Recursive resolution (ถามครั้งเดียวได้คำตอบ) Resolver ใช้ Iterative resolution (ถามทีละชั้นเองจนได้คำตอบ)
6. Worked Example: dig แสดงการ resolution จริง
คำสั่ง dig ให้ข้อมูล DNS ละเอียดกว่า nslookup
# ถาม A record ของ google.com
$ dig google.com
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 300 IN A 142.250.x.x
;; Query time: 12 msec
;; SERVER: 8.8.8.8#53
;; WHEN: ...
# แปลความ:
# 300 = TTL (วินาที)
# IN = Internet class
# A = Record type
# 12 msec = ใช้เวลา 12ms ถึง resolver
# ดู trace ทีละขั้น (Iterative จาก root)
$ dig +trace google.com# MX record (mail server)
dig google.com MX
# TXT record (SPF, verification)
dig google.com TXT
# NS record (nameservers)
dig google.com NS
# Reverse DNS (IP → domain)
dig -x 8.8.8.8
# ถาม DNS server เฉพาะ
dig @1.1.1.1 google.com7. Practical Notes: จุดสับสนของมือใหม่
- เปลี่ยน DNS record แล้วยังไม่เห็นผล → ดู TTL เดิม อาจต้องรอนาน
- flush DNS cache บน macOS: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
- /etc/hosts override DNS ทำให้เหมาะทดสอบ domain ก่อน go-live จริง
- DNS lookup failure ≠ เว็บล่ม — ตรวจว่า DNS ใช้งานได้: ping 8.8.8.8 ก่อน
- NXDOMAIN error แปลว่า domain ไม่มีอยู่ใน DNS ไม่ใช่เว็บไม่ response
8. Recap + เชื่อมไปบทถัดไป
- DNS Resolution ค้นหา IP จาก cache ใกล้ที่สุดก่อน ถ้าไม่มีค่อยถามชั้นถัดไป
- /etc/hosts override DNS — ใช้ทดสอบ local development ได้
- Browser ใช้ Recursive, Resolver ใช้ Iterative เพื่อถามทีละชั้น
- dig ใช้ debug DNS ได้ดีกว่า nslookup — ดู TTL, trace, record types
- บทถัดไปจะอธิบาย HTTP vs HTTPS — protocol หลักที่ browser ใช้ดึงเนื้อหาเว็บ