กระบวนการแปลงชื่อ DNS ทั้งหมด — จากเบราว์เซอร์ถึง root server ต้องผ่านกี่ขั้น?

1. ขั้นตอนทั้งหมด 8 ขั้น

┌─────────────────────────────────────────────────────────────┐
│  เบราว์เซอร์ (Chrome / Firefox) — พิมพ์ google.com              │
└────────────────┬────────────────────────────────────────────┘
                 │ ① แคช DNS ของเบราว์เซอร์ (Chrome ~60s)
                 ↓ miss
┌─────────────────────────────────────────────────────────────┐
│  stub resolver ของ OS + แคช DNS ของระบบ                     │
└────────────────┬────────────────────────────────────────────┘
                 │ ② แคชของระบบ miss → ส่ง query UDP ไปยังเราเตอร์
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  DNS forwarding ของเราเตอร์ที่บ้าน + แคชของเราเตอร์              │
└────────────────┬────────────────────────────────────────────┘
                 │ ③ แคชของเราเตอร์ miss → ส่งต่อไปยัง recursive resolver ของ ISP
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  recursive resolver ของ ISP / สาธารณะ                       │
│  (1.1.1.1 / 8.8.8.8 / 223.5.5.5)                            │
│  แคช hit: ตอบกลับทันที ทั้งกระบวนการใช้เวลา 1-5ms                 │
│  แคช miss: เข้าสู่ขั้นตอน “ค้นหาเต็มรูปแบบ” ด้านล่าง                  │
└────────────────┬────────────────────────────────────────────┘
                 │ ④ ถาม root NS ว่า “google.com อยู่ที่ไหน?”
                 ↓
        root nameserver 13 กลุ่ม (a~m.root-servers.net)
                 │ ⑤ ตอบว่า “ไม่รู้ ไปถาม NS ของ .com: a.gtld-servers.net”
                 ↓
        เซิร์ฟเวอร์ authoritative ของ TLD .com (Verisign)
                 │ ⑥ ตอบว่า “ฉันก็มีไม่ครบ ไปถาม NS ของ google.com: ns1.google.com”
                 ↓
        เซิร์ฟเวอร์ authoritative ของ google.com (Google ดูแลเอง)
                 │ ⑦ ตอบว่า “เรคคอร์ด A ของ google.com = 142.250.x.x”
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ⑧ recursive resolver เก็บคำตอบไว้ในแคช (ตาม TTL)             │
│     แล้วส่งกลับให้ไคลเอนต์ — ทุกชั้นที่ผ่านมา                          │
│     ก็เก็บสำเนาไว้ในแคชของตัวเองด้วย                             │
└─────────────────────────────────────────────────────────────┘

ข้อสังเกตสำคัญ: ในสถานการณ์จริง แทบไม่เคยต้องผ่านครบทั้ง 8 ขั้น ที่อยู่ IP ของเว็บไซต์ใหญ่ ๆ แทบจะอยู่ในแคชของ recursive resolver เสมอ ผู้ใช้ทั่วไปจึงได้คำตอบตั้งแต่ขั้นที่ ④ มีเพียงโดเมนที่ไม่ค่อยมีคนใช้ เว็บไซต์ที่นาน ๆ จะมีคนเข้า TTL ที่หมดอายุ หรือโดเมนที่เพิ่งจดใหม่เท่านั้นที่จะต้องผ่านขั้นตอนทั้งหมด

2. อธิบายแคช DNS ทั้ง 5 ชั้น

ตั้งแต่ DNS ถูกออกแบบในปี 1983 ก็คำนึงถึงข้อเท็จจริงข้อหนึ่งไว้แล้ว: การสอบถาม (lookup) มีมากกว่าการเปลี่ยนแปลงถึง 100,000 เท่า แคชจึงมีอยู่ทุกที่ โดยแต่ละชั้นจะเก็บข้อมูลไว้ตามระยะเวลา TTL (Time To Live)

3. การสอบถามแบบ Recursive เทียบกับ Iterative — แนวคิดสำคัญ

3.1 แบบ Recursive (เรียกซ้ำ)

