Loading Search Modal Component...
https://thadaw.com/posts/feed.xml

เข้าใจพื้นฐานของ DNS และการย้าย DNS ไปยัง Azure DNS Zone

2025-09-09

สวัสดีครับ วันนี้อยากมาเล่าเรื่อง DNS Zone และการย้ายโดเมนมาที่ Azure DNS Zone กันแบบง่าย ๆ หลายคนอาจเคยได้ยินคำว่า DNS แล้วรู้สึกว่าเป็นศัพท์เทคนิคที่ซับซ้อน แต่จริง ๆ แล้ว DNS ก็คือ สมุดโทรศัพท์ของอินเทอร์เน็ต นี่เองครับ ถ้าเปรียบเทียบให้เห็นภาพ: โดเมนเนม (example.com) ก็เหมือน “ชื่อคน” ในสมุดโทรศัพท์, IP Address (1.2.3.4) ก็เหมือน “เบอร์โทรศัพท์จริง” ส่วน DNS Record คือบันทึกที่บอกว่า ชื่อนี้ต้องโทรไปที่เบอร์ไหน เวลาที่เบราว์เซอร์อยากเข้าเว็บ มันก็แค่เปิดสมุดโทรศัพท์เล่มนี้ดู แล้วรู้ทันทีว่าจะต้องวิ่งไปที่ IP ไหนถึงจะเจอเว็บไซต์ของเรา

พื้นฐานของ DNS

แล้วในสมุดโทรศัพท์ของอินเทอร์เน็ตเอง ก็ไม่ได้มีแค่ “ชื่อ → เบอร์” แบบเดียว แต่ยังมีหลายประเภทของการเชื่อมต่อ ที่บอกว่าโดเมนควรวิ่งไปหาปลายทางแบบไหนบ้าง ตัวอย่างที่เจอบ่อย ๆ ได้แก่

  • A Record → ระบุว่า ชื่อนี้ ต้องชี้ไปยัง หมายเลขบ้านจริง (IP Address แบบตัวเลข)
  • CNAME Record → เป็นเหมือน ชื่อเล่น ของชื่อหลัก เช่น www.example.com ชี้ไปที่ example.com
  • MX Record → ใช้สำหรับ อีเมล บอกว่าถ้ามีใครจะส่งจดหมาย (อีเมล) มาที่ @example.com ต้องไปที่ “ไปรษณีย์เซิร์ฟเวอร์” ไหน
  • TXT Record → เป็นเหมือน โน้ตสั้น ๆ ที่แนบไว้กับชื่อ เช่น การยืนยันความเป็นเจ้าของโดเมน หรือการตั้งค่าความปลอดภัยของอีเมล

แต่ถ้าวันหนึ่งเราไม่ได้อยากใช้แค่เว็บสำเร็จรูปของผู้ให้บริการแล้ว เช่น อยากเอาโดเมนนี้ไปชี้เข้ากับแอปที่รันอยู่บน Azure, ใช้กับอีเมลของ Microsoft 365 หรือ Google Workspace, หรืออยากควบคุม DNS ด้วยโค้ด (Infrastructure as Code) ปัญหาจะเริ่มตามมาทันทีครับ เพราะ DNS Record ที่ผู้ให้บริการตั้งมาให้อาจไม่ตรงกับสิ่งที่เราต้องการ หรือบางครั้ง panel ของผู้ให้บริการก็ไม่ยืดหยุ่นพอที่จะรองรับการตั้งค่าซับซ้อน เมื่อถึงจุดนี้เองที่เราจะเริ่มเห็นประโยชน์ของการ “ย้าย DNS Zone” มาจัดการเองบน Azure DNS ครับ

ทำไมถึงต้องใช้ Azure DNS

