ใช้ NSLookup / DNS Debug ปัญหา Network ให้ตรงจุด

ทำไม DNS = root cause บ่อยจัง

มีคำพูดในวงการ: "It's always DNS"

ปัญหา network ที่ลึกลับที่สุด — ส่วนใหญ่เป็น DNS แค่ดูไม่ออก

ตัวอย่าง:

API call timeout → DNS resolve ช้า
App connect database ไม่ได้ → DNS cache ตอบ IP เก่า
Email ส่งไม่ออก → SPF / MX record ผิด
Pod ใน K8s คุยกันไม่ได้ → CoreDNS ปัญหา

ทั้งหมดดูคล้าย "network down" แต่จริงๆ DNS

เครื่องมือพื้นฐาน

`dig` — เครื่องมือหลัก

dig example.com

ผลลัพธ์ตัวที่สำคัญ:

;; QUESTION SECTION:
;example.com.                  IN     A

;; ANSWER SECTION:
example.com.       300         IN     A      93.184.216.34

;; Query time: 23 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)

อ่าน:

ANSWER SECTION = ผลลัพธ์
TTL (300) = cache ได้กี่วินาที
SERVER = resolver ที่ตอบ
Query time = ใช้เวลาเท่าไหร่

`dig +short`

ขี้เกียจอ่านยาว:

$ dig +short example.com
93.184.216.34

`dig +trace` — ตามจาก root

ดู DNS resolution ทั้ง chain:

dig +trace example.com

ลำดับ:

Root server (.)
TLD server (.com)
Authoritative server ของ domain
คำตอบ A record

ใช้เมื่อสงสัยว่า resolver cache ตัวกลางมีปัญหา

`nslookup`

เก่ากว่า dig แต่มีในทุก OS รวม Windows:

nslookup example.com
nslookup example.com 8.8.8.8     # ใช้ resolver ของ Google

`host`

สั้นที่สุด:

host example.com
# example.com has address 93.184.216.34
# example.com mail is handled by 0 mail.example.com.

ใช้แยกประเภท record

A — IPv4

dig example.com A

AAAA — IPv6

dig example.com AAAA

MX — mail server

dig example.com MX

TXT — text record (SPF, DKIM, verification)

dig example.com TXT

NS — nameserver ของ domain

dig example.com NS

CNAME — alias

dig www.example.com CNAME

SRV — service record

dig _service._tcp.example.com SRV

ALL records พร้อมกัน

dig example.com ANY

ลำดับการ debug เมื่อมีปัญหา DNS

Step 1: resolver บนเครื่อง

dig example.com

ถ้าไม่ได้คำตอบ → resolver เครื่องมีปัญหา

ดู resolver ที่ใช้:

# Linux
cat /etc/resolv.conf

# macOS
scutil --dns | grep nameserver

# Windows
ipconfig /all | findstr /i "DNS"

ลองด้วย public resolver:

dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

ถ้า public ตอบได้ แต่ของเครื่องไม่ตอบ → ISP / corporate DNS มีปัญหา

Step 2: cache resolver

ถ้า DNS ตอบ IP เก่า หลังเพิ่งเปลี่ยน — cache ค้าง

ดู TTL:

dig example.com | grep -E "^example"
# example.com.    300    IN  A  ...

TTL = 300 → cache 5 นาที

clear cache:

# Ubuntu (systemd-resolved)
sudo systemd-resolve --flush-caches
sudo resolvectl flush-caches

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Windows
ipconfig /flushdns

# Linux ที่ใช้ nscd
sudo systemctl restart nscd

Step 3: authoritative server

เช็คว่า authoritative server ของ domain ตอบถูกมั้ย:

# หา NS server ก่อน
dig example.com NS

# query ตรงไป NS
dig @ns1.example.com example.com

ถ้า authoritative ตอบ IP ใหม่ แต่ resolver ของเครื่องตอบ IP เก่า → cache issue

Step 4: reverse lookup

จาก IP → domain:

dig -x 93.184.216.34
# หรือ
nslookup 93.184.216.34

ใช้ตรวจ:

PTR record ของ mail server (สำคัญสำหรับ email deliverability)
ค้นว่า IP นั้น resolve เป็นอะไร

DNS ใน Kubernetes