ไคลเอนต์ (เบราว์เซอร์ / stub ของ OS) บอก recursive resolver ของ ISP ว่า: “ช่วยหา IP ของ google.com ให้ที ฉันไม่สนว่าคุณจะทำอย่างไร” recursive resolver ต้องค้นหาให้ครบทั้งกระบวนการและส่งผลลัพธ์สุดท้ายกลับมา

3.2 แบบ Iterative (วนซ้ำ)

เมื่อ recursive resolver คุยกับ root, TLD และเซิร์ฟเวอร์ authoritative การสื่อสารนั้นจะเป็นแบบ iterative — มันถาม root แล้ว root บอกว่า “ไปถาม .com” มันก็ไปถาม .com แล้ว .com บอกว่า “ไปถาม google” มันก็ไปถาม google แต่ละขั้นข้ามไปเพียงทีละหนึ่ง hop — ไม่ใช่แบบ “ฉันถาม root แล้ว root จัดการทุกอย่างให้”

4. ทดสอบด้วยตัวเอง — dig +trace

dig +trace จะบังคับให้ค้นหาแบบ iterative เต็มรูปแบบและแสดงทุกขั้น:

$ dig +trace cleanip.io

; <<>> DiG 9.10.6 <<>> +trace cleanip.io
;; global options: +cmd

; ① hop ที่ 1 — สอบถาม root (.)
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
... (เรคคอร์ด NS ของ root 13 รายการ)
;; Received 525 bytes from 127.0.0.53#53 in 5 ms

; ② hop ที่ 2 — สอบถาม TLD .io
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      b0.nic.io.
... (NS 4 ตัวของ .io)
;; Received 822 bytes from 198.41.0.4#53(a.root-servers.net) in 121 ms

; ③ hop ที่ 3 — สอบถามเซิร์ฟเวอร์ authoritative ของ cleanip.io
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 109 bytes from 156.154.150.6#53(a0.nic.io) in 53 ms

; ④ ได้คำตอบในที่สุด
cleanip.io.             300     IN      A       104.21.x.x
cleanip.io.             300     IN      A       172.67.x.x
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 154 bytes from 173.245.59.108#53(nolan.ns.cloudflare.com) in 12 ms

อธิบายผล:

• ทั้งกระบวนการใช้เวลา 5 + 121 + 53 + 12 = 191 ms — การสอบถามครั้งแรกที่ยังไม่มีแคชช้าจริง ๆ
• แต่ถ้าสอบถามโดเมนเดิมอีกครั้งในวินาทีถัดมา จะใช้เวลาเพียง 1-2 ms เพราะแคช recursive ของ ISP มีข้อมูลอยู่แล้ว (TTL 300 วินาที)
• 104.21.x.x / 172.67.x.x เป็นที่อยู่ CDN ของ Cloudflare — IP ต้นทางจริงของเว็บไซต์เราถูกซ่อนอยู่หลัง CDN

5. อธิบาย TTL — แคชอยู่ได้นานแค่ไหนกันแน่

TTL (Time To Live) คือฟิลด์ที่เซิร์ฟเวอร์ authoritative ใช้บอก recursive resolver ทุกตัวว่า “แคชไว้ได้นานสุดเท่านี้” โดยมีหน่วยเป็นวินาที

หมายเหตุ: TTL คือ “ระยะเวลาแคชสูงสุด” — resolver แต่ละตัวล้างแคชก่อนกำหนดได้ แต่ขยายเวลาไม่ได้ ดังนั้นแม้ TTL ที่ฝั่ง authoritative กำหนดจะเป็น 1 ชั่วโมง resolver บางตัวก็อาจสอบถามใหม่หลังผ่านไปเพียง 10 นาที

ข้อควรระวัง: ก่อนเปลี่ยน IP ให้ลด TTL ลงก่อน (1-5 นาที) และรอให้ TTL เดิมหมดอายุทั้งหมดก่อนจึงสลับ — ไม่อย่างนั้นผู้ใช้บางส่วนจะยังเข้า IP เก่าต่อไปนานกว่าหนึ่งชั่วโมง

6. ตารางสรุปประเภทเรคคอร์ด DNS

7. การปรับแต่ง DNS — ทำให้การแปลงชื่อเร็วขึ้นได้อย่างไร

7.1 เลือก recursive resolver ที่อยู่ใกล้

