DNS ของประภาคาร Nebula ใครบ้างที่ถามบันทึกใดได้
ผู้รับฟังแบบเลือกได้ตอบจากข้อมูลโฮสต์ที่ประภาคารถืออยู่ การค้นหาบันทึก A และ TXT ต่างกันในด้านการเข้าถึงและผู้ชม จึงควรผูกมันอย่างตั้งใจ
บทบาทประภาคารใน Nebula ทำงานหลายอย่างที่คนมักคิดว่าเป็นอัตโนมัติ และการตอบ DNS ไม่ใช่หนึ่งในนั้น บริการชื่อเป็นผู้รับฟังแบบเลือกได้ที่เริ่มต้นในสถานะปิด ซึ่งเป็นเหตุผลว่าทำไมโฮสต์ที่แปลงชื่อได้ดีภายใน overlay อาจไม่มีอะไรเลยสำหรับแปลงแล็ปท็อปของเพื่อนร่วมงาน ก่อนเปิดใช้งาน ควรตัดสินใจว่าใครควรเข้าถึงมันและยอมตอบบันทึกชนิดใด เพราะสองคำตอบนั้นต่างกัน
ผู้รับฟังเป็นทางเลือกและปิดอยู่โดยค่าเริ่มต้น
การค้นพบและ DNS เป็นบริการแยกกัน ประภาคารช่วยให้เพียร์พบกันและยังตอบคำถามชื่อเกี่ยวกับโฮสต์ที่รู้จักได้ด้วย แต่ส่วนหลังต้องเปิดอย่างชัดเจนในการกำหนดค่า
ตัดสินใจว่าอินเทอร์เฟซและเครือข่ายใดควรเข้าถึงผู้รับฟังก่อนเปิดใช้งานสิ่งใด บริการ DNS ที่ตอบบนอินเทอร์เฟซที่คุณไม่ได้ตั้งใจจะกลายเป็นการรั่วไหลข้อมูลเล็กน้อยโดยไม่มีบันทึกใดให้ใครอ่าน การตัดสินใจตอนนี้ถูกกว่าการจำกัดภายหลังมาก เมื่อมีบางอย่างขึ้นกับคำตอบที่ผิด สองบรรทัดของการกำหนดค่าอธิบายได้ง่ายกว่าบันทึกเหตุการณ์ในอีกครึ่งปี
บันทึก A และ TXT ไม่ได้ใช้ผู้ชมร่วมกัน
บันทึกสองชนิดนี้ตอบภายใต้เงื่อนไขต่างกัน และการปฏิบัติต่อมันเป็นบริการเดียวคือข้อผิดพลาดที่บทความนี้มีไว้เพื่อป้องกัน
| Query | What it returns | Who can reach it |
|---|---|---|
| A record for a host name | That host Nebula IP | Any host that can reach the listener, overlay or not |
| TXT for a host IP | Certificate information | Only over the Nebula network |
ความไม่สมมาตรนั้นเป็นเจตนา ไม่ใช่ความหลงลืม การแมปชื่อเป็นที่อยู่มีค่าน้อยสำหรับคนนอก ขณะที่เมทาดาทาของใบรับรองอธิบายตัวตนใน overlay ของคุณ อย่าพาสมมติฐานจากแถวหนึ่งไปอีกแถวเพียงเพราะกระบวนการเดียวกันตอบทั้งสอง
มันตอบเฉพาะเกี่ยวกับโฮสต์ของประภาคารเอง
นี่ไม่ใช่ตัวแปลงทั่วไปสำหรับสำนักงาน VPC บนคลาวด์ หรืออินเทอร์เน็ตสาธารณะของคุณ ประภาคารตอบจากข้อมูลโฮสต์ที่ได้รับมา คุณสมบัตินี้จึงอยู่บนโหนดประภาคารไม่ใช่บนทุกเพียร์
เมื่อชื่อล้มเหลวและ overlay ไม่เกี่ยวข้อง ให้หาโซนและตัวแปลงที่เป็นเจ้าของจริง การผสมตัวแปลง overlay เข้าในการกำหนดค่า DNS ทั่วไปของโฮสต์ทำให้เกิดความล้มเหลวที่ดูเหมือนสุ่ม เพราะบางชื่อแปลงได้และบางชื่อไม่มีอะไรตอบ
ดู จุดเข้า bootstrap ด้วย ชื่อโฮสต์ที่ใช้เข้าถึงประภาคารแรกต้องแปลงผ่านเส้นทางปกติก่อนที่การค้นพบจะพึ่งพาได้ ปัญหาไก่กับไข่ตรงนี้จึงดูเหมือน overlay ที่เสียหายทุกประการ มันยังรายงานแบบเดียวกันด้วย เพียร์ที่ไม่เคยขึ้นมาและไม่มีสาเหตุชัดเจน ตรวจสอบการแปลงชื่อก่อนแตะใบรับรอง เพราะลำดับนี้จับคนที่เริ่มจากครึ่งที่ยากกว่า
ตรวจสอบที่อยู่ผูกพัน แล้วทดสอบจากภายนอก
lighthouse.dns.host และ lighthouse.dns.port กำหนดว่าบริการทางเลือกฟังที่ใด ตรวจสอบค่าเหล่านี้ร่วมกับไฟร์วอลล์ของโฮสต์และนโยบายเครือข่าย เพราะที่อยู่ผูกพันเป็นคำแถลงเจตนา ไม่ใช่การควบคุมความปลอดภัยในตัวเอง
dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +shortสอบถามจากเครือข่ายที่คุณตั้งใจจะอนุญาต ไม่ใช่จากประภาคารเอง การค้นหาที่สำเร็จบนประภาคารพิสูจน์ว่ากระบวนการทำงานอยู่ และไม่ได้บอกอะไรเกี่ยวกับสิ่งที่โฮสต์ภายนอกถามได้ ซึ่งเป็นคำถามที่สำคัญจริง ๆ
เปิดเผยอย่างตั้งใจ
ชื่อและเมทาดาทาของใบรับรองเป็นข้อมูลปฏิบัติการที่มีประโยชน์ และประโยชน์ตัดได้ทั้งสองทาง ตัดสินใจว่าผู้รับฟังควรมีไว้สำหรับ overlay เท่านั้น อนุญาตบันทึกชนิดใด และใครตรวจทานการกำหนดค่าเมื่อมีการเปลี่ยนแปลง
จากนั้นจดบันทึกไว้ข้างการตั้งค่าประภาคาร คนถัดไปที่ต้องแก้ปัญหาการแปลงชื่อจะสันนิษฐานว่าบริการนี้มีอยู่ตลอดเวลา และจะสันนิษฐานว่ามันเข้าถึงได้เสมอจากทุกที่ที่เขาบังเอิญทดสอบ หนึ่งย่อหน้าที่บันทึกที่อยู่ผูกพัน เครือข่ายที่อนุญาต และชนิดบันทึก ช่วยประหยัดบ่ายของคนนั้นและประหยัดข้อความที่ถามว่าทำไมบางอย่างเปลี่ยนไป