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

สามรูปแบบสำหรับเนมสเปซเดียว

TypeWhat your resolver keepsUpstream mustFails when
forwarda forwarder listanswer queries from your source addressupstream is down and forward only is set
stubthe zone's NS records and addressesanswer NS queries for the zonedelegation data goes stale after an NS change
secondarya full copy of the zonepermit AXFR or IXFR from your sourcetransfer is blocked by ACL or firewall

การส่งต่อแบบมีเงื่อนไข: การผูกมัดที่น้อยที่สุด

สมมติรีโซลเวอร์ในออฟฟิศอยู่ที่ 192.168.10.53 และเซิร์ฟเวอร์ของบริษัทอยู่ที่ 10.40.0.53 ซึ่งเข้าถึงได้ผ่านอุโมงค์ที่อนุมัติแล้ว คำประกาศมีสามบรรทัด และบรรทัดที่น่าสนใจคือ forward only เพราะมันเปลี่ยนพฤติกรรมเมื่อล้มเหลว ไม่ใช่เส้นทาง

zone "corp.example" {
    type forward;
    forward only;
    forwarders { 10.40.0.53; };
};

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

สตับหรือเซคันดารี: เมื่อการมอบอำนาจสำคัญ

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

zone "corp.example" {
    type stub;
    masters { 10.40.0.53; };
};

zone "corp.example" {
    type secondary;
    primaries { 10.40.0.53; };
    file "corp.example.db";
};

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

การตรวจสอบที่ชี้ขาดระหว่างสองวิธี

BIND สร้างคำค้นขาออกของตัวเอง คำถามจึงไม่ใช่ว่าแล็ปท็อปเข้าถึง 10.40.0.53 ได้หรือไม่ แต่เป็นว่าโฮสต์ของรีโซลเวอร์เข้าถึงได้จากที่อยู่ต้นทางที่เซิร์ฟเวอร์ของบริษัทจะเห็น ถามเคอร์เนลก่อน แล้วถามเซิร์ฟเวอร์ ตามลำดับนั้น

ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example

อนุญาต UDP และ TCP บนเส้นทาง คำตอบที่ถูกตัดให้สั้นบังคับให้ใช้ TCP และนโยบายที่อนุญาตเฉพาะ UDP จะทำให้เกิดความล้มเหลวเป็นระยะที่ดูเหมือนแพ็กเก็ตหาย ฝั่งบริษัทต้องมีทั้งกฎอนุญาตสำหรับต้นทางของรีโซลเวอร์และเส้นทางย้อนกลับมาที่ต้นทางนั้น ต้นทางนั้นอาจเป็นที่อยู่ที่กำหนดเส้นทางของรีโซลเวอร์หรือที่อยู่ที่แปลอย่างชัดเจน และแทบไม่เคยเป็นที่อยู่จากพูลของผู้ใช้ ถ้าคำค้น NS ล้มเหลว โซนสตับจะทำงานไม่ได้ไม่ว่าโซนฟอร์เวิร์ดจะมีพฤติกรรมอย่างไร

ตรวจสอบคำตอบ ไม่ใช่อุโมงค์

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

ให้ไคลเอนต์ชี้ไปที่รีโซลเวอร์ในออฟฟิศ และเปิดการตรวจสอบ DNSSEC ไว้ เบราว์เซอร์ที่กำหนดค่าให้ใช้รีโซลเวอร์เข้ารหัสอิสระจะข้ามรูปแบบนี้ไปทั้งหมด และการปิดการตรวจสอบเพื่อให้คำตอบที่ไม่คาดคิดดูถูกต้องนั้นแลกความล้มเหลวที่มองเห็นได้กับความล้มเหลวที่มองไม่เห็น

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

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