ในจีนแผ่นดินใหญ่: 223.5.5.5 (Alibaba) / 119.29.29.29 (DNSPod) resolve เว็บไซต์ในจีนได้เร็วที่สุด ต่างประเทศ: 1.1.1.1 (Cloudflare มีโหนด anycast ครอบคลุมกว้างที่สุด) / 8.8.8.8 (Google) ดูรวม resolver ของ DNS สาธารณะ.

7.2 เปิดใช้ DoH (DNS-over-HTTPS)

การเข้ารหัสคำขอ DNS ผ่าน HTTPS ทำให้ ISP มองไม่เห็นหรือแก้ไขคำขอไม่ได้ (ป้องกันการ hijack แบบ NXDOMAIN) Chrome, Firefox และ Edge รองรับทั้งหมด — เพียงเปิดในการตั้งค่า

7.3 อุ่นเครื่องล่วงหน้า (DNS Prefetch)

เพิ่ม <link rel="dns-prefetch" href="//api.example.com"> ลงใน <head> ของเว็บไซต์ เพื่อให้เบราว์เซอร์ resolve ล่วงหน้าในช่วงที่ว่าง — เมื่อถึงคำขอจริงก็จะ hit แคชทันที

7.4 ใช้ CDN + Anycast NS

วาง NS แบบ authoritative ไว้บน Anycast (Cloudflare / Route 53) เพื่อให้ผู้ใช้ทั่วโลกเข้าถึงอินสแตนซ์ที่ใกล้ที่สุด — ลดความหน่วงของขั้นที่ ③ จาก 100ms เหลือ 10ms

7.5 ตั้งค่า TTL อย่างเหมาะสม

ตั้ง TTL ยาว (1-7 วัน) สำหรับเรคคอร์ดที่ไม่ค่อยเปลี่ยน (NS / MX) และตั้ง TTL สั้น (5-60 นาที) สำหรับเรคคอร์ด A ที่อาจต้องสลับ

8. คำถามที่พบบ่อย

8.1 เปลี่ยน DNS แล้วแต่ไม่มีผล — ทำไม?

ก่อนอื่นให้ดูว่า TTL ปัจจุบันคือเท่าไร หลังเปลี่ยน DNS แล้ว recursive resolver ทุกตัวจะยังส่ง IP เก่ากลับมาจนกว่า TTL เดิมจะหมดอายุ “การเผยแพร่ทั่วโลก” โดยทั่วไปใช้เวลาประมาณ 2 เท่าของ TTL (เผื่อกรณีที่ resolver แต่ละตัวไม่ซิงก์กัน)

• ฝั่งไคลเอนต์: ipconfig /flushdns (Windows) / sudo killall -HUP mDNSResponder (macOS)
• รอให้แคชของ recursive resolver สาธารณะหมดอายุ: 1.1.1.1 / 8.8.8.8 ต่างก็มีเครื่องมือ “purge” ของตัวเองสำหรับล้างแคชด้วยตนเอง

8.2 บางคนเข้าได้ บางคนเข้าไม่ได้ — DNS ถูกปนเปื้อน (DNS Pollution)

พบบ่อยเมื่อเข้าเว็บไซต์ต่างประเทศจากจีนแผ่นดินใหญ่ — GFW ฉีดคำตอบ DNS ปลอมเข้ามา / ISP ทำการ hijack คำขอ DNS การเปลี่ยนไปใช้ DoH (DNS แบบเข้ารหัสในเบราว์เซอร์) ช่วยเลี่ยงการปนเปื้อน DNS ได้เกือบทั้งหมด

8.3 จดโดเมนแล้วต้องรอนานแค่ไหนจึงจะใช้งานได้?

หลังจดทะเบียน หน่วยงานจดทะเบียน TLD (TLD registry) จะส่งเรคคอร์ด NS ของคุณขึ้นไปยังเซิร์ฟเวอร์ authoritative ระดับบนสุดของ .com / .net เป็นต้น — โดยทั่วไปใช้เวลา 15 นาทีถึง 24 ชั่วโมง ส่วนโดเมน .cn / .com.cn อาจต้องจดแจ้ง ICP (ICP filing) ก่อนจึงจะ resolve ได้ในจีนแผ่นดินใหญ่