BIND และ Active Directory® - เครือข่าย SME

ดัชนีทั่วไปของซีรี่ส์: Computer Networks for SMEs: Introduction

สวัสดีเพื่อน!. วัตถุประสงค์หลักของบทความนี้คือการแสดงให้เห็นว่าเราสามารถรวมบริการ DNS ตาม BIND9 ในเครือข่าย Microsoft ได้อย่างไรซึ่งพบได้บ่อยใน SMEs จำนวนมาก

มันเกิดขึ้นจากคำขออย่างเป็นทางการของเพื่อนที่อาศัยอยู่ใน La Tierra del Fuego -Fuegian- เชี่ยวชาญในMicrosoft® Networks - รวมใบรับรอง - เพื่อแนะนำคุณในส่วนนี้ของการย้ายเซิร์ฟเวอร์ของคุณไปยัง Linux ค่าใช้จ่ายของ สนับสนุน ช่างเทคนิคที่จ่ายเงินMicrosoft®อยู่แล้ว เหลือทน สำหรับ บริษัท ที่เขาทำงานอยู่และเขาเป็นผู้ถือหุ้นหลักของเขา

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

สำหรับผู้มาใหม่ในหัวข้อนี้และก่อนที่จะอ่านต่อเราขอแนะนำให้คุณอ่านและศึกษาบทความก่อนหน้าสามเรื่องเกี่ยวกับ SME Networks:

• DNS และ DHCP ใน openSUSE 13.2 "Harlequin"
• DNS และ DHCP บน CentOS 7
• DNS และ DHCP ใน Debian 8 "Jessie"

เหมือนกับการดูสามในสี่ส่วนของ«ยมโลก»เผยแพร่จนถึงวันนี้และนี่คือครั้งที่สี่

พารามิเตอร์ทั่วไป

หลังจากการแลกเปลี่ยนหลายครั้งผ่าน อีเมลในที่สุดฉันก็ชัดเจนเกี่ยวกับพารามิเตอร์หลักของเครือข่ายปัจจุบันของคุณซึ่ง ได้แก่ :

ชื่อโดเมน mordor.fan LAN Network 10.10.10.0/24 ==================================== ========================================= วัตถุประสงค์ที่อยู่ IP ของเซิร์ฟเวอร์ (เซิร์ฟเวอร์ที่ใช้ระบบปฏิบัติการ Windows ) ================================================ ============================== sauron.mordor.fan. 10.10.10.3 Active Directory® 2008 SR2 mamba.mordor.fan 10.10.10.4 เซิร์ฟเวอร์ไฟล์ Windows darklord.mordor.fan 10.10.10.6 พร็อกซีเกตเวย์และไฟร์วอลล์บน Kerios troll.mordor.fan 10.10.10.7 บล็อกอิง ... จำ shadowftp.mordor.fan ไม่ได้ 10.10.10.8 เซิร์ฟเวอร์ FTP blackelf.mordor.fan 10.10.10.9 บริการอีเมลฉบับเต็ม blackspider.mordor.fan 10.10.10.10 บริการ WWW palantir.mordor.fan 10.10.10.11 แชทบน Openfire สำหรับ Windows

ฉันขออนุญาต Fuegian เพื่อตั้งนามแฝงให้มากที่สุดเท่าที่จำเป็นเพื่อเคลียร์ใจของฉันและให้ฉันอนุญาตจากเขา:

CNAME จริง ============================== sauron ad-dc mamba fileserver darklord proxyweb troll blog shadowftp ftpserver blackelf mail blackspider www palantir openfire

ฉันประกาศระเบียน DNS ที่สำคัญทั้งหมดในการติดตั้ง Active Directory Windows 2008 ที่ฉันถูกบังคับให้ติดตั้งเพื่อแนะนำฉันในการสร้างโพสต์นี้

เกี่ยวกับระเบียน SRV ของ DNS ของ Active Directory

รีจิสเตอร์ เอส.อาร์.วี o Service Locators - ใช้กันอย่างแพร่หลายใน Microsoft Active Directory - ถูกกำหนดไว้ใน ขอความคิดเห็น RFC 2782. อนุญาตให้ระบุตำแหน่งของบริการตามโปรโตคอล TCP / IP ผ่านแบบสอบถาม DNS ตัวอย่างเช่นลูกค้าในเครือข่าย Microsoft สามารถค้นหาตำแหน่งของ Domain Controllers - ตัวควบคุมโดเมน ที่ให้บริการ LDAP ผ่านโปรโตคอล TCP บนพอร์ต 389 ผ่านแบบสอบถาม DNS เดียว

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

ใน ขอความคิดเห็น RFC 1700 การกำหนดชื่อสัญลักษณ์สากลสำหรับบริการที่รู้จักกันดี - บริการที่เป็นที่รู้จักและชื่อเช่น«_เทลเน็ต""_smtp»สำหรับบริการ Telnet y SMTP. หากไม่ได้กำหนดชื่อสัญลักษณ์สำหรับ Well Known Service ชื่อท้องถิ่นหรือชื่ออื่นสามารถใช้ได้ตามความต้องการของผู้ใช้

วัตถุประสงค์ของแต่ละฟิลด์«พิเศษ»ที่ใช้ในการประกาศ SRV Resource Record มีดังต่อไปนี้:

• โดเมน: "Pdc._msdcs.mordor.fan.«. ชื่อ DNS ของบริการที่บันทึก SRV อ้างถึง ชื่อ DNS ในตัวอย่างหมายถึง -more หรือ less- ตัวควบคุมโดเมนหลัก ของพื้นที่ _msdcs.mordor.fan.
• Service: "_Ldap". ชื่อสัญลักษณ์ของบริการที่กำหนดไว้ตาม ขอความคิดเห็น RFC 1700.
• โปรโตคอล: "_Tcp". ระบุประเภทของโปรโตคอลการขนส่ง โดยทั่วไปสามารถใช้ค่า _tcp o _udpแม้ว่า - และในความเป็นจริงแล้ว - โปรโตคอลการขนส่งประเภทใดก็ตามที่ระบุไว้ใน ขอความคิดเห็น RFC 1700. ตัวอย่างเช่นสำหรับบริการ พูดคุย ตามโปรโตคอล XMPPฟิลด์นี้จะมีค่าเป็น _xmpp.
• ลำดับความสำคัญ"0«. ประกาศลำดับความสำคัญหรือค่ากำหนดสำหรับไฟล์ โฮสต์ที่เสนอบริการนี้ ที่เราจะได้เห็นในภายหลัง แบบสอบถาม DNS ของไคลเอ็นต์เกี่ยวกับบริการที่กำหนดโดยระเบียน SRV นี้เมื่อได้รับการตอบสนองที่เหมาะสมจะพยายามติดต่อโฮสต์แรกที่มีอยู่โดยมีหมายเลขต่ำสุดที่ระบุไว้ในฟิลด์ ลำดับความสำคัญ. ช่วงของค่าที่ฟิลด์นี้สามารถรับได้คือ 0 65535.
• น้ำหนัก"100«. สามารถใช้ร่วมกับ ลำดับความสำคัญ เพื่อจัดเตรียมกลไกการทำโหลดบาลานซ์เมื่อมีเซิร์ฟเวอร์หลายเครื่องที่ให้บริการเดียวกัน ควรมีระเบียน SRV ที่คล้ายกันสำหรับแต่ละเซิร์ฟเวอร์ในไฟล์ Zone โดยมีการประกาศชื่อในฟิลด์ โฮสต์ที่เสนอบริการนี้. ก่อนเซิร์ฟเวอร์ที่มีค่าเท่ากันในฟิลด์ ลำดับความสำคัญค่าฟิลด์ น้ำหนัก สามารถใช้เป็นระดับการกำหนดลักษณะเพิ่มเติมเพื่อขอรับการเลือกเซิร์ฟเวอร์ที่แน่นอนสำหรับการทำโหลดบาลานซ์ ช่วงของค่าที่ฟิลด์นี้สามารถรับได้คือ 0 65535. ถ้าไม่จำเป็นต้องมีการทำโหลดบาลานซ์เช่นในกรณีของเซิร์ฟเวอร์เดียวขอแนะนำให้กำหนดค่า 0 เพื่อทำให้บันทึก SRV อ่านง่ายขึ้น
• หมายเลขพอร์ต - พอร์ต"389«. หมายเลขพอร์ตเข้า โฮสต์ที่เสนอบริการนี้ ที่ให้บริการที่ระบุไว้ในฟิลด์ Service. หมายเลขพอร์ตที่แนะนำสำหรับ Well-Known Service แต่ละประเภทจะระบุไว้ใน ขอความคิดเห็น RFC 1700แม้ว่าจะสามารถใช้ค่าระหว่าง 0 และ 65535.
• โฮสต์ที่เสนอบริการนี้ - เป้าหมาย"sauron.mordor.fan.«. ระบุไฟล์ เอฟคิวดีเอ็น ที่ระบุไฟล์ เจ้าภาพ ที่ให้บริการที่ระบุโดยบันทึก SRV ประเภทบันทึก«A»ในโดเมนเนมสเปซสำหรับแต่ละโดเมน เอฟคิวดีเอ็น จากเซิร์ฟเวอร์หรือ เจ้าภาพ ที่ให้บริการ ง่ายกว่าบันทึกประเภท A ในโซนทางตรง
  • หมายเหตุ:
    ในการระบุอย่างเป็นทางการว่าไม่มีบริการที่ระบุโดยเรกคอร์ด SRV บนโฮสต์นี้รายการเดียว (.) จุด.

