BIND და Active Directory® - მცირე და საშუალო ბიზნესის ქსელები

სერიის ზოგადი ინდექსი: კომპიუტერული ქსელები მცირე და საშუალო ბიზნესისთვის: შესავალი

გამარჯობა მეგობრებო !. ამ სტატიის მთავარი მიზანია აჩვენოს, თუ როგორ შეგვიძლია DNS სერვისის ინტეგრირება BIND9- ის ბაზაზე Microsoft- ის ქსელში, რომელიც ძალიან გავრცელებულია მრავალ მცირე და საშუალო საწარმოში.

ეს წარმოიშობა მეგობრის ოფიციალური თხოვნით, რომელიც ლა ტიერა დელ ფუეგოში ცხოვრობს -ფუგელი- სპეციალიზირებულია Microsoft® Networks– ში - მოწმობებში - თქვენი სერვერების Linux– ზე გადასვლის პროცესში. ხარჯები მხარდაჭერა ტექნიკოსი, რომელიც იხდის Microsoft®– ს, უკვე არის აუტანელი კომპანიისთვის, რომელშიც ის მუშაობს და რომლის ის არის მისი ძირითადი აქციონერი.

მე ამიგო ფუგელი აქვს დიდი იუმორის გრძნობა და რადგან მან ნახა სამი ფილმის სერია «ბეჭდების მბრძანებელი»იგი მოიხიბლა მისი ბნელი პერსონაჟების მრავალმა სახელმა. მკითხველო მეგობარო, ნუ გაგიკვირდებათ თქვენი დომენისა და თქვენი სერვერების სახელები.

ამ თემის ახალბედაებისთვის და კითხვის გაგრძელებამდე გირჩევთ წაიკითხოთ და შეისწავლოთ მცირე და საშუალო ბიზნესის ქსელების სამი წინა სტატია:

• DNS და DHCP in openSUSE 13.2 "არლეკინი"
• DNS და DHCP CentOS 7-ზე
• DNS და DHCP Debian 8 "Jessie" - ში

ეს ჰგავს ოთხი ნაწილის სამიდან ყურებას «ქვესკნელი»გამოქვეყნებულია დღემდე და ეს უკვე მეოთხეა.

ზოგადი პარამეტრები

რამდენიმე გაცვლის შემდეგ ელდა ბოლოს, მე გავერკვიე თქვენი ამჟამინდელი ქსელის ძირითადი პარამეტრების შესახებ, რომლებიც:

დომენის სახელი mordor.fan LAN ქსელი 10.10.10.0/24 ===================================== ============================================ სერვერები IP მისამართის დანიშნულება (სერვერები ოპერაციული სისტემებით ვინდოუსი) =============================================== ================================= sauron.mordor.fan. 10.10.10.3 Active Directory® 2008 SR2 mamba.mordor.fan. 10.10.10.4 ვინდოუსის ფაილების სერვერი 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- ისთვის

ვთხოვე ნებართვა ფუგელი დავაყენე რაც შეიძლება მეტსახელი აზრების გასარკვევად და მომცა მისი ნებართვა:

ნამდვილი CNAME =============================== sauron ad-dc mamba fileserver darklord proxyweb troll blog shadowftp ftpserver blackelf mail blackspider www palantir openfire

მე გამოვაცხადე ყველა მნიშვნელოვანი DNS ჩანაწერი Active Directory Windows 2008-ის ინსტალაციის დროს, რომელიც იძულებული გავხდი განმეხორციელებინა, ამ სახელმძღვანელოს გაგზავნისას.

აქტიური დირექტორიის DNS- ის SRV ჩანაწერების შესახებ

რეგისტრები SRV o სერვისის ლოკატორები - Microsoft Active Directory- ში ფართოდ გავრცელებული - განისაზღვრება აქ კომენტარის მოთხოვნა RFC 2782. ისინი საშუალებას გვაძლევს DNS შეკითხვის საშუალებით განლაგდეს მომსახურება TCP / IP პროტოკოლის საფუძველზე. მაგალითად, Microsoft- ის ქსელში მყოფ მომხმარებელს შეუძლია დაადგინოს დომენის კონტროლერების ადგილმდებარეობა - დომენის კონტროლერები რომლებიც უზრუნველყოფენ LDAP სერვისს TCP პროტოკოლის 389 პორტზე, ერთი DNS მოთხოვნის საშუალებით.

ნორმალურია, რომ ტყეებში - ტყეებიდა ხეები - ხეები Microsoft– ის დიდი ქსელის რამდენიმე დომენის კონტროლერი არსებობს. სხვადასხვა ქსელში SRV ჩანაწერების გამოყენებით, რომლებიც ქმნიან ამ ქსელის დომენური სახელის სივრცეს, შეგვიძლია შევინარჩუნოთ სერვერების სია, რომლებიც უზრუნველყოფენ მსგავს ცნობილ სერვისებს, შეკვეთით უპირატესობის მიხედვით, თითოეული სატრანსპორტო პროტოკოლისა და პორტის შესაბამისად. ერთ-ერთი სერვერი.

In კომენტარის მოთხოვნა RFC 1700 უნივერსალური სიმბოლური სახელების განსაზღვრა კარგად ცნობილი სერვისებისთვის - კარგად ცნობილი სერვისი, და სახელები, როგორიცაა «_ტელნეტი««_ smtp»მომსახურებისთვის telnet y SMTP. თუ კარგად ცნობილი სერვისისთვის არ არის განსაზღვრული სიმბოლური სახელი, მომხმარებლის სახელით შეიძლება გამოყენებულ იქნეს ადგილობრივი სახელი ან სხვა სახელი.

თითოეული დარგის მიზანისპეციალური», რომელიც გამოიყენება SRV რესურსის ჩანაწერის დეკლარაციაში არის შემდეგი:

• დომენის: "Pdc._msdcs.mordor.fan.« DNS სერვისის სახელი, რომელსაც ეხება SRV ჩანაწერი. DNS სახელი მაგალითში ნიშნავს-მეტნაკლებად- ძირითადი დომენის კონტროლერი ტერიტორიის _msdcs.mordor.fan.
• სამსახურის: "_Ldap". მომსახურების სიმბოლური სახელი, რომელიც მოცემულია შესაბამისად კომენტარის მოთხოვნა RFC 1700.
• ოქმი: "_Tcp". მიუთითებს სატრანსპორტო პროტოკოლის ტიპზე. როგორც წესი, მას შეუძლია მიიღოს მნიშვნელობები _tcp o _ხმა, თუმცა - და სინამდვილეში - ნებისმიერი ტიპის სატრანსპორტო პროტოკოლი მითითებულია აქ კომენტარის მოთხოვნა RFC 1700. მაგალითად, სამსახურისთვის სტატისტიკა პროტოკოლის საფუძველზე XMPP, ამ ველს ექნება მნიშვნელობა _xmpp.
• პრიორიტეტი'0« გამოაცხადეთ პრიორიტეტი ან უპირატესობა მასპინძელი, რომელიც გთავაზობთ ამ მომსახურებას რომ შემდეგ ვნახავთ. კლიენტების DNS მოთხოვნები ამ SRV ჩანაწერით განსაზღვრული მომსახურების შესახებ, შესაბამისი პასუხის მიღების შემდეგ, შეეცდებიან დაუკავშირდნენ პირველ არსებულ მასპინძელს, რომელშიც მოცემულია ამ სფეროში ყველაზე დაბალი რიცხვი. პრიორიტეტი. ღირებულებების დიაპაზონი, რომელიც ამ ველს შეუძლია მიიღოს არის 0 65535.
• წონა'100« შეიძლება გამოყენებულ იქნას კომბინაციაში პრიორიტეტი უზრუნველყოს დატვირთვის დაბალანსების მექანიზმი, როდესაც არსებობს რამდენიმე სერვერი, რომლებიც ერთსა და იმავე მომსახურებას უზრუნველყოფენ. ზონის ფაილში უნდა არსებობდეს მსგავსი SRV ჩანაწერი თითოეული სერვერისთვის, რომლის ველში დეკლარირებული იქნება მისი სახელი მასპინძელი, რომელიც გთავაზობთ ამ მომსახურებას. ველში თანაბარი მნიშვნელობების მქონე სერვერებზე პრიორიტეტი, ველის მნიშვნელობა წონა ის შეიძლება გამოყენებულ იქნას როგორც დამატებითი დონის პრეფერენცია დატვირთვის დაბალანსებისთვის სერვერის ზუსტი არჩევანის მისაღებად. ღირებულებების დიაპაზონი, რომელიც ამ ველს შეუძლია მიიღოს არის 0 65535. თუ დატვირთვის დაბალანსება არ არის საჭირო, მაგალითად, როგორც ერთი სერვერის შემთხვევაში, ჩვენ გირჩევთ მივანიჭოთ მნიშვნელობას 0 რომ SRV ჩანაწერი უფრო ადვილად იკითხებოდეს.
• პორტის ნომერი - პორტი'389« პორტის ნომერი მასპინძელი, რომელიც გთავაზობთ ამ მომსახურებას რომელიც უზრუნველყოფს სფეროში მითითებულ მომსახურებას სამსახურის. პორტის რეკომენდებული ნომერი თითოეული ტიპის კარგად ცნობილი სერვისისთვის მითითებულია კომენტარის მოთხოვნა RFC 1700, თუმცა მას შეუძლია მიიღოს მნიშვნელობა შორის 0 და 65535.
• მასპინძელი, რომელიც გთავაზობთ ამ მომსახურებას - სამიზნე'საურონი. მორდორ.ფან.« განსაზღვრავს FQDN რომ ერთმნიშვნელოვნად განსაზღვრავს მასპინძელი რომელიც უზრუნველყოფს SRV ჩანაწერით მითითებულ მომსახურებას. ჩანაწერის ტიპი «A»დომენის სახელების სივრცეში თითოეული FQDN სერვერიდან ან მასპინძელი რომელიც უზრუნველყოფს მომსახურებას. უფრო მარტივი, ტიპის ჩანაწერი A პირდაპირ ზონაში (ზონებში).
  • შენიშვნა:
    ავტორიტეტად რომ მიუთითოს, რომ SRV ჩანაწერით განსაზღვრული სერვისი არ არის მოცემული ამ ჰოსტზე,.) წერტილი.

ჩვენ უბრალოდ გვინდა გავიმეოროთ, რომ ქსელის ან აქტიური დირექტორიის სწორი ფუნქციონირება დიდწილად ეყრდნობა დომენის სახელების სერვისის სწორად მუშაობას..

აქტიური დირექტორიის DNS ჩანაწერები

ახალი DNS სერვერის ზონების შესაქმნელად BIND– ზე დაყრდნობით, Active Directory Ac– დან უნდა მივიღოთ ყველა DNS ჩანაწერი. ცხოვრების გასამარტივებლად ჩვენ გუნდში მივდივართ საურონი. მორდორ.ფან -Active Directory® 2008 SR2- და DNS ადმინისტრაციულ კონსოლში ჩვენ ვააქტიურებთ Zone Transfer -direct და inverse- ამ ტიპის სერვისებში გამოცხადებული ძირითადი ზონებისთვის, რომლებიც არიან:

• _msdcs.mordor.fan
• მორდო.ფან
• 10.10.10. in- ადრ. არპა

მას შემდეგ, რაც შესრულდება წინა ნაბიჯი და სასურველია Linux კომპიუტერიდან, რომლის IP მისამართია Windows ქსელის მიერ გამოყენებული ქვექსელის ფარგლებში, ჩვენ ვასრულებთ:

buzz @ sysadmin: dig $ dig @ 10.10.10.3 _msdcs.mordor.fan axfr> ტემპი /rrs._msdcs.mordor.fan
buzz @ sysadmin: dig $ dig @ 10.10.10.3 mordor.fan axfr> temp / rrs.mordor.fan
buzz @ sysadmin: dig $ dig @ 10.10.10.3 10.10.10.in-addr.arpa axfr> temp / rrs.10.10.10.in- ადდრ.არპაში

• გაიხსენეთ წინა სტატიებიდან, რომ მოწყობილობის IP მისამართი sysadmin.fromlinux.fan ეს 10.10.10.1 ან 192.168.10.1.

სამ წინა ბრძანებაში შეგვიძლია აღმოფხვრას ვარიანტი 10.10.10.3 -ჰკითხეთ DNS სერვერს ამ მისამართით- თუ საქმეში ვაცხადებთ /etc/resolv.conf სერვერის IP- ზე საურონი. მორდორ.ფან:

buzz @ sysadmin: cat $ cat /etc/resolv.conf # გენერირებულია NetworkManager- ის მიერ ძიება linux.fan nameserver- დან 192.168.10.5 nameserver 10.10.10.3

უკიდურესი სიფრთხილით რედაქტირების შემდეგ, როგორც BIND– ის ნებისმიერი ზონის ფაილი შეესაბამება, ჩვენ მივიღებთ შემდეგ მონაცემებს:

RR ჩანაწერები საწყისი ზონიდან _msdcs.mordor.fan

buzz @ sysadmin: cat $ cat temp / rrs._msdcs.mordor.fan 
; ეხება SOA და NS _msdcs.mordor.fan. 3600 SOA sauron.mordor.fan- ში. მასპინძელი .ordord.fan. 12 900 600 86400 3600 _msdcs.mordor.fan. 3600 NS sauron- ში. Mordor.fan. ; ; გლობალური კატალოგი gc._msdcs.mordor.fan. 600 IN 10.10.10.3; ; მეტსახელები - აქტიური დირექტორიის LDAP– ის შეცვლილ და კერძო მონაცემთა ბაზაში– SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 IN CNAME sauron.mordor.fan. ; ; შეცვლილია და ხდება პირადი LDAP აქტიური დირექტორიის _ldap._tcp.Default-First-Site-Same-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. ; ; KERBEROS შეცვლილია და პირადია აქტიური დირექტორიიდან _kerberos._tcp.Default-First-Site-Same-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan.

RR ჩანაწერები ორიგინალური ზონის მორდოდან .fan

buzz @ sysadmin: cat $ cat temp / rrs.mordor.fan 
; ეხება SOA, NS, MX და A ჩანაწერებს, რომლებიც მას ასახავს; დომენის სახელი SAURON– ის IP– ზე; ყველაფერი აქტიური დირექტორიიდან mordor.fan. 3600 SOA sauron.mordor.fan- ში. მასპინძელი. 48 900 600 86400 3600 მორდორი. ფან. 600 in 10.10.10.3 mordor.fan. 3600 NS sauron- ში. Mordor.fan. მორდო.ფან. 3600 IN MX 10 blackelf.mordor.fan. _msdcs.mordor.fan. 3600 NS sauron- ში. Mordor.fan. ; ; ასევე მნიშვნელოვანია A ჩანაწერები DomainDnsZones.mordor.fan. 600 IN 10.10.10.3 ForestDnsZones.mordor.fan. 600 IN 10.10.10.3; ; გლობალური კატალოგი _gc._tcp.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _gc._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. ; ; აქტიური დირექტორიის _ldap._tcp.mordor.fan შეცვლილი და კერძო LDAP. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. ; ; პირადი შეცვლილი KERBEROS აქტიური დირექტორიის _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan 600 IN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 600 IN SRV 0 100 464 sauron.mordor.fan. _kerberos._udp.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 600 IN SRV 0 100 464 sauron.mordor.fan. ; ; ფიქსირდება IP ფიქსირებული IP -> სერვერებით blackelf.mordor.fan. 3600 წელს 10.10.10.9 blackspider.mordor.fan. 3600 წელს 10.10.10.10 darklord.mordor.fan. 3600 წელს 10.10.10.6 mamba.mordor.fan. 3600 in 10.10.10.4 palantir.mordor.fan. 3600 წელს 10.10.10.11 sauron.mordor.fan. 3600 წელს 10.10.10.3 ჩრდილი. Mordor.fan. 3600 წელს 10.10.10.8 ტროლი. Mordor.fan. 3600 წელს 10.10.10.7; ; CNAME აღრიცხავს ad-dc.mordor.fan. 3600 CNAME- ში sauron.mordor.fan. ბლოგი.mordor.fan. 3600 CNAME– ში troll.mordor.fan. ფაილების სერვერი .ordor.fan. 3600 CNAME- ში mamba.mordor.fan. ftpserver.mordor.fan. 3600 IN CNAME shadowftp.mordor.fan. ფოსტა. წესრიგი. ფან. 3600 CNAME– ში balckelf.mordor.fan. ღია ცეცხლი. წესრიგი. ფან. 3600 IN CNAME palantir.mordor.fan. მარიონეტული .ordord.fan. 3600 CNAME- ში darklord.mordor.fan. www.mordor.fan. 3600 IN CNAME blackspider.mordor.fan.