สาเหตุที่หลายคนเลือกจะย้าย DNS มาจัดการเองบน Azure DNS ก็เพราะว่ามันช่วยให้เราควบคุมได้มากกว่าการปล่อยให้ผู้ให้บริการโดเมนเป็นคนจัดการครับ อย่างแรกเลยคือเรื่อง ความยืดหยุ่น เวลาเราอยากเพิ่ม record แปลก ๆ หรือแก้ไขค่าให้ตรงกับระบบที่เราสร้างเอง บางที panel ของผู้ให้บริการเดิมไม่รองรับ แต่บน Azure DNS เราตั้งค่าได้เต็มที่ อีกอย่างคือมันรองรับการทำงานแบบ Automation ผ่าน API, Azure CLI หรือ Terraform ซึ่งสำคัญมากเวลาที่เรามีหลาย environment เช่น Dev, UAT, Prod แล้วอยากให้ DNS ถูกสร้างและอัปเดตแบบอัตโนมัติพร้อมกับระบบอื่น ๆ สุดท้ายคือ การเชื่อมต่อกับบริการ Azure อื่น ๆ ที่ทำได้เนียนกว่า เช่น App Service, Container App หรือ VM พอใช้ DNS ของ Azure อยู่แล้ว การผูก custom domain เข้ากับ service เหล่านี้ก็สะดวกขึ้นมากครับ

DNS ทำงานยังไง

หลายคนอาจจะสงสัยว่า เวลาที่เราซื้อโดเมนมาแล้ว เราจะเอาโดเมนนี้ไปใช้กับบริการ DNS ของเจ้าอื่นได้ยังไง เพราะอาจเข้าใจว่าการซื้อโดเมนมันเหมือนกับการสมัครใช้ซอฟต์แวร์แบบ Subscription (SaaS) ที่ล็อกเราไว้กับระบบของเขา ย้ายออกไปที่อื่นแทบจะเป็นไปไม่ได้ แต่ความจริงแล้วการ “ซื้อโดเมน” คือการจดทะเบียนชื่อบนอินเทอร์เน็ตครับ ส่วนบริการ DNS ที่แถมมาด้วยเป็นแค่ ตัวช่วย ที่ registrar เตรียมไว้ให้เราเท่านั้น เราสามารถเลือกได้เลยว่าจะใช้ DNS ของเขา หรือย้ายไปใช้ DNS Provider รายอื่น เช่น Azure DNS หรือ Cloudflare โดยทำได้แค่การเปลี่ยน Nameserver ของโดเมนให้ชี้ไปยังระบบใหม่เท่านั้นเอง

เพื่อให้เห็นภาพชัดขึ้น ลองมาดูกันครับว่าเวลาเรามี Domain, DNS และ Nameserver ทั้งสามอย่างนี้ทำงานร่วมกันยังไง

  • Domain → คือ “ชื่อ” ที่เราจดทะเบียนไว้ เช่น example.com คล้าย ๆ กับการที่เราไปจองชื่อร้านในห้าง ว่าชื่อนี้เป็นของเราแล้ว คนอื่นจะมาใช้ชื่อเดียวกันไม่ได้
  • DNS Record → คือ “กฎการแปลงชื่อ” ว่าเวลามีคนเรียก example.com ต้องไปที่ไหนต่อ เช่น A record ชี้ไป IP ของเซิร์ฟเวอร์, MX record ชี้ไปเซิร์ฟเวอร์อีเมล
  • Nameserver (NS) → คือ “คนเฝ้าสมุดโทรศัพท์” คอยตอบคำถามเวลามีคนมาถามว่าชื่อนี้ต้องไปที่ไหน สมมติเราเปลี่ยน nameserver ของโดเมนไปเป็นของ Azure DNS ก็หมายความว่า ต่อจากนี้ใครก็ตามที่ถามข้อมูลเกี่ยวกับ example.com จะต้องไปถาม Azure DNS เพื่อให้มันตอบกลับมา

ดังนั้นภาพรวมการทำงานคือ Domain เป็นชื่อ, DNS Record คือกฎการชี้ทาง, และ Nameserver คือผู้ให้บริการที่ถือสมุดบันทึกนี้ไว้ พอเราย้าย nameserver ไปเจ้าไหน ก็เท่ากับว่ามอบสิทธิ์การจัดการ DNS Record ทั้งหมดให้เจ้านั้นไปดูแลครับ

เวลาที่เราเข้า example.com มันทำงานยังไง?