เราเพียงต้องการย้ำว่าการทำงานที่ถูกต้องของเครือข่ายหรือ Active Directory®นั้นขึ้นอยู่กับการทำงานที่ถูกต้องของบริการชื่อโดเมน.

ระเบียน DNS ของ Active Directory

ในการสร้างโซนของเซิร์ฟเวอร์ DNS ใหม่โดยใช้ BIND เราต้องได้รับระเบียน DNS ทั้งหมดจาก Active Directory® เพื่อให้ชีวิตง่ายขึ้นเราไปที่ทีม sauron.mordor.fan -Active Directory® 2008 SR2- และใน DNS Administration Console เราเปิดใช้งาน Zone Transfer -direct และ inverse- สำหรับโซนหลักที่ประกาศในบริการประเภทนี้ซึ่ง ได้แก่ :

• _msdcs.mordor.fan
• มอร์ดอร์.แฟน
• 10.10.10.in-addr.harp

เมื่อดำเนินการขั้นตอนก่อนหน้านี้แล้วและโดยเฉพาะอย่างยิ่งจากคอมพิวเตอร์ Linux ที่มีที่อยู่ IP อยู่ในช่วงของซับเน็ตที่ใช้โดยเครือข่าย Windows เราจะดำเนินการ:

buzz @ sysadmin: ~ $ dig @ 10.10.10.3 _msdcs.mordor.fan axfr> อุณหภูมิ /rrs._msdcs.mordor.fan
buzz @ sysadmin: ~ $ dig @ 10.10.10.3 mordor.fan axfr> temp / rrs.mordor.fan
buzz @ sysadmin: ~ $ dig @ 10.10.10.3 10.10.10.in-addr.arpa axfr> temp / rrs.10.10.10.in-addr.arpa

• จำได้จากบทความก่อนหน้านี้ว่าที่อยู่ IP ของเครื่อง ผู้ดูแลระบบdesdelinux.พัดลม ES ฮิต หรือ 192.168.10.1.

ในสามคำสั่งก่อนหน้านี้เราสามารถกำจัดตัวเลือกได้ @10.10.10.3 -ถามเซิร์ฟเวอร์ DNS ด้วยที่อยู่นั้น- ถ้าเราประกาศในไฟล์ / etc / resolv.conf ไปยังเซิร์ฟเวอร์ IP sauron.mordor.fan:

buzz@sysadmin:~$ cat /etc/resolv.conf # สร้างโดยการค้นหา NetworkManager desdelinuxเนมเซิร์ฟเวอร์ .fan 192.168.10.5 เนมเซิร์ฟเวอร์ 10.10.10.3

หลังจากแก้ไขด้วยความระมัดระวังเป็นอย่างยิ่งเนื่องจากสอดคล้องกับไฟล์โซนใด ๆ ใน BIND เราจะได้รับข้อมูลต่อไปนี้:

บันทึก RR จากโซนเดิม _msdcs.mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs._msdcs.mordor.fan 
; เกี่ยวข้องกับ SOA และ NS _msdcs.mordor.fan 3600 ใน SOA sauron.mordor.fan hostmaster.mordor.fan. 12 900 600 86400 _msdcs.mordor.fan 3600 ใน NS sauron.mordor.fan ; ; แคตตาล็อกทั่วโลก gc._msdcs.mordor.fan 3600 ในก 600; ; นามแฝง - ในฐานข้อมูล LDAP ที่ปรับเปลี่ยนและเป็นส่วนตัวของ Active Directory- ของ SAURON 10.10.10.3-03296249a82-1aa-a49f4-0f28900d5b._msdcs.mordor.fan 256 ใน CNAME sauron.mordor.fan ; ; LDAP ที่ปรับเปลี่ยนและเป็นส่วนตัวของ Active Directory _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan 600 IN SRV 600 sauron.mordor.fan _ldap._tcp.dc._msdcs.mordor.fan 0 IN SRV 100 sauron.mordor.fan _ldap._tcp.389d600d-0fdb-100cf-a389-d18c3360b8d40.domains._msdcs.mordor.fan 678 IN SRV 7 sauron.mordor.fan _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan 420 IN SRV 6 775 sauron.mordor.fan _ldap._tcp.gc._msdcs.mordor.fan 600 IN SRV 0 100 sauron.mordor.fan _ldap._tcp.pdc._msdcs.mordor.fan 389 IN SRV 600 sauron.mordor.fan ; ; KERBEROS แก้ไขและเป็นส่วนตัวจาก Active Directory _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan 0 IN SRV 100 3268 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan 600 IN SRV 0 100 sauron.mordor.fan.

RRs บันทึกจากโซนเดิม mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs.mordor.fan 
; เกี่ยวข้องกับ SOA, NS, MX และระเบียน A ที่แมป; ชื่อโดเมนกับ IP ของ SAURON; สิ่งต่างๆจาก Active Directory mordor.fan 3600 ใน SOA sauron.mordor.fan hostmaster.mordor.fan. 48 900 600 mordor.fan. 86400 IN A 3600 mordor.fan. 600 ใน NS sauron.mordor.fan mordor.fan. 10.10.10.3 ใน MX 3600 blackelf.mordor.fan _msdcs.mordor.fan 3600 ใน NS sauron.mordor.fan ; ; ที่สำคัญบันทึก DomainDnsZones.mordor.fan 10 IN A 3600 ForestDnsZones.mordor.fan 600 ในก 10.10.10.3; ; แคตตาล็อกทั่วโลก _gc._tcp.mordor.fan 600 IN SRV 10.10.10.3 600 sauron.mordor.fan _gc._tcp.Default-First-Site-Name._sites.mordor.fan 0 IN SRV 100 3268 sauron.mordor.fan ; ; LDAP ที่ปรับเปลี่ยนและเป็นส่วนตัวของ Active Directory _ldap._tcp.mordor.fan 600 IN SRV 0 sauron.mordor.fan _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan 100 IN SRV 3268 sauron.mordor.fan _ldap._tcp.DomainDnsZones.mordor.fan 600 IN SRV 0 sauron.mordor.fan _ldap._tcp.Default-First-Site-Name._sites.mordor.fan 100 IN SRV 389 sauron.mordor.fan _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan 600 IN SRV 0 sauron.mordor.fan _ldap._tcp.ForestDnsZones.mordor.fan 100 IN SRV 389 sauron.mordor.fan ; ; KERBEROS ที่ปรับเปลี่ยนและเป็นส่วนตัวจาก Active Directory _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan 600 IN SRV 0 100 389 sauron.mordor.fan. _kerberos._tcp.mordor.fan 600 IN SRV 0 100 389 sauron.mordor.fan. _kpasswd._tcp.mordor.fan 600 IN SRV 0 sauron.mordor.fan _kerberos._udp.mordor.fan 100 IN SRV 389 600 0 sauron.mordor.fan. _kpasswd._udp.mordor.fan 100 IN SRV 389 sauron.mordor.fan ; ; บันทึกที่มี IP คงที่ -> เซิร์ฟเวอร์ Blackelf.mordor.fan 600 ใน 0 blackspider.mordor.fan 100 ใน 88 darklord.mordor.fan 600 ใน 0 mamba.mordor.fan 100 ใน 88 palantir.mordor.fan 600 ใน 0 sauron.mordor.fan 100 ใน 464 shadowftp.mordor.fan 600 ใน 0 troll.mordor.fan 100 ใน 88; ; CNAME บันทึก ad-dc.mordor.fan 600 ใน CNAME sauron.mordor.fan blog.mordor.fan. 0 ใน CNAME troll.mordor.fan fileserver.mordor.fan 100 ใน CNAME mamba.mordor.fan ftpserver.mordor.fan. 464 ใน CNAME shadowftp.mordor.fan mail.mordor.fan. 3600 ใน CNAME balckelf.mordor.fan openfire.mordor.fan. 10.10.10.9 ใน CNAME palantir.mordor.fan proxy.mordor.fan 3600 ใน CNAME darklord.mordor.fan www.mordor.fan. 10.10.10.10 ใน CNAME blackspider.mordor.fan

บันทึก RR จากโซนเดิม 10.10.10.in-addr.arpa