K8s มี internal DNS = CoreDNS — pod resolve service ด้วยชื่อ:

my-svc.my-namespace.svc.cluster.local

ทดสอบใน pod:

kubectl run -it --rm dns-test --image=busybox:1.36 -- nslookup kubernetes.default

ผลที่ดี:

Name:   kubernetes.default
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local

ถ้าเจอ:

Server can't find kubernetes.default: NXDOMAIN

→ CoreDNS มีปัญหา

ตรวจ:

kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs -n kube-system -l k8s-app=kube-dns

ดู resolver ใน pod:

kubectl exec -it <pod> -- cat /etc/resolv.conf
# nameserver 10.96.0.10           ← CoreDNS service IP
# search default.svc.cluster.local svc.cluster.local cluster.local

ถ้า nameserver ผิด — pod spec เผลอ override dnsPolicy

Custom resolver ใน Linux

ถ้าอยาก override resolver บางช่วง:

# ใช้ /etc/hosts สำหรับ static map
echo "192.168.1.50  myapi.local" | sudo tee -a /etc/hosts

# ทดสอบ
ping myapi.local

ถ้าใช้ systemd-resolved:

sudo resolvectl dns eth0 1.1.1.1 8.8.8.8
sudo resolvectl status

DNS leak / privacy

ตรวจว่า DNS ไม่หลุดออก ISP:

# query ผ่าน DoH (DNS over HTTPS)
curl -H "accept: application/dns-json" \
  "https://cloudflare-dns.com/dns-query?name=example.com&type=A"

config ใน OS ให้ใช้ DoH:

macOS: System Settings → Network → DNS → ใส่ 1.1.1.1 + เปิด TLS
Linux: ใช้ dnscrypt-proxy หรือ NextDNS

Tool เสริม

`mtr`

combine traceroute + ping continuous:

mtr example.com

เห็น hop ที่ packet loss ระหว่างทาง

`tcpdump` ดู DNS query

sudo tcpdump -i any -n port 53 -c 20

ดู query ที่ส่งออก / response ที่กลับ — ใช้ตอนสงสัยว่า DNS query ส่งไปไหน

`dnstop` — top สำหรับ DNS traffic

sudo dnstop eth0

real-time top ของ domain ที่ถูก query มากที่สุด

ตัวอย่างเคสจริง

Case 1: Email ส่งไม่ออก

# เช็ค MX
dig yourdomain.com MX

# เช็ค SPF
dig yourdomain.com TXT | grep -i spf

# เช็ค DKIM
dig default._domainkey.yourdomain.com TXT

# เช็ค DMARC
dig _dmarc.yourdomain.com TXT

ใช้เครื่องมือออนไลน์ summary: mxtoolbox.com

Case 2: เว็บโหลดช้า — DNS resolution ช้า

dig example.com | grep "Query time"
# Query time: 1245 msec   ← ช้ามาก

เปลี่ยน resolver:

sudo resolvectl dns eth0 1.1.1.1

ทดสอบใหม่ — ถ้าเร็วขึ้น แปลว่า ISP DNS ช้า

Case 3: Domain เพิ่งเปลี่ยน DNS แต่ยังไป IP เก่า

# ดู authoritative ก่อน
dig +trace example.com

# ดู resolver
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

# clear cache local
sudo systemd-resolve --flush-caches

ถ้า authoritative ตอบใหม่แล้ว resolver public ก็ได้แล้ว — รอแค่ TTL ของ cache เก่าหมด (สูงสุด 24-48 ชั่วโมง)

สรุป

DNS เป็นต้นทางของปัญหา network เยอะกว่าที่คิด

เครื่องมือสำคัญ: dig, nslookup, host, mtr, tcpdump

วิธี debug:

ลอง resolver ตัวอื่น (public DNS)
clear cache local
ใช้ dig +trace ดูทั้ง chain
ตรวจ TTL — ของเก่า cache อยู่นานแค่ไหน
ใน K8s — ดู CoreDNS

ถ้า "network down" ลอง DNS ก่อนเสมอ — ส่วนใหญ่เจอที่นี่

อ่านเพิ่ม: HTTPS / TLS ทำงานยังไง — DNS เป็นจุดเริ่มของ HTTPS handshake