RRs ჩანაწერები საწყისი ზონიდან 10.10.10.in-addr.arpa- ში

buzz @ sysadmin: cat $ cat temp / rrs.10.10.10.in-addr.arpa 
; ეხება SOA და NS 10.10.10.in-addr.arpa- ს. 3600 SOA sauron.mordor.fan- ში. მასპინძელი .ordord.fan. 21 900 600 86400 3600 10.10.10.addr.arpa. 3600 NS sauron- ში. Mordor.fan. ; ; PTR ჩანაწერები 10.10.10.10.in-addr.arpa. 3600 IN PTR blackspider.mordor.fan. 11.10.10.10.addr.arpa. 3600 IN PTR palantir.mordor.fan. 3.10.10.10.addr.arpa. 3600 IN PTR sauron.mordor.fan. 4.10.10.10.addr.arpa. 3600 IN PTR mamba.mordor.fan. 5.10.10.10.addr.arpa. 3600 IN PTR dnslinux.mordor.fan. 6.10.10.10.addr.arpa. 3600 IN PTR darklord.mordor.fan. 7.10.10.10.addr.arpa. 3600 IN PTR troll.mordor.fan. 8.10.10.10.addr.arpa. 3600 IN PTR shadowftp.mordor.fan. 9.10.10.10.addr.arpa. 3600 IN PTR blackelf.mordor.fan.

ამ ეტაპზე შეგვიძლია ვიფიქროთ, რომ გვაქვს აუცილებელი მონაცემები, რომ ჩვენი თავგადასავალი გავაგრძელოთ, და არა უშუალოდ მასზე დაკვირვების გარეშე TTL და სხვა მონაცემები, რომლებიც ძალიან ლაკონურად გვაწვდის Microsoftft® Active Directory® 2008 SR2 64 ბიტის DNS– ს გამოშვებას და პირდაპირ დაკვირვებას.

DNS მენეჯერის სურათები 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-ზე.

ბაზის ოპერაციული სისტემა

მე ამიგო ფუგელიგარდა იმისა, რომ Microsoft® Windows– ის ნამდვილი სპეციალისტია - მას აქვს ამ კომპანიის მიერ გაცემული რამდენიმე სერთიფიკატი - მან წაიკითხა და პრაქტიკაში გამოიყენა სტატიები კომპიუტერებზე გამოქვეყნებული FromLinux., და მან მითხრა, რომ მას აშკარად სურდა დებიანზე დაფუძნებული გადაწყვეტა. 😉

გთხოვთ, მოგახსენოთ სერვერის ახალი, სუფთა ინსტალაცია დებიანი 8 "ჯესი". ამასთან, ის, რასაც ქვემოთ დავწერთ, მოქმედებს CentOS და openSUSE დისტრიბუციისთვის, რომელთა სტატიები ადრე ვახსენეთ. BIND და DHCP ერთნაირია ნებისმიერ დისტროში. პაკეტების შემნახველების მიერ მცირე განაწილებები შემოდის თითოეულ განაწილებაში.

ჩვენ გავაკეთებთ ინსტალაციას, როგორც ეს მითითებულია DNS და DHCP Debian 8 "Jessie" - ში, ზრუნვა IP- ს გამოყენებაზე 10.10.10.5 და ქსელი 10.10.10.0/24., BIND- ის კონფიგურაციამდეც კი.

ჩვენ ვადგენთ BIND– ს დებიანის სტილში

/და ა.შ./სავალდებულო/დასახელებული.conf

ფაილი /და ა.შ./სავალდებულო/დასახელებული.conf ჩვენ დავტოვებთ მას, როგორც ის დაინსტალირებულია.

/etc/bind/named.conf.options

ფაილი /etc/bind/named.conf.options უნდა დარჩეს შემდეგი შინაარსით:

root @ dnslinux: ~ # cp /etc/bind/named.conf.options /etc/bind/named.conf.options.original

root @ dnslinux: n # nano /etc/bind/named.conf.options
პარამეტრები {დირექტორია "/ var / cache / bind"; // თუ თქვენსსა და სახელთა სერვერებს შორის არის firewall, რომელთანაც გსურთ // საუბარი, შეიძლება დაგჭირდეთ Firewall– ის დაფიქსირება, რათა მრავალი // პორტი ისაუბროთ. იხილეთ http://www.kb.cert.org/vuls/id/800113 // თუ თქვენსმა ISP- მ მოგვაწოდა ერთი ან მეტი IP მისამართი სტაბილური // სახელების სერვერებისთვის, თქვენ ალბათ გსურთ გამოიყენოთ ისინი, როგორც გადაგზავნილები. // გააუქმეთ კომენტარი შემდეგ ბლოკს და ჩასვით მისამართები, რომლებიც შეცვლის // ყველა 0-ს ჩანაცვლების ნიშანს. // ექსპედიტორი {// 0.0.0.0; //}; // =============================================== ======================= $ // თუ BIND აღრიცხავს შეცდომის შეტყობინებებს ძირეული გასაღების ვადის ამოწურვის შესახებ, // თქვენ უნდა განაახლოთ თქვენი გასაღებები. იხილეთ https://www.isc.org/bind-keys // ================================== ====================================== $

    // ჩვენ არ გვინდა DNSSEC
        dnssec- ჩართვა არა;
        //dnssec- ვალიდაციის ავტომატიზაცია;

        auth-nxdomain არა; # შეესაბამება RFC1035

 // ჩვენ არ გვჭირდება IPv6 მისამართების მოსმენა
        // მოსმენა- on-v6 {ნებისმიერი; };
    listen-on-v6 {არცერთი; };

 // localhost- ისა და sysadmin- ის შემოწმებისთვის
    // მეშვეობით // mordor.fan axfr // dig 10.10.10.in-addr.arpa axfr // dig _msdcs.mordor.fan axfr // ჩვენ არ გვაქვს Slave DNS ... აქამდე
 დაუშვას-გადარიცხვა {localhost; 10.10.10.1; };
};

// შესვლა BIND
შესვლა {

        არხის მოთხოვნები {
        ფაილი "/var/log/named/queries.log" ვერსიები 3 ზომა 1 მ;
        სიმძიმის ინფორმაცია;
        ბეჭდვის დრო დიახ;
        ბეჭდვის სიმძიმის დიახ;
        ბეჭდვითი კატეგორიის დიახ;
        };

        არხის მოთხოვნის შეცდომა {
        ფაილი "/var/log/named/query-error.log" ვერსიები 3 ზომა 1 მ;
        სიმძიმის ინფორმაცია;
        ბეჭდვის დრო დიახ;
        ბეჭდვის სიმძიმის დიახ;
        ბეჭდვითი კატეგორიის დიახ;
        };

                                
კატეგორიის მოთხოვნები {
         მოთხოვნები;
         };

კატეგორიის მოთხოვნა-შეცდომები {
         მოთხოვნა-შეცდომა;
         };

};