ลองมาดูขั้นตอนการทำงานของ DNS กันแบบละเอียด ๆ ครับ สมมติว่าเรามีโดเมน example.com ที่จดทะเบียนกับ Google Domain แล้วตั้ง nameserver ไปที่ Azure DNS Zone ที่เราสร้างไว้ (เช่น ns1-01.azure-dns.com, ns2-01.azure-dns.net, etc.) และใน Azure DNS Zone เราตั้ง A record ให้ example.com ชี้ไปที่ IP ของเว็บเซิร์ฟเวอร์ที่รันอยู่บน Azure (เช่น 20.50.100.25) เวลาที่ผู้ใช้พิมพ์ example.com ในเบราว์เซอร์ ขั้นตอนการทำงานจะเป็นดังนี้ครับ:

  1. ผู้ใช้พิมพ์ example.com ใน browser

    • Browser จะถามระบบปฏิบัติการก่อนว่าเคยเก็บ IP ของ example.com ไว้ใน cache ไหม (เหมือนเราเคยจดเบอร์โทรเพื่อนลงมือถือไว้แล้ว)
    • ถ้าไม่มี → ต้องไปถามคนอื่น (DNS Resolver)

  2. DNS Resolver รับหน้าที่ตามหาคำตอบ

    • Resolver เปรียบเหมือน “คนกลาง” ที่เราส่งคำถามไปให้ เช่น DNS ของ ISP, Google (8.8.8.8), หรือ Cloudflare (1.1.1.1)
    • ถ้า resolver ไม่เคยเจอ example.com มาก่อน → มันต้องเริ่มออกเดินทางตามหา

  3. ถาม Root Server ก่อน

    • Root Server คือ “สารบัญใหญ่สุด” ของโลกอินเทอร์เน็ต
    • มันจะไม่รู้ว่า example.com อยู่ที่ไหน แต่จะตอบว่า 👉 “อ๋อ ชื่อที่ลงท้ายด้วย .com ต้องไปถามที่ .com TLD Server นะ”

  4. ไปถาม TLD Server (.com)

    • TLD Server ของ .com ก็ยังไม่รู้ IP ของ example.com โดยตรง

    • แต่มันรู้ว่าโดเมนนี้ใช้ Nameserver ของเจ้าไหน เช่น

      example.com → ใช้ Nameserver ns1-01.azure-dns.com

    • ตรงนี้แหละครับคือ จุดที่ domain ของเราผูกกับ nameserver

      • Domain = example.com (ที่เราจดทะเบียน)
      • Nameserver = ns1-01.azure-dns.com (ที่เราตั้งให้ชี้ไปยัง Azure DNS)

  5. ถาม Nameserver ของโดเมนเรา (Azure DNS)

    • คราวนี้ Resolver ก็เลยไปถาม Nameserver ของเราโดยตรง

    • Azure DNS จะเปิด “สมุดของเรา” (DNS Zone) มาดูว่าเราตั้ง record อะไรไว้

      • เช่น A Record: example.com → 20.50.100.25

    • แล้ว Azure DNS จะตอบกลับมาทันที

  6. Resolver ส่งคำตอบกลับไปที่ Browser

    • Resolver จะเก็บคำตอบนี้ไว้ใน cache (เพื่อให้ครั้งหน้าเร็วขึ้น)
    • แล้วส่ง IP กลับไปให้ Browser

  7. Browser รู้ IP แล้ว → ไปเจอเซิร์ฟเวอร์จริง

    • ได้เลข IP แล้ว Browser ก็ตรงไปหา Web Server ของเราที่ 20.50.100.25
    • สุดท้ายก็โหลดหน้าเว็บมาแสดง

สรุปด้วย Diagram