buzz @ sysadmin: ~ $ cat temp / rrs.10.10.10.in-addr.arpa 
; เกี่ยวข้องกับ SOA และ NS 10.10.10.in-addr.arpa 3600 ใน SOA sauron.mordor.fan hostmaster.mordor.fan. 21 900 600 86400.in-addr.arpa 3600 ใน NS sauron.mordor.fan ; ; PTR บันทึก 10.10.10.in-addr.arpa 3600 ใน PTR blackspider.mordor.fan 10.10.10.10.in-addr.arpa 3600 ใน PTR palantir.mordor.fan 11.10.10.10.in-addr.arpa 3600 ใน PTR sauron.mordor.fan 3.10.10.10.in-addr.arpa 3600 ใน PTR mamba.mordor.fan 4.10.10.10.in-addr.arpa 3600 ใน PTR dnslinux.mordor.fan 5.10.10.10.in-addr.arpa 3600 ใน PTR darklord.mordor.fan 6.10.10.10.in-addr.arpa 3600 ใน PTR troll.mordor.fan 7.10.10.10.in-addr.arpa 3600 ใน PTR shadowftp.mordor.fan 8.10.10.10.in-addr.arpa 3600 ใน PTR blackelf.mordor.fan

เมื่อถึงจุดนี้เราสามารถคิดได้ว่าเรามีข้อมูลที่จำเป็นในการผจญภัยต่อไปไม่ใช่โดยไม่สังเกตก่อน TTL และข้อมูลอื่น ๆ ที่กระชับเอาท์พุทและการสังเกตโดยตรงของ DNS ของ Active Directory® 2008 SR2 64 บิตจากMicrosft®ให้เรา

รูปภาพของ DNS Manager ใน SAURON

ทีมงาน Dnslinux.mordor.fan.

หากเราตรวจสอบอย่างใกล้ชิดกับที่อยู่ IP 10.10.10.5 ไม่มีการกำหนดชื่อให้อย่างแม่นยำเพื่อที่จะถูกครอบครองโดยชื่อของ DNS ใหม่ dnslinux.mordor.fan. ในการติดตั้งคู่ DNS และ DHCP เราสามารถรับคำแนะนำจากบทความ DNS และ DHCP ใน Debian 8 "Jessie" y DNS และ DHCP บน CentOS 7.

ระบบปฏิบัติการพื้นฐาน

มีมี่ Fuegianนอกเหนือจากการเป็นผู้เชี่ยวชาญที่แท้จริงในMicrosoft® Windows แล้วเขายังมีใบรับรองสองสามฉบับที่ออกโดย บริษัท นั้น - เขาได้อ่านและนำไปปฏิบัติบางบทความบนเดสก์ท็อปที่เผยแพร่ใน DesdeLinux. และเขาบอกฉันว่าเขาต้องการโซลูชันที่ใช้ Debian อย่างชัดเจน 😉

เพื่อให้คุณพอใจเราจะเริ่มต้นด้วยการติดตั้งเซิร์ฟเวอร์ที่ใหม่และสะอาดตาม Debian 8 "เจสซี". อย่างไรก็ตามสิ่งที่เราจะเขียนต่อไปนั้นใช้ได้สำหรับการแจกแจง CentOS และ openSUSE ซึ่งมีบทความที่เรากล่าวถึงก่อนหน้านี้ BIND และ DHCP เหมือนกันในทุก distro ผู้ดูแลบรรจุภัณฑ์จะมีการเปลี่ยนแปลงเล็กน้อยในการแจกจ่ายแต่ละครั้ง

เราจะทำการติดตั้งตามที่ระบุไว้ใน DNS และ DHCP ใน Debian 8 "Jessie", ดูแลการใช้งาน IP 10.10.10.5 และเครือข่าย 10.10.10.0/24ก่อนกำหนดค่า BIND

เรากำหนดค่า BIND ในสไตล์ Debian

/etc/bind/named.conf

ไฟล์ /etc/bind/named.conf เราปล่อยไว้ตามที่ติดตั้ง

/etc/bind/named.conf.options

ไฟล์ /etc/bind/named.conf.options ควรมีเนื้อหาต่อไปนี้:

รูท @ dnslinux: ~ # cp /etc/bind/named.conf.options /etc/bind/named.conf.options.original

root @ dnslinux: ~ # นาโน /etc/bind/named.conf.options
ตัวเลือก {ไดเรกทอรี "/ var / cache / bind"; // หากมีไฟร์วอลล์ระหว่างคุณและเนมเซิร์ฟเวอร์ที่คุณต้องการ // คุยด้วยคุณอาจต้องแก้ไขไฟร์วอลล์เพื่อให้พอร์ต // หลายพอร์ตสามารถพูดคุยได้ โปรดดู http://www.kb.cert.org/vuls/id/800113 // หาก ISP ของคุณให้ที่อยู่ IP อย่างน้อยหนึ่งรายการสำหรับเซิร์ฟเวอร์ชื่อ // ที่เสถียรคุณอาจต้องการใช้เป็นผู้ส่งต่อ // ยกเลิกการใส่เครื่องหมายในบล็อกต่อไปนี้และใส่ที่อยู่แทนที่ // ตัวยึดตำแหน่งของ all-0 // ตัวส่งต่อ {// 0.0.0.0; //}; // ============================================== ===================== $ // หาก BIND บันทึกข้อความแสดงข้อผิดพลาดเกี่ยวกับคีย์หลักที่หมดอายุแล้ว // คุณจะต้องอัปเดตคีย์ของคุณ ดู https://www.isc.org/bind-keys // ================================= =================================== $

    // เราไม่ต้องการ DNSSEC
        dnssec- เปิดใช้งานไม่;
        //dnssec-validation auto;

        auth-nxdomain no; # เป็นไปตาม RFC1035

 // เราไม่จำเป็นต้องฟังที่อยู่ IPv6
        // ฟัง-on-v6 {ใด ๆ ; };
    ฟังบน v6 {ไม่มี; };

 // สำหรับการตรวจสอบจาก localhost และ sysadmin
    // ผ่าน // ขุด mordor.fan axfr // ขุด 10.10.10.in-addr.arpa axfr // ขุด _msdcs.mordor.fan axfr // เราไม่มี Slave DNS ... จนถึงตอนนี้
 อนุญาตให้โอน {localhost; 10.10.10.1; };
};

// การเชื่อมโยงการบันทึก
การบันทึก {

        แบบสอบถามช่อง {
        ไฟล์ "/var/log/named/queries.log" เวอร์ชัน 3 ขนาด 1m;
        ข้อมูลความรุนแรง
        เวลาพิมพ์ใช่;
        พิมพ์ - ความรุนแรงใช่;
        ประเภทการพิมพ์ใช่;
        };

        ข้อผิดพลาดการสืบค้นช่อง {
        ไฟล์ "/var/log/named/query-error.log" เวอร์ชัน 3 ขนาด 1m;
        ข้อมูลความรุนแรง
        เวลาพิมพ์ใช่;
        พิมพ์ - ความรุนแรงใช่;
        ประเภทการพิมพ์ใช่;
        };

                                
การค้นหาหมวดหมู่ {
         แบบสอบถาม;
         };

หมวดหมู่ข้อผิดพลาดในการค้นหา {
         แบบสอบถามข้อผิดพลาด;
         };

};

• เราแนะนำการจับบันทึก BIND เป็นไฟล์ NEW ปรากฏในชุดบทความในหัวข้อนี้ เราสร้างลโฟลเดอร์และไฟล์ที่จำเป็นสำหรับ เข้าสู่ระบบ ของ BIND:

รูท @ dnslinux: ~ # mkdir / var / log / named
root @ dnslinux: ~ # touch /var/log/named/queries.log
root @ dnslinux: ~ # touch /var/log/named/query-error.log
รูท @ dnslinux: ~ # chown -R bind: bind / var / log / named

เราตรวจสอบไวยากรณ์ของไฟล์ที่กำหนดค่าไว้

root @ dnslinux: ~ # named-checkconf 
รูท @ dnslinux: ~ #

/etc/bind/named.conf.local

เราสร้างไฟล์ /etc/bind/zones.rfcFreeBSD ที่มีเนื้อหาเดียวกันกับที่ระบุไว้ใน DNS และ DHCP ใน Debian 8 "Jessie".

รูท @ dnslinux: ~ # nano /etc/bind/zones.rfcFreeBSD

ไฟล์ /etc/bind/named.conf.local ควรมีเนื้อหาต่อไปนี้:

// // ทำการกำหนดค่าภายในเครื่องที่นี่ // // ลองเพิ่มโซน 1918 ที่นี่หากไม่ได้ใช้ใน // องค์กรของคุณ
รวม "/etc/bind/zones.rfc1918"; รวม "/etc/bind/zones.rfcFreeBSD";

โซน "mordor.fan" {พิมพ์ master; ไฟล์ "/var/lib/bind/db.mordor.fan"; }; โซน "10.10.10.in-addr.arpa" {พิมพ์ master; ไฟล์ "/var/lib/bind/db.10.10.10.in-addr.arpa"; };