• ჩვენ წარმოგიდგენთ BIND ჟურნალების აღებას, როგორც NEW ამ თემაზე სტატიების სერიაში გამოჩენა. ჩვენ ვქმნით ლსაქაღალდე და ფაილები ხე BIND– ის:

root @ dnslinux: ~ # mkdir / var / log / დაასახელა
root @ dnslinux: ~ # touch /var/log/named/queries.log
root @ dnslinux: ~ # touch /var/log/named/query-error.log
root @ dnslinux: ~ # chown -R bind: bind / var / log / დასახელებულია

ჩვენ ვამოწმებთ კონფიგურირებული ფაილების სინტაქსს

root @ dnslinux: ~ # names-checkconf 
root @ dnslinux: ~ #

/და ა.შ./სავალდებულო/დასახელებული. კონფ. ლოკალური

ჩვენ ვქმნით ფაილს /etc/bind/zones.rfcFreeBSD იგივე შინაარსით, როგორც მითითებულია DNS და DHCP Debian 8 "Jessie" - ში.

root @ dnslinux: n # nano /etc/bind/zones.rfcFreeBSD

ფაილი /და ა.შ./სავალდებულო/დასახელებული. კონფ. ლოკალური უნდა დარჩეს შემდეგი შინაარსით:

// // აქ გააკეთეთ რაიმე ადგილობრივი კონფიგურაცია // // გაითვალისწინეთ აქ 1918 წლის ზონების დამატება, თუ ისინი არ გამოიყენება თქვენს // ორგანიზაციაში
მოიცავს "/etc/bind/zones.rfc1918"; მოიცავს "/etc/bind/zones.rfcFreeBSD";

ზონა "mordor.fan" {ტიპის ოსტატი; ფაილი "/var/lib/bind/db.mordor.fan"; }; ზონა "10.10.10.in-addr.arpa" {ტიპის სამაგისტრო; ფაილი "/var/lib/bind/db.10.10.10.in-addr.arpa"; };

ზონა "_msdcs.mordor.fan" {ტიპის ოსტატი;
 გამშვები სახელების იგნორირება; ფაილი "/etc/bind/db._msdcs.mordor.fan"; }; root @ dnslinux: ~ # names-checkconf
root @ dnslinux: ~ #

ზონის ფაილი mordor.fan

root @ dnslinux: ~ # ნანო /var/lib/bind/db.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; სერიული 1D; განახლება 1H; ცადეთ 1W; ვადა ამოიწურა 3H); მინიმალური ან; ნეგატიური ქეშირების დრო საცხოვრებლად;
; იყავით ძალიან ფრთხილად შემდეგი ჩანაწერებით
@ NS dnslinux.mordor.fan.
@ 10.10.10.5
@ IN MX 10 blackelf.mordor.fan. @ IN TXT "კეთილი იყოს თქვენი მობრძანება მორდორის ბნელ ქსელში";
_msdcs.mordor.fan. NS- ში dnslinux.mordor.fan.
;
dnslinux.mordor.fan. 10.10.10.5-ში
; ძალიან ფრთხილად დაასრულეთ შემდეგი ჩანაწერები;
DomainDnsZones.mordor.fan. In 10.10.10.3 ForestDnsZones.mordor.fan. In 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._tcp.mordor.fan შეცვლილი და კერძო LDAP. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. ; ; აქტიური დირექტორიის _kerberos._tcp.Default-First-Site-Same-Name._sites.mordor.fan შეცვლილი და პირადი KERBEROS. 600 IN SRV 0 0 88 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 600 IN SRV 0 0 88 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 600 IN SRV 0 0 464 sauron.mordor.fan. _kerberos._udp.mordor.fan. 600 IN SRV 0 0 88 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 600 IN SRV 0 0 464 sauron.mordor.fan. ; ; ფიქსირდება IP ფიქსირებული IP -> სერვერებით blackelf.mordor.fan. In 10.10.10.9 blackspider.mordor.fan. 10.10.10.10-ში darklord.mordor.fan. In 10.10.10.6 mamba.mordor.fan. In 10.10.10.4 palantir.mordor.fan. 10.10.10.11 წელს
sauron.mordor.fan. 10.10.10.3-ში
shadowftp.mordor.fan. 10.10.10.8 ტროლში. Mordor.fan. In 10.10.10.7; ; CNAME აღრიცხავს ad-dc.mordor.fan. IN CNAME sauron.mordor.fan- ში. ბლოგი.mordor.fan. IN CNAME troll.mordor.fan. ფაილების სერვერი .ordor.fan. IN CNAME mamba.mordor.fan. ftpserver.mordor.fan. IN CNAME shadowftp.mordor.fan. ფოსტა. წესრიგი. ფან. IN CNAME balckelf.mordor.fan. ღია ცეცხლი. წესრიგი. ფან. CNAME– ში palantir.mordor.fan. მარიონეტული .ordord.fan. CNAME- ში darklord.mordor.fan. www.mordor.fan. IN CNAME blackspider.mordor.fan.

root @ dnslinux: ~ # names-checkzone mordor.fan /var/lib/bind/db.mordor.fan 
ზონა mordor.fan/IN: დატვირთული სერიალი 1 კარგი

Დროება 600 TTL ყველა SRV რეგისტრიდან ჩვენ ვინახავთ მათ იმ შემთხვევაში, თუ Slave BIND- ს დავაყენებთ შემდეგ დროში. ეს ჩანაწერები წარმოადგენს Active Directory® სერვისებს, რომლებიც ძირითადად კითხულობენ მონაცემებს თქვენი LDAP მონაცემთა ბაზიდან. მას შემდეგ, რაც ეს მონაცემთა ბაზა ხშირად იცვლება, სინქრონიზაციის დრო მოკლედ უნდა იყოს შედგენილი, Master - Slave DNS სქემაში. Microsoft– ის ფილოსოფიის თანახმად, რომელიც Active Directory 2000– დან 2008 წლამდე შეინიშნებოდა, ამ ტიპის SRV ჩანაწერებისათვის შენარჩუნებულია 600 მნიშვნელობა.

L TTL ფიქსირებული IP სერვერებიდან, ისინი გამოცხადებულ დროში არიან SOA– ს 3 საათში.

ზონის ფაილი 10.10.10.in-addr.arpa

root @ dnslinux: ~ # ნანო /var/lib/bind/db.10.10.10.in- ადდრ.არპაში
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; სერიული 1D; განახლება 1H; ცადეთ 1W; ვადა ამოიწურება 3H); მინიმალური ან; ნეგატიური ქეშირების დრო საცხოვრებლად; @ NS dnslinux.mordor.fan. ; 10 IN PTR blackspider.mordor.fan. 11 IN PTR palantir.mordor.fan. 3 IN PTR sauron.mordor.fan. 4 IN PTR mamba.mordor.fan. 5 IN PTR dnslinux.mordor.fan. 6 IN PTR darklord.mordor.fan. 7 IN PTR troll.mordor.fan. 8 IN PTR shadowftp.mordor.fan. 9 IN PTR blackelf.mordor.fan.

root @ dnslinux: ~ # names-checkzone 10.10.10.in-addr.arpa /var/lib/bind/db.10.10.10.in-addr.arpa 
ზონა 10.10.10.in-addr.arpa/IN: დატვირთული სერიალი 1 კარგი

ზონის ფაილი _msdcs.mordor.fan

მოდით გავითვალისწინოთ ის, რაც რეკომენდებულია ფაილში /usr/share/doc/bind9/README.Debian.gz სამაგისტრო ზონების ფაილების ადგილმდებარეობის შესახებ, რომლებიც არ ექვემდებარება DHCP დინამიკურ განახლებას.

