ทำไมการเรียนรู้ DNS จึงยังยากอยู่?

 (jvns.ca)
3 คะแนน โดย GN⁺ 2023-07-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • DNS ถูกใช้งานมาตั้งแต่ทศวรรษ 1980 นานกว่า 35 ปี และโครงสร้างก็ค่อนข้างเสถียร แต่โปรแกรมเมอร์จำนวนมากยังต้องใช้เวลานานกว่าจะสามารถ ดีบักปัญหาพื้นฐานได้อย่างมั่นใจ
  • ความยากไม่ได้อยู่ที่ความซับซ้อนของ DNS เองเท่าไร แต่อยู่ที่มี องค์ประกอบที่มองไม่เห็น จำนวนมาก เช่น แคชของ resolver, ไลบรารี DNS ภายในเครื่อง และการสนทนากับ authoritative nameserver
  • dig เป็นเครื่องมือที่ทรงพลัง แต่โครงสร้างผลลัพธ์และคำศัพท์ไม่คุ้นเคย และแม้ฟีเจอร์อย่าง +norecurse จะมีประโยชน์ การตีความผลลัพธ์ก็ ไม่เป็นไปตามสัญชาตญาณ
  • กับดักที่พบบ่อย เช่น negative caching, ประวัติที่ musl ไม่รองรับ TCP DNS, resolver ที่เพิกเฉยต่อ TTL, การแคชถาวรของ nginx, และ ndots ของ Kubernetes เป็นสิ่งที่เรียนรู้ได้ยากจนกว่าจะมีใครบอก
  • สำหรับคนที่แตะ DNS ไม่บ่อย cheat sheet จะช่วยได้ และปัญหาที่ทดลองเองแล้วรู้สึกเสี่ยงสามารถบรรเทาได้ด้วยสภาพแวดล้อมทดลองที่ปลอดภัยอย่าง Mess With DNS

DNS เป็นเทคโนโลยีเก่า แต่ก็ยังยาก

  • DNS ถูกใช้งานมานานกว่า 35 ปีตั้งแต่ยุค RFC 1034 ใช้กับเว็บไซต์ทุกแห่งบนอินเทอร์เน็ต และในหลายแง่ก็ยังทำงานคล้ายกับเมื่อ 30 ปีก่อน
  • ถึงอย่างนั้น การดีบักปัญหาพื้นฐานอย่าง “ตั้งค่าโดเมนถูกต้องแล้วแต่ resolve ไม่ได้” หรือ “ผลลัพธ์ DNS ของ dig กับเบราว์เซอร์ไม่ตรงกัน” ก็ยังอาจใช้เวลานาน
  • คนที่รู้สึกว่า DNS ยากมักติดอยู่ที่จุดต่อไปนี้
    • แม้แต่การเปลี่ยน DNS แบบง่าย ๆ ของเว็บไซต์ก็ยังไม่รู้สึกสบายใจ
    • สับสนกับข้อเท็จจริงที่ว่า DNS record ไม่ได้ถูก push แต่ถูก pull
    • แม้จะรู้แนวคิดพื้นฐาน แต่ก็สับสนกับพฤติกรรมรายละเอียด เช่น negative caching และความแตกต่างระหว่าง DNS query ของ dig กับของเบราว์เซอร์

Resolver และ nameserver ที่มองไม่เห็น

  • โฟลว์พื้นฐานเวลาคอมพิวเตอร์ส่งคำขอ DNS ดูเหมือนเรียบง่าย
    • คอมพิวเตอร์ส่งคำขอไปยังเซิร์ฟเวอร์ที่เรียกว่า resolver
    • resolver ตรวจสอบแคช และหากจำเป็นก็ส่งคำขออีกครั้งไปยัง authoritative nameserver
  • องค์ประกอบหลายอย่างที่สำคัญในการดีบักจริงไม่ได้ปรากฏให้เห็นโดยปกติ
    • ยากที่จะรู้ว่ามีอะไรอยู่ใน แคช ของ resolver
    • ไม่ชัดเจนว่าไลบรารี DNS ใดในเครื่องเป็นตัวจัดการคำขอ
      • อาจเป็น libc getaddrinfo, glibc, musl, implementation ของ Apple, โค้ด DNS ของเบราว์เซอร์เอง หรือ implementation แบบกำหนดเองอื่น ๆ
      • แต่ละ implementation มีการตั้งค่า วิธีแคช และการรองรับฟีเจอร์ที่ต่างกันเล็กน้อย
      • DNS ของ musl ไม่รองรับ TCP จนถึงต้นปี 2023
    • มองไม่เห็นการสนทนาระหว่าง resolver กับ authoritative nameserver
      • หากสามารถติดตามได้ว่ามีการ query ไปยัง authoritative nameserver ใดและได้คำตอบอะไร ก็จะเข้าใจปัญหา DNS จำนวนมากได้ง่ายขึ้น

แนวทางในการเผยให้เห็นระบบที่ซ่อนอยู่

  • แค่บอกว่ามีองค์ประกอบที่ซ่อนอยู่ใดบ้าง ก็ช่วยการเรียนรู้ได้มากแล้ว
    • หากไม่รู้ว่าแม้ในคอมพิวเตอร์เครื่องเดียวกันก็อาจใช้ไลบรารี DNS หลายตัวตามสถานการณ์ ก็อาจสับสนอยู่นาน
  • Mess With DNS ทดลองใช้แนวทางแบบ fishbowl ที่แสดงส่วนที่ปกติไม่เห็น
    • ทำให้เห็นการสนทนาบางส่วนระหว่าง resolver กับ authoritative nameserver ได้
  • ยังมีวิธีใส่ข้อมูลดีบักลงใน DNS response ด้วย
    • มีฟีเจอร์ที่เรียกว่า Extended DNS Errors หรือ EDE อยู่แล้ว
    • เครื่องมือต่าง ๆ กำลังค่อย ๆ เพิ่มการรองรับ EDE