โซน "_msdcs.mordor.fan" {พิมพ์ master;
 ไม่สนใจชื่อเช็ค ไฟล์ "/etc/bind/db._msdcs.mordor.fan"; }; root @ dnslinux: ~ # named-checkconf
รูท @ dnslinux: ~ #

ไฟล์โซน mordor.fan

root @ dnslinux: ~ # นาโน /var/lib/bind/db.mordor.fan
$ TTL 3H @ ใน SOA dnslinux.mordor.fan root.dnslinux.mordor.fan (1; อนุกรม 1D รีเฟรช 1H; ลองอีกครั้ง 1W หมดอายุ 3H); ขั้นต่ำหรือ; เวลาแคชเชิงลบในการใช้งาน
; ระมัดระวังเป็นอย่างยิ่งกับบันทึกต่อไปนี้
@ ใน NS dnslinux.mordor.fan.
@ ใน 10.10.10.5
@ ใน MX 10 blackelf.mordor.fan. @ IN TXT "Wellcome to The Dark Lan of Mordor";
_msdcs.mordor.fan ใน NS dnslinux.mordor.fan
;
dnslinux.mordor.fan. ใน 10.10.10.5
; จบอย่างระมัดระวังด้วยการบันทึกต่อไปนี้
DomainDnsZones.mordor.fan ใน 10.10.10.3 ForestDnsZones.mordor.fan ในก 10.10.10.3; ; แคตตาล็อกทั่วโลก _gc._tcp.mordor.fan 600 IN SRV 0 0 3268 sauron.mordor.fan _gc._tcp.Default-First-Site-Name._sites.mordor.fan 600 IN SRV 0 0 3268 sauron.mordor.fan ; ; LDAP ที่ปรับเปลี่ยนและเป็นส่วนตัวของ Active Directory _ldap._tcp.mordor.fan 600 IN SRV 0 0 sauron.mordor.fan _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan 389 IN SRV 600 0 sauron.mordor.fan _ldap._tcp.DomainDnsZones.mordor.fan 0 IN SRV 389 600 sauron.mordor.fan _ldap._tcp.Default-First-Site-Name._sites.mordor.fan 0 IN SRV 0 389 sauron.mordor.fan _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan 600 IN SRV 0 0 sauron.mordor.fan _ldap._tcp.ForestDnsZones.mordor.fan 389 IN SRV 600 0 sauron.mordor.fan ; ; KERBEROS ที่ปรับเปลี่ยนและเป็นส่วนตัวจาก Active Directory _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan 0 IN SRV 389 600 0 sauron.mordor.fan _kerberos._tcp.mordor.fan 0 IN SRV 389 600 0 sauron.mordor.fan _kpasswd._tcp.mordor.fan 0 IN SRV 88 600 sauron.mordor.fan _kerberos._udp.mordor.fan 0 IN SRV 0 88 600 sauron.mordor.fan _kpasswd._udp.mordor.fan 0 IN SRV 0 464 sauron.mordor.fan ; ; บันทึกที่มี IP คงที่ -> เซิร์ฟเวอร์ Blackelf.mordor.fan ใน 600 blackspider.mordor.fan ใน 0 darklord.mordor.fan ใน 0 mamba.mordor.fan ใน 88 palantir.mordor.fan ใน 600
sauron.mordor.fan. ใน 10.10.10.3
shadowftp.mordor.fan. ใน 10.10.10.8 troll.mordor.fan ในก 10.10.10.7; ; CNAME บันทึก ad-dc.mordor.fan ใน CNAME sauron.mordor.fan blog.mordor.fan. ใน CNAME troll.mordor.fan fileserver.mordor.fan ใน CNAME mamba.mordor.fan ftpserver.mordor.fan. ใน CNAME shadowftp.mordor.fan mail.mordor.fan. ใน CNAME balckelf.mordor.fan openfire.mordor.fan. ใน CNAME palantir.mordor.fan proxy.mordor.fan ใน CNAME darklord.mordor.fan www.mordor.fan. ใน CNAME blackspider.mordor.fan

ราก @ dnslinux: ~ # named-checkzone mordor.fan /var/lib/bind/db.mordor.fan 
โซน mordor.fan/IN: โหลด serial 1 OK

เวลา ทีทีแอล 600 ของการลงทะเบียน SRV ทั้งหมดเราจะเก็บไว้ในกรณีที่เราติดตั้ง Slave BIND ในครั้งต่อ ๆ ไป ระเบียนเหล่านี้แสดงถึงบริการ Active Directory®ซึ่งส่วนใหญ่อ่านข้อมูลจากฐานข้อมูล LDAP ของคุณ เนื่องจากฐานข้อมูลนั้นมีการเปลี่ยนแปลงบ่อยครั้งเวลาในการซิงค์จึงต้องสั้นในแผน Master - Slave DNS ตามปรัชญาของ Microsoft ที่สังเกตได้จาก Active Directory 2000 ถึง 2008 ค่า 600 จะยังคงอยู่สำหรับเร็กคอร์ด SRV ประเภทนี้

ลอส TTL ของเซิร์ฟเวอร์ที่มี IP คงที่ซึ่งอยู่ภายใต้เวลาที่ประกาศไว้ใน SOA ที่ 3 ชั่วโมง

ไฟล์โซน 10.10.10.in-addr.arpa

root @ dnslinux: ~ # นาโน /var/lib/bind/db.10.10.10.in-addr.arpa
$ TTL 3H @ ใน SOA dnslinux.mordor.fan root.dnslinux.mordor.fan (1; อนุกรม 1D รีเฟรช 1H; ลองอีกครั้ง 1W หมดอายุ 3H); ขั้นต่ำหรือ; เวลาแคชเชิงลบในการใช้งาน @ IN NS dnslinux.mordor.fan. ; 10 ใน PTR blackspider.mordor.fan 11 ใน PTR palantir.mordor.fan 3 ใน PTR sauron.mordor.fan 4 ใน PTR mamba.mordor.fan 5 ใน PTR dnslinux.mordor.fan 6 ใน PTR darklord.mordor.fan 7 ใน PTR troll.mordor.fan 8 ใน PTR shadowftp.mordor.fan 9 ใน PTR blackelf.mordor.fan

รูท @ dnslinux: ~ # named-checkzone 10.10.10.in-addr.arpa /var/lib/bind/db.10.10.10.in-addr.arpa 
โซน 10.10.10.in-addr.arpa/IN: โหลด serial 1 OK

ไฟล์โซน _msdcs.mordor.fan

ลองพิจารณาสิ่งที่แนะนำในไฟล์ /usr/share/doc/bind9/README.Debian.gz เกี่ยวกับตำแหน่งของไฟล์ของ Master Zones ที่ไม่อยู่ภายใต้การอัปเดตแบบไดนามิกโดย DHCP

รูท @ dnslinux: ~ # nano /etc/bind/db._msdcs.mordor.fan
$ TTL 3H @ ใน SOA dnslinux.mordor.fan root.dnslinux.mordor.fan (1; อนุกรม 1D รีเฟรช 1H; ลองอีกครั้ง 1W หมดอายุ 3H); ขั้นต่ำหรือ; เวลาแคชเชิงลบในการใช้งาน @ IN NS dnslinux.mordor.fan. ; ; ; แคตตาล็อกทั่วโลก gc._msdcs.mordor.fan 600 ในก 10.10.10.3; ; นามแฝง - ในฐานข้อมูล LDAP ที่ปรับเปลี่ยนและเป็นส่วนตัวของ Active Directory- ของ SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan 600 ใน CNAME sauron.mordor.fan ; ; LDAP ที่ปรับเปลี่ยนและเป็นส่วนตัวของ Active Directory _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan 600 IN SRV 0 sauron.mordor.fan _ldap._tcp.dc._msdcs.mordor.fan 100 IN SRV 389 sauron.mordor.fan _ldap._tcp.600d0d-100fdb-389cf-a18-d3360c8b40d678.domains._msdcs.mordor.fan 7 IN SRV 420 sauron.mordor.fan _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan 6 IN SRV 775 600 sauron.mordor.fan _ldap._tcp.gc._msdcs.mordor.fan 0 IN SRV 100 389 sauron.mordor.fan _ldap._tcp.pdc._msdcs.mordor.fan 600 IN SRV 0 sauron.mordor.fan ; ; KERBEROS ที่ปรับเปลี่ยนและเป็นส่วนตัวของ Active Directory _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan 100 IN SRV 3268 600 0 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan 100 IN SRV 3268 600 0 sauron.mordor.fan.

เราตรวจสอบไวยากรณ์และเราสามารถเพิกเฉยต่อข้อผิดพลาดที่ส่งกลับเนื่องจากในการกำหนดค่าโซนนี้ในไฟล์ /etc/bind/named.conf.local เรารวมคำสั่ง ไม่สนใจชื่อเช็ค. โซนจะถูกโหลดอย่างถูกต้องโดย BIND