root @ dnslinux: n # nano /etc/bind/db._msdcs.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; სერიული 1D; განახლება 1H; ცადეთ 1W; ვადა ამოიწურება 3H); მინიმალური ან; ნეგატიური ქეშირების დრო საცხოვრებლად; @ NS dnslinux.mordor.fan. ; ; ; გლობალური კატალოგი gc._msdcs.mordor.fan. 600 IN 10.10.10.3; ; მეტსახელები - აქტიური დირექტორიის LDAP– ის შეცვლილ და კერძო მონაცემთა ბაზაში– SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 IN CNAME sauron.mordor.fan. ; ; შეცვლილია და ხდება პირადი LDAP აქტიური დირექტორიის _ldap._tcp.Default-First-Site-Same-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. ; ; KERBEROS შეცვლილია და პირადია აქტიური დირექტორიიდან _kerberos._tcp.Default-First-Site-Same-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan.

ჩვენ ვამოწმებთ სინტაქსს და შეგვიძლია უგულებელვყოთ ის შეცდომა, რომელიც მას უბრუნებს, ვინაიდან ფაილის ამ ზონის კონფიგურაციაში /და ა.შ./სავალდებულო/დასახელებული. კონფ. ლოკალური ჩვენ მოიცავს განცხადებას გამშვები სახელების იგნორირება;. ზონა სწორად ჩაიტვირთება 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 OK

root @ dnslinux: ~ # systemctl გადატვირთეთ bind9.service 
root @ dnslinux: ~ # systemctl სტატუსი bind9.service 
9. bind9.service - BIND დომენის სახელის სერვერი ჩატვირთულია: დატვირთულია (/lib/systemd/system/bind9.service; ჩართულია) Drop-In: /run/systemd/generator/bind50.service.d └─XNUMX-insserv.conf- $ names.conf აქტიურია: აქტიური (გაშვებული) მზედან 2017-02-12 08:48:38 EST; 2 წამის წინ Docs: კაცი: დაასახელა (8) პროცესი: 859 ExecStop = / usr / sbin / rndc შეჩერება (კოდი = გამოვიდა, სტატუსი = 0 / წარმატება) მთავარი PID: 864 (დასახელებული) CG ჯგუფი: /system.slice/bind9.service 864 / usr / sbin / named -f -u bind 12 თებერვალი 08:48:38 dnslinux დაასახელა [864]: ზონა 3.efip6.arpa/IN: დატვირთულია სერიალი 1 თებერვალი 12 08:48:38 dnslinux დაასახელა [864 ]: zone befip6.arpa/IN: დატვირთულია სერიალი 1 თებერვალი 12 08:48:38 dnslinux დაასახელა [864]: zone 0.efip6.arpa/IN: დატვირთულია სერიალი 1 თებერვალი 12 08:48:38 dnslinux დაასახელა [864]: ზონა 7.efip6.arpa/IN: დატვირთულია სერიალი 1 თებერვალი 12 08:48:38 dnslinux დაასახელა [864]: zone mordor.fan/IN: დატვირთულია სერიალი 1 თებერვალი 12 08:48:38 dnslinux დაასახელა [864]: ზონის მაგალითი .org / IN: დატვირთულია სერიალი 1 თებერვალი 12 08:48:38 dnslinux დაასახელა [864]: zone _msdcs.mordor.fan/IN: დატვირთულია სერიალი 1 თებერვალი 12 08:48:38 dnslinux დაასახელა [864]: ზონა არასწორია / IN : ჩაიტვირთა სერიალი 1 თებერვალი 12 08:48:38 dnslinux დაასახელა [864]: ყველა ზონა დატვირთულია
თებერვალი 12 08:48:38 dnslinux დაასახელა [864]: გაშვებული

ჩვენ ვურჩევთ BIND- ს

სანამ DHCP ინსტალაციის შემდეგ, ჩვენ უნდა შევასრულოთ მთელი რიგი შემოწმებები, რაც მოიცავს Windows 7 კლიენტის დომენში შესვლასაც კი მორდო.ფან წარმოდგენილია კომპიუტერში დაინსტალირებული Active Directory საურონი. მორდორ.ფან.

პირველი, რაც უნდა გააკეთოთ, შეაჩეროს DNS სერვისი კომპიუტერზე საურონი. მორდორ.ფანდა განაცხადეთ თქვენი ქსელის ინტერფეისში, რომ ამიერიდან თქვენი DNS სერვერი იქნება 10.10.10.5 dnslinux.mordor.fan.

თვით სერვერის კონსოლში საურონი. მორდორ.ფან ჩვენ ვასრულებთ:

Microsoft Windows [ვერსია 6.1.7600]
საავტორო უფლებები (გ) 2009 Microsoft Corporation. Ყველა უფლება დაცულია.

C: \ მომხმარებლები \ ადმინისტრატორი> 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

> მორდო.ფან
სერვერი: 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 სვრ ჰოსტის სახელი = 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 წონა = 100 პორტი = 389 svr ჰოსტის სახელი = 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: \ მომხმარებლები \ ადმინისტრატორი>

DNS მოთხოვნებისგან საურონი. მორდორ.ფან დამაკმაყოფილებელია.

შემდეგი ნაბიჯი იქნება სხვა ვირტუალური მანქანის შექმნა Windows 7-ით დაინსტალირებული. რადგან ჯერ კიდევ არ გვაქვს DHCP სერვისი დაინსტალირებული, კომპიუტერს მივცემთ სახელწოდებით «win7»IP მისამართი 10.10.10.251. ჩვენ ასევე ვაცხადებთ, რომ თქვენი DNS სერვერი იქნება 10.10.10.5 dnslinux.mordor.fan, და რომ საძიებო დომენი იქნება მორდო.ფან. ჩვენ ამ კომპიუტერს არ დავარეგისტრირებთ DNS- ში, რადგან მას ასევე გამოვიყენებთ DHCP სერვისის შესამოწმებლად, მისი ინსტალაციის შემდეგ.

შემდეგ ჩვენ ვხსნით კონსოლს CMD და მასში ჩვენ ვასრულებთ:

Microsoft Windows [ვერსია 6.1.7601]
საავტორო უფლებები (გ) 2009 Microsoft Corporation. Ყველა უფლება დაცულია.

C: \ მომხმარებლები \ buzz> nslookup
ნაგულისხმევი სერვერი: dnslinux.mordor.fan მისამართი: 10.10.10.5

> მორდო.ფან
სერვერი: 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 ჰოსტის სახელი = 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- პირველი საიტის სახელი. _sites.ForestDnsZones
სერვერი: dnslinux.mordor.fan მისამართი: 10.10.10.5 _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.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
> გასვლა

C: \ მომხმარებლები \ buzz>

კლიენტისგან გაკეთებული DNS მოთხოვნები «win7»ასევე დამაკმაყოფილებელი იყო.

აქტიურ დირექტორიაში ჩვენ ვქმნით მომხმარებელს «სარუმანი«, კლიენტში შესვლისას მისი გამოყენების მიზნით win7 დომენში მორდო.ფან., მეთოდის გამოყენებით «ქსელის ID«, მომხმარებლის სახელების გამოყენება saruman@mordor.fan y administrator@mordor.fan. გაწევრიანება წარმატებით დასრულდა და დასტურდება შემდეგი სკრინშოტით:

დინამიური განახლებების შესახებ Microsoft® DNS- სა და BIND- ში

რადგან DNS სერვისი შეჩერებულია Active Directory®- ში, ეს კლიენტისთვის შეუძლებელი იყო «win7»დარეგისტრირეთ თქვენი სახელი და IP მისამართი ამ DNS– ში. გაცილებით ნაკლებია dnslinux.mordor.fan ვინაიდან ჩვენ არანაირი განცხადება არ გაგვიკეთებია დაშვება-განახლება ჩართული ნებისმიერი სფეროსთვის.

