სერიის ზოგადი ინდექსი: კომპიუტერული ქსელები მცირე და საშუალო ბიზნესისთვის: შესავალი
გამარჯობა მეგობრებო !. ამ სტატიაში ვნახავთ, თუ როგორ შეგვიძლია განვახორციელოთ სერვისების მნიშვნელოვანი წყვილი ქსელებისათვის, რომლებიც შექმნილია ქსელში DNS და DHCP CentOS– ზე - Linux, კონკრეტულად მის ვერსიაში 7.2.
- ზოგიერთ სტატიაში DNS ეხება იმ ფაქტს, რომ ამ სერვისის განხორციელება გარკვეულწილად ბუნდოვანი და რთულია. მე არ ვეთანხმები ამ განცხადებას. მირჩევნია ვთქვა, რომ ეს ცოტათი კონცეპტუალურია და რომ მის ბევრ კონფიგურაციის ფაილს აქვს რთული სინტაქსი. საბედნიეროდ, ჩვენ გვაქვს ინსტრუმენტები, რათა გადავამოწმოთ ეტაპობრივად თითოეული კონფიგურაციის ფაილის სინტაქსი, რომელსაც ვცვლით. ამიტომ, შევეცდებით ამ პოსტის კითხვა რაც შეიძლება სასიამოვნო და სასიამოვნო გავხადოთ..
მათთვის, ვინც ეძებს ორივე სერვისის საფუძვლებს, ჩვენ გირჩევთ დაიწყოთ ძიება Wikipedia- ზე, როგორც ესპანურ, ასევე ინგლისურ ვერსიებში. არანაკლებ მართალია, რომ ინგლისურენოვანი სტატიები თითქმის ყოველთვის უფრო სრულყოფილი და თანმიმდევრულია. მიუხედავად ამისა, ვიკიპედია არის ძალიან კარგი საწყისი წერტილი.
მათთვის, ვისაც ნამდვილად სურს გაეცნოს DNS და BIND– ს შესახებ, გირჩევთ წაიკითხოთ წიგნი «OReilly - DNS და BIND 4ed" დაწერილია პოლ ალბცი y კრიკეტი ლიუ, ან მოგვიანებით გამოცემა, რომელიც ნამდვილად არსებობს.
ჩვენ უკვე გამოვაქვეყნეთ სტატია თემაზე:DNS და DHCP in openSUSE 13.2 Harlequin - მცირე და საშუალო ბიზნესის ქსელები»გრაფიკული გარემოს მოყვარულთათვის. ამასთან, ამიერიდან მათ წააწყდებათ სტატიები ამ თემაზე - და არა სხვების შესახებ - დაწერილი ტერმინალის ან კონსოლის ემულატორის მრავალი გამოყენებისას. ვაი, კლასიკურ სტილში, რომელსაც იყენებენ UNIX® / Linux სისტემის ადმინისტრატორები.
თუ გსურთ გაიგოთ მეტი ამ სტატიის სათაურის გვარის შესახებმცირე და საშუალო ბიზნესის ქსელები»გვერდის მონახულება შეგიძლიათ ამ ბლოგში«მცირე და საშუალო ბიზნესის ქსელები: პირველი ვირტუალური ჭრა« მასში ნახავთ მრავალი სხვა გამოქვეყნებული სტატიის ბმულებს.
- CentOS 7 ოპერაციული სისტემის ინსტალაციის დასრულების შემდეგ, ჩვენ გირჩევთ პაკეტებს, el დირექტორია /usr/share/doc/bind-9.9.4/ შეიცავს უამრავ დოკუმენტაციას, რომლის გირჩევთ გაეცნოთ ინტერნეტის ძიებას, სანამ არ იცით, რომ თქვენს ხელთაა და საკუთარ სახლში შეგიძლიათ იპოვოთ ის, რასაც ეძებთ.
ინდექსი
- 1 ბაზის სისტემის ინსტალაცია
- 2 ჩვენ ვაყენებთ კონფიგურაციას BIND - დასახელებული
- 3 ჩვენ ვაყენებთ და ვაყენებთ კონფიგურაციას DHCP
- 4 რა რჩება გასაკეთებელი?
- 5 ზონების ფაილების ხელით მოდიფიკაცია
- 6 რეზიუმე
- 7 შემდეგი მიწოდება
ბაზის სისტემის ინსტალაცია
დომენისა და DNS სერვერის ზოგადი მონაცემები
დომენის სახელი: fromlinux.fan DNS სერვერის სახელი: dns.fromlinux.fan IP მისამართი: 192.168.10.5 ქვეტენის ნიღაბი: 255.255.255.0
მონტაჟი
ჩვენ ვიწყებთ CentOS 7 ოპერაციული სისტემის ახალი ან სუფთა ინსტალაციით, როგორც ეს მითითებულია წინა სტატიაში «CentOS 7 Hypervisor I - SMB ქსელები« საჭიროა მხოლოდ შემდეგი ცვლილებების შეტანა:
- In 22 სურათი «პროგრამული უზრუნველყოფის შერჩევა«, ჩვენ გირჩევთ აირჩიოთ მარცხენა სვეტში«ბაზის გარემო»ვარიანტი, რომელიც შეესაბამება«ინფრასტრუქტურის სერვერი«, მარჯვენა სვეტში ყოფნისას«დანამატები შერჩეული გარემოსთვის»მონიშნეთ ველიDNS სახელის სერვერი« მოგვიანებით დავაყენებთ DHCP სერვერს.
- გავიხსენოთ დამატებითი საცავების დეკლარაცია, როგორც ნაჩვენებია აქ 23 სურათი, დაყენების შემდეგ «ქსელი და გუნდის სახელი".
- სურათები, რომლებიც ეხება დანაყოფებს, რომლებსაც ჩვენს მყარ დისკზე შევქმნით, მხოლოდ სახელმძღვანელოდ არის მოცემული. თავისუფლად შეარჩიეთ დანაყოფები საკუთარი შეხედულებისამებრ, პრაქტიკისა და კარგი განსჯის საფუძველზე.
- დაბოლოს, სურათი 13 «NETWORK & TEAM NAME», ჩვენ უნდა შევცვალოთ მნიშვნელობები დომენისა და DNS სერვერის ზოგადი პარამეტრების შესაბამისად, არ დავივიწყოთ მასპინძლის სახელის მითითება - ამ შემთხვევაშიდნს«- ქსელის კონფიგურაციის დასრულების შემდეგ. პოზიტიურია ამის გაკეთება Ping ქსელის გააქტიურების შემდეგ - სხვა მასპინძელიდან - მითითებულ IP მისამართამდე:
მართლაც ცოტა და ძალიან აშკარა ცვლილებებია, რაც წინა სტატიასთან დაკავშირებით უნდა გავაკეთოთ.
საწყისი შემოწმება და კორექტირება
ოპერაციული სისტემის დაყენების შემდეგ, ჩვენ უნდა გადავხედოთ შემდეგ ფაილებს, და ამისათვის ჩვენ ვიწყებთ სესიას SSH– ის საშუალებით ჩვენი კომპიუტერიდან sysadmin.fromlinux.fan:
buzz @ sysadmin: ~ $ ssh 192.168.10.5 buzz@192.168.10.5 პაროლი: ბოლო შესვლა: შაბ 28 იანვარს 09:48:05 2017 წლიდან 192.168.10.1 [ზუზუნი @ დნს] $
ზემოხსენებული ოპერაცია შეიძლება ჩვეულებრივზე მეტხანს გაგრძელდეს და ეს ძირითადად განპირობებულია იმით, რომ ჩვენ ჯერ კიდევ არ გვაქვს DNS LAN- ზე. მოგვიანებით კვლავ შეამოწმეთ, რომ DNS მუშაობს.
[buzz @ dns] $ კატა / ა.შ. / მასპინძლები 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 :: 1 localhost localhost.localdomain localhost6 localhost6.localdomain6 [buzz @ dns] $ cat / etc / hostname დნს [buzz @ dns] $ cat / etc / sysconfig / ქსელის სკრიპტები / ifcfg-eth0 TYPE=Ethernet BOOTPROTO=none DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=no IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPV6_FAILURE_FATAL=no NAME=eth0 UUID=946f5ac9-238a-4a94-9acb-9e3458c680fe DEVICE=eth0 ONBOOT=yes IPADDR=192.168.10.5 PREFIX=24 GATEWAY=192.168.10.1 DNS1=127.0.0.1 DOMAIN=desdelinux.fan [buzz @ dns] $ კატა / და ა.შ. /resolv.conf # გენერირებულია NetworkManager- ის მიერ linux.fan nameserver- ის ძიებით 127.0.0.1
ძირითადი კონფიგურაციები პასუხობს ჩვენს არჩევანს. გაითვალისწინეთ, რომ სერვერზეც კი Red Hat 7 - CentOS 7, ნაგულისხმევად არის კონფიგურირებული როდის ქსელის მენეჯერი ისე, რომ ის მართავს ქსელის ინტერფეისებს, იქნება ეს სადენიანი ან უსადენო (WiFi), VPN კავშირი, PPPoE კავშირი და ნებისმიერი სხვა ქსელური კავშირი.
[buzz @ dns] $ sudo systemctl სტატუსის ქსელის მენეჯერი [sudo] პაროლი buzz- ისთვის: ● networkmanager.service დატვირთულია: ვერ მოიძებნა (მიზეზი: ასეთი ფაილი ან დირექტორია არ არის) აქტიური: არააქტიური (მკვდარი) [buzz @ dns] $ sudo systemctl სტატუსი NetworkManager ● NetworkManager.service - დატვირთულია ქსელის მენეჯერი: ჩატვირთულია (/usr/lib/systemd/system/NetworkManager.service; ჩართულია; გამყიდველის წინასწარ დაყენებული: ჩართულია) აქტიური: აქტიური (გაშვებული) შაბათიდან 2017-01-28 12:23:59 EST; 12 წთ-ის წინ მთავარი PID: 705 (NetworkManager) CGroup: /system.slice/NetworkManager.service └─705 / usr / sbin / NetworkManager - no-daemon
Red Hat - CentOS ასევე საშუალებას გაძლევთ დაუკავშირდეთ და გათიშოთ ქსელის ინტერფეისი კლასიკური ბრძანებების გამოყენებით თუკი e თუ ქვემოთ. მოდით გაუშვით სერვერის კონსოლზე:
[root @ dns] # ifdown eth0 მოწყობილობა 'eth0' წარმატებით გათიშულია. [root @ dns] # ifup eth0 კავშირი წარმატებით გააქტიურდა (D-Bus აქტიური გზა: / org / Freedesktop / NetworkManager / ActiveConnection / 1)
- ჩვენ გთავაზობთ ნუ შეცვლით ნაგულისხმევ პარამეტრებს, რომლებსაც გთავაზობთ CentOS 7 ქსელის მენეჯერი.
ჩვენ საბოლოოდ ვაცხადებთ საცავებს, რომელთა გამოყენებას ვაპირებთ და ოპერაციული სისტემის განახლებას საჭიროების შემთხვევაში:
[buzz @ dns] $ su პაროლი: [root @ dns buzz] # cd /etc/yum.repos.d/ [root @ dns yum.repos.d] # ლ-ლ სულ 28 -rw-r - r--. 1 ძირეული ფესვი 1664 დეკემბერი 9 2015 CentOS-Base.repo -rw-r - r--. 1 ძირეული ფესვი 1309 9 წლის 2015 დეკემბერი CentOS-CR.repo -rw-r - r--. 1 ძირეული ფესვი 649 დეკემბერი 9 2015 CentOS-Debuginfo.repo -rw-r - r--. 1 ძირეული ფესვი 290 9 წლის 2015 დეკემბერი CentOS-fasttrack.repo -rw-r - r--. 1 ძირეული ფესვი 630 დეკემბერი 9 2015 CentOS-Media.repo -rw-r - r--. 1 ძირეული ფესვი 1331 დეკემბერი 9 2015 CentOS-Sources.repo -rw-r - r--. 1 ძირეული ფესვი 1952 წლის 9 დეკემბერი 2015 CentOS-Vault.repo
ჯანსაღია CentOS– ის რეკომენდებული საცავებიდან ორიგინალი დეკლარაციის ფაილების შინაარსის წაკითხვა. ჩვენ მიერ განხორციელებული ცვლილებები გამოწვეულია იმით, რომ ინტერნეტი არ გვაქვს და ვთანამშრომლობთ WWW Village– დან გადმოწერილ ადგილობრივ საცავებთან კოლეგების მიერ, რომლებიც ჩვენს ცხოვრებას ცოტათი ამარტივებენ. 😉
[root @ dns yum.repos.d] # mkdir ორიგინალი [root @ dns yum.repos.d] # mv CentOS- * ორიგინალი / [root @ dns yum.repos.d] # nano centos-repos.repo [centos-base] name=CentOS-$releasever baseurl=http://10.10.10.1/repos/centos/7/base/ gpgcheck=0 enabled=1 [centos-updates] name=CentOS-$releasever baseurl=http://10.10.10.1/repos/centos/7/updates/x86_64/ gpgcheck=0 enabled=1 [root @ dns yum.repos.d] # yum ყველას გაწმენდა დატვირთული დანამატები: fastestmirror, langpacks დასუფთავების საცავები: centos-base centos- განახლებები ყველაფრის გასუფთავება [root @ dns yum.repos.d] # yum განახლება დატვირთული დანამატები: fastestmirror, centos-base langpacks | 3.4 კბ 00:00 სთ-ის განახლება | 3.4 კბ 00:00 (1/2): centos-base / პირველადი_დბ | 5.3 მბ 00:00 (2/2): centos-განახლებები / პირველადი_დბ | 9.1 MB 00:00 უსწრაფესი სარკეების განსაზღვრა განახლებების პაკეტები არ არის მითითებული
შეტყობინება «არა (არსებობს) განახლებული პაკეტები» - «განახლებისთვის არ არის მითითებული პაკეტები»მიუთითებს იმაზე, რომ ინსტალაციის დროს ჩვენთვის ყველაზე განახლებული საცავების გამოცხადებით დაინსტალირდა ზუსტად ყველაზე მიმდინარე პაკეტები.
SELinux კონტექსტისა და Firewall– ის შესახებ
ჩვენ ვაპირებთ ამ სტატიის ფოკუსირებას DNS და DHCP სერვისების განხორციელებაზე, რაც მისი მთავარი მიზანია.
თუ რომელიმე მკითხველმა ინსტალაციის პროცესში აირჩია უსაფრთხოების პოლიტიკა, როგორც მითითებულია აქ 06 სურათი საცნობარო სტატიის «CentOS 7 Hypervisor I - SMB ქსელები»გამოიყენება ამ DNS - DHCP სერვერის ინსტალაციისთვის და თქვენ აღმოაჩენთ, რომ არ იცით SELinux– ისა და CentOS Firewall– ის სწორად კონფიგურაცია, გთავაზობთ შემდეგს აწარმოოთ:
შეცვალეთ ფაილი / etc / sysconfig / selinux და შეიცვალა SELINUX = აღსრულება მიერ SELINUX = გამორთე
[root @ dns] # nano / etc / sysconfig / selinux # ეს ფაილი აკონტროლებს SELinux– ის მდგომარეობას სისტემაში. # SELINUX = შეუძლია მიიღოს ამ სამი მნიშვნელობიდან ერთი: # აღსრულება - SELinux უსაფრთხოების პოლიტიკა ხორციელდება. # ნებადართული - SELinux იძენს გაფრთხილებებს აღსრულების ნაცვლად. # გამორთულია - SELinux პოლიტიკა არ არის ჩატვირთული. SELINUX = გამორთულია # SELINUXTYPE = შეიძლება სამი ორიდან ერთის აღება: # მიზნობრივი - მიზნობრივი პროცესები დაცულია, # მინიმუმი - მიზნობრივი პოლიტიკის შეცვლა. მხოლოდ შერჩეული პროცესები არის $ $ მილიონი - უსაფრთხოების მრავალ დონის დაცვა. SELINUXTYPE = მიზანმიმართული
შემდეგ აწარმოეთ შემდეგი ბრძანებები
[root @ dns] # setenforce 0
[root @ dns] # სამსახურის ცეცხლის სამყაროს შეჩერება გადამისამართება / bin / systemctl stop firewalld.service- ზე [root @ dns] # systemctl გამორთეთ firewalld ამოღებულია Symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service. Symlink /etc/systemd/system/basic.target.wants/firewalld.service წაიშალა.
თუ თქვენ იყენებთ DNS სერვერს, რომელიც ინტერნეტის წინაშე დგას, თქვენ არ უნდა გააკეთოთ ეს ზემოთ, მაგრამ SELinux კონტექსტისა და Firewall- ის სწორად კონფიგურაცია გჭირდებათ. იხილეთ "სერვერის კონფიგურაცია GNU / Linux– ით, ავტორის ჯოელ ბარიოს დუენიას მიერ" ან თავად CentOS– ის დოკუმენტაცია - Red Hat
ჩვენ ვაყენებთ კონფიგურაციას BIND - დასახელებული
- El დირექტორია /usr/share/doc/bind-9.9.4/ ეს შეიცავს უამრავ დოკუმენტაციას, რომლის გირჩევთ კონსულტაციას გაუკეთოთ ინტერნეტის ძებნაში, ისე რომ არ იცოდეთ, რომ თქვენს ხელთაა და საკუთარ სახლში შეგიძლიათ იპოვოთ ის, რასაც ეძებთ.
ბევრ დისტრიბუციაში იწოდება BND პაკეტის საშუალებით დაინსტალირებული DNS სერვისი დასახელდა (დაარქვით Daemon) CentOS 7 – ში ის ინსტალაცია გამორთულია სტანდარტულად, შემდეგი ბრძანების გამოცემის შესაბამისად, სადაც ნათქვამია, რომ მისი სტატუსია «ინვალიდები«და რომ ეს მდგომარეობა წინასწარ განსაზღვრულია მისი« გამყიდველის »მიერ - გამყიდველის წინასწარ დაყენება. ცნობისთვის, BIND არის უფასო პროგრამა.
დასახელებული სერვისის ჩართვა
[root @ dns] დასახელებულია # systemctl სტატუსი ● named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service); ინვალიდები; გამყიდველის წინასწარ დაყენება: გამორთულია) აქტიური: არააქტიური (მკვდარი) [root @ dns] დასახელებულია # systemctl ჩართვა შეიქმნა სიგნალი /etc/systemd/system/multi-user.target.wants/named.service დან /usr/lib/systemd/system/named.service. [root @ dns] დასახელებულია # systemctl [root @ dns] დასახელებულია # systemctl სტატუსი ● named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service); ჩართულია; გამყიდველის წინასწარ დაყენება: გამორთულია) აქტიური: აქტიური (გაშვებული) შაბათიდან 2017-01-28 13:22:38 EST; 5 წთ-ის წინ პროცესი: 1990 ExecStart = / usr / sbin / სახელად -u დაასახელა $ OPTIONS (კოდი = გამოვიდა, სტატუსი = 0 / წარმატება) პროცესი: 1988 ExecStartPre = / bin / bash -c if [! "$ DISABLE_ZONE_CHECKING" == "დიახ"]; შემდეგ / usr / sbin / names-checkconf -z /etc/named.conf; other echo "ზონის ფაილების შემოწმება გამორთულია"; fi (კოდი = გამოვიდა, სტატუსი = 0 / წარმატება) მთავარი PID: 1993 (დასახელებული) CGroup: /system.slice/named.service └─1993 / usr / sbin / names -u დაასახელა 28 იანვარს 13:22:45 dns დაასახელა [1993]: შეცდომა (ქსელი მიუწვდომელია) გადაჭრის './NS/IN': 2001: 500: 2f :: f # 53 28 იანვარი, 13:22:47 dns დაასახელა [1993]: შეცდომა (ქსელი მიუწვდომელია) გადაჭრის ”./ DNSKEY / IN ': 2001: 500: 3 :: 42 # 53 28 იანვარს 13:22:47 dns დაასახელა [1993]: შეცდომა (ქსელის მიუწვდომელი) მოგვარება' ./NS/IN ': 2001: 500: 3 :: 42 # 53 იანვ. 28 13:22:47 dns დაასახელა [1993]: შეცდომა (ქსელი მიუწვდომელია) გადაჭრის './DNSKEY/IN': 2001: 500: 2d :: d # 53 Jan 28 13:22:47 dns დაასახელა [1993 ]: შეცდომა (ქსელი მიუწვდომელია) გადაჭრის './NS/IN': 2001: 500: 2d :: d # 53 იანვ. 28 13:22:47 dns დაასახელა [1993]: შეცდომა (ქსელი მიუწვდომელია) გადაჭრის './DNSKEY/ IN ': 2001: dc3 :: 35 # 53 Jan 28 13:22:47 dns დაასახელა [1993]: შეცდომა (ქსელი მიუწვდომელია) გადაჭრის' ./NS/IN ': 2001: dc3 :: 35 # 53 28 იანვარი 13: 22:47 dns დაასახელა [1993]: შეცდომა (ქსელი მიუწვდომელია) გადაჭრის './DNSKEY/IN': 2001: 7fe :: 53 # 53 Jan 28 13:22:47 dns დაასახელა [1993]: შეცდომა (ქსელი მიუწვდომელია) res olving './NS/IN': 2001: 7fe :: 53 # 53 28 იანვარს, 13:22:48 dns დაასახელა [1993]: Manage-keys-zone: DNSKEY კომპლექტის მიღება ვერ ხერხდება '.': ვადა ამოიწურა [root @ dns] დასახელებულია # systemctl გადატვირთვა [root @ dns] დასახელებულია # systemctl სტატუსი ● named.service - Berkeley Internet Name Domain (DNS) დატვირთულია: ჩატვირთული (/usr/lib/systemd/system/named.service; ჩართულია; გამყიდველის წინასწარ დაყენებული: გამორთულია) აქტიური: აქტიური (გაშვებული) შაბათიდან 2017-01-28 13:29:41 EST; 1 წამის წინ პროცესი: 1449 ExecStop = / bin / sh -c / usr / sbin / rndc stop> / dev / null 2> & 1 || / bin / kill -TERM $ MAINPID (კოდი = გამოსული, სტატუსი = 0 / წარმატება) პროცესი: 1460 ExecStart = / usr / sbin / დაასახელა -u დაასახელა $ OPTIONS (კოდი = გამოვიდა, სტატუსი = 0 / წარმატება) პროცესი: 1457 ExecStartPre = / bin / bash -c თუ [! "$ DISABLE_ZONE_CHECKING" == "დიახ"]; შემდეგ / usr / sbin / names-checkconf -z /etc/named.conf; other echo "ზონის ფაილების შემოწმება გამორთულია"; fi (კოდი = გამოვიდა, სტატუსი = 0 / წარმატება) მთავარი PID: 1463 (დასახელებული) CGroup: /system.slice/named.service └─1463 / usr / sbin / დასახელებული -u დაასახელა 28 იანვარს 13:29:41 dns დაასახელა [1463]: Manage-keys-zone: ჟურნალის ფაილი მოძველებულია: ჟურნალის ფაილის ამოღება 28 იანვარს 13:29:41 dns დაასახელა [1463]: Manage-keys-zone: დატვირთული სერიული 2 28 იანვარს 13:29:41 dns დაასახელა [1463]: ზონა 0.in-addr.arpa/IN: დატვირთულია სერიალი 0 იან 28 13 29:41:1463 dns დაასახელა [0]: zone localhost.localdomain / IN: დატვირთულია სერიალი 28 13 იანვარი 29:41:1463 დნს დაასახელა [1.0.0.127]: ზონა 0.in-addr.arpa/IN: დატვირთულია სერიული 28 იან 13 29 41:1463:1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 dns დაასახელა [6]: ზონა 0 .28.ip13.arpa / IN: დატვირთულია სერიული 29 41 იანვარს 1463:0:28 dns დაასახელა [13]: zone localhost / IN: დატვირთულია სერიული 29 41 იანვარს 1463 28 : 13: 29 დნს დაასახელა [41]: ყველა ზონა ჩაიტვირთა 1463 იანვარს 28:13:29 დნს სახელით [41]: მიმდინარე 1 იანვარს XNUMX:XNUMX:XNUMX დნს სისტემა [XNUMX]: დაიწყო ბერკლი ინტერნეტის სახელის დომენმა (DNS).
სერვისის ჩართვის შემდეგ დასახელდა და ჩვენ მას პირველად ვიწყებთ, ბრძანების გამომავალი systemctl სტატუსი დასახელებულია აჩვენებს შეცდომებს. ქვემოთ მოცემული სერვისის გადატვირთვისას, დასახელდა ქმნის ყველა კონფიგურაციის ფაილს, რომელიც, სტანდარტულად, აუცილებელია მისი სწორი მუშაობისთვის. ამიტომ, როდესაც ჩვენ კვლავ შევასრულებთ ბრძანებას systemctl სტატუსი დასახელებულია აღარ არის ნაჩვენები შეცდომები.
- ძვირფასო, ძვირადღირებულ და მომთხოვნ მკითხველს: თუ გსურთ გაიგოთ - სულ მცირე - რომელი გზა მიდის კურდღლის ხვრელის ბოლომდე, გთხოვთ მშვიდად გაეცნოთ თითოეული ბრძანების დეტალურ შედეგებს. 😉 რა თქმა უნდა, სტატია ცოტა გრძელი ჩანს, მაგრამ არ უარყოთ, რომ ის განმარტებებსა და სიცხადეებს იძენს.
ჩვენ ვცვლით ფაილს /etc/named.conf
ბევრი მკითხველის კომენტარი გამოხატავს -მე ამას არ ვამბობ- მანია, რომელიც აქვთ Linux- ის სხვადასხვა დისტრიბუციის შემნახველებს, სისტემის კონფიგურაციის ფაილების განთავსება სხვადასხვა სახელების საქაღალდეებში, დისტროს მიხედვით. ისინი მართლები არიან. მაგრამ რა შეგვიძლია გავაკეთოთ ჩვენ, უბრალო მომხმარებლებმა, რომლებიც ამ დისტრიბუციებს იყენებენ? მოირგეთ! 😉
სხვათა შორის, FreeBSD- ში, UNIX®- ის კლონი «Origin» - ში, ფაილი არის /usr/local/etc/namedb/named.conf; დებიანში ყოფნის გარდა, ოთხ ფაილში გაყოფის გარდა names.conf, names.conf.options, names.conf.default-zone და names.conf.local, საქაღალდეშია / etc / bind /. ვისაც სურს იცოდეს, სად ათავსებს openSUSE, წაიკითხეთ «DNS და DHCP in openSUSE 13.2 Harlequin - მცირე და საშუალო ბიზნესის ქსელები« მკითხველი მართალია! 😉
და როგორც ყოველთვის ვაკეთებთ: სანამ რამეს შეცვლით, ჩვენ ვინახავთ ორიგინალ კონფიგურაციის ფაილს სხვა სახელით.
[root @ dns] # cp /etc/named.conf /etc/named.conf.original
გასაღების შექმნის ნაცვლად ცხოვრების გამარტივება TSIG DHCP– ს მიერ DNS– ის დინამიური განახლებებისთვის, ჩვენ ვაკოპირებთ იმავე გასაღებს rndc.გასაღები როგორც dhcp. გასაღები.
[root @ dns] # cp /etc/rndc.key /etc/dhcp.key [root @ dns] # ნანო / და ა.შ. /dhcp.key გასაღები "dhcp-key" {ალგორითმი hmac-md5; საიდუმლო "OI7Vs + TO83L7ghUm2xNVKg =="; };
ასე რომ დასახელდა შეუძლია წაიკითხოს ახლახან გადაწერილი ფაილი, ჩვენ ვცვლით მის მფლობელთა ჯგუფს:
[root @ dns] # chown root: დაასახელა /etc/dhcp.key [root @ dns] # ls -l /etc/rndc.key /etc/dhcp.key -rw-r -----. 1 ფესვი, სახელად 77 იანვარი 28 16:36 PM /etc/dhcp.key -rw-r -----. 1 ფესვი, სახელად 77 იანვარი 28 13:22 /etc/rndc.key
წინა დეტალების მსგავსი მცირე დეტალები არის ის, რამაც შეიძლება გაგვაგიჟოს იმის გარკვევა, ახლა ... სად არის პრობლემა ...? კიდევ რამდენიმე ზედსართავი სახელით, რომელსაც ჩვენ არ ვწერთ პატივმოყვარეობის პატივისცემის გამო.
ახლა თუ - საბოლოოდ! - ჩვენ ვანაწილებთ ფაილს /და ა.შ. დაასახელა. conf. ცვლილებები ან დამატებები, რაც ჩვენ შევიტანეთ ორიგინალის მიმართ, არის თამამი. კარგად დააკვირდით რამდენია.
[root @ dns] # nano /etc/named.conf // // named.conf // // მოწოდებულია Red Hat bind პაკეტის მიერ ISC BIND დასახელებული (8) DNS // სერვერის კონფიგურაციისთვის მხოლოდ მხოლოდ სახელების სერვერის ქეშირებისთვის (მხოლოდ localhost DNS გადაჭრის სახით). // // იხილეთ / usr / share / doc / bind * / ნიმუში / მაგალითად დასახელებული კონფიგურაციის ფაილები. // // წვდომის კონტროლის სია, რომელშიც ნათქვამია, თუ რომელ ქსელებს შეეძლებათ კონსულტაცია // ჩემი დასახელებული სერვერი აკრული { 127.0.0.0/8; 192.168.10.0/24; }; პარამეტრები { // მე ვაცხადებ, რომ დასახელებული daemon ასევე ისმენს ინტერფეისს // eth0 რომელსაც აქვს IP: 192.168.10.5 მოსასმენად პორტი 53 {127.0.0.1; 192.168.10.5; }; listen-on-v6 პორტი 53 {:: 1; }; დირექტორია "/ var / დასახელებული"; dump-file "/var/named/data/cache_dump.db"; სტატისტიკური ფაილი "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; // ფორვარდერების განცხადება // ექსპედიტორი { // 0.0.0.0; // 1.1.1.1; //}; // ჯერ წინ; // მე მხოლოდ დაშვებულ კითხვებს ვუშვებ ჩემს დაბნეულ ACL– ს დასაშვები მოთხოვნა {mired; }; // შეამოწმეთ ბრძანებით dig desdelinux.fan axfr // მხოლოდ SysAdmin სამუშაო სადგურიდან და მხოლოდ localhost– დან // ჩვენ არ გვაქვს მონა DNS სერვერები. ჩვენ ეს არ გვჭირდება ... აქამდე. დაუშვას-გადარიცხვა {localhost; 192.168.10.1; }; / * - თუ თქვენ აშენებთ ავტორიტეტულ DNS სერვერს, ნუ ჩართავთ უკან დაბრუნებას. - თუ აშენებთ RECURSIVE (ქეშირების) DNS სერვერს, უნდა ჩართოთ რეკურსი. - თუ თქვენს რეკურსიულ DNS სერვერს აქვს საჯარო IP მისამართი, თქვენ უნდა ჩართოთ წვდომის კონტროლი, რათა შეზღუდოთ მოთხოვნები თქვენი ლეგიტიმური მომხმარებლებისთვის. ამის შეუსრულებლობა გამოიწვევს თქვენი სერვერის DNS გამაძლიერებელი შეტევების დიდ ნაწილს. თქვენს ქსელში BCP38– ის განხორციელება მნიშვნელოვნად შეამცირებს შეტევის ზედაპირს * / // ჩვენ გვსურს AUTHORITY სერვერი ჩვენი LAN– ისთვის - SME რეკურსია არა; dnssec- ჩართვა დიახ; dnssec- ვალიდაცია დიახ; / * ISC DLV გასაღების გზა * / bindkeys-file "/etc/named.iscdlv.key"; მოახერხა-გასაღებები-დირექტორია "/ var / დასახელებული / დინამიური"; pid-file "/run/named/named.pid"; სესიის keyfile "/run/named/session.key"; }; შესვლა {არხის default_debug {ფაილი "data / named.run"; სიმძიმის დინამიური; }; }; ზონა "." IN {ტიპის მინიშნება; ფაილი "დაასახელა.კა"; }; მოიცავს "/etc/named.rfc1912.zones"; მოიცავს "/etc/named.root.key"; // ჩვენ ჩავრთავთ TSIG კლავიშს DNS დინამიური განახლებისთვის // DHCP მოიცავს "/etc/dhcp.key"; // სახელის, ტიპის, მდებარეობისა და განახლების ნებართვის დეკლარაცია // DNS ჩანაწერების ზონების // ორივე ზონა არის სამაგისტრო ზონა "desdelinux.fan" { ტიპის ოსტატი; ფაილი "დინამიური / db.fromlinux.fan"; დაშვება-განახლება {გასაღები dhcp-key; }; }; ზონა "10.168.192.in-addr.arpa" { ტიპის ოსტატი; ფაილი "დინამიური / db.10.168.192.in-addr.arpa"; დაშვება-განახლება {გასაღები dhcp-key; }; };
ჩვენ სინტაქსს ვამოწმებთ
[root @ dns] # დასახელებული- checkconf [root @ dns] #
რადგან ზემოთ მოცემული ბრძანება არაფერს დაუბრუნებს, სინტაქსი კარგია. ამასთან, თუ იგივე ბრძანება შევასრულეთ, ოღონდ ოფციონით -z, გამომავალი იქნება:
[root @ dns] # names-checkconf -z zone localhost.localdomain / IN: დატვირთული სერიული 0 zone localhost / IN: დატვირთული სერიული 0 zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .ip6.arpa / IN: დატვირთულია სერიული 0 ზონა 1.0.0.127.in-addr.arpa/IN: დატვირთულია სერიული 0 ზონა 0.in-addr.arpa/IN: დატვირთულია სერიული 0 ზონა linux.fan/IN: იტვირთება ძირითადი ფაილის დინამიკიდან / db.from linux.fan ჩაიშალა: ფაილი ვერ მოიძებნა ზონაში linux.fan/IN: შეცდომის გამო არ ჩაიტვირთა. _default / desdelinux.fan / IN: ფაილი ვერ მოიძებნა ზონაში 10.168.192.in-addr.arpa/IN: ფაილის დინამიკიდან ჩატვირთვა / db.10.168.192.in-addr.arpa ვერ მოხერხდა: ფაილი ვერ მოიძებნა ზონაში 10.168.192 .in-addr.arpa / IN: არ ჩაიტვირთა შეცდომების გამო. _default / 10.168.192.in-addr.arpa / IN: ფაილი ვერ მოიძებნა
რა თქმა უნდა, ეს არის შეცდომები, რომლებიც ხდება, რადგან ჩვენ ჯერ არ შევქმენით DNS ჩანაწერის ზონები ჩვენი დომენისთვის.
- ბრძანების შესახებ დამატებითი ინფორმაციისთვის სახელწოდებით- checkconf, გაიქეცი კაცი სახელად-ჩეკონფი, სანამ რაიმე სხვა ინფორმაციას მოძებნით ინტერნეტში. გარწმუნებთ, რომ ეს დიდ დროს დაზოგავს.
ჩვენ ვქმნით Direct Zone ფაილს linux.fan– დან
... ჯერ ცოტათი თეორიის გარეშე. 😉
როგორც ზონის მონაცემთა ფაილის შესაქმნელად შაბლონი, შეგვიძლია ავიღოთ /var/named/named.activeან /usr/share/doc/bind-9.9.4/sample/var/named/named.empty. ორივე იდენტურია.
[root @ dns] # კატა /var/named/named.empty $ TTL 3H @ IN SOA @ rname.invalid. (0; სერიული 1D; განახლება 1H; ცადეთ 1W; ვადა ამოიწურა 3H); მინიმალური ან ნეგატიური ქეშირების დრო NS @ A 127.0.0.1 AAAA- სთვის საცხოვრებლად :: 1
ცხოვრების დრო - დროა ვიცხოვროთ TTL SOA ჩანაწერი
ავიღოთ ფრჩხილი და ავუხსნათ ის TTL - ცხოვრების დრო რეესტრიდან SOA - უფლებამოსილების დაწყება სამაგისტრო ზონის. საინტერესოა ვიცოდეთ მათი მნიშვნელობა, თუ როდის გვინდა მათი რომელიმე ღირებულების შეცვლა.
$ TTL: ცხოვრების დრო - ცხოვრების დრო ფაილი ყველა ჩანაწერისთვის, რომელიც დეკლარაციას მიჰყვება (მაგრამ წინ უსწრებს სხვა $ TTL დეკლარაციას) და არ აქვს გამოკვეთილი TTL დეკლარაცია.
სერიალი: ზონის მონაცემების სერიული ნომერი. ყოველთვის, როდესაც ზონაში ხელით ვცვლით DNS ჩანაწერს, ეს რიცხვი 1-ით უნდა გავზარდოთ, განსაკუთრებით თუ გვაქვს მონა ან მეორადი სერვერები. ყოველთვის, როდესაც მეორადი ან მონა DNS სერვერი დაუკავშირდება მის სამაგისტრო სერვერს, ის ითხოვს მასტერის მონაცემების სერიულ ნომერს. თუ მონის სერიული ნომერი ნაკლებია, მაშინ მონა სერვერზე ამ ზონის მონაცემები მოძველებულია, ხოლო მონა ასრულებს ზონის გადაცემას, რომ განაახლოს საკუთარი თავი.
განახლება: იგი მონა სერვერს ეუბნება დროის ინტერვალს, რომელშიც მან უნდა შეამოწმოს, არის თუ არა მისი მონაცემები განახლებული მასტერთან მიმართებაში.
სცადეთ კიდევ ერთხელ: თუ ძირითადი სერვერი არ არის ხელმისაწვდომი - იმიტომ, რომ იგი დაავადდა, ვთქვათ - მონა დროის ინტერვალის შემდეგ განახლება, სცადეთ კიდევ ერთხელ იგი მონას ეუბნება, რამდენ ხანს უნდა დაველოდოთ, სანამ კვლავ შეეცდება თავის ბატონთან კონტაქტს.
იწურება: თუ მონა დროთა განმავლობაში ვერ დაუკავშირდება თავის პატრონს იწურება, მაშინ, თუ მონა-სამაგისტრო ზონის ურთიერთობა მოიშალა და მონა სერვერს სხვა არჩევანი არ აქვს, თუ არა ამ საკითხის მოქმედების ვადის ამოწურვა. მონა DNS სერვერის მიერ ზონის ვადის ამოწურვა ნიშნავს, რომ იგი შეწყვეტს ამ ზონასთან დაკავშირებულ DNS მოთხოვნებზე რეაგირებას, რადგან არსებული მონაცემები ძალიან ძველია, რომ სასარგებლო იყოს.
- ზემოხსენებული გვასწავლის არაპირდაპირი გზით და სავსე საღი აზრით - ყველაზე ნაკლებად საყოველთაო გრძნობებით - რომ თუ ჩვენ არ დაგვჭირდება მონა DNS სერვერები ჩვენი მცირე და საშუალო ბიზნესის მუშაობისთვის, ჩვენ მას არ განვახორციელებთ, თუ ისინი მკაცრად არ არის საჭირო. ყოველთვის ვცდილობთ მარტივიდან რთულზე გადასვლას.
მინიმუნი: ვერსიებში სავალდებულო 8.2, ბოლო ჩანაწერი SOA ეს ასევე მიუთითებს ნაგულისხმევი სიცოცხლის ხანგრძლივობაზე - ცხოვრების ნაგულისხმევი დრო, და ნეგატიური ქეშის მთელი ცხოვრების განმავლობაში - უარყოფითი ქეშირების დრო ცხოვრებისთვის ზონისთვის. ეს დრო ეხება ზონისთვის ავტორიტეტული სერვერის მიერ მოცემულ ყველა უარყოფით პასუხს.
ზონის ფაილი /var/named/dynamic/db.fromlinux.fan
[root @ dns] # nano /var/named/dynamic/db.fromlinux.fan $ TTL 3H @ IN SOA dns.fromlinux.fan. root.dns.fromlinux.fan. (1; სერიული 1D; განახლება 1H; ცადეთ 1W; ვადა ამოიწურა 3H); მინიმალური ან; ნეგატიური ქეშირების დრო საცხოვრებლად; @ NS dns.fromlinux.fan. @ IN MX 10 mail.fromlinux.fan. @ IN TXT "FromLinux, თქვენი ბლოგი ეძღვნება თავისუფალ პროგრამულ უზრუნველყოფას"; sysadmin IN 192.168.10.1 AD-dc IN A 192.168.10.3 ფაილების სერვერი IN 192.168.10.4 dns IN 192.168.10.5 პროქსი ქსელი 192.168.10.6 ბლოგზე 192.168.10.7 ftpserver IN 192.168.10.8 ფოსტა 192.168.10.9 ფოსტა XNUMX IN
ჩვენ ვამოწმებთ /var/named/dynamic/db.fromlinux.fan
[root @ dns] # დასახელებული-გამშვები ზონა linux.fan / var / დასახელებული / დინამიური / db. fromlinux.fan ზონა linux.fan/IN– დან: დატვირთულია სერიალი 1 კარგი
ჩვენ ვქმნით ინვერსიული ზონის ფაილს 10.168.192.in-addr.arpa
- ამ ზონის SOA ჩანაწერი იგივეა, რაც პირდაპირი ზონის MX ჩანაწერის გათვალისწინების გარეშე..
[root @ dns] # nano /var/named/dynamic/db.10.168.192.in-addr.arpa $ TTL 3H @ IN SOA dns.fromlinux.fan. root.dns.fromlinux.fan. (1; სერიული 1D; განახლება 1H; ცადეთ 1W; ვადა ამოიწურება 3H); მინიმალური ან; ნეგატიური ქეშირების დრო საცხოვრებლად; @ NS dns.fromlinux.fan. ; 1 IN PTR sysadmin.fromlinux.fan. 3 IN PTR ad-dc.fromlinux.fan. 4 IN PTR fileserver.fromlinux.fan. 5 IN PTR dns.fromlinux.fan. 6 IN PTR მარიონეტული ქსელი .desdelinux.fan. 7 IN PTR ბლოგზე .desdelinux.fan. 8 IN PTR ftpserver.fromlinux.fan. 9 IN PTR mail.fromlinux.fan. [root @ dns] # names-checkzone 10.168.192.in-addr.arpa /var/named/dynamic/db.10.168.192.in-addr.arpa ზონა 10.168.192.in-addr.arpa/IN: დატვირთული სერიალი 1 კარგი
დასახელებულის გადატვირთვამდე ვამოწმებთ მის კონფიგურაციას
- სანამ არ დავრწმუნდებით, რომ დაასახელა names.conf- ის კონფიგურაციის ფაილები და მისი ზონის ფაილები არ არის სწორად კონფიგურირებული, გირჩევთ, არ განაახლოთ დასახელებული daemon. თუ ამას ვაკეთებთ და მოგვიანებით ზონაში შეიტანეთ ფაილი, მოდიფიცირებული ზონის სერიული ნომერი 1-ით უნდა გავზარდოთ.
- მოდით ვნახოთ "". დომენისა და მასპინძლის სახელების ბოლოს.
[root @ dns] # დასახელებული- checkconf [root @ dns] # names-checkconf -z zone localhost.localdomain / IN: დატვირთული სერიული 0 zone localhost / IN: დატვირთული სერიული 0 zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .ip6.arpa / IN: დატვირთული სერიული 0 ზონა 1.0.0.127.in-addr.arpa/IN: დატვირთული სერიული 0 ზონა 0.in-addr.arpa/IN: დატვირთულია სერიული 0 ზონა linux.fan/IN: დატვირთული სერიული 1 ზონა 10.168.192. 1.in-addr.arpa/IN: დატვირთული სერიალი XNUMX
ყველა მიმდინარე დასახელებული კონფიგურაცია
სიცხადის მოსაპოვებლად და მიუხედავად იმისა, რომ სტატია გრძელი ხდება, ჩვენ ვაძლევთ ბრძანების სრულ შედეგს სახელწოდებით- checkconf -zp:
[root @ dns] # names-checkconf -zp zone localhost.localdomain / IN: დატვირთული სერიული 0 zone localhost / IN: დატვირთული სერიული 0 zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0ipip.arpa / IN: დატვირთული სერიული 6 ზონა 0.in-addr.arpa/IN: დატვირთული სერიული 1.0.0.127 ზონა 0.in-addr.arpa/IN: დატვირთულია სერიული 0 ზონა linux.fan/IN: დატვირთული სერიული 0 ზონა 1. 10.168.192.in-addr.arpa/IN: დატვირთულია სერიული 1 ვარიანტი {bindkeys-file "/etc/named.iscdlv.key"; სესიის keyfile "/run/named/session.key"; დირექტორია "/ var / დასახელებული"; dump-file "/var/named/data/cache_dump.db"; მოსასმენად პორტი 53 {127.0.0.1/32; 192.168.10.5/32; }; listen-on-v6 პორტი 53 {:: 1/128; }; მოახერხა-გასაღებები-დირექტორია "/ var / დასახელებული / დინამიური"; memstatistics-file "/var/named/data/named_mem_stats.txt"; pid-file "/run/named/named.pid"; სტატისტიკა-ფაილი "/var/named/data/named_stats.txt"; dnssec- ჩართვა დიახ; dnssec- ვალიდაცია დიახ; რეკურსია არა; ნებადართული მოთხოვნა {"mired"; }; დაშვება-გადაცემა {192.168.10.1/32; }; }; acl "mired" {127.0.0.0/8; 192.168.10.0/24; }; შესვლა {არხი "default_debug" {ფაილი "მონაცემები / დასახელებული. გაშვება"; სიმძიმის დინამიური; }; }; გასაღები "dhcp-key" {ალგორითმი "hmac-md5"; საიდუმლო "OI7Vs + TO83L7ghUm2xNVKg =="; }; ზონა "." IN {ტიპის მინიშნება; ფაილი "დაასახელა.კა"; }; ზონა "localhost.localdomain" IN {ტიპის master; ფაილი "დაასახელა. localhost"; დაუშვით-განაახლეთ {"არცერთი"; }; }; zone "localhost" IN {ტიპის ოსტატი; ფაილი "დაასახელა. localhost"; დაუშვით-განაახლეთ {"არცერთი"; }; }; ზონა "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {ტიპის master; ფაილი "named.loopback"; დაუშვით-განაახლეთ {"არცერთი"; }; }; ზონა "1.0.0.127.in-addr.arpa" IN {ტიპის სამაგისტრო; ფაილი "names.loopback"; დაუშვით-განაახლეთ {"არცერთი"; }; }; ზონა "0.in-addr.arpa" IN {ტიპის სამაგისტრო; ფაილი "დაასახელა. ცარიელი"; დაუშვით-განაახლეთ {"არცერთი"; }; }; ზონა "desdelinux.fan" {ტიპის ოსტატი; ფაილი "დინამიური / db.fromlinux.fan"; დაუშვით-განაახლეთ {გასაღები "dhcp-key"; }; }; ზონა "10.168.192.in-addr.arpa" {ტიპის ოსტატი; ფაილი "დინამიური / db.10.168.192.in-addr.arpa"; დაუშვით-განაახლეთ {გასაღები "dhcp-key"; }; }; მართული კლავიშები {"." გასაღები საწყის-257 3 აგვისტოს "AwEAAagAIKlVZrpC8Ia6gEzahOR + 7W9euxhJhVVLOyQbSEW29O0gcCjF FVQUTf8v6fLjwBd58YI0EzrAcQqBGCzh / RStIoO0g8NfnfL0MTJRkxoX bfDaUeVPQuYEhg2NZWAJQ37VnMVDxP / VHL9M / QZxkjf496 / Efucp5gaD X2RS6CXpoY6LsvPVjR68ZSwzz0apAzvN1dlzEheX9ICJBBtuA7G6LQpz W3hOA5hzCTMjJPJ2LbqF8dsV6DoBQzgul6sGIcGOYl0OyQdXfZ7relS Qageu + ipAdTTJ57AsRTAoub25ONGcLmqrAmRLKBP8dfwhYB1N4knNnulq QXA + Uk7ihz1 ="; };
- მოდიფიკაციის პროცედურის შემდეგ დაასახელა ჩვენი საჭიროებების შესაბამისად და შეამოწმეთ თითოეული ზონის ფაილი და შეამოწმეთ იგი, ეჭვი გვეპარება, რომ კონფიგურაციის ძირითადი პრობლემები შეგვექმნება. დასასრულს, ჩვენ ვხვდებით, რომ ეს არის ბიჭის თამაში, მრავალი კონცეფციითა და უსიამოვნო სინტაქსით.
შემოწმებებმა დამაკმაყოფილებელი შედეგი გამოიღო, ამიტომ BIND- ის გადატვირთვა შეგვიძლია დასახელდა.
ჩვენ გადატვირთეთ დასახელებული და შეამოწმეთ მისი სტატუსი
[root @ dns] # systemctl გადატვირთეთ names.service [root @ dns] # systemctl სტატუსის დასახელება. სერვისი
თუ ჩვენ მივიღეთ რაიმე შეცდომა ბოლო ბრძანების გამომავალში, ჩვენ უნდა გადატვირთოთ დაასახელა. მომსახურება და გადაამოწმე შენი სტატუსი. შეცდომების დაკარგვის შემთხვევაში, მომსახურება წარმატებით დაიწყო. წინააღმდეგ შემთხვევაში, ჩვენ უნდა განვახორციელოთ ყველა შეცვლილი და შექმნილი ფაილი და განმეორდეს პროცედურა.
სტატუსის სწორი გამომავალი უნდა იყოს:
[root @ dns] # systemctl სტატუსის დასახელება. სერვისი ● named.service - Berkeley Internet Name Domain (DNS) დატვირთულია: ჩატვირთული (/usr/lib/systemd/system/named.service; ჩართულია; გამყიდველის წინასწარ დაყენებული: გამორთულია) აქტიური: აქტიური (გაშვებული) მზის შემდეგ 2017-01-29 10:05:32 EST; 2 წთ 57 წმ-ის წინ პროცესი: 1777 ExecStop = / bin / sh -c / usr / sbin / rndc stop> / dev / null 2> & 1 || / bin / kill -TERM $ MAINPID (კოდი = გამოსული, სტატუსი = 0 / წარმატება) პროცესი: 1788 ExecStart = / usr / sbin / დასახელებული -u დაასახელა $ OPTIONS (კოდი = გამოვიდა, სტატუსი = 0 / წარმატება) პროცესი: 1786 ExecStartPre = / bin / bash -c თუ [! "$ DISABLE_ZONE_CHECKING" == "დიახ"]; შემდეგ / usr / sbin / names-checkconf -z /etc/named.conf; other echo "ზონის ფაილების შემოწმება გამორთულია"; fi (კოდი = გამოვიდა, სტატუსი = 0 / წარმატება) მთავარი PID: 1791 (დასახელებული) CGroup: /system.slice/named.service └─1791 / usr / sbin / დასახელებული -u დაასახელა 29 იანვარს 10:05:32 dns დაასახელა [1791]: zone 1.0.0.127.in-addr.arpa/IN: დატვირთულია სერიალი 0 იან 29 10 05:32:1791 dns დაასახელა [10.168.192]: zone 1.in-addr.arpa/IN: დატვირთულია სერიალი 29 იან 10 05:32:1791 დნს დაასახელა [1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0]: ზონა 6.ip0.arpa/IN: ჩატვირთულია სერიული 29 იანვარს 10 05:32:1791 დნს დაასახელა [1]: zone desdelinux.fan/IN: ჩატვირთულია სერიალი 29 იანვარს 10 05:32:1791 დნს დაასახელა [0]: zone localhost.localdomain / IN: ჩატვირთულია სერიალი 29 10 იანვარს 05:32:1791 dns დაასახელა [0]: zone localhost / IN: დატვირთულია სერიული 29 იანვარს 10 05:32:1791 dns დაასახელა [XNUMX]: ყველა ზონა დატვირთულია 29 იანვარს 10:05:32 დნს დაასახელა [1791]: გაშვებული 29 იანვარს 10:05:32 dns systemd [1]: დაიწყო Berkeley Internet Name Domain (DNS). 29 იანვარს 10:05:32 dns დაასახელა [1791]: ზონა 10.168.192.in-addr.arpa/IN: შეტყობინებების გაგზავნა (სერია 1)
ამოწმებს
შემოწმების ჩატარება შეიძლება იმავე სერვერზე ან LAN- ზე ჩართულ მანქანაზე. ჩვენ გვირჩევნია, ეს გუნდიდან გავაკეთოთ sysadmin.fromlinux.fan რომელსაც ჩვენ მივეცით გამოხატული ნებართვა, რომ მას შეეძლოს ზონის გადაცემა. Ფაილი /etc/resolv.conf ამ გუნდის შემდეგია:
buzz @ sysadmin: cat $ cat /etc/resolv.conf # გენერირებულია NetworkManager- ის მიერ linux.fan nameserver- ის ძიებით 192.168.10.5 buzz @ sysadmin: dig $ dig from linux.fan axfr ; << >> DiG 9.9.5-9 + deb8u1-Debian << >> desdelinux.fan axfr ;; გლობალური პარამეტრები: + cmd საწყისი linux.fan. 10800 SOA dns.fromlinux.fan. root.dns.fromlinux.fan. 1 86400 3600 604800 10800 linux.fan– დან. 10800 IN NS dns.fromlinux.fan. linux– დან .fan. 10800 IN MX 10 mail.fromlinux.fan. linux– დან .fan. 10800 TXT "FromLinux, თქვენი ბლოგი ეძღვნება თავისუფალ პროგრამულ უზრუნველყოფას" ad-dc.desdelinux.fan. 10800 წელს 192.168.10.3 ბლოგზე .desdelinux.fan. 10800 A 192.168.10.7 dns.fromlinux.fan. 10800 IN 192.168.10.5 fileserver.fromlinux.fan. 10800 IN 192.168.10.4 ftpserver.fromlinux.fan. 10800 IN 192.168.10.8 mail.fromlinux.fan. 10800 IN 192.168.10.9 proxyweb.fromlinux.fan. 10800 IN 192.168.10.6 sysadmin.fromlinux.fan. 10800 IN დან 192.168.10.1 მდე linux.fan. 10800 SOA dns.fromlinux.fan. root.dns.fromlinux.fan. 1 86400 3600 604800 10800 ;; შეკითხვის დრო: 0 msec ;; სერვერი: 192.168.10.5 # 53 (192.168.10.5) ;; როდის: მზე 29 იანვარს 11:44:18 EST 2017 ;; XFR ზომა: 13 ჩანაწერი (შეტყობინებები 1, ბაიტი 385) buzz @ sysadmin: dig $ dig 10.168.192.in-addr.arpa axfr ; << >> DiG 9.9.5-9 + deb8u1-Debian << >> 10.168.192.in-addr.arpa axfr ;; გლობალური პარამეტრები: + სმდ 10.168.192.in-addr.arpa- ში. 10800 SOA dns.fromlinux.fan.10.168.192.in-addr.arpa. root.dns.fromlinux.fan.10.168.192.in-addr.arpa. 1 86400 3600 604800 10800 10.168.192.in- ადდრ.არპაში. 10800 IN NS dns.fromlinux.fan. 1.10.168.192.in- ადდრ.არპაში. 10800 IN PTR sysadmin.fromlinux.fan. 3.10.168.192.in- ადდრ.არპაში. 10800 IN PTR ad-dc.fromlinux.fan. 4.10.168.192.in- ადდრ.არპაში. 10800 IN PTR fileserver.fromlinux.fan. 5.10.168.192.in- ადდრ.არპაში. 10800 IN PTR dns.fromlinux.fan. 6.10.168.192.in- ადდრ.არპაში. 10800 IN PTR proxyweb.fromlinux.fan. 7.10.168.192.in- ადდრ.არპაში. 10800 IN PTR ბლოგზე .desdelinux.fan. 8.10.168.192.in.addr.arpa. 10800 IN PTR ftpserver.fromlinux.fan. 9.10.168.192.in- ადდრ.არპაში. 10800 IN PTR ფოსტა. Fromlinux.fan. 10.168.192. in- ადრ. არპა. 10800 IN SOA dns.fromlinux.fan.10.168.192.in-addr.arpa. root.dns.fromlinux.fan.10.168.192.in-addr.arpa. 1 86400 3600 604800 10800 ;; შეკითხვის დრო: 0 msec ;; სერვერი: 192.168.10.5 # 53 (192.168.10.5) ;; როდის: მზე 29 იანვარს 11:44:57 EST 2017 ;; XFR ზომა: 11 ჩანაწერი (შეტყობინებები 1, ბაიტი 352) buzz @ sysadmin: ~ $ dig in SOA საწყისი linux.fan buzz @ sysadmin: dig $ dig in MX linux.fan buzz @ sysadmin: ~ $ dig IN TXT linux.fan buzz @ sysadmin: host $ მასპინძელი dns dns.fromlinux.fan აქვს მისამართი 192.168.10.5 buzz @ sysadmin: host $ მასპინძელი sysadmin sysadmin.desdelinux.fan მისამართი აქვს 192.168.10.1 ... და ჩვენთვის საჭირო ნებისმიერი სხვა შემოწმება
- ჯერჯერობით, ჩვენ გვაქვს საფუძველი DNS სერვერის ჩვენს SME ქსელში. ვიმედოვნებთ, რომ მოგეწონათ მთელი პროცედურა, რომელიც საკმაოდ მარტივი იყო, არა? 😉
ჩვენ ვაყენებთ და ვაყენებთ კონფიგურაციას DHCP
[root @ dns] # yum დააყენეთ dhcp დატვირთული დანამატები: fastestmirror, centos-base langpacks | 3.4 kB 00:00:00 centos- განახლებები | 3.4 kB 00:00:00 ინახება სარკის სიჩქარე cached hostfile– დან დამოკიდებულების ამოხსნა -> გარიგების ტესტის გაშვება -> პაკეტი dhcp.x86_64 12: 4.2.5-42.el7.centos უნდა იყოს დაინსტალირებული -> დამოკიდებულებების ამოხსნა წყდება გადაჭრილი დამოკიდებულებები =============================================== ================================================ ===================================== პაკეტის არქიტექტურის ვერსიის საცავის ზომა ============ ================================================ ================================================ ======================= ინსტალაცია: dhcp x86_64 12: 4.2.5-42.el7.centos centos-base 511 k ტრანზაქციის რეზიუმე ==== ================================================ ================================================ ============================= დააინსტალირეთ 1 პაკეტი ჩამოტვირთვის ჯამური ზომა: 511 კ დაინსტალირებული ზომა: 1.4 მ კარგად არის [y / d / N]: y პაკეტების ჩამოტვირთვა: dhcp-4.2.5-42.el7.centos.x86_64.rpm | 511 kB 00:00:00 მიმდინარე ტრანსაქციის შემოწმება გარიგების ტესტის ჩატარება ტრანსაქციის ტესტი წარმატებით განხორციელდა ტრანსაქციის ჩატარება ინსტალაცია: 12: dhcp-4.2.5-42.el7.centos.x86_64 1/1 შემოწმება: 12: dhcp-4.2.5-42. el7.centos.x86_64 1/1 დაინსტალირებული: dhcp.x86_64 12: 4.2.5-42.el7.centos შესრულებულია! [root @ dns] # nano /etc/dhcp/dhcpd.conf # # DHCP სერვერის კონფიგურაციის ფაილი. # იხილეთ /usr/share/doc/dhcp*/dhcpd.conf.example # იხილეთ dhcpd.conf (5) man გვერდი # ddns-update-style interim; ddns- განახლებები ჩართულია; ddns-domainname "desdelinux.fan."; ddns-rev-domainname "in-addr.arpa."; კლიენტის განახლების იგნორირება; ავტორიტეტული; ვარიანტი ip- გადამისამართება გამორთულია; დომენის სახელი "desdelinux.fan"; # ვარიანტი ntp-servers 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, 3.pool.ntp.org; მოიცავს "/etc/dhcp.key"; ზონა linux– დან .fan. {პირველადი 127.0.0.1; გასაღები dhcp- გასაღები; } ზონა 10.168.192.in- ადდრ.არპაში. {პირველადი 127.0.0.1; გასაღები dhcp- გასაღები; } shared-network redlocal {subnet 192.168.10.0 netmask 255.255.255.0 {option router 192.168.10.1; ვარიანტი subnet-mask 255.255.255.0; ვარიანტი სამაუწყებლო-მისამართი 192.168.10.255; ვარიანტი domain-name-servers 192.168.10.5; ვარიანტი netbios-name-servers 192.168.10.5; დიაპაზონი 192.168.10.30 192.168.10.250; }} # END dhcpd.conf [root @ dns] # dhcpd -t ინტერნეტ სისტემების კონსორციუმი DHCP სერვერი 4.2.5 საავტორო უფლებები 2004-2013 ინტერნეტ სისტემების კონსორციუმი. Ყველა უფლება დაცულია. ინფორმაციისთვის, ეწვიეთ https://www.isc.org/software/dhcp/ არ ეძებთ LDAP- ს, რადგან ldap-server, ldap-port და ldap-base-dn არ იყო მითითებული კონფიგურაციის ფაილში [root @ dns] # systemctl საშუალებას dhcpd შეიქმნა სიგნალი /etc/systemd/system/multi-user.target.wants/dhcpd.service- დან /usr/lib/systemd/system/dhcpd.service- დან. [root @ dns] # systemctl იწყება dhcpd [root @ dns] # systemctl სტატუსი dhcpd ● dhcpd.service - DHCPv4 სერვერი Daemon დატვირთულია: დატვირთულია (/usr/lib/systemd/system/dhcpd.service; ჩართულია; გამყიდველის წინასწარ დაყენებული: გამორთულია) აქტიური: აქტიური (გაშვებული) 2017-01-29 12:04:59 მისი T; 23 წლის წინ Docs: man: dhcpd (8) man: dhcpd.conf (5) მთავარი PID: 2381 (dhcpd) სტატუსი: "პაკეტების გაგზავნა ..." C ჯგუფი: /system.slice/dhcpd.service 2381 / usr / sbin / dhcpd -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd - no-pid 29 იანვარს 12:04:59 dns dhcpd [2381]: Internet Systems Consortium DHCP Server 4.2.5 29 იანვარი 12 04 : 59: 2381 dns dhcpd [2004]: საავტორო უფლებები 2013-29 ინტერნეტ სისტემების კონსორციუმი. 12 იანვარი 04:59:2381 dns dhcpd [29]: ყველა უფლება დაცულია. 12 იანვარის 04:59:2381 dns dhcpd [29]: ინფორმაციისთვის ეწვიეთ https://www.isc.org/software/dhcp/ 12 იანვარს 04:59:2381 dns dhcpd [29]: LDAP– ს არ ეძებთ ldap– დან -სერვერი, ldap-port და ldap-base-dn არ იყო მითითებული კონფიგურაციის ფაილში 12 იანვარი 04:59:2381 dns dhcpd [0]: დაწერა 29 საიჯარო საიტის იჯარა. 12 იანვარის 04:59:2381 dns dhcpd [0]: მოსმენა LPF / eth52 / 54: 00: 12: 17: 04: 29 / redlocal 12 იანვარს 04:59:2381 dns dhcpd [0]: იგზავნება LPF / eth52 / 54: 00: 12: 17: 04: 29 / redlocal 12 იანვარი 04:59:2381 dns dhcpd [29]: Socket / fallback / fallback-net- ზე გაგზავნა 12 იანვარს 04:59:1 dns systemd [4]: დაიწყო DHCPvXNUMX სერვერი Daemon.
რა რჩება გასაკეთებელი?
მარტივი დაიწყეთ Windows 7 ან სხვა კლიენტი უფასო პროგრამით და დაიწყეთ ტესტირება და შემოწმება. ჩვენ ეს გავაკეთეთ ორ კლიენტთან ერთად: შვიდი.ფრომლინუქსი.ფანი y suse-desktop.fromlinux.fan. შემოწმებები შემდეგი იყო:
buzz @ sysadmin: ~ $ მასპინძელი შვიდი Seve.fromlinux.fan– ს აქვს მისამართი 192.168.10.30 buzz @ sysadmin: host $ მასპინძელი Seve.fromlinux.fan Seve.fromlinux.fan– ს აქვს მისამართი 192.168.10.30 buzz @ sysadmin: ~ $ dig in TXT seven.fromlinux.fan .... ;; კითხვის განყოფილება:; შვიდი. Fromlinux.fan. IN TXT ;; პასუხი განყოფილება: შვიდი.desdelinux.fan. 3600 IN TXT "31b7228ddd3a3b73be2fda9e09e601f3e9"....
ჩვენ გუნდს ვუწოდებთ "შვიდს" "LAGER" და გადატვირთეთ. ახალი LAGER- ის გადატვირთვის შემდეგ, ჩვენ ვამოწმებთ:
buzz @ sysadmin: ~ $ მასპინძელი შვიდი მასპინძელი შვიდი ვერ მოიძებნა: 5 (უარყოფილია) buzz @ sysadmin: host $ მასპინძელი Seve.fromlinux.fan მასპინძელი Seve.desdelinux.fan ვერ მოიძებნა: 3 (NXDOMAIN) ბაზ@sysadmin: host $ მასპინძელი lager.desdelinux.fan აქვს მისამართი 192.168.10.30 ბაზ@sysadmin: ~ $ მასპინძელი lager.fromlinux.fan lager.desdelinux.fan აქვს მისამართი 192.168.10.30 buzz @ sysadmin: ~ $ dig IN TXT lager.fromlinux.fan .... ;; კითხვა სექცია:; lager.fromlinux.fan. IN TXT ;; პასუხის ნაწილი: lager.fromlinux.fan. 3600 IN TXT "31b7228ddd3a3b73be2fda9e09e601f3e9"....
Suse-desktop კლიენტის შესახებ:
buzz @ sysadmin: host $ host suse-dektop მასპინძელი suse-dektop ვერ მოიძებნა: 5 (უარყოფილია) buzz @ sysadmin: host $ host suse-desktop suse-desktop.desdelinux.fan აქვს მისამართი 192.168.10.33 buzz @ sysadmin: host $ მასპინძელი suse-desktop.fromlinux.fan suse-desktop.desdelinux.fan აქვს მისამართი 192.168.10.33 buzz @ sysadmin: host $ მასპინძელი 192.168.10.33 33.10.168.192.in-addr.arpa დომენის სახელის მაჩვენებელი suse-desktop.desdelinux.fan. buzz @ sysadmin: host $ მასპინძელი 192.168.10.30 30.10.168.192.in-addr.arpa დომენის სახელის მაჩვენებელი LAGER.desdelinux.fan.
buzz @ sysadmin: dig $ dig -x 192.168.10.33 .... ;; კითხვის სექცია: 33.10.168.192.in- ადდრ.არპაში. IN PTR ;; პასუხი განყოფილება: 33.10.168.192.in- ადდრ.არპაში. 3600 IN PTR suse-desktop.fromlinux.fan. ;; უფლებამოსილების სექცია: 10.168.192.in-addr.arpa. 10800 IN NS dns.fromlinux.fan. ;; დამატებითი სექცია: dns.fromlinux.fan. 10800 A 192.168.10.5 წელს .... buzz @ sysadmin: ~ $ dig IN TXT suse-desktop.fromlinux.fan .... ; suse-desktop.desdelinux.fan. IN TXT ;; პასუხის გაცემა სექცია: suse-desktop.desdelinux.fan. 3600 TXT "31b78d287769160c93e6dca472e9b46d73" ;; უფლებამოსილების განყოფილება: desdelinux.fan. 10800 IN NS dns.fromlinux.fan. ;; დამატებითი სექცია: dns.fromlinux.fan. 10800 წელს 192.168.10.5 ....
მოდით ასევე გავაწარმოოთ შემდეგი ბრძანებები
[root @ dns] # იჭრება linux.fan axfr- დან ; << >> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 << >> desdelinux.fan axfr ;; გლობალური პარამეტრები: + cmd საწყისი linux.fan. 10800 SOA dns.fromlinux.fan. root.dns.fromlinux.fan. 6 86400 3600 604800 10800 linux- ისგან .fan. 10800 IN NS dns.fromlinux.fan. linux– დან .fan. 10800 IN MX 10 mail.fromlinux.fan. linux– დან .fan. 10800 TXT "FromLinux, თქვენი ბლოგი ეძღვნება თავისუფალ პროგრამულ უზრუნველყოფას" ad-dc.desdelinux.fan. 10800 წელს 192.168.10.3 ბლოგზე .desdelinux.fan. 10800 A 192.168.10.7 dns.fromlinux.fan. 10800 IN 192.168.10.5 fileserver.fromlinux.fan. 10800 IN 192.168.10.4 ftpserver.fromlinux.fan. 10800 წელს 192.168.10.8 LAGER.fromlinux.fan. 3600 IN TXT "31b7228ddd3a3b73be2fda9e09e601f3e9"LAGER.fromlinux.fan. 3600 In 192.168.10.30 mail.fromlinux.fan. 10800 IN 192.168.10.9 proxyweb.fromlinux.fan. 10800 IN 192.168.10.6 suse-desktop.fromlinux.fan. 3600 IN TXT "31b78d287769160c93e6dca472e9b46d73"suse-desktop.desdelinux.fan. 3600 192.168.10.33 წელს sysadmin.fromlinux.fan. 10800 IN დან 192.168.10.1 მდე linux.fan. 10800 SOA dns.fromlinux.fan. root.dns.fromlinux.fan. 6 86400 3600 604800 10800
ზემოთ მოცემულ გამოცემაში ჩვენ გამოვყოთ თამამი მათ TTL წამებში - DHCP სერვისის მიერ მინიჭებული IP მისამართების მქონე კომპიუტერებისთვის, მათთვის, ვისაც აქვს DHCP- ის მიერ გაცხადებული TTL 3600- ის დეკლარაცია. ფიქსირებულ IP– ებს ხელმძღვანელობს თითოეული ზონის ფაილის SOA ჩანაწერში გამოცხადებული $ TTL 3H –3 საათი = 10800 წამი.
მათ შეუძლიათ უკუქცევითი ზონის შემოწმება ანალოგიურად.
[root @ dns] # dig 10.168.192.in-addr.arpa axfr
სხვა ძალიან საინტერესო ბრძანებებია:
[root @ dns] # names-journalprint /var/named/dynamic/db.desdelinux.fan.jnl [root @ dns] # names-journalprint /var/named/dynamic/db.10.168.192.in-addr.arpa.jnl [root @ dns] # journalctl -f
ზონების ფაილების ხელით მოდიფიკაცია
მას შემდეგ, რაც DHCP შემოდის თამაშში, დინამიურად განახლდება ზონის ფაილები დასახელდათუ ოდესმე დაგვჭირდება ზონის ფაილის ხელით შეცვლა, უნდა გავატაროთ შემდეგი პროცედურა, მაგრამ არა მანამდე, სანამ ოდნავ მეტს გავიგებთ კომუნალური მუშაობის შესახებ rndc სახელის სერვერის კონტროლისთვის.
[root @ dns] # კაცი rndc .... ყინვა [ზონა [კლასი [ნახვა]]] დინამიური ზონის განახლებების შეჩერება. თუ ზონა არ არის მითითებული, ყველა ზონა შეჩერებულია. ეს საშუალებას იძლევა ხელით რედაქტირდეს ზონაში, რომელიც ჩვეულებრივ განახლდება დინამიური განახლებით. ეს ასევე იწვევს ჟურნალის ფაილის ცვლილებების სინქრონიზაციას საძიებო ფაილში. დინამიური განახლების ყველა მცდელობა უარყოფილი იქნება, სანამ ზონა გაყინულია. დათბობა [ზონა [კლასი [ნახვა]]] გაყინული დინამიური ზონის განახლებების ჩართვა. თუ ზონა არ არის მითითებული, მაშინ ყველა გაყინული ზონა ჩართულია. ეს იწვევს სერვერს ზონის დისკიდან ხელახლა ჩატვირთვას და დატვირთვის დასრულების შემდეგ კვლავ ჩართავს დინამიურ განახლებებს. ზონის დათბობის შემდეგ, დინამიკურ განახლებებზე უარი აღარ იქნება. თუ ზონა შეიცვალა და გამოიყენება ixfr-from- განსხვავებების ვარიანტი, მაშინ ჟურნალის ფაილი განახლდება, რომ ასახოს ზონაში მომხდარი ცვლილებები. წინააღმდეგ შემთხვევაში, ზონის შეცვლის შემთხვევაში, არსებული ჟურნალის ფაილი წაიშლება. ....
რა, გგონია, მთელი სახელმძღვანელოს გადაწერას ვაპირებ? ... ცალი და ისინი მანქანით მიდიან. დანარჩენს კი შენზე ვტოვებ. 😉
ძირითადად:
- rndc ყინვები [ზონა [კლასი [ნახვა]]], აჩერებს ზონის დინამიკურ განახლებას. თუ ერთი არ არის მითითებული, ყველა გაყინული იქნება. ბრძანება საშუალებას იძლევა გაყინული ზონის ან ყველა ზონის ხელით რედაქტირება. ნებისმიერი დინამიური განახლება უარყოფილი იქნება გაყინვის დროს.
- rndc დათბობა [ზონა [კლასი [ნახვა]]], საშუალებას იძლევა დინამიური განახლებები ადრე გაყინულ ზონაზე. DNS სერვერი გადატვირთავს ზონის ფაილს დისკიდან, ხოლო დინამიკური განახლებები ხელახლა ჩართულია გადატვირთვის დასრულების შემდეგ.
გაფრთხილება უნდა იქნას მიღებული ზონის ფაილის ხელით რედაქტირებისას? იგივე, რაც ჩვენ ვქმნით მას, არ უნდა დაგვავიწყდეს სერიული ნომრის 1-ით გაზრდა სერიალი ფაილის შენახვა საბოლოო ცვლილებებით.
მაგალითად:
[root @ dns] # rndc გაყინვას linux.fan– ისგან
[root @ dns] # nano /var/named/dynamic/db.fromlinux.fan
მე ვცვლი ზონის ფაილს რაიმე მიზეზით, აუცილებელი თუ არა. მე ვინახავ ცვლილებებს
[root @ dns] # rndc დათბობა linux.fan– დან
დაიწყო ზონის განახლება და დათბობა. შეამოწმეთ ჟურნალები, რომ ნახოთ შედეგი.
[root @ dns] # journalctl -f
29 იანვარს 14:06:46 dns დაასახელა [2257]: დათბობის ზონა 'desdelinux.fan/IN': წარმატება
29 იანვარს 14:06:46 dns დაასახელა [2257]: zone linux.fan/IN: ზონის სერიული (6) უცვლელი. ზონა შეიძლება ვერ გადავიდეს მონებზე.
29 იანვარს 14:06:46 dns დაასახელა [2257]: zone desdelinux.fan/IN: დატვირთულია სერიული 6
წინა გამოსვლის შეცდომა, რომელიც წითლად გამოჩნდება კონსოლზე, გამოწვეულია იმით, რომ "დამავიწყდა" სერიული ნომრის 1-ით გაზრდა. თუ პროცედურას სწორად მივყვებოდი, გამომავალი იქნებოდა
[root @ dns] # journalctl -f - ჟურნალები იწყება მზე 2017-01-29 08:31:32 EST. - 29 იანვარს 14:06:46 dns დაასახელა [2257]: zone desdelinux.fan/IN: ჩაიტვირთა სერია 6 იანვარს 29 14:10:01 dns systemd [1]: დაიწყო მომხმარებლის ფესვის 43-ე სესია. 29 იანვარს 14:10:01 dns systemd [1]: მომხმარებლის ფესვის 43-ე სესიის დაწყება. 29 იანვარს 14:10:01 dns CROND [2693]: (root) CMD (/ usr / lib64 / sa / sa1 1 1) 29 იანვარს 14:10:45 dns დაასახელა [2257]: მიიღო კონტროლის არხის ბრძანება 'გაყინვა Linux- ისგან. გულშემატკივართა '29 იანვარს 14:10:45 dns დაასახელა [2257]: გაყინვის ზონა' desdelinux.fan/IN ': წარმატება 29 იანვარს 14:10:58 dns დაასახელა [2257]: მიიღო კონტროლის არხის ბრძანება' thaw desdelinux.fan 'Jan 29 14:10:58 დნს დაასახელა [2257]: გალღობა ზონაში 'desdelinux.fan/IN': წარმატება 29 იანვარს 14:10:58 დნს დაასახელა [2257]: ზონა desdelinux.fan/IN: ჟურნალის ფაილი მოძველებულია: ჟურნალის ფაილის ამოღება 29 იანვარს 14:10:58 dns დაასახელა [2257]: zone desdelinux.fan/IN: დატვირთულია სერიული 7
- მკითხველო მეგობრებო, ვიმეორებ, რომ ყურადღებით უნდა წაიკითხოთ ბრძანებების შედეგები. რისთვისაც მისმა დეველოპერებმა იმდენი სამუშაო დახარჯეს თითოეული ბრძანების პროგრამირებაში, რაც არ უნდა მარტივი იყოს იგი.
რეზიუმე
ჯერჯერობით ჩვენ განვიხილეთ DNS - DHCP წყვილი, მნიშვნელოვანი და გადამწყვეტი სერვისები ჩვენი მცირე და საშუალო ბიზნესის ქსელის მუშაობისთვის, რაც ეხება DHCP– ის მეშვეობით დინამიური მისამართების მინიჭებას და DNS– ით კომპიუტერისა და დომენური სახელების გადაწყვეტას.
ვიმედოვნებთ, რომ თქვენც მოგეწონათ მთელი პროცედურა. მიუხედავად იმისა, რომ შეიძლება უფრო რთული ჩანდეს კონსოლის გამოყენება, მისი დახმარებით UNIX and / Linux- ში სერვისის დანერგვა ბევრად უფრო მარტივი და აღმზრდელია.
ისინი მაპატიებენ შექსპირის და არა სერვანტესის ენაზე შექმნილი, დაწერილი, შესწორებული, გადაწერილი და გამოქვეყნებული ცნებების არასწორი ინტერპრეტაციისთვის. 😉
შემდეგი მიწოდება
მე ვფიქრობ, ცოტა მეტი იგივე - თეორიული დამატება DNS ჩანაწერებზე - მაგრამ Debian- ში. ჩვენ არ შეგვიძლია დავივიწყოთ ეს განაწილება, არა?
15 კომენტარი დატოვე შენი
დიდი მადლობა ასეთი ნაყოფიერი სტატიების წერაში თქვენი საქებრისთვის. ეს ჩემთვის ძალიან სასარგებლო იქნება
და დიდი მადლობა, კრისტიან, რომ გამომყევი და ამ პოსტის შეფასებისთვის. წარმატებები!
ფედერიკოს ამ ახალ პოსტს პირველად გადახედვის შემდეგ, კიდევ ერთხელ შეიმჩნევა დიდი პროფესიონალიზმი, რომელიც ჩანს მთელი PYMES სერიის განმავლობაში; შესანიშნავი დეტალების გარდა, რომელიც ასახავს თქვენს დომენს ნებისმიერი ქსელის ორ ყველაზე მნიშვნელოვან სერვისზე (DNS და DHCP). ამ შემთხვევით და ჩემი წინა კომენტარებისგან განსხვავებით, მე მაქვს მეორე კომენტარი, რომელიც გაკეთდა მას შემდეგ, რაც პრაქტიკულად გამოიყენა ის, რაც ამ პოსტში აღვნიშნე.
კომენტარები არ არის, 400-ზე !!! ფიკო მადლობას გიხდით, რადგან თქვენ კარგად იცით, რომ თქვენს პოსტებს ვკითხულობ და მეტის მოთხოვნა არ შეგვიძლია. თქვენ იწყება ძალიან კარგი ორგანიზაციით, თუ როგორ უნდა დააყენოთ და დააყენოთ მომხმარებლის პერსონალური სამუშაო მაგიდა, სამუშაო სადგური არის საფუძველი, ეს არის ქსელის სერვისების არსებობის გრძნობა, რომლებსაც კარგად ხსნით. თქვენ ასვლაზე ხართ და მართალია, რომ დონე იზრდება, მართალია, თქვენ დაწერეთ და გამოაქვეყნეთ მათთვის, ვინც იმაზე ნაკლებია, ვინც იწყებს, მათთვის, ვინც გარკვეული დროით ჩემნაირია და ყველაზე მოწინავე.
დროთა განმავლობაში მივედი იმ დასკვნამდე, რომ ვიცი, რომ ბევრი უკვე ჩამოვიდა, თეორია, რომლის შეძენაც ამდენს გვიღირს იმის გამო, რომ არ გვინდა კითხვა, რადგან შესრულება უკვე ბევრად უფრო ადვილია, როდესაც ვიცით, რას ვაკეთებთ, რატომ ???, კითხვები, სად უნდა ვიპოვოთ და როგორ უნდა დააღწიოთ შეცდომას, რომელიც ამდენ თავის ტკივილს იწვევს, როდესაც არც კი ვიცით საიდან წარმოიშვა ეს ზედმეტი.
ამ მიზეზით, მე არ მსურს დატოვოთ ის თეორიული ელემენტები, რომლებსაც შეიტანთ DNS ჩანაწერებთან დაკავშირებით თქვენს მიერ გამოცხადებულ შემდეგ პუბლიკაციაში, მით უფრო, როდესაც საქმე ეხება საყვარელ და საყვარელ DEBIAN- ს.
დიდი მადლობა და ველოდებით.
შესანიშნავი, როგორც ყოველთვის ფიკო! ველოდები დებიანის ვერსიას, წლების განმავლობაში ყველაფერს ვთამაშობდი ამ დისტროთი.
ვონგი: თქვენი აზრი წაკითხვის შემდეგ ბევრს ღირს. ველოდები თქვენს კომენტარს, როდესაც შეამოწმებთ შინაარსს, რადგან ვიცი, რომ ასე გსურთ ამის გაკეთება. 😉
კრესპო: როგორც ყოველთვის, თქვენი კომენტარები ძალიან კარგად არის მიღებული. მე ვხედავ, რომ თქვენ აიღეთ ზოგადი ხაზი, რომელიც მე წამოვწიე ამ სერიის კომპოზიციაში. იმედი მაქვს, რომ შენსავით ბევრმა უკვე შეამჩნია. მადლობა კომენტარისთვის.
დუნტერი: კარგია, რომ კიდევ ერთხელ წამიკითხავ! დიდხანს ლოდინი აღარ მოგიწევთ. არაუგვიანეს ორშაბათისთვის - ან მანამდე - ის დასრულდება გამოსაქვეყნებლად. არ იფიქროთ, რომ ჩემთვის ადვილია სამი განსხვავებული დისტრიბუციის გაშუქება, მაგრამ პატივცემული მკითხველი ამას ითხოვს. არა მხოლოდ Debian და Ubuntu, არამედ სამი ორიენტირებული მცირე და საშუალო ბიზნესის მიმართულებით.
კარგით, თუ გამოაქვეყნეთ ეს იმიტომ, რომ შეგიძლიათ, ჩვენ მხარს ვუჭერთ თქვენ და ვიცით, რომ თქვენ ამ ხაზს მიჰყვებით.
როგორც დუნტი, დაველოდები დებიანის გათავისუფლებას ბასრი კბილებით. კარგი იქნება, თუ ცოტათი გააშუქებთ NTP– ს შესახებ. Sl2 და დიდი ჩახუტება. თუ ჩემმა მასწავლებლებმა მასწავლეს ყველაფერი ასე, HAHAJJA, Platinum Degree, HAHAJJA.
ბრძანების შედეგებში დეტალების დონე აუცილებელია მისი მნიშვნელობის საჩვენებლად. ისინი ბევრს ამბობენ. მართალია, რამდენიმე სტატია ამ დონის დეტალებს ეხება, რადგან მათ მიაჩნიათ, რომ წაკითხული იქნება გრძელი და მძიმე სტატიები. SysAdmin– ის ამოცანის ნაწილია ამ მძიმე და დეტალური შედეგების წაკითხვა, არა მხოლოდ პრობლემის წინაშე, არამედ შემოწმების წინაშეც.
გამარჯობა ფედერიკო, ადრეც დავპირდი, რომ კომენტარს დავწერ მას შემდეგ, რაც ყურადღებით შეისწავლიდი პოსტს; აი, შემდეგ ისინი მიდიან:
- DHCP- ის მიერ DNS დინამიური განახლებებისთვის TSIG გასაღების გენერირების ნაცვლად, იგივე rndc.key გასაღების კოპირება, როგორც dhcp.key, აშკარად "ასე მარტივი" აჩვენებს, რომ მიზანი მხოლოდ ტექნიკური არ არის HOWTO-INSTALL-DNS - & - DHCP, მაგრამ გვასწავლის ფიქრს, 5 ვარსკვლავი ავტორს.
- ძალიან საინტერესოა DNS კონფიგურაციის ფაილში, names.conf, ხაზის არსებობა «allow-transfer {localhost; 192.168.10.1; }; » დომენის «desdelinux.fan» შესამოწმებლად მხოლოდ SysAdmin სამუშაო სადგურიდან და localhost- იდან (თვითონ DNS სერვერი) და ასევე ჩასმა TSIG გასაღები DHCP– დან DNS– ის განახლებისთვის.
- ძალიან კარგია DNS- ის პირდაპირი და შებრუნებული ზონების შექმნა, ასევე მათი ტიპის ჩანაწერების "დეტალური" განმარტება, ასევე ბრძანების შესრულების გარდა "# named-checkconf -zp", რათა შეამოწმოს დასახელებული ყველა სინტაქსი მის გამოყენებამდე მყარი გადატვირთვის, ისევე როგორც "dig" ბრძანების გაშვების მაგალითები, სხვადასხვა ტიპის DNS ჩანაწერების დასაზუსტებლად.
. DHCP კონფიგურაციაში (/etc/dhcp/dhcpd.conf ფაილის გამოყენებით):
- როგორ დავამატოთ ჩვენი ადგილობრივი ქსელი თავისი დიაპაზონით, დინამიური IP მისამართების მინიჭებისთვის, სახელის სერვერის განმარტება და ა.შ. ასევე როგორ უნდა ვუთხრათ DHCP- ს განაახლოს DNS ჩანაწერები მის კონფიგურაციაში "ddns- ..." ხაზების გამოყენებით.
. როდესაც ყველაფერი უკვე ფუნქციონირებს, 5 ვარსკვლავი ავტორი ავტორი, შეასრულოს ბრძანება "# dig desdelinux.fan axfr", რათა შეამოწმოს კომპიუტერების TTL LAN- ში, რომლებსაც აქვთ სტატიკური IP, რომელთაც აქვთ მინიჭებული დინამიური IP.
. დაბოლოს, GREAT, ზონების ფაილების სახელმძღვანელო მოდიფიკაცია მათ გაყინვით ჯერ "# rndc freeze desdelinux.fan" - ით, შემდეგ ცვლილებების შეტანა და ბოლოს მათი გაყინვა "# rndc thaw desdelinux.fan" - ით
. და საუკეთესო, ყველაფერი გაკეთდა ტერმინალიდან.
გააგრძელე ფიკო.
Hello,
მე შემიძლია ვთქვათ, რომ ეს არის იგივე გამოძიება, რომელიც შეგიძლიათ გააკეთოთ, თუ გსურთ გამოიყენოთ ეს მონაცემები და დააჭირეთ თქვენს კომპიუტერს. ასე რომ, მთლიანი გენი აკონტროლებენ მობილური ტელეფონზე.
Het zit m dus ook in het dns in dhcp. Ik weet echt niet hoe ik dit moet oplossen en het kan verwijderen. Missichien dat iemand mij გინდა დახმარება? Dit არის სახელი, რომელიც არის მეტი პროგრამა. Walgelijk gedrag vind ik het.
ვონგი: თქვენი კომენტარი ავსებს სტატიას. სერიოზულად, ეს გვიჩვენებს, რომ თქვენ ის საფუძვლიანად შეისწავლეთ. წინააღმდეგ შემთხვევაში, თქვენ ვერ გააკეთებთ კომენტარს დეტალების დონით, რასაც აკეთებთ. უბრალოდ დაამატე ეს დაშვება-გადაცემა ის ძირითადად გამოიყენება მაშინ, როდესაც გვაქვს DNS Slave და ჩვენ ვუშვებთ ზონების გადატანას მასტერიდან მასზე. მე ასე ვიყენებ, რადგან ეს არის მარტივი განსახორციელებელი მექანიზმი, რომლითაც ხდება ერთი კომპიუტერიდან არა საშიში შემოწმება. დიდი მადლობა თქვენი 5 შეფასებისთვის. მოგესალმებით! და გელოდები ჩემს შემდეგ სტატიებში.
გამარჯობა ფედერიკო. ვიცი, რომ ცოტა დამაგვიანდა, მაგრამ მინდა კითხვა დამისვა.
დამეხმარება ეს პროცედურა, თუ მსურს დომენის მითითება ჩემს VPS სერვერზე?
ყოველ 15 წუთში მივიღებ ამ სისტემურ შეტყობინებებს:
DHCPREQUEST eth0- ზე 67 პორტისკენ (xid =…)
DHCPACK დან (xid =)
ვალდებულია - განახლება 970 წამში.
და რაც მე მესმის, უნდა შევქმნა A ჩანაწერი ჩემი დომენით და ჩემი ერთგულ სერვერზე.
* ვულოცავ და მადლობას გიხდით ამ სტატიისთვის, არ ვიცი ის არის თუ არა ის, რასაც ვეძებდი, მაგრამ მე ეს ძალიან საინტერესო და კარგად ახსნილი მქონდა. გარდა ამისა, მე ვიღებ რეკომენდაციას "DNS და BIND" - ის შესახებ, რომ უკვე ცოტათი ვჭორაობდი და ძალიან საინტერესო ჩანს.
მივესალმოთ არგენტინიდან!
გთხოვთ დამიკავშირდეთ valdestoujague@yandex.com