เราลองมาดูภาพรวมการทำงานของ DNS ผ่าน sequence diagram กันครับ

  sequenceDiagram
    participant U as User's Browser
    participant R as DNS Resolver (ISP / 8.8.8.8 / 1.1.1.1)
    participant Root as Root Server
    participant TLD as TLD Server (.com)
    participant NS as Authoritative Nameserver (Azure DNS)
    participant WS as Web Server (20.50.100.25)

    U->>U: 1. Check local cache
    U->>R: 2. Query example.com
    R->>Root: 3. Ask Root for .com
    Root-->>R: Referral → TLD Server (.com)
    R->>TLD: 4. Ask TLD for example.com
    TLD-->>R: Referral → NS (ns1-01.azure-dns.com)
    R->>NS: 5. Ask Azure DNS for example.com
    NS-->>R: A Record → 20.50.100.25
    R-->>U: 6. Return IP 20.50.100.25
    U->>WS: 7. Connect to Web Server
    WS-->>U: 8. Return Web Page

สรุปว่า Domain กับ Nameserver อยู่ตรงไหน

  • Registrar → คือ “ร้านรับจดโดเมน” ที่เราไปซื้อชื่อเว็บ เช่น example.com ให้กลายเป็นของเรา (ตัวอย่างเช่น Metaregistrar, Namecheap, หรือ Google Domain/Squarespace) Registrar มีหน้าที่หลัก ๆ แค่ เก็บทะเบียนชื่อ ว่าใครเป็นเจ้าของ ไม่ได้เก็บรายละเอียดว่าชื่อนี้จะต้องชี้ไปที่ไหน

  • Domain → คือ “ชื่อ” ที่เราจดไว้ เช่น example.com เหมือนเราจองป้ายชื่อร้านค้าในห้าง ใครอยากเรียกร้านเราก็ต้องใช้ชื่อนี้เท่านั้น

  • Nameserver (NS) → คือ “สมุดโทรศัพท์ของโดเมน” ที่บันทึกกฎการชี้ทาง (DNS Record) เอาไว้ ว่าเวลามีใครเรียก example.com ต้องไปเจอ IP ไหน ใช้เมลเซิร์ฟเวอร์อะไร ฯลฯ เราเลือกเองได้ว่าจะใช้ Nameserver ของใคร เช่น Azure DNS, Cloudflare หรือ Nameserver ของ Registrar เดิม

ดังนั้น เวลาใครถามว่า “example.com คืออะไร” → เขาจะวิ่งไปถาม Nameserver ที่เราตั้งไว้ แล้ว Nameserver ก็จะเปิด DNS Zone ของเรา ขึ้นมาตอบว่า ชื่อนี้ต้องไปที่ไหนจริง ๆ ครับ

ขั้นตอนการย้าย DNS มาที่ Azure DNS

พอเราเข้าใจแล้วว่า Domain, Nameserver และ DNS Zone ทำงานยังไง ทีนี้มาดูภาพรวมของการย้าย DNS จากผู้ให้บริการเดิมมาที่ Azure DNS กันครับ จริง ๆ แล้วขั้นตอนไม่ซับซ้อนเลย แค่ต้องทำตามลำดับให้ถูกต้อง

  1. สร้าง DNS Zone บน Azure

    • เข้า Azure Portal แล้วสร้าง Resource ประเภท DNS Zone
    • ตั้งชื่อ Zone ให้ตรงกับโดเมนที่เรามี เช่น tt-ss-lab.com

  2. เพิ่ม DNS Record ลงไปใน Zone

    • ก๊อปปี้ Record เดิมที่มีอยู่บน DNS ของผู้ให้บริการเก่า (เช่น A, MX, CNAME, TXT) มาใส่ใน Azure DNS
    • ตรวจสอบให้ครบ โดยเฉพาะ record สำคัญอย่าง MX (อีเมล) และ TXT (ที่ใช้ยืนยันกับบริการต่าง ๆ)

  3. อัปเดต Nameserver ที่ Registrar

    • พอเราสร้าง Zone เสร็จ Azure จะให้ Nameserver ชุดใหม่ (เช่น ns1-01.azure-dns.com, ns2-01.azure-dns.net)
    • เข้าไปที่ Registrar ที่เราซื้อโดเมน (เช่น Google Domain/Squarespace, Namecheap) แล้วเปลี่ยน Nameserver ของโดเมนให้ชี้ไปยัง Azure DNS
    • อย่างตัวอย่างนี้ผมใช้ Registrar (ผู้ให้บริการจด Domain) ในไทย และสามารถอัพเดทค่าของ nameserver จาก Azure ได้

  4. รอ Propagation

    • หลังจากเปลี่ยน Nameserver อาจต้องรอ 24–48 ชั่วโมง กว่าข้อมูลจะอัปเดตไปทั่วโลก
    • ระหว่างนี้บาง resolver อาจยังตอบข้อมูลเก่าอยู่ ถือว่าเป็นเรื่องปกติ