เบาะแสจาก Extended DNS Errors

  • Extended DNS Errors เป็นวิธีใหม่ที่ DNS server ให้ ข้อมูลดีบัก เพิ่มเติมใน response
  • หาก query โดเมนที่ไม่มีอยู่จริง xjwudh.com ด้วย dig @8.8.8.8 xjwudh.com อาจได้ข้อผิดพลาดเพิ่มเติมดังนี้
; EDE: 12 (NSEC Missing): (Invalid denial of existence of xjwudh.com/a)
  • ตัวอย่างนี้ดูเหมือนเป็นรายการที่เกี่ยวกับ DNSSEC และจุดสำคัญคือมีข้อความดีบักเพิ่มเติมมากับ response
  • หากต้องการเห็นตัวอย่างข้างต้น จำเป็นต้องใช้ dig เวอร์ชันที่ใหม่กว่า

dig ทรงพลังแต่อ่านยาก

  • dig มีประโยชน์ในการตรวจสอบสถานะภายในของ DNS
  • เมื่อใช้ dig +norecurse จะตรวจสอบได้ว่า DNS resolver ตัวหนึ่งมี record ใดอยู่ในแคชบ้าง
    • 8.8.8.8 ดูเหมือนจะคืนค่า SERVFAIL หากไม่มี response อยู่ในแคช
    • google.com อยู่ในแคช จึงคืนค่า NOERROR และ A record
    • homestarrunner.com ไม่อยู่ในแคชจึงคืนค่า SERVFAIL แต่ไม่ได้หมายความว่าไม่มี DNS record
  • ผลลัพธ์ของ dig อ่านยากหากไม่คุ้นเคย
    • หัวข้ออย่าง ->>HEADER<<-, flags:, OPT PSEUDOSECTION:, QUESTION SECTION:, ANSWER SECTION: ดูไม่คุ้นตา
    • การขึ้นบรรทัดใหม่และช่องว่างระหว่าง section ให้ความรู้สึกไม่สม่ำเสมอ
    • ใน MSG SIZE rcvd: 47 ยากที่จะรู้ว่ามี field อื่นนอกจาก rcvd หรือไม่
    • ต้องรู้ว่าแม้จะบอกว่ามี record 1 รายการใน section ADDITIONAL แต่จริง ๆ แล้ว OPT PSEUDOSECTION ทำหน้าที่นั้น
  • ผลลัพธ์ของ dig ดูเหมือนสคริปต์ที่เติบโตขึ้นเองตามกาลเวลา มากกว่าจะเป็นรูปแบบที่ออกแบบมาอย่างตั้งใจตั้งแต่แรก

วิธีทำให้เครื่องมือ DNS อ่านง่ายขึ้น

  • เอกสารที่อธิบายผลลัพธ์ของ dig เองช่วยได้
    • how to use dig อธิบายโครงสร้างผลลัพธ์ของ dig และวิธีตั้งค่าผลลัพธ์พื้นฐานให้สั้นลง
  • อาจสร้างเครื่องมือที่เป็นมิตรกว่านี้ได้
    • มีทางเลือกอย่าง dog, doggo, DNS lookup tool
    • แต่เมื่อต้องใช้ฟีเจอร์ขั้นสูงอย่าง +norecurse การจัดการด้วย dig ตัวเดียวอาจดีกว่า
    • การแทนที่ขอบเขตฟีเจอร์ที่กว้างของ dig เป็นงานใหญ่
  • อีกแนวทางหนึ่งคือเพิ่มตัวเลือกอย่าง +human ให้ผลลัพธ์ของ dig เพื่อแสดงข้อมูลเดียวกันอย่างมีโครงสร้างมากขึ้น
    • สามารถแยก header, query, response, additional section, เวลา, server, protocol และขนาด response ได้ชัดเจน
    • ไม่ใช่การลดปริมาณข้อมูล แต่เป็นแนวทางที่นำเสนอ ข้อมูลเดียวกัน ให้อ่านง่ายขึ้น
  • dig รุ่นใหม่มีรูปแบบผลลัพธ์ +yaml
    • อาจรู้สึกชัดเจนกว่า แต่แม้แต่ DNS response ง่าย ๆ ก็อาจยืดยาวจนแสดงไม่หมดในหน้าจอเดียว

กับดัก DNS ที่พบบ่อยแต่เรียนรู้ได้ยาก

  • DNS มีกับดักที่พบได้ค่อนข้างบ่อย แต่ยากจะรู้จนกว่าจะมีใครบอก

  • negative caching

    • หากเข้าโดเมนที่ยังไม่มี DNS record สถานะ “ไม่มี” ของ record นั้นอาจถูกแคชไว้
    • หากสถานะนี้ถูกแคชไว้หลายชั่วโมง จะกลายเป็นเรื่องยุ่งยากมาก

  • ความแตกต่างของ implementation ของ getaddrinfo

  • resolver ที่เพิกเฉยต่อ TTL

    • แม้จะตั้ง TTL ของ DNS record ไว้ 5 นาที แต่ resolver บางตัวอาจเพิกเฉยและแคชนานกว่านั้น เช่น 24 ชั่วโมง

  • ปัญหาการตั้งค่า nginx

    • หากตั้งค่า nginx ผิด อาจทำให้ DNS record ถูกแคชตลอดไป

  • ndots ของ Kubernetes

    • ndots อาจทำให้ DNS ของ Kubernetes ช้าลง