root @ dnslinux: ~ # named-checkzone _msdcs.mordor.fan /etc/bind/db._msdcs.mordor.fan 
/etc/bind/db._msdcs.mordor.fan:14: gc._msdcs.mordor.fan: ชื่อเจ้าของที่ไม่ดี (เช็คชื่อ) โซน _msdcs.mordor.fan/IN: โหลดซีเรียล 1 ตกลง

root @ dnslinux: ~ # systemctl รีสตาร์ท bind9.service 
root @ dnslinux: ~ # systemctl สถานะ bind9.service 
● bind9.service - BIND Domain Name Server Loaded: loaded (/lib/systemd/system/bind9.service; enable) Drop-In: /run/systemd/generator/bind9.service.d └─50-insserv.conf- $ named.conf ใช้งานอยู่: ใช้งานอยู่ (วิ่ง) ตั้งแต่อา. 2017-02-12 08:48:38 EST; 2 วินาทีที่แล้ว Docs: man: named (8) Process: 859 ExecStop = / usr / sbin / rndc stop (code = exited, status = 0 / SUCCESS) Main PID: 864 (named) CGroup: /system.slice/bind9.service └─864 / usr / sbin / named -f -u bind 12 ก.พ. 08:48:38 dnslinux ชื่อ [864]: zone 3.efip6.arpa/IN: loaded serial 1 ก.พ. 12 08:48:38 dnslinux ชื่อ [864 ]: zone befip6.arpa/IN: loaded serial 1 ก.พ. 12 08:48:38 dnslinux ชื่อ [864]: zone 0.efip6.arpa/IN: loaded serial 1 ก.พ. 12 08:48:38 dnslinux ชื่อ [864]: zone 7.efip6.arpa/IN: loaded serial 1 ก.พ. 12 08:48:38 dnslinux ชื่อ [864]: zone mordor.fan/IN: loaded serial 1 ก.พ. 12 08:48:38 dnslinux ชื่อ [864]: ตัวอย่างโซน .org / IN: loaded serial 1 ก.พ. 12 08:48:38 dnslinux ชื่อ [864]: zone _msdcs.mordor.fan/IN: loaded serial 1 ก.พ. 12 08:48:38 dnslinux ชื่อ [864]: zone invalid / IN : โหลด serial 1 ก.พ. 12 08:48:38 dnslinux ชื่อ [864]: โหลดทุกโซนแล้ว
12 ก.พ. 08:48:38 dnslinux ชื่อ [864]: วิ่ง

เราปรึกษา BIND

antes หลังจากติดตั้ง DHCP เราจะต้องดำเนินการตรวจสอบหลายชุดซึ่งรวมถึงการเข้าร่วมไคลเอนต์ Windows 7 กับโดเมน มอร์ดอร์.แฟน แสดงโดย Active Directory ที่ติดตั้งบนคอมพิวเตอร์ sauron.mordor.fan.

สิ่งแรกที่ต้องทำคือหยุดบริการ DNS บนคอมพิวเตอร์ sauron.mordor.fanและประกาศในอินเทอร์เฟซเครือข่ายของคุณว่านับจากนี้เซิร์ฟเวอร์ DNS ของคุณจะเป็นไฟล์ 10.10.10.5 dnslinux.mordor.fan.

ในคอนโซลของเซิร์ฟเวอร์เอง sauron.mordor.fan เราดำเนินการ:

Microsoft Windows [Thai Version 6.1.7600]
ลิขสิทธิ์ (c) 2009 Microsoft Corporation สงวนลิขสิทธิ์.

C: \ Users \ Administrator> nslookup
เซิร์ฟเวอร์เริ่มต้น: dnslinux.mordor.fan ที่อยู่: 10.10.10.5

> gc._msdcs
เซิร์ฟเวอร์: dnslinux.mordor.fan ที่อยู่: 10.10.10.5 ชื่อ: gc._msdcs.mordor.fan ที่อยู่: 10.10.10.3

> mordor.fan
เซิร์ฟเวอร์: dnslinux.mordor.fan ที่อยู่: 10.10.10.5 ชื่อ: mordor.fan ที่อยู่: 10.10.10.3

> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs
เซิร์ฟเวอร์: dnslinux.mordor.fan ที่อยู่: 10.10.10.5 ชื่อ: sauron.mordor.fan ที่อยู่: 10.10.10.3 นามแฝง: 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan

> กำหนดประเภท = SRV
> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
เซิร์ฟเวอร์: dnslinux.mordor.fan ที่อยู่: 10.10.10.5 _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan ตำแหน่ง SRV บริการน้ำแข็ง: ลำดับความสำคัญ = 0 น้ำหนัก = 100 พอร์ต = 88 svr hostname = sauron.mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan ที่อยู่อินเทอร์เน็ต sauron.mordor.fan = 10.10.10.3 ที่อยู่อินเทอร์เน็ต dnslinux.mordor.fan = 10.10.10.5
> _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs
เซิร์ฟเวอร์: dnslinux.mordor.fan ที่อยู่: 10.10.10.5 _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan ตำแหน่งบริการ SRV: ลำดับความสำคัญ = 0 weight = 100 port = 389 svr hostname = sauron .mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan ที่อยู่อินเทอร์เน็ต sauron.mordor.fan = 10.10.10.3 ที่อยู่อินเทอร์เน็ต dnslinux.mordor.fan = 10.10.10.5
> ออก

C: \ Users \ Administrator>

แบบสอบถาม DNS ที่สร้างจาก sauron.mordor.fan เป็นที่น่าพอใจ

ขั้นตอนต่อไปคือการสร้างเครื่องเสมือนอื่นที่ติดตั้ง Windows 7 เนื่องจากเรายังไม่ได้ติดตั้งบริการ DHCP เราจะให้คอมพิวเตอร์ที่มีชื่อ«win7»ที่อยู่ IP 10.10.10.251. นอกจากนี้เรายังประกาศว่าเซิร์ฟเวอร์ DNS ของคุณจะเป็นไฟล์ 10.10.10.5 dnslinux.mordor.fanและโดเมนการค้นหาจะเป็น มอร์ดอร์.แฟน. เราจะไม่ลงทะเบียนคอมพิวเตอร์เครื่องนั้นใน DNS เนื่องจากเราจะใช้เพื่อทดสอบบริการ DHCP ด้วยหลังจากที่เราติดตั้ง

ต่อไปเราจะเปิดคอนโซล CMD และในนั้นเราดำเนินการ:

Microsoft Windows [Thai Version 6.1.7601]
ลิขสิทธิ์ (c) 2009 Microsoft Corporation สงวนลิขสิทธิ์.

C: \ Users \ buzz> nslookup
เซิร์ฟเวอร์เริ่มต้น: dnslinux.mordor.fan ที่อยู่: 10.10.10.5

> mordor.fan
เซิร์ฟเวอร์: dnslinux.mordor.fan ที่อยู่: 10.10.10.5 ชื่อ: mordor.fan ที่อยู่: 10.10.10.3

> กำหนดประเภท = SRV
> _ldap._tcp.DomainDnsZones
เซิร์ฟเวอร์: dnslinux.mordor.fan ที่อยู่: 10.10.10.5 _ldap._tcp.DomainDnsZones.mordor.fan ตำแหน่งบริการ SRV: ลำดับความสำคัญ = 0 น้ำหนัก = 0 พอร์ต = 389 svr ชื่อโฮสต์ = sauron.mordor.fan mordor.fan nameserver = dnslinux.mordor ที่อยู่อินเทอร์เน็ต .fan sauron.mordor.fan = 10.10.10.3 dnslinux.mordor.fan ที่อยู่อินเทอร์เน็ต = 10.10.10.5
> _kpasswd._udp
เซิร์ฟเวอร์: dnslinux.mordor.fan ที่อยู่: 10.10.10.5 _kpasswd._udp.mordor.fan ตำแหน่งบริการ SRV: ลำดับความสำคัญ = 0 น้ำหนัก = 0 พอร์ต = 464 svr hostname = sauron.mordor.fan mordor.fan nameserver = dnslinux.mordor.fan ที่อยู่อินเทอร์เน็ต sauron.mordor.fan = 10.10.10.3 dnslinux.mordor.fan ที่อยู่อินเทอร์เน็ต = 10.10.10.5
> _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones
เซิร์ฟเวอร์: dnslinux.mordor.fan ที่อยู่: 10.10.10.5 _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan ตำแหน่ง SRV serv ice: Priority = 0 weight = 0 port = 389 svr hostname = sauron mordor.fan mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan ที่อยู่อินเทอร์เน็ต = 10.10.10.3 ที่อยู่อินเทอร์เน็ต dnslinux.mordor.fan = 10.10.10.5
> ทางออก

