ย้อนกลับการมอบหมายโซนไปยังซับเน็ตน้อยกว่า /24 ใน BIND มันทำงานอย่างไร

วันหนึ่งฉันต้องเผชิญกับภารกิจในการให้สิทธิ์แก่ลูกค้ารายหนึ่งของฉันในการแก้ไขบันทึก PTR ของซับเน็ต /28 ที่มอบหมายให้เขา ฉันไม่มีระบบอัตโนมัติสำหรับการแก้ไขการตั้งค่า BIND จากภายนอก ดังนั้นฉันจึงตัดสินใจใช้เส้นทางอื่น - เพื่อมอบหมายโซน PTR ของซับเน็ต /24 ให้กับลูกค้า

ดูเหมือนว่า - อะไรจะง่ายกว่านี้? เราเพียงลงทะเบียนซับเน็ตตามต้องการและนำทางไปยัง NS ที่ต้องการ เช่นเดียวกับที่ทำกับโดเมนย่อย แต่ไม่มี. มันไม่ง่ายขนาดนั้น (แม้ว่าในความเป็นจริงแล้วโดยทั่วไปจะเป็นแบบดั้งเดิม แต่สัญชาตญาณจะไม่ช่วย) นั่นคือเหตุผลที่ฉันเขียนบทความนี้

ใครอยากจะคิดออกเองก็สามารถอ่านได้ RFC
ใครอยากได้โซลูชั่นสำเร็จรูป เชิญที่ cat ครับ

เพื่อไม่ให้เป็นการล่าช้าสำหรับผู้ที่ชอบวิธีการคัดลอกและวาง ฉันจะโพสต์ส่วนที่ใช้งานได้จริงก่อน จากนั้นจึงโพสต์ส่วนทางทฤษฎี

1. ฝึกฝน โซนมอบหมาย /28

สมมติว่าเรามีซับเน็ต 7.8.9.0/24. เราจำเป็นต้องมอบหมายเครือข่ายย่อย 7.8.9.240/28 ไปยังไคลเอนต์ DNS 7.8.7.8 (ns1.client.โดเมน).

ใน DNS ของผู้ให้บริการ คุณต้องค้นหาไฟล์ที่อธิบายโซนย้อนกลับของซับเน็ตนี้ ช่างมัน 9.8.7.in-addr.harp.
เราแสดงความคิดเห็นในรายการตั้งแต่ 240 ถึง 255 หากมี และในตอนท้ายของไฟล์เราเขียนดังนี้:

255-240  IN  NS      7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240

อย่าลืมเพิ่มโซนซีเรียลและทำ

rndc reload

การดำเนินการนี้จะทำให้ส่วนของผู้ให้บริการเสร็จสมบูรณ์ มาดู DNS ของลูกค้ากันดีกว่า

ก่อนอื่นเรามาสร้างไฟล์ /etc/bind/master/255-240.9.8.7.in-addr.arpa เนื้อหาต่อไปนี้:

$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@                       1D IN SOA       ns1.client.domain. root.client.domain. (
                        2008152607      ; serial
                        3H              ; refresh
                        15M             ; retry
                        1W              ; expiry
                        1D )            ; minimum
@                       IN NS        ns1.client.domain.
@                       IN NS        ns2.client.domain.
241                     IN PTR          test.client.domain.
242                     IN PTR          test2.client.domain.
245                     IN PTR          test5.client.domain.

และใน ชื่อ.conf เพิ่มคำอธิบายของไฟล์ใหม่ของเรา:

zone "255-240.9.8.7.in-addr.arpa." IN {
        type master;
        file "master/255-240.9.8.7.in-addr.arpa";
};

B รีสตาร์ทกระบวนการผูก

/etc/init.d/named restart

ทั้งหมด. ตอนนี้คุณสามารถตรวจสอบได้

#>  host 7.8.9.245 
245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.
245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.

โปรดทราบว่าไม่เพียงแต่จะได้รับบันทึก PTR เท่านั้น แต่ยังให้ CNAME ด้วย นั่นเป็นวิธีที่ควรจะเป็น หากคุณสงสัยว่าทำไม ยินดีต้อนรับสู่บทถัดไป

2. ทฤษฎี มันทำงานอย่างไร.

เป็นการยากที่จะกำหนดค่าและดีบักกล่องดำ มันง่ายกว่ามากถ้าคุณเข้าใจสิ่งที่เกิดขึ้นภายใน

เมื่อเรามอบหมายโดเมนย่อยในโดเมน โดเมนจากนั้นเราก็เขียนบางอย่างดังนี้:

client.domain.	NS	ns1.client.domain.
ns1.client.domain.	A	7.8.7.8