แค่ 4 ขั้นตอนนี้ เราก็ย้าย DNS มาจัดการเองบน Azure DNS ได้แล้วครับ ทีนี้เราจะควบคุม DNS ผ่าน Azure Portal, Azure CLI หรือ Terraform ก็ได้ สะดวกและยืดหยุ่นกว่าการผูกติดอยู่กับ DNS ของ registrar เดิมเยอะเลย

เราสามารถไปดูขั้นตอนละเอียด ๆ พร้อมภาพประกอบได้ใน เอกสารของ Microsoft ครับ

Propagation คืออะไร ทำไมต้องรอ?

เวลาที่เราเปลี่ยน Nameserver หรือแก้ DNS Record สิ่งที่หลายคนจะเจอคือ กดบันทึกแล้วลอง dig หรือเข้าเว็บทันที ผลลัพธ์กลับเป็น SERVFAIL หรือยังเจอค่าของ DNS เดิมอยู่ ทั้ง ๆ ที่เราตั้งค่าใหม่เรียบร้อยแล้ว …จริง ๆ แล้วนี่คือเรื่องปกติครับ เพราะมันเกี่ยวกับสิ่งที่เรียกว่า DNS Propagation

ลองนึกภาพว่า DNS ไม่ได้เก็บอยู่ที่เซิร์ฟเวอร์กลางแค่จุดเดียว แต่เป็น สมุดโทรศัพท์ที่กระจายอยู่ทั่วโลก ไม่ว่าจะเป็น resolver ของ ISP, ของ Google, ของ Cloudflare หรือขององค์กรต่าง ๆ แต่ละที่ก็จะเก็บ “สำเนา” ของสมุดไว้ใน cache ของตัวเอง และแต่ละ record จะมีอายุการเก็บกำหนดโดยค่า TTL (Time To Live) เช่น 300 วินาที (5 นาที), 3600 วินาที (1 ชั่วโมง) หรือบางครั้งยาวเป็นวัน

เมื่อเรามีการเปลี่ยน DNS Record → ข้อมูลใหม่จะถูกบันทึกที่ Nameserver ของเรา (เช่น Azure DNS) ทันที แต่ resolver ที่อื่น ๆ ทั่วโลกอาจยังเก็บค่าของ record เก่าไว้ใน cache จนกว่า TTL จะหมด ถึงตอนนั้น resolver ถึงจะกลับไปถาม Nameserver ของเราอีกครั้ง แล้วค่อยอัปเดตค่าใหม่

สรุปให้เข้าใจง่าย ๆ

  • DNS ทำงานแบบกระจายศูนย์ → ไม่มีที่เก็บกลาง ทุก resolver มีสำเนาของตัวเอง
  • ค่า TTL คือกำหนดว่า “ข้อมูลเก่านี้จะใช้ได้นานแค่ไหน”
  • ระหว่าง propagation (24–48 ชั่วโมงในกรณีเปลี่ยน Nameserver) → บางที่อาจตอบข้อมูลใหม่แล้ว แต่บางที่ยังตอบข้อมูลเก่าอยู่

ดังนั้นเวลาที่เพิ่งย้าย DNS มาที่ Azure แล้วเจอว่าเว็บยังเข้าไม่ได้ อย่าเพิ่งตกใจไปครับ ส่วนใหญ่ไม่ใช่ตั้งค่าผิด แต่เป็นเพราะ propagation กำลังทำงานอยู่ รอให้ cache ทั่วโลกหมดอายุแล้วข้อมูลใหม่จะแพร่กระจายไปครบเอง

กรณีศึกษาของจริง: ย้ายโดเมนไป Azure DNS แล้วเจอ SERVFAIL