C: \ Users \ buzz>

แบบสอบถาม DNS ที่สร้างจากไคลเอนต์«win7»ยังเป็นที่น่าพอใจ

ใน Active Directory เราสร้างผู้ใช้«ซารูมาน«โดยมีจุดประสงค์เพื่อใช้เมื่อเข้าร่วมไคลเอนต์ win7 ไปยังโดเมน มอร์ดอร์.แฟน. โดยใช้วิธี«รหัสเครือข่าย«, การใช้ชื่อผู้ใช้ saruman@mordor.fan y ผู้ดูแลระบบ@mordor.fan. การเข้าร่วมประสบความสำเร็จและได้รับการพิสูจน์โดยภาพหน้าจอต่อไปนี้:

เกี่ยวกับ Dynamic Updates ในMicrosoft® DNS และ BIND

เนื่องจากเราหยุดให้บริการ DNS ใน Active Directory®ไคลเอ็นต์จึงไม่สามารถทำได้«win7»ลงทะเบียนชื่อและที่อยู่ IP ของคุณใน DNS นั้น น้อยกว่ามาก dnslinux.mordor.fan เนื่องจากเราไม่ได้แถลงใด ๆ อนุญาตให้อัปเดต สำหรับพื้นที่ใด ๆ ที่เกี่ยวข้อง

และนี่คือจุดเริ่มต้นของการต่อสู้ที่ดีกับเพื่อนของฉัน Fuegian. ในอีเมลฉบับแรกของฉันเกี่ยวกับประเด็นนี้ฉันแสดงความคิดเห็น:

• บทความของ Microsoft เกี่ยวกับการใช้ BIND และ Active Directory®แนะนำให้อัปเดต Direct Zone โดยเฉพาะ -Penetrada- โดยตรง โดยไคลเอนต์ Windows ที่เข้าร่วมกับโดเมน Active Directory อยู่แล้ว.
• นั่นคือเหตุผลที่โดยค่าเริ่มต้นในโซน DNS ของ Active Directory® Secure Dynamic Updates จึงได้รับอนุญาต โดยไคลเอนต์ Windows ได้เข้าร่วมกับโดเมน Active Directory แล้ว. หากพวกเขาไม่สามัคคีกันพวกเขาก็ละเว้นจากผลที่ตามมา
• DNS ของ Active Directory รองรับการอัปเดตแบบไดนามิก "Secure only" "Nonsecure and secure" หรือ "None" ซึ่งเหมือนกับการบอกว่า NO Updates หรือ None.
• ใช่จริงๆ Microsoft Philosophy ไม่เห็นด้วยว่าลูกค้าจะไม่อัปเดตข้อมูลของตนใน DNS ของตนโดยจะไม่ปล่อยให้ความเป็นไปได้ในการปิดใช้งานการอัปเดตแบบไดนามิกใน DNS ของตนเว้นเสียแต่ว่าตัวเลือกนั้นจะถูกทิ้งไว้เพื่อวัตถุประสงค์ที่ซ่อนอยู่มากขึ้น.
• Microsoft เสนอ "ความปลอดภัย" เพื่อแลกกับความมืด ในฐานะเพื่อนร่วมงานและเพื่อนที่สอบผ่านหลักสูตรMicrosft® Certificates บอกฉัน จริง. นอกจากนี้ El Fueguino ยืนยันกับฉัน
• ไคลเอนต์ที่ได้รับที่อยู่ IP ผ่าน DHCP ที่ติดตั้งบนเครื่องUNIX® / Linux จะไม่สามารถแก้ไขที่อยู่ IP ของชื่อของตนเองได้ จนกว่าคุณจะเข้าร่วมโดเมน Active Directoryตราบใดที่ใช้Microsoft®หรือ BIND เป็น DNS โดยไม่มีการอัปเดตแบบไดนามิกจาก DHCP
• ถ้าฉันติดตั้ง DHCP ใน Active Directory®เองฉันต้องประกาศว่าโซนได้รับการอัพเดตโดยMicrosoft® DHCP
• หากเราจะใช้ BIND เป็น DNS สำหรับเครือข่าย Windows มันเป็นตรรกะและแนะนำให้เราติดตั้ง BIND-DHCP duo โดยการอัปเดต BIND แบบไดนามิกในภายหลังและสรุปเรื่องได้
• ในโลกของเครือข่าย LAN บนUNIX® / Linux นับตั้งแต่มีการคิดค้นการอัปเดตแบบไดนามิกบน BIND จึงอนุญาตเฉพาะ Mr. DHCP เท่านั้น«เจาะ»ถึง Mrs. BIND กับการอัปเดตของเธอ กรุณาผ่อนคลายที่เป็นระเบียบ
• เมื่อฉันประกาศในโซน มอร์ดอร์.แฟน ตัวอย่างเช่น: อนุญาตให้อัปเดต {10.10.10.0/24; };BIND เองแจ้งให้ฉันทราบเมื่อเริ่มหรือรีสตาร์ทว่า:

  • โซน 'mordor.fan' อนุญาตให้อัปเดตตามที่อยู่ IP ซึ่งไม่ปลอดภัย

• ในโลกUNIX® / Linux อันศักดิ์สิทธิ์ความทะลึ่งกับ DNS นั้นไม่สามารถยอมรับได้.

คุณลองนึกภาพการแลกเปลี่ยนที่เหลือกับเพื่อนของฉัน Fuegian ตลอด อีเมล, โทรเลขแชทโทรศัพท์ที่จ่ายให้เขา (แน่นอนผู้ชายฉันไม่มีกิโลสำหรับเรื่องนั้น) และแม้แต่ข้อความผ่านนกพิราบผู้ให้บริการในศตวรรษที่ XXI!

เขาขู่ว่าจะไม่ส่งลูกชายของสัตว์เลี้ยงอีกัวน่ามาให้ฉัน«เปตรา»ที่เขาสัญญากับฉันว่าเป็นส่วนหนึ่งของการชำระเงิน ที่นั่นฉันกลัวจริงๆ ดังนั้นฉันจึงเริ่มต้นอีกครั้ง แต่จากอีกมุมหนึ่ง

• Active Directory "เกือบ" ที่สามารถทำได้ด้วย Samba 4 ช่วยแก้ปัญหานี้ได้อย่างเชี่ยวชาญทั้งเมื่อเราใช้ DNS ภายในหรือ BIND ที่คอมไพล์เพื่อรองรับโซน DLZ - โซนโหลด Dinamycหรือโซนที่โหลดแบบไดนามิก
• ยังคงประสบปัญหาเดิม: เมื่อไคลเอนต์ได้รับที่อยู่ IP ผ่าน DHCP ที่ติดตั้งใน อื่น ๆ เครื่องUNIX® / Linux คุณจะไม่สามารถแก้ไขที่อยู่ IP ของชื่อของคุณเองได้ จนกว่าจะเข้าร่วมกับโดเมนของ Samba 4 AD-DC.
• รวม BIND-DLZ และ DHCP duo ไว้ในเครื่องเดียวกันโดยที่ไฟล์ AD-DC แซมบ้า 4 เป็นงานสำหรับผู้เชี่ยวชาญจริงๆ

Fuegian เขาเรียกฉันไปที่บทและตะโกนใส่ฉัน: เราไม่ได้พูดถึง AD-DC แซมบ้า 4แต่Microsoft® Active Directory®! และฉันตอบอย่างถ่อมตัวว่าฉันรู้สึกยินดีกับส่วนหนึ่งของบทความต่อไปนี้ที่ฉันกำลังจะเขียน

นั่นคือตอนที่ฉันบอกเขาว่าการตัดสินใจขั้นสุดท้ายเกี่ยวกับการอัปเดตแบบไดนามิกสำหรับคอมพิวเตอร์ไคลเอนต์บนเครือข่ายของเขาถูกปล่อยให้เป็นอิสระ ที่ฉันจะให้เขาเท่านั้น ชนิด เขียนก่อนเกี่ยวกับ อนุญาตให้อัปเดต {10.10.10.0/24; };และไม่มีอะไรอีกแล้ว ว่าฉันไม่รับผิดชอบต่อสิ่งที่เป็นผลมาจากความสำส่อนที่ไคลเอนต์ Windows แต่ละตัวหรือ Linux- ในเครือข่ายของตน«จะเจาะ»โดยไม่ต้องรับโทษต่อ BIND

ถ้าคุณรู้จักรีดเดอร์เพื่อนของฉันว่านี่คือจุดสิ้นสุดของการทะเลาะวิวาทคุณจะไม่เชื่อ เพื่อนของฉัน Fuegian เขายอมรับวิธีแก้ปัญหา - และเขาจะส่งอีกัวน่ามาให้ฉัน«พีท« - ตอนนี้ฉันแบ่งปันกับคุณ

เราติดตั้งและกำหนดค่า DHCP

สำหรับรายละเอียดเพิ่มเติมอ่าน DNS และ DHCP ใน Debian 8 "Jessie".

