DNS Resolution, Start to Finish

ทุกครั้งที่คุณพิมพ์โดเมนลงในเบราว์เซอร์ สายโซ่ของการค้นหาจะเริ่มทำงานก่อนที่แพ็กเกตแม้แต่เพียงหนึ่งแพ็กเกตจะไปถึงไซต์ที่คุณต้องการ สายโซ่นี้ส่วนใหญ่นั้นมองไม่เห็น และคำอธิบายส่วนใหญ่ของมันก็หยุดแค่ "มันเหมือนสมุดโทรศัพท์" นี่คือสิ่งที่เกิดขึ้นจริง ทีละขั้นตอน รวมถึงส่วนที่คนส่วนใหญ่มักข้ามไป

Stub resolver ไม่ฉลาด

ระบบปฏิบัติการของคุณไม่ทำการแก้ปัญหา DNS จริงด้วยตัวมันเอง มันเรียกใช้ stub resolver ซึ่งเป็นโค้ดบางเบาที่แค่ส่งต่อคำค้นหาของคุณไปยังเซิร์ฟเวอร์ DNS ใด ๆ ที่ได้รับการกำหนดค่าใน /etc/resolv.conf บน Linux หรือในการตั้งค่าแอดแปตเตอร์เครือข่ายของคุณบน Windows ตรวจสอบของคุณด้วย:

cat /etc/resolv.conf

ไฟล์นั้นมักจะชี้ไปที่เราเตอร์ของคุณ (เช่น 192.168.1.1) resolver ของ ISP ของคุณ หรือไปยังตัวที่สาธารณะเช่น 1.1.1.1 หรือ 8.8.8.8 Stub resolver ไม่มีตรรกะแคชของตัวเองนอกเหนือจากสิ่งที่ OS หรือ daemon ที่เป็นส่วนท้องถิ่นเช่น systemd-resolved ให้มา

Recursive resolver ทำงานจริง

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

dig example.com

ดู ANSWER SECTION — ตัวเลขก่อนประเภทบันทึก (เช่น 300 ก่อน A) คือ TTL ในหน่วยวินาที นี่คือระยะเวลาที่ resolver ได้รับอนุญาตให้แคชบันทึกก่อนถามอีกครั้ง

หากไม่มีการแคช recursive resolver จะเริ่มการเดินลงตามลำดับชั้น DNS จากราก

Root, TLD และเซิร์ฟเวอร์อำนาจสัตยาบรรณ

มีที่อยู่เซิร์ฟเวอร์ราก 13 ที่อยู่ (a.root-servers.net ถึง m.root-servers.net) แต่ละที่อยู่ได้รับการสนับสนุนโดยเครื่องจักรทางกายภาพจำนวนมากผ่านการกำหนดเส้นทาง anycast Sเซิร์ฟเวอร์รากไม่รู้ว่า example.com อยู่ที่ไหน แต่รู้ว่าเซิร์ฟเวอร์ใดจัดการ .com ดังนั้นมันจึงส่งกลับการอ้างอิง

จากนั้น resolver จะถาม .com TLD server ซึ่งอีกครั้งไม่รู้คำตอบสุดท้าย แต่รู้ว่าเซิร์ฟเวอร์ชื่อใดเป็นอำนาจสัตยาบรรณสำหรับ example.com โดยเฉพาะ คุณสามารถดูการมอบสิทธิ์นี้ได้ด้วยตัวเอง:

dig +trace example.com

คำสั่งนั้นแสดงให้เห็นทุก hop: root จากนั้น TLD จากนั้น authoritative nameservers สำหรับโดเมน ลงท้ายด้วยบันทึก A หรือ AAAA จริง เป็นคำสั่งที่ดีที่สุดคำเดียวสำหรับการทำความเข้าใจ DNS ด้วยสายตาแทนที่จะเป็นทางทฤษฎี

Authoritative nameserver คือจุดหยุดสุดท้าย เป็นเซิร์ฟเวอร์ที่เจ้าของโดเมนกำหนดค่าจริง ๆ บ่อยครั้งผ่านแผง DNS ของ registrar หรือบริการเช่น Route 53 หรือ Cloudflare DNS นี่เป็นเซิร์ฟเวอร์เพียงเครื่องเดียวในสายโซ่ทั้งหมดที่มีคำตอบจริง ตามแบบบัญญัติแทนที่จะเป็นสำเนาแคชหรือการอ้างอิง