და სწორედ აქ ჩამოყალიბდა კარგი ბრძოლა ჩემს მეგობართან ფუგელი. ჩემს პირველ წერილში ამ ასპექტის შესახებ კომენტარი გავაკეთე:

• Microsoft– ის სტატიებში BIND– ისა და Active Directory recommend– ის გამოყენების შესახებ ისინი რეკომენდაციას უწევენ, განსაკუთრებით პირდაპირი ზონის განახლებას.პენტრადა- პირდაპირ Windows კლიენტების მიერ, რომლებიც უკვე შეუერთდნენ Active Directory დომენს.
• ამიტომ, ნაგულისხმევად, ნებადართულია Active Directory® უსაფრთხო დინამიკური განახლებების DNS ზონებში Windows– ის კლიენტებმა უკვე შეუერთდნენ Active Directory დომენს. თუ ისინი ერთიანნი არ არიან, თავს იკავებენ შედეგებისგან.
• აქტიური დირექტორიის DNS მხარს უჭერს დინამიკურ განახლებებს "მხოლოდ უსაფრთხო", "არასაიმედო და უსაფრთხო" ან "არცერთი", რაც იგივეა, თუ არა უახლესი ინფორმაცია და არცერთი.
• Დიახ მართლა Microsoft- ის ფილოსოფია არ ეთანხმება, რომ მისი მომხმარებლები არ განაახლებენ თავიანთ მონაცემებს DNS (ებში), ეს არ დატოვებს დინამიური განახლებების გამორთვის შესაძლებლობას მათ DNS (ებში), თუ ეს ვარიანტი არ არის დარჩება უფრო ფარული მიზნებისთვის.
• Microsoft გთავაზობთ "უსაფრთხოებას" Darkness- ის სანაცვლოდ, როგორც მითხრეს კოლეგამ და მეგობარმა, რომელმაც გაიარა Microsft® სერთიფიკატების კურსები. მართალია. გარდა ამისა, El Fueguino- მ დამიდასტურა.
• კლიენტი, რომელიც იძენს IP მისამართს, მაგალითად, UNIX® / Linux აპარატზე დაინსტალირებული DHCP საშუალებით, ვერ შეძლებს საკუთარი სახელის IP მისამართის მოგვარებას სანამ არ შეუერთდებით Active Directory დომენს, სანამ Microsoft® ან BIND გამოიყენება როგორც DNS DHCP– დან დინამიური განახლებების გარეშე.
• თუ DHCP დავაყენებ Active Directory®– ში, მაშინ უნდა განვაცხადო, რომ ზონები განახლებულია Microsoft® DHCP– ის მიერ.
• თუ ჩვენ ვიყენებთ BIND- ს, როგორც Windows ქსელის DNS- ს, ლოგიკურია და გირჩევთ, რომ დავაინსტალიროთ BIND-DHCP დუეტი, ამ უკანასკნელმა დინამიურად განაახლოს BIND და დასრულდეს საკითხი.
• LANIX ქსელში UNIX® / Linux– ზე, რადგან BIND– ზე გამოიგონეს დინამიური განახლებები, მხოლოდ მისტერ DHCP არის დაშვებულიშეღწევა»ქალბატონ BIND– ს თავისი განახლებებით. დასვენება, რომელიც წესრიგშია, გთხოვთ.
• როცა ზონაში ვაცხადებ მორდო.ფან მაგალითად: დაშვება-განახლება {10.10.10.0/24; };, BIND თვითონ მაცნობს, როდესაც იგი იწყება ან გადატვირთეთ, რომ:

  • ზონა 'mordor.fan' საშუალებას იძლევა განახლდეს IP მისამართი, რომელიც არ არის უსაფრთხო

• საკრალურ UNIX Linux / Linux სამყაროში DNS– ის ასეთი საზრიანი დაუშვებელია.

თქვენ წარმოიდგინეთ გაცვლის დანარჩენი ნაწილი ჩემს მეგობართან ფუგელი მეშვეობით ელექტრონული ფოსტის, Telegram ჩატი, მის მიერ გადახდილი სატელეფონო ზარები (რა თქმა უნდა კაცო, ამისთვის კილო არ მაქვს) და შეტყობინებებიც კი XXI საუკუნის გადამზიდავი მტრედების საშუალებით!

ის კი იმუქრებოდა, რომ არ გამომიგზავნებოდი მისი შინაური ცხოველის შვილი, მისი იგუანა «Petra»რომ მან შემპირდა, როგორც გადახდის ნაწილი. იქ ნამდვილად შემეშინდა. ასე რომ, თავიდან დავიწყე, მაგრამ სხვა კუთხით.

• ”თითქმის” აქტიური დირექტორია, რომლის მიღწევა Samba 4-ით შესაძლებელია, ოსტატურად წყვეტს ამ ასპექტს, როგორც მის შიდა DNS- ს, ან DLZ ზონების მხარდასაჭერად შედგენილი BIND - დინამიკის დატვირთული ზონები, ან დინამიურად დატვირთული ზონები.
• იგი კვლავ აწუხებს იგივე: როდესაც კლიენტი იძენს IP მისამართს DHCP– ის საშუალებით, რომელიც დაინსტალირებულია სხვა UNIX® / Linux მანქანა, თქვენ ვერ შეძლებთ თქვენი საკუთარი სახელის IP მისამართის მოგვარებას სანამ ის Samba 4 AD-DC დომენს არ შეუერთდება.
• ინტეგრირება BIND-DLZ და DHCP დუეტზე იმავე აპარატზე, სადაც AD-DC სამბა 4 ეს სამუშაოა ნამდვილი სპეციალისტისთვის.

ფუგელი მან თავისკენ მიმიწოდა და მიყვირა: ჩვენ ამაზე არ ვსაუბრობთ AD-DC სამბა 4, მაგრამ Microsoft® Active Directory®! მე თავმდაბლურად ვუპასუხე, რომ აღფრთოვანებული ვარ შემდეგი სტატიების ნაწილით, რომლის დაწერასაც ვაპირებდი.

ამ დროს მას ვუთხარი, რომ საბოლოო გადაწყვეტილება კლიენტ კომპიუტერებზე დინამიური განახლებების შესახებ მის ქსელში, დარჩა მის თავისუფალ ნებაზე. რომ მე მხოლოდ მას მივცემდი tip ადრე დაწერილი დაახლოებით დაშვება-განახლება {10.10.10.0/24; };და მეტი არაფერი. რომ მე არ ვიყავი პასუხისმგებელი იმაზე, თუ რა შედეგი მოჰყვა ამ უძლურებას, რომ თითოეული Windows კლიენტი - ან Linux - თავის ქსელშიშეაღწევს»BIND– ს დაუსჯელად.

რომ იცოდე, ჩემო მეგობარო, მკითხველო, რომ ეს იყო ჩხუბის ბოლო წერტილი, არ დაიჯერებდი ამას. Ჩემი მეგობარი ფუგელი მან მიიღო გამოსავალი - და ის გამომიგზავნის იგუანას «პეტრიკა«- რომ ახლა მე გაგიზიარებ.

ჩვენ ვაყენებთ და ვაყენებთ კონფიგურაციას DHCP

დამატებითი ინფორმაციისთვის წაიკითხეთ DNS და DHCP Debian 8 "Jessie" - ში.

root @ dnslinux: ~ # შესაძლებლობის ინსტალაცია isc-dhcp- სერვერი

root @ dnslinux: ~ # nano / etc / default / isc-dhcp-server .... # რა ინტერფეისებზე უნდა ემსახურებოდეს DHCP სერვერი (dhcpd) DHCP მოთხოვნებს? # გამოყავით მრავალი ინტერფეისი ინტერვალებით, მაგ. "Eth0 eth1". ინტერფეისი = "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. კერძო
პირადი გასაღების ფორმატი: v1.3 ალგორითმი: 157 (HMAC_MD5) გასაღები: 3HT / bg / 6YwezUShKYofj5g == ბიტი: AAA = შექმნილი: 20170212205030 გამოქვეყნება: 20170212205030 გააქტიურება: 20170212205030