root @ dnslinux: ~ # aptitude ติดตั้ง isc-dhcp-server

root @ dnslinux: ~ # nano / etc / default / isc-dhcp-server .... # บนอินเทอร์เฟซใดที่เซิร์ฟเวอร์ DHCP (dhcpd) ควรให้บริการคำขอ DHCP # แยกอินเทอร์เฟซหลายรายการด้วยช่องว่างเช่น "eth0 eth1" INTERFACES = "eth0" root @ dnslinux: ~ # dnssec-keygen -a HMAC-MD5 -b 128 -r / dev / urandom -n USER dhcp-key
รหัส Kdhcp +157 + 29836

root @ dnslinux: ~ # cat Kdhcp-key +157 + 29836.private
Private-key-format: v1.3 Algorithm: 157 (HMAC_MD5) Key: 3HT / bg / 6YwezUShKYofj5g == Bits: AAA = Created: 20170212205030 เผยแพร่: 20170212205030 เปิดใช้งาน: 20170212205030

root @ dnslinux: ~ # นาโน dhcp.key
คีย์ dhcp-key {algorithm hmac-md5; ลับ "3HT / bg / 6YwezUShKYofj5g =="; };

root @ dnslinux: ~ # install -o root -g bind -m 0640 dhcp.key /etc/bind/dhcp.key
root @ dnslinux: ~ # install -o root -g root -m 0640 dhcp.key /etc/dhcp/dhcp.key

รูท @ dnslinux: ~ # nano /etc/bind/named.conf.local
// // ทำการกำหนดค่าภายในเครื่องที่นี่ // // พิจารณาเพิ่มโซน 1918 ที่นี่หากไม่ได้ใช้ใน // องค์กรของคุณรวม "/etc/bind/zones.rfc1918"; รวม "/etc/bind/zones.rfcFreeBSD";
// อย่าลืม ... ฉันลืมและจ่ายเงินด้วยความผิดพลาด ;-)
รวม "/etc/bind/dhcp.key";


โซน "mordor.fan" {พิมพ์ master;
        อนุญาตให้อัปเดต {10.10.10.3; คีย์ dhcp-key; };
        ไฟล์ "/var/lib/bind/db.mordor.fan"; }; โซน "10.10.10.in-addr.arpa" {พิมพ์ master;
        อนุญาตให้อัปเดต {10.10.10.3; คีย์ dhcp-key; };
        ไฟล์ "/var/lib/bind/db.10.10.10.in-addr.arpa"; }; โซน "_msdcs.mordor.fan" {พิมพ์ master; ไม่สนใจชื่อเช็ค ไฟล์ "/etc/bind/db._msdcs.mordor.fan"; };

root @ dnslinux: ~ # named-checkconf 
รูท @ dnslinux: ~ #

รูท @ dnslinux: ~ # nano /etc/dhcp/dhcpd.conf
ddns-update-style ระหว่างกาล; ddns-updates on; ddns-domainname "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; ละเว้นการอัปเดตไคลเอ็นต์ เผด็จการ; ตัวเลือกการส่งต่อ ip ปิด; ชื่อโดเมนตัวเลือก "mordor.fan"; รวม "/etc/dhcp/dhcp.key"; โซน mordor.fan. {หลัก 127.0.0.1; คีย์ dhcp-key; } โซน 10.10.10.in-addr.arpa {หลัก 127.0.0.1; คีย์ dhcp-key; } redlocal เครือข่ายที่ใช้ร่วมกัน {subnet 10.10.10.0 netmask 255.255.255.0 {เราเตอร์ตัวเลือก 10.10.10.1; ตัวเลือกซับเน็ตมาสก์ 255.255.255.0; ตัวเลือกที่อยู่ออกอากาศ 10.10.10.255; ตัวเลือกโดเมนเนมเซิร์ฟเวอร์ 10.10.10.5; ตัวเลือก netbios-name-servers 10.10.10.5; พิสัย 10.10.10.30 10.10.10.250; }} # END dhcpd.conf

รูท @ dnslinux: ~ # dhcpd -t
Internet Systems Consortium DHCP Server 4.3.1 ลิขสิทธิ์ 2004-2014 Internet Systems Consortium สงวนลิขสิทธิ์. สำหรับข้อมูลโปรดไปที่ https://www.isc.org/software/dhcp/ ไฟล์ Config: /etc/dhcp/dhcpd.conf ไฟล์ฐานข้อมูล: /var/lib/dhcp/dhcpd.leases ไฟล์ PID: / var / run /dhcpd.pid

root @ dnslinux: ~ # systemctl รีสตาร์ท bind9.service 
root @ dnslinux: ~ # systemctl สถานะ bind9.service 

root @ dnslinux: ~ # systemctl start isc-dhcp-server.service
root @ dnslinux: ~ # systemctl สถานะ isc-dhcp-server.service

เกี่ยวข้องกับอะไร ตรวจสอบกับลูกค้าและ การแก้ไขไฟล์โซนด้วยตนเองเราฝากไว้ให้คุณเพื่อนผู้อ่านอ่านได้โดยตรงจาก DNS และ DHCP ใน Debian 8 "Jessie"และนำไปใช้กับเงื่อนไขจริงของคุณ เราทำการตรวจสอบที่จำเป็นทั้งหมดและได้ผลลัพธ์ที่น่าพอใจ แน่นอนเราส่งสำเนาทั้งหมดไปที่ Fuegian. จะไม่มีอีกแล้ว!

เคล็ดลับ

ทั่วไป

• อดทนให้ดีก่อนที่จะเริ่ม.
  
• ขั้นแรกให้ติดตั้งและกำหนดค่า BIND ตรวจสอบทุกอย่างและดูบันทึกทั้งหมดที่คุณประกาศไว้ในแต่ละไฟล์ในสามโซนหรือมากกว่านั้นทั้งจาก Active Directory และจากเซิร์ฟเวอร์ DNS บน Linux ถ้าเป็นไปได้จากเครื่อง Linux ที่ไม่ได้เชื่อมต่อกับโดเมนให้ทำการสืบค้น DNS ที่จำเป็นไปยัง BIND
  
• เข้าร่วมไคลเอนต์ Windows ที่มีที่อยู่ IP คงที่กับโดเมนที่มีอยู่และตรวจสอบการตั้งค่า BIND ทั้งหมดจากไคลเอนต์ Windows อีกครั้ง
• หลังจากที่คุณแน่ใจอย่างไม่ต้องสงสัยว่าการกำหนดค่า BIND ใหม่เอี่ยมของคุณนั้นถูกต้องสมบูรณ์แล้วให้ลองติดตั้งกำหนดค่าและเริ่มบริการ DHCP
• ในกรณีที่เกิดข้อผิดพลาดให้ทำซ้ำขั้นตอนทั้งหมดจากศูนย์ 0
• ระวังการคัดลอกและวาง! และช่องว่างพิเศษในแต่ละบรรทัดของไฟล์ named.conf.xxxx
  
• หลังจากนั้นเขาก็ไม่บ่น - น้อยกว่าเพื่อนของฉัน Fuegian - ว่าเขาไม่ได้รับคำแนะนำอย่างถูกต้อง.

เคล็ดลับอื่น ๆ