วิธีแชร์และจัดทำเอกสารเกี่ยวกับกับดัก

  • ความรู้เกี่ยวกับกับดักแปลก ๆ หาได้ยาก และการที่ผู้คนต้องค้นพบปัญหาเดิมซ้ำ ๆ เองนั้นไม่มีประสิทธิภาพ
  • เมื่ออธิบายหัวข้อใด การชี้ให้เห็นกับดักที่พบบ่อยไปด้วยจะช่วยได้มาก
    • ตัวอย่างที่ไม่ใช่ DNS คือบทนำ Flexbox ของ Josh Comeau ที่อธิบาย minimum size gotcha
  • วิธีที่ชุมชนรวบรวมกับดักที่พบบ่อยไว้ก็มีประโยชน์
    • ใน Bash นั้น shellcheck มีประโยชน์มากในฐานะชุดรวมกับดักของ bash
  • การจัดทำเอกสารกับดักของ DNS ก็ยากเช่นกัน เพราะผู้ใช้แต่ละคนเจอปัญหาไม่เหมือนกัน
    • คนที่ตั้งค่า DNS ให้โดเมนส่วนตัวทุก 3 ปีครั้ง กับคนที่ดูแล DNS ของโดเมนที่มีทราฟฟิกสูง อาจเจอกับดักคนละแบบกัน

การใช้งานที่ไม่บ่อยและความยากในการทดลอง

  • หลายคนแตะ DNS น้อยมาก
    • หากยุ่งกับ DNS แค่ทุก 3 ปีครั้ง ก็เป็นธรรมดาที่จะเรียนรู้ได้ยาก
    • cheat sheet อย่าง “ขั้นตอนการเปลี่ยน nameserver” อาจช่วยได้
  • DNS ยังเป็นเทคโนโลยีที่น่ากลัวต่อการทดลอง เพราะอาจทำให้โดเมนของตัวเองพังได้
    • Mess With DNS ถูกสร้างขึ้นเพื่อลดภาระความกังวลในการทดลองแบบนี้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-07-29