ตอนที่ผมย้ายโดเมน tt-ss-lab.com มาที่ Azure DNS สิ่งแรกที่ทำหลังจากเปลี่ยน Nameserver ที่ registrar ก็คือรีบลอง dig เพื่อเช็กผลลัพธ์ แต่สิ่งที่เจอคือทุก query กลับมาตอบว่า

status: SERVFAIL

ตอนนั้นผมก็คิดว่าต้องตั้งค่าผิดแน่ ๆ เพราะลองถามทั้ง A, MX, CNAME, TXT ก็ยัง FAIL เหมือนเดิมทั้งหมด

แต่พอลองไล่เช็กไปทีละขั้นก็เจอสาเหตุจริง ๆ อยู่สองข้อ:

  1. Propagation ยังไม่เสร็จ หลังเปลี่ยน Nameserver ข้อมูลยังไม่กระจายไปทั่วโลก resolver ของ ISP ที่ใช้ยังชี้ไป Nameserver เก่า เลยตอบกลับด้วย error

  2. Zone ใน Azure ยังว่างเปล่า ถึง Nameserver ใหม่จะถูกเปลี่ยนเรียบร้อยแล้ว แต่ DNS Zone ของผมยังไม่มี record พื้นฐานเลย พอ resolver ภายนอกถามมาก็เลย “ไม่มีคำตอบจะตอบกลับ” → กลายเป็น SERVFAIL

วิธีแก้

  • ผมลองถามตรงไปที่ Nameserver ของ Azure โดยใช้คำสั่ง:

    dig CNAME test-azure.tt-ss-lab.com @ns1-01.azure-dns.com

    คราวนี้ได้คำตอบกลับมาทันที ว่า test-azure.tt-ss-lab.com ชี้ไปยัง chaiyo-ca.jollyplant...azurecontainerapps.io แสดงว่า Zone ทำงานปกติแล้ว

  • นอกจากนี้ ผมลองใช้ nslookup แทน dig ก็ได้คำตอบกลับมาจาก resolver อีกตัวหนึ่งเร็วกว่า (non-authoritative answer) ทำให้มั่นใจได้ว่าค่าถูกต้อง เพียงแต่ propagation บาง resolver ยังไม่อัปเดต

  • สรุปแล้วปัญหามาจาก Propagation ที่ยังไม่เสร็จ + ไม่มี record พื้นฐาน (A, MX, TXT) ใน Zone นั่นเอง

หลังจากตรวจสอบด้วย nslookup

หลังจากที่ผมลอง nslookup แล้วเริ่มเห็นข้อมูล CNAME ของ test-azure.tt-ss-lab.com ชี้ไปที่ Azure Container App ได้ถูกต้อง ผมก็ไปลองขั้นตอนถัดไปทันที คือ ผูก Custom Domain บน Azure Container App

$ nslookup test-azure.tt-ss-lab.com

;; Got SERVFAIL reply from 2001:fb0:100::207:49, trying next server
Server:		2001:fb0:100::207:29
Address:	2001:fb0:100::207:29#53

Non-authoritative answer:
test-azure.tt-ss-lab.com	canonical name = chaiyo-ca.jollyplant-effa115b.southeastasia.azurecontainerapps.io.
Name:	chaiyo-ca.jollyplant-effa115b.southeastasia.azurecontainerapps.io
Address: 40.119.236.238

ผลลัพธ์คือ Azure สามารถ validate domain ผ่านได้เลย เพราะมันเห็นว่า CNAME record ถูกต้องแล้ว หลังจากนั้นก็สามารถผูก test-azure.tt-ss-lab.com เข้ากับ Container App ของผมได้สำเร็จ โดยไม่ต้องรอ propagation ครบทุก resolver ด้วยซ้ำ

นี่ทำให้เห็นว่า บางครั้งแม้เราจะเจอ SERVFAIL จาก dig แต่ถ้าลองเช็กด้วย nslookup หรือ query ตรงไปยัง Nameserver ของ Azure ก็อาจได้คำตอบที่ใช้ได้ทันที และสามารถดำเนินการต่อใน Azure ได้เลย