ประเภทบันทึกที่คุณจะจัดการกับมัน

บันทึก A จับคู่ชื่อกับที่อยู่ IPv4 AAAA ทำเช่นเดียวกันสำหรับ IPv6 CNAME ชี้ชื่อหนึ่งไปยังชื่ออื่นแทนที่จะเป็น IP ซึ่งเป็นวิธีที่ CDN เช่น Cloudflare หรือ Fastly กำหนดเส้นทางการรับส่งข้อมูลโดยไม่เปิดเผย IP ดิบ บันทึก MX จัดการการกำหนดเส้นทางเมล และบันทึก TXT เก็บข้อความโดยพลการ ส่วนใหญ่จะใช้ในปัจจุบันสำหรับ SPF, DKIM และสตริงการตรวจสอบโดเมน บันทึก NS บอกโลกว่าเซิร์ฟเวอร์ใดเป็นอำนาจสัตยาบรรณสำหรับโซน และนั่นคือประเภทบันทึกที่ทำให้การมอบสิทธิ์เป็นไปได้ตั้งแต่แรก

จำที่แคชอาศัยอยู่จริง

การแคชเกิดขึ้นที่หลายชั้นพร้อมกัน: เบราว์เซอร์เอง (Chrome มี DNS cache ของตัวเองที่มองเห็นได้ที่ chrome://net-internals/#dns) แคช OS resolver แคชเราเตอร์ท้องถิ่น และ recursive resolver ในปลายน้ำ นี่คือเหตุผลที่การเปลี่ยน DNS สามารถปรากฏเพื่อทำงานได้ทันทีบนอุปกรณ์หนึ่ง และใช้เวลาหลายชั่วโมงจึงจะแสดงบนอุปกรณ์อื่น — คุณไม่ได้ตีแคชเดียวกัน

เมื่อคุณลดค่า TTL ของบันทึกก่อนการอพย้ายแบบวางแผน คุณไม่ได้เพิ่มความเร็วใด ๆ ทันที คุณแค่หดหน้าต่างในระหว่างที่ข้อมูลเก่าสามารถคงอยู่ได้เมื่อการเปลี่ยนแปลงเกิดขึ้นจริง ทำเช่นนี้อย่างน้อยหนึ่งรอบ TTL ล่วงหน้า ไม่ใช่ห้านาทีก่อน cutover

ทำไมเรื่องนี้ถึงสำคัญสำหรับการแก้ไขปัญหา

เมื่อไซต์ไม่สามารถเข้าถึงได้ dig +trace บอกคุณว่าชั้นใดหักพังพอดี: ปัญหา root/TLD ดูแตกต่างอย่างสิ้นเชิงจากเซิร์ฟเวอร์อำนาจสัตยาบรรณที่ไม่ได้กำหนดค่าอย่างถูกต้องหรือแคชเก่าบนเครื่องของคุณเอง การเปรียบเทียบ dig example.com กับ resolver ที่ทำงานได้ดี เช่น dig example.com @1.1.1.1 โดดเดี่ยวว่าปัญหาคือ resolver ท้องถิ่นของคุณหรือการตั้งค่า DNS จริงของโดเมน

DNS ดูเรียบง่ายจากภายนอกเพราะมันมักจะแก้ไขได้ภายใน 100ms และไม่มีใครคิดเกี่ยวกับมัน ข้างใต้ เป็นระบบการค้นหาแบบกระจายแคช และลำดับชั้นที่ทำงานมาโดยส่วนใหญ่ไม่เปลี่ยนแปลงในโครงสร้างตั้งแต่ยุค 1980 ซึ่งเป็นข้อโต้แย้งที่ดีพอสำหรับวิธีการออกแบบเดิมที่ถือ

หากคุณต้องการไปต่อเกี่ยวกับเรื่องนี้ Korra Studio มีส่วนที่เกี่ยวข้องบน DEFENSE_GRID ครอบคลุมส่วนขยายการรักษาความปลอดภัย DNS การขุดอุโมงค์ DNS เป็นเทคนิคการดึงข้อมูล และการสร้าง resolver ของคุณเองตั้งแต่เริ่มต้นใน Python