root @ dnslinux: ~ # nano dhcp.key
გასაღები dhcp-key {ალგორითმი 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

root @ dnslinux: ~ # nano /etc/bind/named.conf.local
// // აქ რაიმე ადგილობრივი კონფიგურაციის გაკეთება მოიცავს "/etc/bind/zones.rfcFreeBSD";
// არ დაგავიწყდეს ... დამავიწყდა და შეცდომებით გადავიხადე. ;-)
მოიცავს "/etc/bind/dhcp.key";


ზონა "mordor.fan" {ტიპის ოსტატი;
        დაშვება-განახლება {10.10.10.3; გასაღები dhcp- გასაღები; };
        ფაილი "/var/lib/bind/db.mordor.fan"; }; ზონა "10.10.10.in-addr.arpa" {ტიპის სამაგისტრო;
        დაშვება-განახლება {10.10.10.3; გასაღები dhcp- გასაღები; };
        ფაილი "/var/lib/bind/db.10.10.10.in-addr.arpa"; }; ზონა "_msdcs.mordor.fan" {ტიპის ოსტატი; გამშვები სახელების იგნორირება; ფაილი "/etc/bind/db._msdcs.mordor.fan"; };

root @ dnslinux: ~ # names-checkconf 
root @ dnslinux: ~ #

root @ dnslinux: ~ # nano /etc/dhcp/dhcpd.conf
ddns- განახლების სტილის შუალედური; ddns- განახლებები ჩართულია; ddns- დომენის სახელი "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; კლიენტის განახლების იგნორირება; ავტორიტეტული; ვარიანტი ip- გადამისამართება გამორთულია; დომენის სახელი "mordor.fan"; მოიცავს "/etc/dhcp/dhcp.key"; ზონის მორდო. ფან. {პირველადი 127.0.0.1; გასაღები dhcp- გასაღები; } ზონა 10.10.10.addr.arpa- ში. {პირველადი 127.0.0.1; გასაღები dhcp- გასაღები; } shared-network redlocal {subnet 10.10.10.0 netmask 255.255.255.0 {option router 10.10.10.1; ვარიანტი subnet-mask 255.255.255.0; ვარიანტი სამაუწყებლო-მისამართი 10.10.10.255; ვარიანტი domain-name-servers 10.10.10.5; ვარიანტი netbios-name-servers 10.10.10.5; დიაპაზონი 10.10.10.30 10.10.10.250; }} # END dhcpd.conf

root @ dnslinux: dh # dhcpd -t
ინტერნეტ სისტემების კონსორციუმი DHCP სერვერი 4.3.1 საავტორო უფლებები 2004-2014 ინტერნეტ სისტემების კონსორციუმი. Ყველა უფლება დაცულია. ინფორმაციისთვის ეწვიეთ https://www.isc.org/software/dhcp/ ფაილის კონფიგურაცია: /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 დაწყება isc-dhcp-server.service
root @ dnslinux: ~ # systemctl სტატუსი isc-dhcp-server.service

რასთან არის დაკავშირებული ამოწმებს კლიენტებთანდა ზონის ფაილების ხელით მოდიფიკაცია, ჩვენ ვტოვებთ მას, მკითხველო მეგობარო, პირდაპირ წაკითხვისგან DNS და DHCP Debian 8 "Jessie" - შიდა გამოიყენეთ იგი თქვენს რეალურ პირობებზე. ჩვენ ჩავატარეთ ყველა საჭირო შემოწმება და მივიღეთ დამაკმაყოფილებელი შედეგები. რა თქმა უნდა, ჩვენ ყველას ვუგზავნით ასლს ფუგელი. აღარ იქნება!

რჩევები

ზოგადი

• მიიღეთ დიდი მოთმინება სანამ დაიწყებთ.
  
• პირველი დააინსტალირეთ და დააკონფიგურირეთ BIND. შეამოწმეთ ყველაფერი და იხილეთ ყველა ჩანაწერი, რომელიც თქვენ განაცხადეთ სამი ან მეტი ზონის თითოეულ ფაილში, როგორც აქტიური დირექტორიიდან, ასევე თავად DNS სერვერიდან Linux- ზე. თუ შესაძლებელია, Linux აპარატიდან, რომელიც არ არის შეერთებული დომენში, გააკეთეთ DNS მოთხოვნები BIND- ზე.
  
• შეუერთდით Windows კლიენტს ფიქსირებული IP მისამართით არსებულ დომენში და გადაამოწმეთ ყველა BIND პარამეტრი Windows კლიენტისგან.
• მას შემდეგ, რაც უეჭველად დარწმუნდებით, რომ თქვენი ახალი BIND- ის კონფიგურაცია სრულიად სწორია, წამოდით DHCP სერვისის ინსტალაციაზე, კონფიგურაციაში და დაიწყეთ.
• შეცდომების შემთხვევაში, გაიმეორეთ მთელი პროცედურა 0-დან.
• ფრთხილად იყავით ასლის და ჩასმა! და დამატებითი ადგილები names.conf.xxxx ფაილების თითოეულ სტრიქონში
  
• ამის შემდეგ, ის არ უჩიოდა - მითუმეტეს ჩემს მეგობარს ფუგიელს - რომ მას სათანადოდ არ ურჩიეს.

სხვა რჩევები

• Დაყავი და იბატონე.
• მცირე და საშუალო ბიზნესის ქსელში უფრო უსაფრთხო და სასარგებლოა ავტორიტეტული BIND ინსტალაცია შიდა LAN ზონებისთვის, რომელიც არ განმეორდება არცერთ ძირეულ სერვერზე: რეკურსია არა;.
• მცირე და საშუალო ბიზნესის ქსელში, რომელიც განთავსებულია ინტერნეტის მიმწოდებლის ქვეშ - ISP, ალბათ, მომსახურება Proxy y SMTP მათ უნდა გადაწყვიტონ დომენური სახელების ინტერნეტი. ის Squid თქვენ გაქვთ შესაძლებლობა გამოაცხადოთ თქვენი DNS გარე ან არა, როდესაც ფოსტის სერვერზე ხართ postfix o MDaemon® ჩვენ ასევე შეგვიძლია გამოვაცხადოთ DNS სერვერები, რომლებსაც გამოვიყენებთ ამ სერვისში. ასეთ შემთხვევებში, ანუ ისეთ შემთხვევებში, რომლებიც არ უზრუნველყოფენ ინტერნეტის მომსახურებას და რომლებიც Ინტერნეტ სერვისის პროვაიდერი, შეგიძლიათ დააინსტალიროთ BIND ექსპედიტორები მიუთითებს DNS- ზე ISPდა გამოაცხადეთ იგი, როგორც მეორადი DNS სერვერებში, რომლებსაც სჭირდებათ გარე მოთხოვნების გადაჭრა LAN– ში, წინააღმდეგ შემთხვევაში მათი დეკლარაცია შესაძლებელია საკუთარი კონფიგურაციის ფაილების საშუალებით.
• თუ დელეგირებული ზონა გექნებათ მთელი თქვენი პასუხისმგებლობის ქვეშშემდეგ კიდევ ერთი მამალი ყვავილი:
  • დააინსტალირეთ DNS სერვერი NSD, რომელიც განსაზღვრული ავტორიტეტული DNS სერვერია, რომელიც პასუხობს ინტერნეტში არსებული კომპიუტერების მოთხოვნებს. გარკვეული ინფორმაციისთვის შესაძლებლობების ჩვენება nsd. Protect გთხოვთ, დაიცვას იგი ძალიან კარგად, რამდენიც საჭიროა ცეცხლის კედლით. ტექნიკა და პროგრამა. ეს იქნება DNS ინტერნეტისთვის და რომ «ხელმწიფის»დაბალი შარვალით არ უნდა მივცეთ. 😉
  • როგორც არასდროს მინახავს მსგავსი შემთხვევა, ანუ მთლად პასუხისმგებელი დელეგირებული ზონისთვის, ძალიან კარგად უნდა დავფიქრდე, რას ვურჩევ ჩვენს ქსელში გარე დომენური სახელების გადაჭრისთვის, რაც მათ სჭირდებათ. მცირე და საშუალო ბიზნესის ქსელის მომხმარებლებს ეს ნამდვილად არ სჭირდებათ. მიმართეთ სპეციალურ ლიტერატურას, ან ამ საგნების სპეციალისტს, რადგან შორს ვარ ერთ-ერთი მათგანი. სერიოზულად.
  • რეკურსია არ არსებობს ავტორიტარულ სერვერებზე. Კარგი?. იმ შემთხვევაში, თუ ვინმე ფიქრობს ამის გაკეთება BIND- ით.
• მიუხედავად იმისა, რომ ჩვენ პირდაპირ მიუთითეთ ფაილი /და ა.შ.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 კლიენტის სერიოზულ და გიჟურ მოთხოვნებს, გადახედეთ აქ შესვლა მოთხოვნები. ბლოგი რომ ამის გამო ჩვენ ვაცხადებთ მას BIND კონფიგურაციაში. შეკვეთა იქნება:

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

• თუ თქვენს კლიენტ კომპიუტერებს არ დაუშვებთ პირდაპირ ინტერნეტთან დაკავშირების საშუალებას, რატომ გჭირდებათ Root DNS სერვერები? ეს მნიშვნელოვნად შეამცირებს ბრძანების გამომუშავებას journalctl -f და წინადან, თუ თქვენი ავტორიტარული DNS სერვერი შიდა ზონებისთვის პირდაპირ არ უკავშირდება ინტერნეტს, რაც უსაფრთხოების თვალსაზრისით რეკომენდებულია.

  root @ dnslinux: ~ # cp /etc/bind/db.root /etc/bind/db.root.original
  root @ dnslinux: c # cp / dev / null /etc/bind/db.root

• თუ არ გჭირდებათ ძირეული სერვერების დეკლარაცია, რატომ გჭირდებათ რეკურსია - Recursion?

  root @ dnslinux: n # nano /etc/bind/named.conf.options
  პარამეტრები {
   ....
   რეკურსია არა;
   ....
  };

რომლის კონკრეტული რჩევა მე ჯერ კიდევ არ ვარ გასაგები

El კაცი dhcpd.conf ბევრ სხვა რამესთან ერთად შემდეგს გვეუბნება:

        განახლების ოპტიმიზაციის განცხადება

            განახლების ოპტიმიზაციის დროშა;

            თუ მოცემული კლიენტისთვის ცრუა განახლების ოპტიმიზაციის პარამეტრი, სერვერი შეეცდება DNS განახლებას ამ კლიენტისთვის, ყოველთვის, როდესაც კლიენტი განაახლებს საიჯარო ხელშეკრულებას, ვიდრე მხოლოდ შეეცდება განახლებას, როდესაც ეს საჭირო იქნება. ეს საშუალებას მისცემს DNS უფრო მარტივად განკურნოს მონაცემთა ბაზის შეუსაბამობებისაგან, მაგრამ ღირებულებაა, რომ DHCP სერვერმა უნდა გააკეთოს კიდევ ბევრი DNS განახლება. გირჩევთ წაიკითხოთ ეს პარამეტრი ჩართული, რაც ნაგულისხმევია. ეს ვარიანტი მოქმედებს მხოლოდ შუალედური DNS განახლების სქემის ქცევაზე და გავლენას არ ახდენს ad-hoc DNS განახლების სქემაზე. თუ ეს პარამეტრი მითითებული არ არის, ან სიმართლეა, DHCP სერვერი განახლდება მხოლოდ მაშინ, როდესაც კლიენტის ინფორმაცია შეიცვლება, კლიენტი მიიღებს სხვა იჯარას, ან კლიენტის საიჯარო ვადა იწურება.

მეტნაკლებად ზუსტი თარგმანი ან ინტერპრეტაცია დაგრჩათ თქვენ, ძვირფასო მკითხველო

პირადად მე დამემართა - და ეს მოხდა სტატიის მომზადების დროს - რომ BIND– ს ვუკავშირდები Active Directory®– ს, ეს არის Microsoftft®– დან ან Samba 4– დან, თუ Active Directory® დომენში რეგისტრირებული კლიენტის კომპიუტერის სახელს შევცვლი. ან AD–DC Samba 4 – ით ის ინახავს თავის ძველ სახელს და IP მისამართს პირდაპირ ზონაში და არა პირიქით, რომელიც სწორად არის განახლებული ახალი სახელით. სხვა სიტყვებით რომ ვთქვათ, ძველი და ახალი სახელები პირდაპირ ზონაში ასახულია იმავე IP მისამართზე, ხოლო პირიქით მხოლოდ ახალი სახელი ჩანს. რომ კარგად გამიგოთ, თავად უნდა სცადოთ.

ვფიქრობ, ეს ერთგვარი შურისძიებაა ფუგელი - არა ჩემთვის, გთხოვთ - თქვენი სერვისების Linux- ზე გადასვლის მცდელობისთვის.

რა თქმა უნდა, ძველი სახელი გაქრება 3600 TTL, ან დრო, რომელიც ჩვენ განვაცხადეთ DHCP კონფიგურაციაში. მაგრამ ჩვენ გვინდა, რომ ის მაშინვე გაქრეს, როგორც ეს ხდება BIND + DHCP- ში აქტიური დირექტორიის გარეშე.

ამ სიტუაციიდან გამოსავალი ვიპოვნე განცხადების ჩასმით განახლების ოპტიმიზაცია მცდარია; ფაილის ზედა ნაწილში დასასრულს /და ა.შ.dhcp/dhcpd.conf:

ddns- განახლების სტილის შუალედური; ddns- განახლებები ჩართულია; ddns- დომენის სახელი "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; კლიენტის განახლების იგნორირება;
განახლების ოპტიმიზაცია მცდარია;

თუ რომელიმე მკითხველმა უფრო მეტი იცის ამის შესახებ, გთხოვთ, გამანათლოთ. ამას ძალიან ვაფასებ.

რეზიუმე

ჩვენ ბევრი ვიხალისეთ ამ თემასთან დაკავშირებით, არა? არ იტანჯება, რადგან ჩვენ გვაქვს BIND, რომელიც მუშაობს Microsoft D ქსელში DNS სერვერზე, გთავაზობთ ყველა SRV ჩანაწერს და სათანადო რეაგირებას ახდენს მათზე გაკეთებულ DNS მოთხოვნებზე. მეორეს მხრივ, ჩვენ გვაქვს DHCP სერვერი, რომელიც ანიჭებს IP მისამართებს და დინამიურად განაახლებს BIND ზონებს.

მაგრამ ჩვენ არ შეგვიძლია ვკითხოთ ... მომენტალურად.

იმედი მაქვს ჩემი მეგობარი ფუგელი იყავი ბედნიერი და კმაყოფილი Linux- ში გადასვლის პირველი ნაბიჯით, რომ Microsoftft®– ის ტექნიკური დახმარების გაუსაძლისი ხარჯები გადაიტანოს.

მნიშვნელოვანი შენიშვნა

პერსონაჟი "ფუგელი»მთლიანად გამოგონილი და ჩემი წარმოსახვის პროდუქტია. ნებისმიერი მსგავსება ან დამთხვევა რეალურ ადამიანებთან იგივეა: ჩემი მხრიდან სუფთა უნებლიე დამთხვევა. მე მხოლოდ ის შევქმენი, რომ ამ სტატიის წერა და კითხვა ცოტათი სასიამოვნო გამხდარიყო. ახლა თუ შეგიძლია მითხრა რომ DNS საკითხი ბნელია.