• หารและพิชิต.
• ในเครือข่าย SME จะปลอดภัยกว่าและมีประโยชน์มากกว่าในการติดตั้ง Authoritative BIND สำหรับโซน LAN ภายในที่ไม่เกิดซ้ำกับเซิร์ฟเวอร์รูทใด ๆ : เลขเรียกซ้ำ;.
• ในเครือข่าย SME ที่อยู่ภายใต้ผู้ให้บริการอินเทอร์เน็ต - ISPบางทีบริการ หนังสือมอบฉันทะ y SMTP พวกเขาจำเป็นต้องแก้ไขชื่อโดเมนบนอินเทอร์เน็ต เขา ปลาหมึก คุณมีตัวเลือกในการประกาศ DNS ภายนอกหรือไม่ในขณะที่อยู่บนเซิร์ฟเวอร์อีเมลตาม postfix o มาแดมอน® เราสามารถประกาศเซิร์ฟเวอร์ DNS ที่เราจะใช้ในบริการนั้นได้ด้วย ในกรณีเช่นนี้นั่นคือกรณีที่ไม่ได้ให้บริการกับอินเทอร์เน็ตและอยู่ภายใต้ก ผู้ให้บริการอินเทอร์เน็ตคุณสามารถติดตั้ง BIND ด้วย ลำเลียง ชี้ไปที่ DNS ของไฟล์ ISPและประกาศเป็น DNS รองในเซิร์ฟเวอร์ที่ต้องการแก้ไขการสืบค้นภายนอกไปยัง LAN มิฉะนั้นจะสามารถประกาศผ่านไฟล์กำหนดค่าของตนเองได้
• หากคุณมี Delegated Zone ภายใต้ความรับผิดชอบทั้งหมดของคุณจากนั้นอีกาไก่อีกตัว:
  • ติดตั้งเซิร์ฟเวอร์ DNS ตาม NSDซึ่งเป็นเซิร์ฟเวอร์ DNS ที่เชื่อถือได้ตามคำจำกัดความที่ตอบสนองต่อการสืบค้นจากคอมพิวเตอร์บนอินเทอร์เน็ต สำหรับข้อมูลบางอย่าง แสดงความถนัด nsd. 😉โปรดป้องกันด้วยกำแพงไฟให้มากเท่าที่จำเป็น ทั้งฮาร์ดแวร์และซอฟต์แวร์ จะเป็น DNS สำหรับอินเทอร์เน็ตและ«ซาร์»เราต้องไม่ใส่กางเกงขาสั้น 😉
  • เนื่องจากฉันไม่เคยเห็นตัวเองในกรณีเช่นนี้กล่าวคือรับผิดชอบโดยสิ้นเชิงสำหรับ Delegated Zone ฉันจะต้องคิดให้ดีว่าจะแนะนำอะไรสำหรับการแก้ปัญหาชื่อโดเมนภายนอก LAN ของเราสำหรับบริการที่ต้องการ . ลูกค้าเครือข่าย SME ไม่จำเป็นจริงๆ ปรึกษาวรรณกรรมเฉพาะทางหรือผู้เชี่ยวชาญในเรื่องเหล่านี้เนื่องจากฉันยังห่างไกลจากการเป็นหนึ่งในนั้น อย่างจริงจัง.
  • ไม่มีการเรียกซ้ำบนเซิร์ฟเวอร์ Authoritarian ตกลง?. เผื่อมีคนคิดจะทำ BIND.
• แม้ว่าเราจะระบุอย่างชัดเจนในไฟล์ /etc/dhcp/dhcpd.conf การประกาศ ละเว้นการอัปเดตไคลเอ็นต์ถ้าเราทำงานบนคอนโซลคอมพิวเตอร์ dnslinux.mordor.fan การสั่งซื้อ Journalctl -fเราจะเห็นว่าเมื่อเริ่มต้นไคลเอนต์ win7.mordor.fan เราได้รับข้อความแสดงข้อผิดพลาดต่อไปนี้:

  • 12 ก.พ. 16:55:41 dnslinux ชื่อ [900]: ไคลเอนต์ 10.10.10.30 # 58762: อัปเดต 'mordor.fan/IN' ถูกปฏิเสธ
    12 ก.พ. 16:55:42 dnslinux ชื่อ [900]: ไคลเอนต์ 10.10.10.30 # 49763: อัปเดต 'mordor.fan/IN' ถูกปฏิเสธ
    12 ก.พ. 16:56:23 dnslinux ชื่อ [900]: ไคลเอนต์ 10.10.10.30 # 63161: อัปเดต 'mordor.fan/IN' ถูกปฏิเสธ
    

  • ในการกำจัดข้อความเหล่านี้เราต้องไปที่ตัวเลือกขั้นสูงของการกำหนดค่าการ์ดเครือข่ายและยกเลิกการเลือกตัวเลือก«ลงทะเบียนที่อยู่ของการเชื่อมต่อนี้ใน DNS«. ซึ่งจะป้องกันไม่ให้ไคลเอ็นต์พยายามลงทะเบียนด้วยตนเองใน Linux DNS ตลอดไปและการสิ้นสุดของปัญหา ขออภัยฉันไม่มีสำเนาของ Windows 7 ในภาษาสเปน 😉
• หากต้องการทราบเกี่ยวกับคำถามที่ร้ายแรงและบ้าคลั่งทั้งหมดที่ไคลเอนต์ Windows 7 ทำโปรดดูที่ไฟล์ บันทึก queries.log สำหรับสิ่งที่เราประกาศในการกำหนดค่า BIND คำสั่งจะเป็น:

  • root @ dnslinux: ~ # tail -f /var/log/named/queries.log

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

  รูท @ dnslinux: ~ # cp /etc/bind/db.root /etc/bind/db.root.original
  รูท @ dnslinux: ~ # cp / dev / null /etc/bind/db.root

• หากคุณไม่ต้องการการประกาศเซิร์ฟเวอร์รูททำไมคุณถึงต้องมีการเรียกซ้ำ - Recursion?

  root @ dnslinux: ~ # นาโน /etc/bind/named.conf.options
  ตัวเลือก {
   ....
   เลขเรียกซ้ำ;
   ....
  };

คำแนะนำเฉพาะที่ฉันยังไม่ชัดเจนนัก

El คน dhcpd.conf บอกเราสิ่งต่อไปนี้ในหลายสิ่งหลายอย่าง:

        คำสั่ง update-optimization

            แฟล็กการปรับปรุงการเพิ่มประสิทธิภาพ

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

ยิ่งมีการแปลหรือการตีความที่แน่นอนมากขึ้นหรือน้อยลงสำหรับคุณผู้อ่านที่รัก

โดยส่วนตัวแล้วมันเกิดขึ้นกับฉัน - และมันเกิดขึ้นระหว่างการสร้างบทความนี้ - เมื่อฉันเชื่อมโยง BIND กับ Active Directory®มันมาจากMicrosft®หรือ Samba 4 ถ้าฉันเปลี่ยนชื่อคอมพิวเตอร์ไคลเอนต์ที่ลงทะเบียนใน โดเมน Active Directory®หรือของ ค.ศ.–ค ของ Samba 4 จะเก็บชื่อและที่อยู่ IP เก่าไว้ใน Direct Zone ไม่ใช่วิธีอื่นซึ่งได้รับการอัปเดตด้วยชื่อใหม่อย่างถูกต้อง กล่าวอีกนัยหนึ่งชื่อเก่าและใหม่จะถูกจับคู่กับที่อยู่ IP เดียวกันใน Direct Zone ในขณะที่ในทางกลับกันจะปรากฏเฉพาะชื่อใหม่เท่านั้น จะเข้าใจฉันดีคุณต้องลองด้วยตัวเอง

ฉันคิดว่ามันเป็นการแก้แค้นแบบหนึ่ง Fuegian - ไม่ใช่สำหรับฉันโปรด - สำหรับการพยายามย้ายบริการของคุณไปยัง Linux

แน่นอนว่าชื่อเก่าจะหายไปเมื่อ ทีทีแอล 3600หรือเวลาที่เราได้ประกาศไว้ในการกำหนดค่า DHCP แต่เราต้องการให้มันหายไปทันทีที่เกิดขึ้นใน BIND + DHCP โดยไม่มี Active Directory ผ่าน.

วิธีแก้ไขสถานการณ์นั้นที่ฉันพบโดยการใส่คำสั่ง การปรับปรุงการเพิ่มประสิทธิภาพเท็จ; ที่ท้ายด้านบนของไฟล์ /etc/dhcp/dhcpd.conf:

ddns-update-style ระหว่างกาล; ddns-updates on; ddns-domainname "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; ละเว้นการอัปเดตไคลเอ็นต์
การปรับปรุงการเพิ่มประสิทธิภาพเท็จ;

หากผู้อ่านคนใดทราบข้อมูลเพิ่มเติมโปรดแจ้งให้ฉันทราบ ฉันจะขอบคุณมันมาก

ข้อมูลอย่างย่อ

เราสนุกกับเรื่องนี้มากใช่มั้ย? ไม่ต้องทุกข์ทรมานเพราะเรามี BIND ที่ทำงานเป็นเซิร์ฟเวอร์ DNS ในเครือข่ายMicrosoft®ซึ่งนำเสนอระเบียน SRV ทั้งหมดและตอบสนองอย่างเหมาะสมกับการสืบค้น DNS ที่ทำกับพวกเขา ในทางกลับกันเรามีเซิร์ฟเวอร์ DHCP ที่ให้ที่อยู่ IP และอัปเดต BIND Zones แบบไดนามิกอย่างถูกต้อง

แต่เราไม่สามารถขอ ...

ฉันหวังว่าเพื่อนของฉัน Fuegian พึงพอใจและพอใจกับขั้นตอนแรกในการย้ายข้อมูลไปยัง Linux เพื่อให้Microsft® Technical Support มีค่าใช้จ่ายที่ไม่สามารถทนทานได้

หมายเหตุสำคัญ

ตัวละคร "Fuegian»เป็นเรื่องสมมติและเป็นผลงานจากจินตนาการของฉัน ความคล้ายคลึงหรือความบังเอิญใด ๆ กับคนจริงๆนั้นเหมือนกัน: Pure Involuntary Coincidence ในส่วนของฉัน ฉันสร้างขึ้นเพื่อให้การเขียนและการอ่านบทความนี้สนุกขึ้นเล็กน้อย ตอนนี้ถ้าคุณสามารถบอกฉันได้ว่าปัญหา DNS มืด,