บทเรียนที่ได้

  1. หลังเปลี่ยน Nameserver อย่าเพิ่งรีบเทสทันที ให้เวลา propagation อย่างน้อย 24–48 ชั่วโมง แต่อาจจะเสร็จเร็วกว่านั้นได้

  2. ตรวจสอบว่า Zone ของเรามี record พื้นฐานครบแล้ว โดยเฉพาะ A record สำหรับ root domain

  3. เวลาเจอ SERVFAIL ให้ลองสองวิธี:

    • ถามตรงไปที่ Nameserver ของ Azure (@ns1-01.azure-dns.com) → ถ้าได้ผลลัพธ์ แสดงว่า Zone ปกติ
    • ใช้ nslookup เช็กกับ resolver ตัวอื่น เผื่อได้คำตอบ non-authoritative ที่ confirm ค่าใหม่ได้เร็วกว่า

ตรงนี้จะช่วยให้คนอ่านมั่นใจว่า ถึง propagation จะยังไม่ครบ แต่เราก็สามารถ validate domain และผูก Custom Domain บน Azure ได้ตั้งแต่เนิ่น ๆ

เครื่องมือ Command Line สำหรับตรวจสอบ DNS

เวลาที่เราย้ายโดเมนหรือแก้ไข DNS การตรวจสอบด้วย command line จะช่วยให้เราเห็นว่าระบบตอบสนองยังไงบ้าง ผมขอสรุปเป็น 5 คำสั่งหลัก ๆ ที่ใช้บ่อยครับ

1. dig

dig A example.com
dig CNAME test-azure.example.com
dig MX example.com
  • ใช้ถาม DNS Record โดยตรง เช่น A, CNAME, MX, TXT
  • แสดงผลละเอียด เช่น TTL, authority, server ที่ตอบ
  • ถ้าเจอ status: SERVFAIL → แสดงว่า resolver ที่ถามยังไม่รู้จัก record นี้ (อาจเป็นเพราะ propagation ยังไม่เสร็จ)

2. dig @nameserver

dig CNAME test-azure.example.com @ns1-01.azure-dns.com
  • ใช้ถามตรงไปยัง Authoritative Nameserver ของโดเมน เช่น Azure DNS
  • จะได้คำตอบตรงจาก DNS Zone ของเรา ไม่ต้องรอ propagation
  • เหมาะมากเวลาอยากเช็กว่า record ที่สร้างไว้ใน Zone ทำงานแล้วหรือยัง

3. nslookup

nslookup example.com
nslookup test-azure.example.com
  • ใช้ง่ายกว่า dig และมักจะตอบว่า Non-authoritative answer
  • หมายความว่า: คำตอบมาจาก resolver ตัวกลาง (เช่น DNS ของ ISP, Google 8.8.8.8, Cloudflare 1.1.1.1) ที่เก็บข้อมูลไว้ใน cache → ไม่ได้ตอบจาก Nameserver ต้นทาง
  • ข้อดี: บางครั้ง resolver บางตัวอัปเดตเร็ว ทำให้เห็นผล propagation ได้ก่อนที่ resolver อื่น ๆ จะตามทัน

4. whois

whois example.com
  • ใช้ดูข้อมูลการจดทะเบียนโดเมน
  • บอกได้ว่า registrar คือใคร, วันหมดอายุ, และ Nameserver ปัจจุบัน ของโดเมนคืออะไร
  • ช่วยเช็กได้ว่าเราส่งค่า Nameserver ไปที่ Azure DNS แล้วหรือยัง

5. host (อีกทางเลือก)

host example.com
  • ผลลัพธ์สั้น กระชับกว่า dig
  • เหมาะสำหรับการตรวจสอบเร็ว ๆ เช่นดูว่า domain resolve ไปที่ IP ไหน