เราบอกทุกคนที่ถามว่าเราไม่รับผิดชอบในพื้นที่นี้และบอกว่าใครเป็นผู้รับผิดชอบ และคำขอทั้งหมดสำหรับ ลูกค้า.โดเมน เปลี่ยนเส้นทางไปที่ 7.8.7.8 เมื่อตรวจสอบเราจะเห็นภาพดังต่อไปนี้ (เราจะละเว้นสิ่งที่ลูกค้ามีอยู่ ไม่สำคัญ):

# host test.client.domain
test.client.domain has address 7.8.9.241

เหล่านั้น. เราได้รับแจ้งว่ามีบันทึก A ดังกล่าวและ IP ของมันคือ 7.8.9.241 ไม่มีข้อมูลที่ไม่จำเป็น

สิ่งเดียวกันนี้สามารถทำได้กับซับเน็ตได้อย่างไร?

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

ลองป้อนแบบนี้:

255-240  IN  NS      7.8.7.8

และ...ปาฏิหาริย์ก็ไม่เกิดขึ้น เราไม่ได้รับคำขอเปลี่ยนเส้นทางใด ๆ ประเด็นก็คือการผูกไม่รู้ด้วยซ้ำว่ารายการเหล่านี้ในไฟล์โซนย้อนกลับคือที่อยู่ IP และยิ่งกว่านั้นไม่เข้าใจรายการช่วง สำหรับเขา นี่เป็นเพียงโดเมนย่อยเชิงสัญลักษณ์บางประเภท เหล่านั้น. สำหรับการผูกจะไม่มีความแตกต่างระหว่าง "255-240"และ"ลูกค้าของเรา". และสำหรับการขอไปในที่ที่ต้องไป ที่อยู่ในคำขอควรมีลักษณะดังนี้: 241.255-240.9.8.7.in-addr.arpa. หรือเช่นนี้หากเราใช้โดเมนย่อยของอักขระ: 241.oursuperclient.9.8.7.in-addr.arpa. สิ่งนี้แตกต่างจากปกติ: 241.9.8.7.in-addr.harp.

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

และนี่คือจุดที่พวกเขาเข้ามามีบทบาท CNAME.

ในด้านของผู้ให้บริการ คุณต้องสร้างนามแฝงสำหรับที่อยู่ IP ทั้งหมดของเครือข่ายย่อยในรูปแบบที่จะส่งต่อคำขอไปยัง DNS ไคลเอ็นต์

255-240  IN  NS      ns1.client.domain.
241     IN  CNAME   241.255-240
242     IN  CNAME   242.255-240
и т.д.

นี่สำหรับผู้ทำงานหนัก =)

และสำหรับคนขี้เกียจการออกแบบด้านล่างนี้เหมาะกว่า:

255-240  IN  NS      ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240

ตอนนี้ขอข้อมูลได้ที่ 7.8.9.241 ของ 241.9.8.7.in-addr.harp บนเซิร์ฟเวอร์ DNS ของผู้ให้บริการจะถูกแปลงเป็น 241.255-240.9.8.7.in-addr.arpa และไปที่ไคลเอนต์ DNS

ฝั่งไคลเอ็นต์จะต้องจัดการกับคำขอดังกล่าว ดังนั้นเราจึงสร้างโซน 255-240.9.8.7.in-addr.arpa. โดยหลักการแล้ว เราสามารถวางรายการย้อนกลับสำหรับ ip ใดๆ ของซับเน็ต /24 ทั้งหมดได้ แต่พวกเขาจะถามเราเกี่ยวกับรายการที่ผู้ให้บริการส่งต่อมาหาเราเท่านั้น ดังนั้นเราจะไม่สามารถเล่นได้ =)
เพื่อแสดงให้เห็น ฉันจะยกตัวอย่างเนื้อหาของไฟล์โซนย้อนกลับจากฝั่งไคลเอ็นต์อีกครั้ง:

$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@                       1D IN SOA       ns1.client.domain. root.client.domain. (
                        2008152607      ; serial
                        3H              ; refresh
                        15M             ; retry
                        1W              ; expiry
                        1D )            ; minimum
@                       IN NS        ns1.client.domain.
@                       IN NS        ns2.client.domain.
241                     IN PTR          test.client.domain.
242                     IN PTR          test2.client.domain.
245                     IN PTR          test5.client.domain.

เป็นเพราะเราใช้ CNAME ในฝั่งของผู้ให้บริการ และเพื่อตอบสนองต่อคำขอข้อมูลตามที่อยู่ IP เราได้รับสองบันทึก ไม่ใช่หนึ่งรายการ

#>  host 7.8.9.245 
245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.
245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.

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

ที่มา: will.com

เพิ่มความคิดเห็น