ความคิดเห็นจาก Hacker News

  • ผมไม่เห็นด้วยกับบทความนี้ DNS ไม่ใช่สิ่งที่เรียนรู้ยากจริง ๆ เพียงแต่มีคนจำนวนน้อยที่ยอมใช้เวลาเรียนมันเท่านั้น
    ข้อดีของ DNS คือ เมื่อมีการ query ระบบจะบอกสถานะภายในของตัวเองให้รู้ สำหรับ zone ที่รู้จักอยู่แล้ว เราสามารถตรวจดู DNS server และทำความเข้าใจการทำงานได้ง่าย และเครื่องมือฟรีอย่าง dig ก็มีให้ใช้กันอย่างแพร่หลาย
    ตลอดเส้นทางอาชีพ ผมมักแปลกใจเสมอที่คนที่เคยทำงานด้วยกันจดจำความรู้ด้าน DNS ของผมได้มากที่สุด เพราะผมไม่ได้คิดว่าตัวเองรู้เรื่องลึกลับหรือพิเศษอะไร DNS มีมาตรฐานที่ดีมาก implementation ของ server และ client ที่พบได้ทั่วไปก็ปฏิบัติตามมาตรฐานอย่างเคร่งครัด และสังเกตพฤติกรรมได้ง่ายด้วยเครื่องมือฟรี แค่ต้องใช้ความพยายามและเวลาเท่านั้น ไม่ได้ยากจริง ๆ

    • ในฐานะคนเขียนบทความนี้ ผมอยากพูดสักสองสามอย่างเกี่ยวกับมุมมองที่ว่า DNS ไม่ได้ยากจริง ๆ ผมใช้เวลาหลายปีกว่าจะ debug ปัญหา DNS ได้อย่างสบายใจเต็มที่ และเขียนบทความนี้เพื่ออธิบายว่าทำไมมันถึงยากสำหรับผม
      เมื่อก่อนผมเคยคิดว่า “ไม่หรอก จริง ๆ แล้วมันง่าย!” เป็นคำให้กำลังใจสำหรับคำพูดที่ว่า “เรียนรู้ยาก” ผมชอบ DNS และคิดว่ามันเรียบง่ายอย่างน่าทึ่งในหลายแง่ ตัวอย่างเช่น https://implement-dns.wizardzines.com แสดงวิธีสร้าง toy DNS resolver ตั้งแต่ต้นด้วยโค้ด Python ง่าย ๆ
      แต่เมื่อเวลาผ่านไป ผมได้เรียนรู้ว่า “ไม่หรอก เรียนง่าย!” มักถูกมองว่าเหมือนพูดว่า “มันไม่ได้ยากหรอก คุณต่างหากที่โง่” มากกว่าจะเป็นกำลังใจว่า “คุณทำได้!” ถ้าผมสับสนกับหัวข้อหนึ่งอยู่หลายปี แล้วมีคนบอกว่า “จริง ๆ มันง่ายนะ?” มันไม่ได้ช่วยอะไรมากนัก
      ดังนั้นตอนนี้ผมจึงไม่พูดแบบนั้นแล้ว แต่ทุ่มเทมากขึ้นกับการทำความเข้าใจว่าทำไมผู้คนถึงรู้สึกว่าบางอย่างยาก และลดกำแพงเหล่านั้นลง
    • ถ้ามองจาก เครื่องมือสำหรับเรียน DNS ผมคิดว่ามันเรียนยาก
      BIND ทำหน้าที่ของมันได้ยอดเยี่ยม แต่ไฟล์ config ไม่ค่อยดี คู่มือก็ยาว แข็งทื่อ และบางครั้งซับซ้อนโดยไม่จำเป็น dig ทรงพลัง แต่ย่อทุกอย่างเหมือนยุคที่ยังใช้เทอร์มินัลกว้าง 80 คอลัมน์ เวลาต้อง debug ปัญหา DNS บางครั้ง Wireshark ยังเป็นเครื่องมือที่ดีกว่า dig ด้วยซ้ำ
      ถ้าให้ใช้ PowerDNS หรือ DNS server สมัยใหม่ตัวอื่น ๆ น่าจะตั้งค่า DNS server ที่ใช้งานได้ง่ายกว่ามาก ส่วน DNS client สมัยใหม่ที่ดี ๆ ผมไม่ค่อยรู้จัก สุดท้ายเลยคุ้นกับ dig ไปเอง ในฐานะคนที่ใช้ flag --color ของคำสั่ง ip ผมอยากให้เครื่องมืออย่าง dig แสดงผลแบบสมัยใหม่กว่านี้ด้วย flag ของ command line ผมผูกเป็น alias ไว้ได้ ขอแค่ใส่ฟีเจอร์มาให้ก็พอ
      พูดจริง ๆ นะ MSG SIZE rcvd: 71 ไม่จำเป็นต้องย่อเลย flags: qr rd ra ก็เขียนให้เต็มได้ เครื่องหมายเซมิโคลอนหน้าบรรทัดต้องการสื่ออะไรผมก็ไม่รู้ แถมทำให้สับสนมากกว่าเดิม
      จึงไม่แปลกเลยที่ผู้คนจะสับสนเมื่อเรียน DNS จากเอกสารและเครื่องมือที่มีให้
    • คุณบอกว่า “ไม่เห็นด้วยกับบทความนี้” แต่ดูเหมือนแทบไม่ได้ตอบประเด็นของบทความเลย แค่คัดค้านชื่อเรื่องเท่านั้น แถมยังดูเหมือนจะเอา DNS ยาก กับ DNS เรียนรู้ยาก มาปนกัน
      ถ้าบอกว่า “แค่ต้องใช้ความพยายามและเวลานิดหน่อย” แล้วต้องใช้ความพยายามและเวลามากแค่ไหน? หลายคนในเธรดนี้บอกว่าเรียนรู้จากการลงมือสร้าง server เอง บอกว่าใช้เวลาหลายเดือนกว่าจะเข้าใจ แล้วก็ย้ำว่า “พอเข้าใจแล้วก็ค่อนข้างง่าย” ถ้าอย่างนั้น สำหรับสิ่งที่แพร่หลายและเรียบง่ายในเชิงแนวคิดขนาดนี้ เราน่าจะเห็นพ้องกันได้ไหมว่าจริง ๆ แล้วมันเรียนรู้ยาก
    • ถ้าอ่านบทความก็จะเห็นว่าทำไมมันถึงเรียนรู้ยาก แนวคิดนั้นง่าย แต่ตอนสอนแนวคิดนี้ มักไม่ได้รวม รายละเอียดของอินเทอร์เน็ตสมัยใหม่ ทั้งหมดเข้าไปด้วย
      ตัวอย่างเช่น กฎที่ browser ใช้ cache และ expire รายการ DNS คืออะไร? กฎนั้นสอดคล้องกันในแต่ละ browser หรือไม่?
    • ผมมองว่า DNS เป็นหนึ่งในเทคโนโลยีที่ตลอดอาชีพการทำงาน เราสามารถเก็บเศษความรู้เล็ก ๆ น้อย ๆ จากที่โน่นที่นี่แล้วผ่านไปได้ ถ้าคนจำนวนมากต้องรับมือกับมันตรง ๆ ก็คงรู้สึกว่ามันซับซ้อนน้อยกว่าที่เป็นจริง แต่ในอุตสาหกรรม สิ่งแบบนี้มักได้รับกลิ่นอายลึกลับบางอย่าง

  • ผมคิดว่าบทความจับประเด็นได้ดี DNS เองไม่ได้ยาก แต่การเรียนรู้ DNS ในโลกจริงนั้นยาก เพราะระหว่างการตั้งใจ lookup กับการได้ผลลัพธ์ที่คาดไว้ มีหลายส่วนตรงกลางที่ ถูกซ่อนไว้
    เมื่อก่อน รูปแบบการเชื่อมต่ออินเทอร์เน็ตพื้นฐานคือ interface หนึ่งตัว gateway หนึ่งตัว และผู้ให้บริการ DNS server หนึ่งราย ตอนนี้อาจเชื่อมต่อกับ WAN หลายเส้นพร้อมกัน เช่น LTE และ WiFi และผู้ใช้ก็รู้ได้ยากว่าเส้นทางการ resolve จริง ๆ ใช้เส้นทางไหน ไม่ชัดเจนเลยว่าเป็น browser, interface มาตรฐานของไลบรารี C ของระบบ, local resolver หรือ recursive resolver ระหว่างทาง, มี local cache หรือไม่, หรือมีการใส่ option พิเศษเป็นค่าเริ่มต้นหรือไม่
    แม้ทุกอย่างจะทำงานได้ ก็ไม่สามารถเชื่อแบบไม่ลืมหูลืมตาได้ว่า query และ response ของแอปหนึ่งใช้เส้นทางเดียวกับอีกแอปหนึ่ง browser 3 ตัวอาจใช้วิธีต่างกันคนละแบบ ระบบปฏิบัติการก็ทำงานอีกแบบหนึ่ง และยังมี mDNS เพิ่มเป็นทางเลือกที่ห้าได้อีก

  • มีมุกว่า ในวิทยาการคอมพิวเตอร์ ปัญหายากมีแค่สามอย่างคือ cache invalidation และ การตั้งชื่อ
    และ DNS ก็คือระบบ caching สำหรับชื่อของสิ่งต่าง ๆ
    https://reddit.com/comments/15c2ul2/comment/jtty9dy

    • ถ้าพูดให้ยุติธรรม DNS เป็นหนึ่งในกรณีที่ ทำเรื่องการตั้งชื่อได้ถูกต้อง
      มีการจัดการทั่วโลก (IANA), เป็นลำดับชั้น, เป็นแบบ federated และแก้ไขได้ง่าย

  • DNS เป็นเทคโนโลยีประเภทที่มี ความไม่สอดคล้องกัน ระหว่างระดับที่ดูเหมือนง่ายกับความยากที่เผยออกมาจริง ๆ
    เราใช้ DNS กันทุกวัน และมันดูง่ายมาก ภาษาของ DNS ในชีวิตประจำวันคือชื่อโดเมน การค้นหา และที่อยู่ IP ภาษานี้ถูกเปิดเผยตรง ๆ ในเบราว์เซอร์ และการเปิดเผยนั้นทำให้เราสร้างโมเดลทางความคิดเกี่ยวกับวิธีทำงานของมัน
    แต่ภายในมีภาษาที่ต่างออกไปโดยสิ้นเชิง เช่น zone, resolver, delegated authority และจุดประหลาด ๆ หลัง top-level domain

    • จุดประหลาดนั้นเรียกว่า root ถ้าไม่มีจุด ชื่อนั้นยังไม่สมบูรณ์ แต่ถ้ามีจุด ชื่อนั้นจะถูกนิยามอย่างสมบูรณ์ กล่าวคือบริบทคือทุกอย่าง ถ้าไม่มีจุด resolver อาจเติมโดเมนของตัวเองหรือบางส่วนของโดเมนนั้นซ้ำ ๆ ต่อท้ายได้
      เช่น host.example.co.uk หมายถึงอะไรเราทั้งคู่รู้กันดี แต่ถ้าไม่มีจุดท้ายชื่อ resolver อาจพยายามค้นหา host.example.co.uk.example.co.uk
      ในการตั้งค่าเริ่มต้นของ Windows กรณีแบบนี้อาจลอง host.example.co.uk.example.co, host.example.co.uk.example, แล้วก็ host.example.co.uk.example อีกครั้ง และ host.example.co.uk. จนได้ผลลัพธ์ก็ได้ อย่างไรก็ตาม ผมไม่เคยเห็น Windows ที่ลองแบบแรกจริง ๆ และพฤติกรรมนี้ดูเหมือนถูกออกแบบมาเพื่อรับมือกับสภาพแวดล้อมองค์กรขนาดใหญ่ที่มี Active Directory แบบสหพันธรัฐซึ่งเป็นสัตว์ประหลาดของ DNS
      ทุกวันนี้เบราว์เซอร์มีแนวโน้มสูงที่จะค่อย ๆ แอบไปหาเซิร์ฟเวอร์ DNS over HTTPS(DoH) โดยไม่ขอความยินยอมจากผู้ใช้ แล้วไปข้องเกี่ยวกับคู่สนทนาน่าสงสัยสารพัด การค้นหา DNS เป็นข้อมูลพื้นฐาน ดังนั้น ISP จึงชอบดูว่าผู้ใช้ไปที่ไหน ผู้ผลิตระบบปฏิบัติการก็ย่อมสามารถส่ง “telemetry” ได้เช่นกัน Google ไม่ได้เป็นเจ้าของเดสก์ท็อป แต่เป็นเจ้าของเบราว์เซอร์ ดังนั้นถ้าทำให้ผู้ใช้ใช้เซิร์ฟเวอร์ DNS ที่ “ปลอดภัย” แทน DNS ที่ผู้ใช้ตั้งไว้ได้ ก็เป็นประโยชน์กับพวกเขา กลเม็ดพวกนี้ทำให้การแก้ปัญหา IT น่าตื่นเต้นกว่าเดิมมาก
      เรื่องจุดท้ายชื่อไม่ต้องกังวลมากนัก เพราะอย่างไรเสียคุณก็แทบแน่ใจได้ว่าไม่ได้ใช้เซิร์ฟเวอร์ DNS ที่คิดว่าใช้อยู่ จงเข้าใจว่า DoH ถูกสร้างมาทำไม และสำหรับผู้ใช้ทั่วไปบางคนก็มีเหตุผลที่จะใช้ เช่น กรณีคนที่ไม่ใช่ผู้เชี่ยวชาญ IT ใช้ฮอตสปอต WiFi อันตราย หากเบราว์เซอร์กลับบ้านอย่างปลอดภัยเพื่อทำ DNS lookup ก็จะป้องกันได้ระดับหนึ่ง แต่คำถามว่า vendor ของเบราว์เซอร์ควรมีสิทธิ์เหยียบย่ำตัวเลือกด้านความปลอดภัยของ endpoint ของผู้ใช้หรือไม่นั้นเป็นอีกเรื่องหนึ่ง
      DNS ซับซ้อนกว่าการค้นหาที่อยู่ธรรมดามาก ทุกวันนี้มันเป็นเรื่องของเงิน และจริง ๆ ก็เป็นแบบนั้นมาตลอดตั้งแต่ราวปี 2000 ตอนนี้มีบริษัทยักษ์ใหญ่ที่ดื้อรั้นมากมายซึ่งอยากเป็นคนตัดสินว่าใครจะได้ประโยชน์จากผู้ใช้
    • ส่วนที่ยากผมว่าอยู่ที่ความเป็น distributed เหนือระดับอะตอมของแต่ละโหนดมีมนตร์ดำมหาศาลเกิดขึ้น และนั่นสร้างความซับซ้อนส่วนใหญ่กับความทึบส่วนใหญ่ขึ้นมา
      DNS เองนั้นง่าย การกระจายข้อมูลที่ไม่ขึ้นกับองค์กรต่างหากที่ยุ่งยากจริง ๆ

  • เมื่อหลายปีก่อน ผมตระหนักว่าตัวเองเข้าใจ DNS แบบเป็นชิ้น ๆ เท่านั้น รู้แนวคิดระดับ CS101 ว่า dig(1), BIND และการแก้ชื่อ DNS แบบ recursive ทำงานอย่างไร แต่ขาด ความรู้ภาคปฏิบัติ ที่จำเป็นต่อการออกแบบและลงมือสร้างระบบที่ไม่ใช่เรื่องเล็ก หรือดีบักระบบที่ไม่ทำงาน
    ดังนั้นผมจึงอ่าน “DNS and BIND” แทบตั้งแต่ต้นจนจบ และตั้งค่าเซิร์ฟเวอร์ BIND จริง ๆ สำหรับเว็บไซต์ส่วนตัวที่ไม่สำคัญนักอยู่หลายเว็บ มันไม่ยาก แต่ต้องลงทุนเวลาพอสมควร BIND อาจไม่ใช่คำตอบที่ถูกต้องสำหรับหลาย use case แต่มีคุณค่ามาก เพราะแนวคิดและคำศัพท์จำนวนมากของ DNS ยังมาจาก BIND
    ผมคิดว่าหนังสือถูกประเมินค่าต่ำไปในการเรียนรู้เรื่องแบบนี้ แหล่งข้อมูลที่หาได้บนเว็บมักเป็นทฤษฎีระดับสูง เช่นแผนภาพบล็อกของ recursive query หรือเป็นเนื้อหาที่เน้นงานเฉพาะ เช่นวิธีใช้ dig ทำ recursive query หรือเป็นเนื้อหาระดับต่ำอย่างการอ่านซอร์สเพื่อทำความเข้าใจนโยบาย retry ของ DNS client ในเครื่อง ถ้าต้องการเข้าใจแต่ละชิ้นส่วนและวิธีที่มันประกอบเข้าด้วยกัน ตั้งแต่ว่ากำลังพยายามบรรลุอะไร ไปจนถึงรายละเอียดการ implement อย่าง cache อยู่ตรงไหน แทบไม่มีอะไรทดแทนแนวทางแบบองค์รวมที่พบได้บ่อยในหนังสือ บนเว็บก็ไม่ใช่ว่าไม่มีเลย แต่หาได้ยาก

  • คนทำ IT ทุกคนควรมีความรู้ภาคปฏิบัติเรื่อง การดีบักปัญหา DNS
    DNS เป็นช่องทางของช่องโหว่ด้านความปลอดภัยที่สำคัญมาโดยตลอดในเชิงประวัติศาสตร์ และมีแนวโน้มว่าจะยังเป็นเช่นนั้นต่อไป ช่องโหว่เหล่านี้นำไปสู่เส้นทางโจมตีของโปรโตคอลอื่นแทบทั้งหมด เช่น SMTP แม้แต่ระบบผู้ออกใบรับรองที่ใช้กับ HTTPS ก็พึ่งพาโปรโตคอลที่โดยพื้นฐานแล้วไม่ปลอดภัยอย่างมาก ถ้าธนาคารซื้อใบรับรอง DV แทน OV คุณจะสังเกตได้ไหม? คงไม่
    ดังนั้นการที่ DNS ดูเรียนยากสำหรับคนที่ไม่ค่อยสนใจก็ไม่ใช่เรื่องแย่เสมอไป เพราะแม้ตอนนี้ก็ยังเห็นคนสร้างฟีเจอร์เกี่ยวกับ DNS โดยไม่ยอมใช้เวลาเข้าใจประวัติของสิ่งอย่าง port randomization, cache poisoning และ AXFR ให้ถูกต้อง

    • ผมรู้สึกว่าอะไรก็ตามที่ broadcast หรือประกาศ การตัดสินใจ routing ไม่ว่าจะอยู่ในเลเยอร์ใดของเครือข่าย ล้วนดูเหมือนเรียบง่ายกว่าความเป็นจริง แต่มีอันตรายแฝงอยู่ได้

  • ขอโปรโมต side project แบบน่าอายหน่อย ในบทความบอกว่าอยากให้การแก้ชื่อ DNS มีโหมด “debug” ซึ่งในเว็บ UI ของ ComfyDNS มีฟีเจอร์นั้นอยู่ :3
    https://comfydns.com/
    รูปที่ด้านบนมีข้อความ TRACE google.com A IN คือฟีเจอร์นั้น
    ComfyDNS ก็เป็นโปรเจกต์ที่ผมทำเพื่อเกาคันส่วนตัวด้วย ผมเบื่อกับการแก้ไฟล์ zone ของ bind9 ด้วยมือ และก็สงสัยว่า DNS ทำงานอย่างไร รู้แค่ผิวเผินแต่ไม่รู้รายละเอียด จึง implement RFC “ตั้งแต่ต้น” ใช้ netty แต่ไม่ได้ใช้ DNS library สนุกทีเดียว
    ถ้าเว็บรับทราฟฟิกไม่ไหวแล้วล่มก็ขออภัยด้วย เป็นแอป Rails ที่รันอยู่บน free tier ของ Oracle Cloud

  • มุกที่ได้ยินกันเสมอคือ DNS เอาปัญหาที่ยากที่สุดสองอย่างในวิทยาการคอมพิวเตอร์คือ การตั้งชื่อ และ การทำให้ cache หมดอายุ มารวมกัน

    • DNS มีตัวนับอายุเป็นวินาที และการนับวินาทีนั้นจะหย่อน ๆ พอสมควรก็ได้
      มันไม่ใช่การ invalidate cache แบบที่ยาก จริง ๆ แล้วแทบไม่จำเป็นต้อง “invalidate” เลย
      ฝั่งเซิร์ฟเวอร์เองก็ยังยอมรับได้เต็มที่ที่จะส่งทั้งเวอร์ชันเก่าและเวอร์ชันใหม่ปนกันไปสักพัก
    • ไม่ใช่มุกหรอก แต่เป็นเรื่องจริง

  • รู้สึกว่าเป็นบทความแนวนี้อีกแล้ว ในยุค 1990 อินเทอร์เน็ตยังเล็กกว่านี้ คอมพิวเตอร์ก็ช้ากว่าและประสิทธิภาพต่ำกว่ามาก แต่พวกเราก็เรียนรู้กันได้ง่ายมาก
    ตอนนั้นสำหรับ ISP แล้ว สิ่งอย่าง DNS, LDAP, SMTP, IMAP ถือเป็นพื้นฐานสุด ๆ และผู้คนก็อ่านเอกสารทางการอย่าง RFC กันจริง ๆ ถ้าจะรันเซิร์ฟเวอร์บนอินเทอร์เน็ตก็ต้องเรียนรู้ และแค่ลงทุนเวลาสักหน่อย—ก็คือใช้เวลาที่ได้รับค่าจ้างในที่ทำงาน—ก็เรียนได้แล้ว
    นักพัฒนาและคนรุ่น DevOps สมัยนี้ไม่มีความอดทนหรือความริเริ่ม คาดหวังให้มีคนป้อนให้ แล้วก็คัดลอกแปะอะไรก็ได้จาก StackOverflow กับบล็อกคุณค่าต่ำ แทนที่จะเรียนรู้รากฐานที่ทำให้อินเทอร์เน็ตตั้งอยู่ได้ กลับหยิบเครื่องมือแรปเปอร์ยอดฮิตประจำสัปดาห์นั้นขึ้นมา ทำตามคำสั่งจากบล็อกห่วย ๆ แล้วพอทุกอย่างพังและทำบริษัทเสียเงินก้อนโต ก็ร้องว่าไม่ยุติธรรม ทั้งหมดเพราะไม่ได้สละเวลาเรียนพื้นฐานว่าอินเทอร์เน็ตทำงานจริงอย่างไร
    เห็นเรื่องแบบนี้มาตลอด จริง ๆ แล้วมันไม่ได้ยากขนาดนั้น แค่ทำการบ้านก็พอ

  • ไม่ยากหรอก DNS เป็นหนึ่งในไม่กี่เทคโนโลยีที่แทบไม่เปลี่ยนไปมากนัก และการทำงานก็ค่อนข้างเข้าใจได้ตามสัญชาตญาณ
    dig อาจทำให้งงได้บ้าง มันมีฟีเจอร์มากกว่า nslookup รุ่นเก่า แต่เข้าใจยากกว่า อนึ่ง nslookup ก็ยังทำงานได้ดีอยู่
    ผมคิดว่าเหตุผลหนึ่งที่คนรุ่นใหม่ในวงการสับสนกับ DNS และโปรโตคอลหลัก ๆ คือทุกวันนี้มีหลายอย่างที่ “แค่ใช้ได้เลย” มากเกินไป
    ตัวอย่างเช่น เราเตอร์ WiFi สมัยนี้แกะออกจากกล่องก็ “แค่ใช้ได้เลย” ทันที ช่วงต้นยุค 2000 ถ้าจะตั้งค่าอะไรแบบนั้น ต้องมีวิศวกรเครือข่ายที่รู้เรื่อง DNS, IP, Ethernet, RFC1918, โปรโตคอล routing จริง ๆ และเรื่องอื่น ๆ อีกมาก และน่าจะเข้าใจดีด้วยว่าทำไมถึงตั้งค่าแบบนั้น
    ถ้าคิดว่า DNS จากมุมมองไคลเอนต์ชวนงง ลองตั้งค่า BIND ดูก็ได้ ;-)
    /เสียงบ่นของคนแก่ไว้หนวดเครา

    • ตอนอายุ 14 เคยดูแลสภาพแวดล้อม Active Directory ของร้านอาหารแห่งหนึ่งแบบลวก ๆ ทั้งเมล เว็บ และ CIFS โดยที่ยังไม่เข้าใจ DNS หรือ DHCP
      จริง ๆ แล้วต้องทำให้ DHCP server ของ WRT54G แจก IP คงที่ของ domain controller เป็น DNS server เพื่อให้ resolve ชื่อได้ถูกต้อง แต่ผมทำให้ทุกอย่างรันได้ด้วย IP address กับรายการใน hosts file แทน ตั้งค่า MX record ของโดเมนไปที่ WAN IP ของเราเตอร์ด้วย และไม่มี PTR record มองย้อนกลับไปแล้ว การที่อีเมลส่งถึงกันได้ราบรื่นขนาดนั้นถือเป็นปาฏิหาริย์
      หลายปีต่อมาถึงได้รู้ว่า DNS ทำงานจริงอย่างไร และช่วงต้นวัย 20 ก็รับช่วง intranet ภายในบริษัทที่ใช้ BIND เป็น nameserver สำหรับ zone ของโดเมนบริษัทภายนอกทั้งหมดมาอีกที ตอนย้ายคอนฟิกนี้ไป VPS เพื่อเพิ่มความน่าเชื่อถือ ได้เรียนรู้เรื่อง zone transfer, SOA และอื่น ๆ อีกมากมาย ผมขอบคุณประสบการณ์นั้น แต่ทุกวันนี้แทบทุกอย่างมีคนหรือระบบจัดการแทนแล้ว จึงกลายเป็นกิจกรรมที่มีคุณค่าต่ำ จะดีหรือร้าย “IT” ก็ไม่ได้ถูกประเมินค่าแบบเดียวกับ “software engineering”
    • จริงอยู่ที่การทำงานค่อนข้างเข้าใจได้ตามสัญชาตญาณ แต่ก็เฉพาะเมื่อมองข้ามความเป็นไปได้ของพฤติกรรมประหลาดสารพัดอย่าง เช่น เซิร์ฟเวอร์ที่ไม่สนใจ TTL
      ผมลืมไม่ได้เลยตอน Firefox ออกอัปเดตที่เปิด DNS-over-HTTPS เป็นค่าเริ่มต้น เราแจก DNS server ภายในให้ workstation ผ่าน DHCP อยู่ แล้วจู่ ๆ ก็มีเสียงร้องว่า “อีเมลหายไปแล้ว! ทุกอย่างพังหมด!” กันถล่มทลาย เว็บเมลภายในกับเว็บเซิร์ฟเวอร์ intranet ดูเหมือนหายไปเฉย ๆ
      ใช้เวลานานเกินจำเป็นกว่าจะหาว่าเกิดอะไรขึ้น ส่วนหนึ่งเพราะคิดว่า “นี่มัน DNS นะ ทำไมจู่ ๆ ถึงพังได้?” แต่ค่อนข้างชัดว่า Mozilla ไม่ได้คาดการณ์ปัญหาที่เดาได้ง่ายแบบนี้ไว้
    • สิ่งที่พูดถึงตรงนี้เป็นแค่ส่วนเล็ก ๆ ของ DNS เท่านั้น
      เช่น ลอง query thing.behind.cdn.it แล้วผมได้คำตอบหนึ่ง คนอื่นกลับได้คำตอบอีกแบบสำหรับชื่อเดียวกัน ตัวมันเองค่อนข้างชัดเจน แต่จะซับซ้อนขึ้นเมื่อมีคนถามอย่างสมเหตุสมผลว่า “ช่วยเปิดช่อง firewall สำหรับ thing.behind.cdn.it ได้ไหม?”
      บางเซิร์ฟเวอร์ forward คำขอ บางเซิร์ฟเวอร์ delegate บางเซิร์ฟเวอร์ lookup ให้แทน และบางเซิร์ฟเวอร์ก็ไม่ทำ ยังมีเวทมนตร์ของ search domain ฝั่งไคลเอนต์อีก และก็ไม่แน่ว่าไคลเอนต์หรือ resolver library ภายในจะเคารพ TTL หรือไม่
      ชนิดของ record ก็มีมากมายนับไม่ถ้วน และบางครั้งเซิร์ฟเวอร์ก็สั่งให้เชื่อมต่อใหม่ด้วย TCP แทน UDP
      ดังนั้น DNS จึงค่อนข้างซับซ้อน มันทำงานได้ดีมาก และส่วนที่ยุ่งยากส่วนใหญ่ถูก abstract ไว้ในสิ่งที่ “โดยทั่วไปก็แค่ทำงานได้” จึงเกิดภาพลวงตาว่ามันเรียบง่าย
    • พูดถึงการรู้จักโปรโตคอลเก่า ๆ ช่วงไม่กี่สัปดาห์ที่ผ่านมา ผมอ่าน Networking for System Administrators และทำโน้ตการ์ด Anki กับทบทวนไปเยอะมาก
      น่าทึ่งที่ผมมั่นใจขึ้นมากในการเข้าใจเครือข่ายในระดับสูง ตั้งแต่ DNS ลงไปถึงสิ่งที่อยู่ข้างใต้ เช่น ethtool และ Ethernet frame
      ผมชอบรู้เรื่องตั้งแต่ฐานราก เลยเลือกเรียนวิศวกรรมไฟฟ้าแทนวิทยาการคอมพิวเตอร์ตอนมหาวิทยาลัย ดังนั้นอาจจะไม่น่าแปลกใจก็ได้
    • ใช่แล้ว การตั้งค่า BIND นั้นยาก Unbound/nsd จัดการง่ายกว่ามาก อย่างไรก็ตาม กระบวนการหาเอกสารที่ถูกต้องเองก็เป็นการฝึกที่น่าหงุดหงิด
      หลักการของ DNS ถ้าเข้าใจว่ามันเป็นแบบ recursive ก็ไม่ได้ยากขนาดนั้น แต่ถ้าจะตั้งค่าโดยคำนึงถึงความปลอดภัย มีโครงสร้างพื้นฐานที่ถูกต้อง และเก็บรายละเอียดสุดท้ายให้ครบ ก็มีอะไรให้เรียนรู้อีกมาก ถ้าไม่นับ BIND ก็ไม่ได้ยากขนาดนั้น