Authoritative vs Non-authoritative

  • Authoritative Answer → มาจาก Nameserver ต้นทางของโดเมนโดยตรง (เช่น Azure DNS) → เป็นข้อมูลจริงล่าสุด 100%
  • Non-authoritative Answer → มาจาก cache ของ resolver ตัวกลาง (เช่น DNS ของ ISP หรือ Google DNS) → เร็วกว่า แต่บางครั้งอาจยังเป็นข้อมูลเก่า
  • 📌 ถ้าอยากเช็กว่าค่าใน DNS Zone ถูกต้องแล้ว → ใช้ dig @ns1-01.azure-dns.com
  • 📌 ถ้าอยากดูว่าค่าเริ่มเผยแพร่ไปทั่วโลกแล้วหรือยัง → ใช้ nslookup หรือ dig ธรรมดา (ไม่ระบุ nameserver)

การใช้คำสั่งเหล่านี้ร่วมกัน จะช่วยให้เราแยกปัญหาได้ทันทีว่า:

  • โดเมนยังไม่เปลี่ยน nameserver ที่ registrar
  • Zone บน Azure DNS ยังไม่มี record
  • หรือ propagation ยังไม่เสร็จ

โดยสรุป

DNS ฟังดูเป็นเรื่องซับซ้อน แต่ถ้าเราเปรียบเทียบให้ง่าย ๆ ว่า Domain คือชื่อร้าน, IP คือเบอร์โทรศัพท์, และ DNS คือสมุดโทรศัพท์ของอินเทอร์เน็ต ทุกอย่างก็จะเริ่มชัดขึ้นทันที

  • เวลาเราซื้อโดเมนจาก registrar → เราได้ทั้ง “ชื่อร้าน” (domain) และ “สมุดโทรศัพท์เบื้องต้น” (DNS record ที่แถมมา)
  • ถ้าอยากควบคุมเองมากขึ้น เช่น ใช้ Azure App Service, Container App หรือจัดการ DNS ด้วยโค้ด (Terraform/CLI) → เราก็แค่เปลี่ยน Nameserver ไปที่ Azure DNS
  • เมื่อเปลี่ยนแล้ว บางครั้งเจอปัญหา SERVFAIL ซึ่งส่วนใหญ่เกิดจาก propagation ที่ยังไม่เสร็จ หรือ Zone ยังไม่มี record พื้นฐาน ไม่ได้แปลว่าตั้งค่าผิด

การตรวจสอบด้วย command line อย่าง dig, nslookup, whois ช่วยให้เรารู้ได้ทันทีว่า ปัญหาอยู่ตรงไหนกันแน่ และไม่ต้องนั่งเดาแบบงง ๆ อีกต่อไป

คำสรุปสำคัญ (Key Takeaways)

  1. DNS Zone = สมุดโทรศัพท์ ของโดเมน → เราสามารถเลือกจะฝากสมุดนี้ไว้กับใครก็ได้ เช่น Azure DNS, Cloudflare หรือ registrar เดิม
  2. Authoritative vs Non-authoritative → ถามตรง Nameserver = ได้ข้อมูลจริงล่าสุด, ถาม resolver ทั่วไป = ได้ข้อมูลจาก cache
  3. Propagation ต้องใช้เวลา → 24–48 ชั่วโมงเป็นเรื่องปกติ อย่าเพิ่งตกใจถ้าเจอ SERVFAIL
  4. เช็กด้วยเครื่องมือ → dig @nsX-azure-dns.com เพื่อตรวจสอบ Zone โดยตรง, nslookup เพื่อตรวจสอบการเผยแพร่

ทิ้งท้าย

พอเราเข้าใจภาพรวมแล้ว DNS จะไม่ใช่ “กล่องดำลึกลับ” อีกต่อไปครับ การย้ายโดเมนมาที่ Azure DNS ก็ไม่ได้ซับซ้อนอย่างที่คิด — แค่เปลี่ยน nameserver, ย้าย record มาครบ, รอ propagation ให้เสร็จ แล้วทุกอย่างก็พร้อมใช้งาน

ถ้าเคยรู้สึกว่า DNS เป็นเรื่องยาก ลองกลับมาอ่านบทความนี้อีกครั้ง คุณจะเห็นว่า จริง ๆ แล้วมันก็แค่ “การเปิดสมุดโทรศัพท์ → หาว่าชื่อนี้ต้องไปเบอร์ไหน” เท่านั้นเอง ✨

ไว้เจอกันใหม่บทความหน้านะ สวัสดีครับ 👋