DNS (დომენის სახელების სისტემა) არის მნიშვნელოვანი და საკმაოდ რთული კონფიგურაციის კომპონენტი, რომელიც აუცილებელია ვებსაიტების და სერვერების მუშაობისთვის. ბევრი მომხმარებელი იყენებს მათი ჰოსტინგის პროვაიდერის მიერ მოწოდებულ DNS სერვერებს, მაგრამ საკუთარი DNS სერვერების ფლობას აქვს გარკვეული უპირატესობები.
ამ გაკვეთილზე თქვენ შეისწავლით თუ როგორ დააინსტალიროთ Bind9 და დააკონფიგურიროთ როგორც ქეშირების ან გადამისამართების DNS სერვერი Ubuntu 14.04 სერვერზე.
მოთხოვნები
- DNS სერვერების ძირითადი ტიპების გაგება. დამატებითი დეტალების გაცნობა შეგიძლიათ აქ.
- ორი მანქანა, რომელთაგან ერთი მაინც მუშაობს Ubuntu 14.04-ზე. პირველი მანქანა კონფიგურირებული იქნება როგორც კლიენტი (IP მისამართი 192.0.2.100), ხოლო მეორე როგორც DNS სერვერი (192.0.2.1).
თქვენ შეისწავლით თუ როგორ უნდა დააკონფიგურიროთ კლიენტის მანქანა DNS სერვერის მეშვეობით მოთხოვნების გასაგზავნად.
DNS სერვერის ქეშირება
ამ ტიპის სერვერებს ასევე უწოდებენ გადამწყვეტებს, რადგან ისინი ამუშავებენ რეკურსიულ შეკითხვებს და ჩვეულებრივ შეუძლიათ მოძებნონ DNS მონაცემები სხვა სერვერებიდან.
როდესაც ქეშირების DNS სერვერი მონიტორინგს უწევს კლიენტის მოთხოვნაზე პასუხს, ის უბრუნებს პასუხს კლიენტს და ასევე ინახავს მას ქეშში შესაბამისი DNS ჩანაწერების TTL მნიშვნელობით დაშვებული დროის განმავლობაში. შემდეგ ქეში შეიძლება გამოყენებულ იქნას, როგორც პასუხების წყარო შემდგომ მოთხოვნებზე, რათა დააჩქაროს მოთხოვნის დამუშავების საერთო დრო.
თქვენი ქსელის კონფიგურაციის თითქმის ყველა DNS სერვერი იქნება ქეშირებული. ქეშირების DNS სერვერი კარგი არჩევანია მრავალი სიტუაციისთვის. თუ არ გსურთ დაეყრდნოთ თქვენი ჰოსტინგის პროვაიდერის DNS სერვერებს ან სხვა საჯარო DNS სერვერებს, დააყენეთ თქვენი საკუთარი ქეშირების DNS სერვერი. რაც უფრო მოკლეა მანძილი DNS სერვერიდან კლიენტის მანქანებამდე, მით უფრო მოკლე დრო სჭირდება DNS მოთხოვნების მომსახურებას.
გადამისამართება DNS სერვერი
კლიენტის პერსპექტივიდან, გადამისამართების DNS სერვერი თითქმის იდენტური იქნება ქეშირების სერვერთან, მაგრამ მექანიზმები და დატვირთვა სრულიად განსხვავებულია.
გადამისამართების DNS სერვერს აქვს იგივე უპირატესობები, რაც ქეშირების სერვერს. თუმცა, ის რეალურად არ ასრულებს რეკურსიულ შეკითხვებს. ამის ნაცვლად, ის გადასცემს ყველა მოთხოვნას გარე გარჩევადობის სერვერზე და შემდეგ ქეშირებს შედეგებს შემდგომი მოთხოვნებისთვის.
ეს საშუალებას აძლევს გადამისამართების სერვერს მოემსახუროს მოთხოვნები მისი ქეშიდან რეკურსიული მოთხოვნების დამუშავების გარეშე. ამრიგად, ეს სერვერი ამუშავებს მხოლოდ ერთ მოთხოვნებს (კლიენტის გადამისამართებულ მოთხოვნებს) და არა მთელ რეკურსიის პროცედურას. ეს შეიძლება იყოს უპირატესობა შეზღუდული გარე გამტარუნარიანობის მქონე გარემოში, სადაც ქეშირების სერვერები ხშირად უნდა შეიცვალოს და იმ სიტუაციებში, როდესაც ლოკალური მოთხოვნები უნდა გადავიდეს ერთ სერვერზე და გარე მოთხოვნები მეორეზე.
1: დააინსტალირეთ Bind DNS სერვერზე
Bind პაკეტის ნახვა შეგიძლიათ Ubuntu-ს ოფიციალურ საცავში. განაახლეთ თქვენი პაკეტის ინდექსი და დააინსტალირეთ Bind apt მენეჯერის გამოყენებით. თქვენ ასევე გჭირდებათ რამდენიმე დამოკიდებულების დაყენება.
sudo apt-get განახლება
sudo apt-get install bind9 bind9utils bind9-doc
ამის შემდეგ შეგიძლიათ დაიწყოთ სერვერის დაყენება. ქეშირების სერვერის კონფიგურაცია შეიძლება გამოყენებულ იქნას, როგორც შაბლონი გადამისამართების სერვერის კონფიგურაციისთვის, ამიტომ ჯერ უნდა დააკონფიგურიროთ ქეშირების DNS სერვერი.
2: ქეშირების DNS სერვერის დაყენება
პირველ რიგში, თქვენ უნდა დააკონფიგურიროთ Bind, როგორც ქეშირების DNS სერვერი. ეს კონფიგურაცია აიძულებს სერვერს რეკურსიულად მოძებნოს პასუხები კლიენტის მოთხოვნებზე სხვა DNS სერვერებზე. ის თანმიმდევრულად იკითხავს ყველა შესაბამის DNS სერვერს, სანამ პასუხს არ იპოვის.
Bind კონფიგურაციის ფაილები ინახება /etc/bind დირექტორიაში.
ფაილების უმეტესობას არ სჭირდება რედაქტირება. მთავარ კონფიგურაციის ფაილს ეწოდება named.conf (დასახელებული და bind არის ერთი და იგივე აპლიკაციის ორი სახელი). ეს ფაილი მიუთითებს named.conf.options, named.conf.local და named.conf.default-zones ფაილებზე.
ქეშირების DNS სერვერის კონფიგურაციისთვის საჭიროა მხოლოდ named.conf.options-ის რედაქტირება.
sudo nano დასახელებული.conf.options
ეს ფაილი ასე გამოიყურება (კომენტარები გამოტოვებულია სიმარტივისთვის):
პარამეტრები (
დირექტორია "/var/cache/bind";
dnssec-validation auto;
listen-on-v6 (ნებისმიერი; );
};
ქეშირების სერვერის დასაყენებლად, თქვენ უნდა შექმნათ წვდომის კონტროლის სია, ან ACL.
თქვენ უნდა დაიცვათ DNS სერვერი, რომელიც ამუშავებს რეკურსიულ შეკითხვებს თავდამსხმელებისგან. DNS გამაძლიერებელი შეტევები განსაკუთრებით საშიშია, რადგან მათ შეუძლიათ სერვერის ჩართვა სერვისის უარყოფის განაწილებულ შეტევებში.
DNS გამაძლიერებელი შეტევები სერვერებისა და ვებსაიტების დაშლის ერთ-ერთი გზაა. ამისათვის თავდამსხმელები ცდილობენ იპოვონ საჯარო DNS სერვერები, რომლებიც ამუშავებენ რეკურსიულ შეკითხვებს. ისინი ატყუებენ მსხვერპლის IP მისამართს და უგზავნიან შეკითხვას, რომელიც უბრუნებს ძალიან დიდ პასუხს DNS სერვერზე. ამ შემთხვევაში, DNS სერვერი უბრუნებს ძალიან ბევრ მონაცემს მსხვერპლის სერვერზე მცირე მოთხოვნის საპასუხოდ, რაც ზრდის თავდამსხმელის ხელმისაწვდომ სიჩქარეს.
საჯარო რეკურსიული DNS სერვერის ჰოსტინგი მოითხოვს ფრთხილად კონფიგურაციას და ადმინისტრირებას. სერვერის გატეხვის თავიდან ასაცილებლად, დააკონფიგურირეთ IP მისამართების სია ან ქსელის დიაპაზონი, რომელსაც სერვერს შეუძლია ენდოს.
პარამეტრების ბლოკამდე დაამატეთ acl ბლოკი. შექმენით ლეიბლი ACL ჯგუფისთვის (ამ სახელმძღვანელოში ჯგუფს უწოდებენ goodclients).
კარგი კლიენტები (
};
პარამეტრები (
. . .
ამ ბლოკში ჩამოთვალეთ IP მისამართები ან ქსელები, რომლებსაც ექნებათ წვდომა ამ DNS სერვერზე. ვინაიდან სერვერი და კლიენტი მუშაობს /24 ქვექსელზე, შეგიძლიათ შეზღუდოთ წვდომა ამ ქვექსელზე. თქვენ ასევე უნდა განბლოკოთ localhost და localnets, რომლებიც ავტომატურად უკავშირდებიან.
კარგი კლიენტები (
192.0.2.0/24;
ლოკალჰოსტი;
ლოკალური ქსელები;
};
პარამეტრები (
. . .
ახლა თქვენ გაქვთ უსაფრთხო კლიენტი ACL. თქვენ შეგიძლიათ დაიწყოთ მოთხოვნის რეზოლუციის დაყენება პარამეტრების ბლოკში. დაამატეთ მას შემდეგი სტრიქონები:
პარამეტრები (
დირექტორია "/var/cache/bind";
რეკურსია დიახ;
. . .
პარამეტრების ბლოკი ცალსახად რთავს რეკურსიას და შემდეგ აკონფიგურირებს დაშვების შეკითხვის ოფციას ACL-ის გამოსაყენებლად. თქვენ ასევე შეგიძლიათ გამოიყენოთ სხვა პარამეტრი, როგორიცაა უფლება-რეკურსია, ACL ჯგუფზე მითითებისთვის. როდესაც რეკურსია ჩართულია, დაშვება-რეკურსია განსაზღვრავს კლიენტთა სიას, რომლებსაც შეუძლიათ გამოიყენონ რეკურსიული სერვისები.
თუმცა, თუ დაშვება-რეკურსია არ არის დაყენებული, Bind ბრუნდება allow-query-cache სიაში, შემდეგ დაშვების შეკითხვის სიაში და ბოლოს ნაგულისხმევი localnets და localhost სიებში. ვინაიდან ჩვენ ვაყენებთ მხოლოდ ქეშირების სერვერს (მას არ აქვს საკუთარი ზონები და არ აგზავნის შეკითხვებს), დაშვებული მოთხოვნების სია ყოველთვის ვრცელდება მხოლოდ რეკურსიაზე. ეს არის ACL-ის განსაზღვრის ყველაზე გავრცელებული გზა.
შეინახეთ და დახურეთ ფაილი.
ეს არის ყველა პარამეტრი, რომელიც უნდა დაემატოს ქეშირების DNS სერვერის კონფიგურაციის ფაილს.
შენიშვნა: თუ გსურთ მხოლოდ ამ ტიპის DNS-ის გამოყენება, გააგრძელეთ კონფიგურაციების შემოწმება, სერვისის გადატვირთვა და კლიენტის კონფიგურაცია.
3: გადამისამართების DNS სერვერის დაყენება
თუ თქვენი ინფრასტრუქტურა უფრო მეტად შეეფერება გადამისამართების DNS სერვერს, შეგიძლიათ ოდნავ დაარეგულიროთ დაყენება.
ამჟამად named.conf.options ფაილი ასე გამოიყურება:
კარგი კლიენტები (
192.0.2.0/24;
ლოკალჰოსტი;
ლოკალური ქსელები;
};
პარამეტრები (
დირექტორია "/var/cache/bind";
რეკურსია დიახ;
დაშვება-შეკითხვა (კარგი კლიენტები;);
dnssec-validation auto;
auth-nxdomain no; # შეესაბამება RFC1035
listen-on-v6 (ნებისმიერი; );
};
თქვენ შეგიძლიათ გამოიყენოთ იგივე ACL, რომ შეზღუდოთ DNS სერვერი კლიენტების კონკრეტულ სიაზე. თუმცა, ეს მოითხოვს კონფიგურაციის მცირე ცვლილებას, რათა სერვერი აღარ შეეცადოს რეკურსიული მოთხოვნების შესრულებას.
არ შეცვალოთ რეკურსია No. გადამისამართების სერვერი კვლავ მხარს უჭერს რეკურსიულ სერვისებს. გადამისამართების სერვერის დასაყენებლად, თქვენ უნდა შექმნათ ქეშირების სერვერების სია, რომლებზეც ის გადამისამართებს მოთხოვნებს.
ეს კეთდება პარამეტრები() ბლოკში. პირველ რიგში, თქვენ უნდა შექმნათ მასში ახალი გადამგზავნის ბლოკი, სადაც შეინახება რეკურსიული სახელების სერვერების IP მისამართები, რომლებზეც გსურთ მოთხოვნების გადამისამართება. ამ შემთხვევაში, ეს იქნება Google DNS სერვერები (8.8.8.8 და 8.8.4.4):
. . .
პარამეტრები (
დირექტორია "/var/cache/bind";
რეკურსია დიახ;
დაშვება-შეკითხვა (კარგი კლიენტები;);
ექსპედიტორები (
8.8.8.8;
8.8.4.4;
};
. . .
შედეგად მიღებული კონფიგურაცია ასე გამოიყურება:
კარგი კლიენტები (
192.0.2.0/24;
ლოკალჰოსტი;
ლოკალური ქსელები;
};
პარამეტრები (
დირექტორია "/var/cache/bind";
რეკურსია დიახ;
დაშვება-შეკითხვა (კარგი კლიენტები;);
ექსპედიტორები (
8.8.8.8;
8.8.4.4;
};
მხოლოდ წინ;
dnssec-validation auto;
auth-nxdomain no; # შეესაბამება RFC1035
listen-on-v6 (ნებისმიერი; );
};
ბოლო ცვლილება ეხება dnssec პარამეტრს. მიმდინარე კონფიგურაციით და DNS სერვერების პარამეტრებიდან გამომდინარე, რომლებზეც გადამისამართებულია მოთხოვნები, შემდეგი შეცდომები შეიძლება გამოჩნდეს ჟურნალებში:
25 ივნისი 15:03:29 დასახელებული ქეში: შეცდომა (დადევნე DS სერვერები) ამოხსნის "in-addr.arpa/DS/IN": 8.8.8.8#53
25 ივნისი 15:03:29 დასახელებული ქეში: შეცდომა (არ არის სწორი DS) გადაჭრის "111.111.111.111.in-addr.arpa/PTR/IN": 8.8.4.4#53
მათ თავიდან ასაცილებლად, თქვენ უნდა შეცვალოთ dnssec-validation პარამეტრი დიახ და ცალსახად ჩართოთ dnssec.
. . .
მხოლოდ წინ;
dnssec-ჩართეთ დიახ;
dnssec-ვალიდაცია დიახ;
auth-nxdomain no; # შეესაბამება RFC1035
. . .
შეინახეთ და დახურეთ ფაილი. გადამისამართების DNS სერვერის დაყენება დასრულებულია.
4: შეამოწმეთ პარამეტრები და გადატვირთეთ Bind
ახლა თქვენ უნდა დარწმუნდეთ, რომ პარამეტრები მუშაობს ისე, როგორც მოსალოდნელია.
კონფიგურაციის ფაილების სინტაქსის შესამოწმებლად, შეიყვანეთ:
sudo სახელად-checkconf
თუ ფაილებში შეცდომები არ არის, ბრძანების სტრიქონი არ აჩვენებს რაიმე გამომავალს.
თუ თქვენ მიიღებთ შეცდომის შეტყობინებას, შეასწორეთ და ხელახლა შეამოწმეთ.
შემდეგ შეგიძლიათ გადატვირთოთ Bind daemon პარამეტრების განახლებისთვის.
sudo სერვისის bind9 გადატვირთვა
შემდეგ თქვენ უნდა შეამოწმოთ სერვერის ჟურნალი. გაუშვით ბრძანება სერვერზე:
sudo tail -f /var/log/syslog
ახლა გახსენით ახალი ტერმინალი და დაიწყეთ კლიენტის აპარატის დაყენება.
5: კლიენტის დაყენება
შესვლა კლიენტის მანქანაში. დარწმუნდით, რომ კლიენტი ჩამოთვლილი იყო კონფიგურირებული DNS სერვერის ACL ჯგუფში. წინააღმდეგ შემთხვევაში, DNS სერვერი უარს იტყვის ამ კლიენტის მოთხოვნების მომსახურებაზე.
შეცვალეთ /etc/resolv.conf ფაილი, რათა სერვერი მიუთითოთ სახელების სერვერზე.
აქ განხორციელებული ცვლილებები გაგრძელდება მხოლოდ გადატვირთვამდე, რაც შესანიშნავია ტესტირებისთვის. თუ თქვენ კმაყოფილი ხართ ტესტის პარამეტრების შედეგებით, შეგიძლიათ ეს პარამეტრები მუდმივი გახადოთ.
გახსენით ფაილი sudo-ით ტექსტურ რედაქტორში:
სუდო ნანო /etc/resolv.conf
ფაილს სჭირდება DNS სერვერების სია, რომლებიც გამოყენებული იქნება მოთხოვნების გადასაჭრელად. ამისათვის გამოიყენეთ სახელების სერვერის დირექტივა. დაწერეთ ყველა მიმდინარე ჩანაწერი და დაამატეთ სახელების სერვერის ხაზი, რომელიც მიუთითებს თქვენს DNS სერვერზე:
სახელების სერვერი 192.0.2.1
# სახელების სერვერი 8.8.4.4
# სახელების სერვერი 8.8.8.8
# სახელების სერვერი 209.244.0.3
შეინახეთ და დახურეთ ფაილი.
ახლა შეგიძლიათ გაგზავნოთ ტესტის მოთხოვნა, რათა დარწმუნდეთ, რომ ის სწორად მოგვარდება.
ამისათვის შეგიძლიათ გამოიყენოთ ping:
ping -c 1 google.com
PING google.com (173.194.33.1) 56(84) ბაიტი მონაცემები.
64 ბაიტი sea09s01-in-f1.1e100.net-დან (173.194.33.1): icmp_seq=1 ttl=55 დრო=63.8 ms
--- google.com პინგ სტატისტიკა ---
1 პაკეტი გადაცემული, 1 მიღებული, 0% პაკეტის დაკარგვა, დრო 0ms
rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000 ms
DNS-ის დანიშნულებაა დომენური სახელების თარგმნა, რომლებიც ადვილად დასამახსოვრებელია ადამიანებისთვის, IP მისამართებად, რომლებსაც კომპიუტერები ესმით, პროცესს, რომელსაც სახელის გარჩევადობა ჰქვია. რას მოგვცემს ჩვენი საკუთარი ქეშირების DNS სერვერის დაყენება? ეს ოდნავ დააჩქარებს საიტების პასუხს + Linux არ იღებს კარგად NetBios სახელებს, მაგრამ ზოგჯერ თქვენ უნდა იპოვოთ კომპიუტერები ან პრინტერები ლოკალურ ქსელში, მაგრამ გსურთ ამის გაკეთება სახელით.
IP მისამართების დამახსოვრება არ არის მოსახერხებელი და DHCP სერვერის ჟურნალის მუდმივად ყურება ასევე არ არის ჩვენი მეთოდი. სწორედ ასეთი შემთხვევებისთვის გჭირდებათ DNS ლოკალურ ქსელში. თავად bind9 პაკეტის დაყენება არ არის რთული, როგორც წესი, ხარვეზები წარმოიქმნება მისი კონფიგურაციის ეტაპზე, რადგან ადვილად წასაკითხი სისტემის კონფიგურაციის ფაილების შემდეგ, ადამიანს გაუგებარი სინტაქსი აწყდება, რომელიც, სხვათა შორის, ძალიან ჰგავს S პროგრამირების ენას. სერვერი იმუშავებს ლოკალური ქსელის შიგნით, აზრი არ აქვს მის chroot გარემოში გადატანას და მთელ დაყენებას ძალიან ცოტა დრო სჭირდება. ამით ლირიკული ნაწილი შეიძლება დასრულდეს, გადავიდეთ ინსტალაციასა და კონფიგურაციაზე.
მოდით დავაყენოთ Bind9 DNS სერვერი:
# apt - მიიღეთ install bind9დასრულების, ჩამოტვირთვისა და ინსტალაციის შემდეგ, ჩვენ გვჭირდება მისი კონფიგურაციის ფაილის რედაქტირება:
#vim /etc/bind/named. კონფ. პარამეტრებიჩვენ ვპოულობთ განყოფილებას, ის მდებარეობს კონფიგურაციის ფაილის დასაწყისში, მის გარდა სხვა არაფერია ...
პარამეტრები ( დირექტორია "/var/cache/bind" ; // თუ თქვენსა და თქვენთვის სასურველ სახელების სერვერებს შორის არის firewall// სასაუბროდ, შეიძლება დაგჭირდეთ Firewall-ის დაფიქსირება, რათა მრავალჯერ დაუშვას// პორტები სასაუბროდ. იხილეთ http://www.kb.cert.org/vuls/id/800113// თუ თქვენმა ISP-მა მოგვაწოდა ერთი ან მეტი IP მისამართი სტაბილურობისთვის// სახელების სერვერები, თქვენ ალბათ გსურთ მათი გამოყენება როგორც გადამგზავნი.// გააუქმეთ შემდეგი ბლოკი და ჩასვით მისამართები// all-0"s placeholder. // forwarders ( // 0.0.0.0; //); auth - nxdomain no; # conform to RFC1035 listen - on - v6 ( any ; ); );გადამგზავნის განყოფილება პასუხისმგებელია იმაზე, თუ სად გაიგზავნება DNS მოთხოვნა სახელის გადაწყვეტისთვის, თუ ის არ არის საკუთარ მონაცემთა ბაზაში. ამ ბოლო დროს საერთოდ არ ვარ კმაყოფილი, ამ სერვერების მუშაობა პროვაიდერთან არის ის, თუ რატომ შეგიძლიათ დააკავშიროთ მესამე მხარის, მაგალითად Google-ის, IP 8.8.8.8-ის დამახსოვრება ძალიან ადვილია, მის მაგალითს გამოვიყენებ. დააკონფიგურირეთ, მაგრამ არავინ შეგაწუხებთ, რომ გამოიყენოთ ის, რაც ყველაზე მეტად მოგწონთ.
ჩვენ ვასწორებთ განყოფილებას, ჯერ უნდა ამოიღოთ მისგან კომენტარები და დაამატოთ მესამე მხარის DNS, თუ საჭიროა რამდენიმე სერვერის დამატება, მაგალითად, თუ google სერვერი ვერ გაუძლებს თქვენს თხოვნებს და გაფუჭდება :), მაშინ სხვა სერვერების IP შეიძლება დაიწეროს სვეტში, მაშინ შეგიძლიათ მიაღწიოთ შეცდომების უფრო დიდ ტოლერანტობას.
ექსპედიტორები (8.8.8.8; 193.58.251.251; //რუსული DNS სერვისი -SkyDNS};ამ განყოფილებაში უმჯობესია შეიყვანოთ სერვერის IP, რომელიც მიუთითეთ ფაილში /etc/resolv.confან შეიყვანეთ განყოფილებაში სახელების სერვერიეს IP. შეინახეთ ცვლილებები და გამოდით. გადატვირთეთ სერვერი და შეამოწმეთ. ჩვენ ვწერთ ბრძანების სტრიქონში nslookup mail.ru
უნდა გამოვიდეს:
ეს იმაზე მეტყველებს, რომ ჩვენი სერვერი არ არის მთავარი ამ ზონის მომსახურეობაში (mail.ru), მაგრამ დაამატა მოთხოვნები ქეშში!
ახლა ჩვენ უნდა შევქმნათ DNS ზონა ჩვენი ქსელისთვის, რათა მანქანებმა იპოვონ სხვადასხვა ქსელური სერვისები - შეიძლება იყოს, მაგალითად, ქსელური პრინტერები, ისინი შეიძლება იყოს დამოუკიდებელი ან გაზიარებული სხვა სამუშაო სადგურებზე.
ჩვენს ზონას შეიძლება ეწოდოს orgname - ე.ი. ორგანიზაციის დასახელება.
პირველ რიგში, ჩვენ ვქმნით ზონას, ამისათვის ჩვენ ვასწორებთ დასახელებული.conf.local
და დაამატეთ მას შემდეგი:
ზონა "orgname" (აკრიფეთ master ; ფაილი "/etc/bind/db.orgname" ; );შენახვა და გამოსვლა
ახლა ჩვენ უნდა შევქმნათ ზონის კონფიგურაციის ფაილი
და ჩასვით მასში შემდეგი:
(გთხოვთ, დიდი ყურადღება მიაქციოთ კონფიგურაციის ფაილის სინტაქსს, წერტილებსაც კი აქვს მნიშვნელობა)
ფესვი. orgname. (20101015 4სთ; განახლების დრო - 4 საათი 1სთ; გამეორება ყოველ საათში 1ვ; რამდენ ხანს შეინახება ინფორმაცია - 1 კვირა 1დ);
ჩანაწერის TTL (სიცოცხლის დრო) არის 1 დღე @ IN NS orgname. ;
nameservername @ IN A 192.168.10.1;
A - ჩანაწერი - ჩვენი DNS სერვერის IP მისამართი, რომელიც ემსახურება ამ ზონას, @ ნიშნავს, რომ ეს არის root ზონა.
* IN CNAME @ პრინტერი IN A 192.168.10.25;შეგიძლიათ შექმნათ DNS ჩანაწერი ქსელური პრინტერისთვის, რომელიც მდებარეობს 192.168.10.25-ზე
ახლა, ახალი ქსელური მოწყობილობის დამატებისას, თქვენ უნდა გააკეთოთ 2 რამ:1) დაჯავშნეთ IP მისამართი DHCP სერვერზე, ამის შესახებ შეგიძლიათ წაიკითხოთ სტატიაში - DHCP სერვერის დაყენება
2) შექმენით DNS ზონა ამ IP-სთვის, ჩაწერეთ მოწყობილობის სახელი XXX.XXX.XXX.XXX-ში. სად: მოწყობილობის სახელი არის მოწყობილობის ქსელის სახელი; XXX.XXX.XXX.XXX არის მისი IP მისამართი, რომელიც დაცულია DHCP სერვერზე.
ახლა ჩვენ გვჭირდება resolv.conf ფაილის რედაქტირება
#vim /etc/resolv. კონფ და შედი იქ:.
სახელების სერვერი 127.0.0.1
ყველაფერი, რაც იქ იყო, შეიძლება კომენტარის გაკეთება # დაყენებით
# გადატვირთვა
ეს გაკეთდა იმისთვის, რომ სერვერმა მოიძიოს ყველაფერი საკუთარ მონაცემთა ბაზაში და მხოლოდ ამის შემდეგ BIND გადამისამართებს მოთხოვნებს სერვერზე 8.8.8.8 IP, რომლის IP შედის დირექტივაში.ექსპედიტორები
ახლა თქვენ შეგიძლიათ შეამოწმოთ ფუნქციონირება: თუ ტესტირება ხდება Windows-ში:
ping მოწყობილობის სახელი. orgname<<>თუ ვამოწმებთ Linux-იდან:<<>ping მოწყობილობის სახელი. orgname - c 4<<- opcode: QUERY, status: NOERROR, id: 63893 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 13, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;tut.by. IN A ;; ANSWER SECTION: tut.by. 103 IN A 178.172.160.5 tut.by. 103 IN A 178.172.160.4 tut.by. 103 IN A 178.172.160.2 tut.by. 103 IN A 178.172.160.3 ;; AUTHORITY SECTION: . 6029 IN NS i.root-servers.net. . 6029 IN NS b.root-servers.net. . 6029 IN NS m.root-servers.net. . 6029 IN NS k.root-servers.net. . 6029 IN NS e.root-servers.net. . 6029 IN NS d.root-servers.net. . 6029 IN NS j.root-servers.net. . 6029 IN NS g.root-servers.net. . 6029 IN NS l.root-servers.net. . 6029 IN NS f.root-servers.net. . 6029 IN NS h.root-servers.net. . 6029 IN NS a.root-servers.net. . 6029 IN NS c.root-servers.net. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Mar 22 16:46:24 MSK 2016 ;; MSG SIZE rcvd: 310
Pings უნდა გადავიდეს IP-ზე, რომელიც თქვენ მიუთითეთ XXX.XXX.XXX.XXX-ის ნაცვლად თქვენ ასევე შეგიძლიათ შეამოწმოთ მოთხოვნების დამუშავების სიჩქარე ბრძანებითგათხრა # dig @127.0.0.1 tut.by ;> DiG 9.9.5-9+deb8u6-Debian > @127.0.0.1 tut.by ; (მოიძებნა 1 სერვერი) ;; გლობალური პარამეტრები: +cmd ;; მივიღე პასუხი: ;; ->>HEADERშუადღე მშვიდობისა, მკითხველო. ვაგრძელებთ თეორიული მასალის შესახებ, მიმდინარე სტატიაში მინდა განვიხილო პრაქტიკული მაგალითი ინსტალაციები და პარამეტრებიგანსხვავებული BIND სერვერის კონფიგურაციები..
სტატიაში მე აღვწერ
DNS ქეშის დაყენებადა სავსე DNS მასტერ სერვერი. აღწერას დავიწყებ ზოგადი ცნებებით და ნებისმიერი ორგანიზებისთვის აუცილებელი ნაბიჯებით DNS სერვერები. ზოგადი ინფორმაციადაასახელა არის დემონი, რომელიც არის ნაწილიპაკეტი bind9 და ყოფნადომენის სერვერი დემონი სახელად. ის იღებს პარამეტრებს მთავარი კონფიგურაციის ფაილიდან, რომელსაც ეწოდება დასახელებული.კონფდა მდებარეობს დირექტორიაში /etc/bind. მთავარ კონფიგურაციაშიაღწერილი სერვერის სამუშაო დირექტორია, ხშირად ეს არის დირექტორია /var/cache/bind, რომელშიც ტყუილია ზონის აღწერილობის ფაილებიდა სხვა სერვისის ფაილები. მიმოწერა ზონების სახელებიდა ზონის აღწერილობის ფაილიკომპლექტი ზონის განყოფილებაპარამეტრით ფაილი. ზონის განყოფილებაის ასევე ადგენს ამ სერვერის პასუხისმგებლობის ტიპს ზონაზე (მასტერი, მონა და ა.შ.) და ასევე განსაზღვრავს სპეციალურ პარამეტრებს მიმდინარე ზონისთვის (მაგალითად, რომელ ინტერფეისზე უნდა დამუშავდეს მოთხოვნები მიმდინარე ზონისთვის). ზონის აღწერილ ფაილებშიშეიცავს ზონის პარამეტრებს და რესურსების ჩანაწერებს (ამ პუნქტში მითითებული ბილიკები შეიძლება განსხვავდებოდეს Linux-ის განაწილების ან პარამეტრების მიხედვით).
ეს არის მუშაობის ზოგადი სქემა, რომელიც დაგეხმარებათ მომავალში თავიდან აიცილოთ დაბნეულობა კონკრეტული კონფიგურაციების განხილვისას.
პროგრამის მე-4 ვერსიის კონფიგურაციის ფაილის ფორმატი განსხვავდება მერვე და მეცხრე ვერსიებისგან გამოყენებული. BIND. იმის გათვალისწინებით, რომ ახლის დაყენების იმედი მაქვს DNSსერვერზე, მაგრამ მე ვერ ვხედავ აზრს ძველი ვერსიის დაყენებაში, ამიტომ გადავხედავ ახალი ვერსიის კონფიგურაციას.
საწყისი მონაცემები
იმისათვის, რომ DNS სწორად იმუშაოს, თქვენ უნდა გქონდეთ. DNS მიმდინარე სტატიაში კონფიგურირებული იქნება Debian დისტრიბუციის ფუნქციებზეც. სტენდის ქსელის კონფიგურაცია შემდეგია:
DNS: ~# CAT/ETC/Network/InterFaces Auto LO IFACE LOOPBACK AUTH0 IFACE ETH0 INETCAS 10.0.152 NETMASK 255.255.255.0 GATEWAY 10.0.254 AUTOO AUTH1 AUTH1 AUTH1. ქსელის ნიღაბი 255.255.255.0
სად 10.0.0.152/24 - გარე ინტერფეისი (პროვაიდერის მიერ გამოყოფილი ქვექსელი), 192.168.1.1/24 - შიდა (ლოკალური ქსელი). საბაჟო ზონას დაერქმევა example.com. მაგალითში ერთად მონა სერვერი, მეორადი სერვერი განთავსდება IP-ზე 10.0.0.191 .
მიმდინარეობს BIND9-ის ინსტალაცია
იმისათვის, რომ DNS სერვერმა იმუშაოს, თქვენ უნდა შებოჭვა 9 (ზოგიერთ განაწილებაში - შებოჭვა ). როგორც დიაგრამაშია აღნიშნული - ძირითადი კონფიგურაციის ფაილი BINDარის ფაილი დასახელებული.კონფ(ეს ფაილი შეიძლება განთავსდეს დირექტორიაში / და ა.შ, ზოგჯერ შიგნით /etc/bind).
პარამეტრები (სინტაქსი) დასახელებული.conf
named.conf ფაილის სინტაქსიიცავს შემდეგ წესებს:
IP მისამართები- IP სია უნდა გამოიყოს სიმბოლოთი ";" , შესაძლებელია ქვექსელის მითითება ფორმატში 192.168.1.1/24 ან 192.168.1.1/255.255.255.0, (IP-ის გამორიცხვისთვის საჭიროა მის წინ წარწერა!), შესაძლებელია სახელების დასახელება. "ნებისმიერი", "არცერთი", "localhost"ორმაგ ბრჭყალებში.
კომენტარები- ხაზები, რომლებიც იწყება #, //-ით და ჩასმულია /* და */-ში, განიხილება კომენტარები.
IN ზონის აღწერილობის ფაილები -სიმბოლო @არის "ცვლადი", რომელიც ინახავს კონფიგურაციის ფაილში მითითებული ზონის სახელს დასახელებული.კონფან @ დირექტივაში $ORIGINმიმდინარე ზონის აღწერა.
თითოეული დასრულებული სტრიქონიპარამეტრები უნდა დასრულდეს სიმბოლოთი; .
Acl განყოფილება
Acl (წვდომის კონტროლის სია)- გაძლევთ საშუალებას მიუთითოთ ქსელების დასახელებული სია. განყოფილების ფორმატი: acl "ქსელის_სახელი" (ip; ip; ip; );
პარამეტრების განყოფილება
პარამეტრების განყოფილებაკომპლექტი გლობალური პარამეტრებიკონფიგურაციის ფაილი, რომელიც აკონტროლებს ყველა ზონას. ამ განყოფილებას აქვს ფორმატი: პარამეტრები (ოფციები_განყოფილება_ოპერატორები);. ოფციები შეიძლება იყოს "ჩამოყრილი". ზონის განყოფილება, ამით ის გადალახავს გლობალურ პარამეტრებს. ხშირად გამოიყენება პარამეტრების განცხადებები:
- დაშვება-შეკითხვა ( list_ip} - საშუალებას აძლევს პასუხებს შეკითხვებზე მხოლოდ დან list_ip. არყოფნის შემთხვევაში, სერვერი პასუხობს ყველა მოთხოვნას.
- დაშვება-რეკურსი( list_ip} - რეკურსიული მოთხოვნები შესრულდება list_ip-ის მოთხოვნებისთვის. დანარჩენისთვის - განმეორებადი. თუ პარამეტრი არ არის მითითებული, სერვერი ასრულებს რეკურსიულ შეკითხვებს ყველა ქსელისთვის.
- დაშვება-გადაცემა ( list_ip} - მიუთითებს სერვერების ჩამონათვალს, რომლებსაც აქვთ სერვერიდან ზონის აღების უფლება (აქ ძირითადად slave სერვერებია მითითებული)
- დირექტორია / path/to/work/dir- განსაზღვრავს აბსოლუტურ გზას სერვერის სამუშაო დირექტორიაში. ეს განცხადება მოქმედებს მხოლოდ პარამეტრების განყოფილებაში.
- ექსპედიტორები ( IP პორტი, IP პორტი...} - მიუთითებს ჰოსტის მისამართებს და, საჭიროების შემთხვევაში, პორტებს, სადაც უნდა მოხდეს მოთხოვნების გაგზავნა (ჩვეულებრივ, აქ მითითებულია ISP პროვაიდერების DNS).
- წინ მხოლოდ ან წინ პირველი - პარამეტრი პირველიმიუთითებს, რომ DNS სერვერმა უნდა სცადოს სახელების გადაჭრა გადამგზავნის პარამეტრში მითითებული DNS სერვერების გამოყენებით და მხოლოდ იმ შემთხვევაში, თუ შეუძლებელი იყო ამ სერვერების გამოყენებით სახელის ამოხსნა, ის თავად შეეცდება სახელის გადაჭრას.
- შეატყობინეთ დიახ|არა - დიახ- აცნობეთ მონა სერვერებს ზონაში ცვლილებების შესახებ, არა- არ შეატყობინო.
- რეკურსიას დიახ|არა - დიახ- შეასრულეთ რეკურსიული მოთხოვნები კლიენტის მოთხოვნის შემთხვევაში, არა- არ შეასრულოთ (მხოლოდ განმეორებითი მოთხოვნები). თუ პასუხი ნაპოვნია ქეშში, ის ბრუნდება ქეშიდან. (შეიძლება გამოიყენოთ მხოლოდ პარამეტრების განყოფილებაში)
ზონის განყოფილება
განსაზღვრავს ზონ(ებ)ის აღწერას. განყოფილების ფორმატი: ზონა ( განყოფილების_ზონის_ოპერატორები}; ოპერატორები, რომლებიც ყველაზე ხშირად გამოიყენება:
- ნება-განახლება ( list_ip} - განსაზღვრავს სისტემებს, რომლებსაც შეუძლიათ დინამიურად განაახლონ ეს ზონა.
- ფაილი "ფაილის სახელი " - განსაზღვრავს ზონის პარამეტრების ფაილის გზას (უნდა მდებარეობდეს დირექტორიაში, რომელიც მითითებულია ოფციების განყოფილებაში დირექტორიაში განაცხადით)
- ოსტატები ( list_ip} -მიუთითებს სამაგისტრო სერვერების სიას. (დაშვებულია მხოლოდ დაქვემდებარებულ ზონებში)
- ტიპი " ზონის_ტიპი
" - მიუთითებს მიმდინარე განყოფილებაში აღწერილი ზონის ტიპზე; zone_type შეიძლება მიიღოს შემდეგი მნიშვნელობები:
- წინ- მიუთითებს გადამისამართების ზონაზე, რომელიც აგზავნის მოთხოვნებს ამ ზონაში.
- მინიშნება- მიუთითებს დამხმარე ზონაზე (ეს ტიპი შეიცავს ინფორმაციას root სერვერების შესახებ, რომლებსაც სერვერი დაუკავშირდება, თუ ქეშში პასუხს ვერ პოულობს)
- ოსტატი- განსაზღვრავს მუშაობას მთავარ სერვერად მიმდინარე ზონისთვის.
- მონა- განსაზღვრავს მუშაობას, როგორც მონ სერვერზე მიმდინარე ზონისთვის.
დამატებითი კონფიგურაციის პარამეტრები
დროის მნიშვნელობები ზონის ფაილებშინაგულისხმევად ის მითითებულია წამებში, თუ მათ არ მოჰყვება რომელიმე შემდეგი ასო: S - წამი, M - წუთი, H - საათი, D - დღეები, W - კვირა. შესაბამისად, ჩანაწერი 2სთ 20მ5წმექნება 2 საათი 20 წუთი 5 წამი და შეესაბამება 8405 წამს.
ნებისმიერი ჰოსტის/შეყვანის სახელი, რომელიც არ მთავრდება წერტილიითვლის არა FQDNსახელწოდება და დაემატება მიმდინარე ზონის სახელწოდებით. მაგალითად, domen ჩანაწერი examle.com ზონის ფაილში გაფართოვდება FQDN სახელით domen.examle.com. .
IN BIND კონფიგურაციის ფაილებიშეიძლება გამოყენებულ იქნას შემდეგი დირექტივები:
- $TTL- განსაზღვრავს ნაგულისხმევ TTL-ს ყველა ჩანაწერისთვის მიმდინარე ზონაში.
- $ORIGIN- ცვლის ზონის სახელს named.conf ფაილში მითითებულისგან. ამავდროულად, ამ დირექტივის ფარგლები არ ვრცელდება "ზემოთ" (ანუ, თუ ფაილი შედის $INCLUDE დირექტივაში, მაშინ $ORIGN-ის ფარგლები არ ვრცელდება მშობელზე)
- $INCLUDE- მოიცავს მითითებულ ფაილს, როგორც ზონის ფაილის ნაწილს.
განსაკუთრებით მინდა აღვწერო პარამეტრის დაშვება-გადაცემა ( 10.0.0.191; );. ეს პარამეტრი აღწერს სერვერებს, რომლებსაც უფლება აქვთ ჩამოტვირთონ ზონის ასლი - ე.წ მონა სერვერი. შემდეგ მაგალითში ჩვენ შევხედავთ პარამეტრს მონა DNS.
იმისათვის, რომ ჟურნალმა სწორად იმუშაოს, თქვენ უნდა შექმნათ შესაბამისი დირექტორია და მიანიჭოთ საჭირო უფლებები:
Dns:~# mkdir /var/log/bind/ dns:~# chmod 744 /var/log/bind/ dns:~# ps aux | grep დაასახელა bind 4298 0.0 3.4 46792 13272 ? Ssl Jul05 0:00 /usr/sbin/named -u bind root 4815 0.0 0.1 3304 772 pts/4 S+ 18:19 0:00 grep named dns:~# chown bind /var/log/bind/ dns:~# -ld /var/log/bind/ drwxr--r-- 2 bind root 4096 Jul 6 18:18 /var/log/bind/
Dns:~# კატა /var/cache/bind/example.com $TTL 3D @ IN SOA ns.example.com. root.example.com. (2011070601; სერიული 8H; განახლება 2H; ხელახლა სცადეთ 2W; ვადა 1D) ; მინიმალური @ IN NS ns.example.com. @ IN NS ns2.example.com. @ IN A 10.0.0.152 @ IN MX 5 mx.example.com. ns IN A 10.0.0.152 ns2 IN A 10.0.0.191 mx IN A 10.0.0.152 www IN CNAME @
ასევე in-addr.arpa დომენში.
Dns:~# კატა /var/cache/bind/0.0.10.in-addr.arpa $TTL 3600 @ IN SOA ns.examle.com. root.example.com. (2007042001; სერია 3600; განახლება 900; ხელახლა სცადე 3600000; ვადა 3600) ; მინიმალური IN NS ns.examle.com.
NS-ში ns2.example.com. 152 IN PTR examle.com. 191 IN PTR ns.example.com. * IN PTR examle.com. dns:~# კატა /var/cache/bind/1.168.192.in-addr.arpa $TTL 3600 @ IN SOA ns.examle.com. root.example.com. (2007042001; სერია 3600; განახლება 900; ხელახლა სცადე 3600000; ვადა 3600) ; მინიმალური IN NS ns.examle.com.
NS-ში ns2.example.com. * IN PTR examle.com.
ჩვენი ქსელი მცირეა, ვარაუდობენ, რომ ქსელში ძალიან ცოტა მანქანაა. ქსელის ყველა სერვისი განთავსებულია ერთ ჰოსტზე, example.com., ასე რომ, როგორც ძირითადი DNS (ns.example.com.) ასევე ფოსტის სერვერი (mx.example.com.) მიუთითებს ერთსა და იმავე მოწყობილობაზე (10.0.0.152). მეორადი (მონური) ავტორიტეტული ზონის სერვერიმთავარი ფუნქცია მონა სერვერი- ზონის აღწერილობის ავტომატური სინქრონიზაცია მთავარ სერვერთან. ეს ამოცანა რეგულირდება დოკუმენტით 4.3.5. RFC 1034
განყოფილებაში ამ დოკუმენტის მიხედვით, რეკომენდირებულია მონაცემთა გაცვლა სერვერებს შორის AXFR მოთხოვნის გამოყენებით. ამ მოთხოვნისთვის, მთელი ზონა უნდა გადაიცეს ერთ TCP კავშირში (RFC 1035).ასევე,
მონა DNS სერვერი იზიარებს დატვირთვას მთავარ სერვერთან ან იღებს მთელ დატვირთვას პირველ სერვერზე წარუმატებლობის შემთხვევაში.სანამ დაიწყებ
მონა DNS სერვერის დაყენება<<>, თქვენ უნდა შეამოწმოთ, შეგიძლიათ თუ არა ზონის ხელით მიღება მეორადი სერვერიდან შემდეგი ბრძანების გამოყენებით:<<>Root@debian:~# dig @10.0.0.152 example.com. axfr ;
- > DiG 9.7.3 > @10.0.0.152 example.com. axfr ; (მოიძებნა 1 სერვერი) ;; გლობალური პარამეტრები: +cmd example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 მაგალითი.com. 259200 IN NS ns.example.com. example.com. 259200 NS ns2.example.com. example.com. 259200 IN 10.0.0.152 მაგალითი.com. 259200 IN MX 5 mx.example.com. mx.example.com. 259200 IN A 10.0.0.152 ns.example.com. 259200 IN A 10.0.0.152 ns2.example.com. 259200 IN A 10.0.0.191 www.example.com. 259200 IN CNAME example.com. example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 ;; მოთხოვნის დრო: 14 მწმ; სერვერი: 10.0.0.152#53 (10.0.0.152) ;; როდის: პარასკევი 8 ივლისი 15:33:54 2011 ;; XFR ზომა: 11 ჩანაწერი (შეტყობინებები 1, ბაიტი 258)კოპირება
- named.conf კონფიგურაციის ფაილი მასტერ სერვერიდან;ჩანაცვლება აკრიფეთ ძირითადი პარამეტრი
- on ტიპის მონაჩანაცვლება პარამეტრის დაშვება-გადაცემა ( 10.0.0.191; );იმ ზონებში, რომლებისთვისაც ის მეორეხარისხოვანი იქნება;
- ზონების წაშლა, რომელსაც მიმდინარე სერვერი არ მოემსახურება, ძირეულის ჩათვლით, თუ მონა არ პასუხობს რეკურსიულ მოთხოვნებს;
- შექმენით დირექტორიებიჟურნალებისთვის, როგორც წინა მაგალითში.
საერთო ჯამში, ჩვენ ვიღებთ მონა სერვერის კონფიგურაციას:
Root@debian:~# cat /etc/bind/named.conf პარამეტრები ( დირექტორია "/var/cache/bind"; დაშვების მოთხოვნა (ნებისმიერი; ); // უპასუხეთ შეკითხვებს ყველა ინტერფეისიდან რეკურსიის ნომერი; // გამორთეთ რეკურსიული მოითხოვს auth-nxdomain no.// RFC1035-ის თავსებადობისთვის listen-on-v6 (არცერთი; არ გვჭირდება IPv6 ვერსია "უცნობი"; // ქვემოთ აღწერილი ზონები განსაზღვრავს სერვერს, როგორც ავტორიტეტს loopback // ინტერფეისებისთვის, ასევე სამაუწყებლო ზონებისთვის (RFC 1912-ის მიხედვით) ზონაში "localhost" ( type master; ფაილი "localhost"; ); ზონა "127.in-addr.arpa" ( type master; ფაილი "127.in-addr.arpa"; ); ზონა "0.in-addr.arpa" ( type master; ფაილი "0.in-addr.arpa"; ); ზონა "255.in-addr.arpa" ( type master; ფაილი "255.in-addr.arpa"; ); // ძირითადი ზონის ზონის აღწერა "example.com" ( type slave; ფაილი "example.com"; masters ( 10.0.0.152; ); ); //უკუ ზონის ზონის აღწერა "0.0.10.in-addr.arpa" ( type slave; ფაილი "0.0.10.in-addr.arpa"; masters (10.0.0.152; ); ); // ჟურნალის პარამეტრების აღრიცხვა ( არხი "misc" ( ფაილი "/var/log/bind/misc.log" ვერსიები 4 ზომა 4 მ; ბეჭდვის დრო დიახ; ბეჭდვის სიმძიმე დიახ; ბეჭდვის კატეგორია YES; ); არხი "შეკითხვა" (ფაილი "/var/log/bind/query.log" ვერსიები 4მ; ბეჭდვის დრო YES; print-severity NO; print-category NO; "misc"; ); ;
გადატვირთვის შემდეგ ჩვენი მონა სერვერიწარმატებით დააკოპირებს მისთვის საჭირო ინფორმაციას მთავარი სერვერიდან, რაც მითითებული იქნება დირექტორიაში ფაილების არსებობით:
Root@debian:~# ls -la /var/cache/bind/ სულ 28 drwxrwxr-x 2 root bind 4096 Jul 8 18:47 . drwxr-xr-x 10 root root 4096 Jul 8 15:17 .. -rw-r--r-- 1 bind bind 416 Jul 8 18:32 0.0.10.in-addr.arpa ...... - rw-r--r-- 1 bind bind 455 Jul 8 18:32 example.com ........
ძირითადად, /stroallow-transfer (pngp მონა სერვერიშეიძლება არ შეინახოს ზონის ასლი მის ფაილურ სისტემაში. ეს ასლი საჭიროა მხოლოდ DNS-ის დაწყებისას. ფაილურ სისტემაში ზონის ასლის არსებობამ შეიძლება თავიდან აიცილოს წარუმატებლობა, თუ ძირითადი სერვერი მიუწვდომელია Slave DNS-ის გაშვების დროს. თუ არ მიუთითებთ ფაილის პარამეტრს ზონის განყოფილებაში, მაშინ ასლი არ იქმნება.
netfilter()-ის დაყენება DNS BIND-ისთვის
სინამდვილეში, სერვერის კონფიგურაციის შემდეგ, კარგი იდეა იქნებოდა მისი დაცვა. ჩვენ ვიცით, რომ სერვერი მუშაობს პორტზე 53/udp. ამის შესახებ სტატიის წაკითხვისა და მისი გაცნობის შემდეგ, შეგიძლიათ შექმნათ წესები ქსელის ტრაფიკის ფილტრაციისთვის:
Dns ~ # iptables-save # ტიპიური iptables წესები DNS-ისთვის *ფილტრი:INPUT DROP :FORWARD DROP :OUTPUT DROP -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTA - -m conntrack --ctstate INVALID -j DROP # დაუშვას ლოკალური ქსელის წვდომა DNS სერვერზე: -A INPUT -s 192.168.1.1/24 -d 192.168.1.1/32 -p udp -m udp --dport 53 -m conntrack - -ctstate NEW -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -p icmp -j ACCEPT -A OUTPUT -p udp -m udp --sport 32768:61000 -j ACCEPT -A OUTPUT -p tcp - m tcp --sport 32768:61000 -j ACCEPT -A OUTPUT -m conntrack --ctstate RELATED,STABLISHED -j ACCEPT # დაუშვას DNS სერვერზე წვდომა გამავალი მოთხოვნების შესასრულებლად -A OUTPUT -p udp -m udp --dport 53 -m conntrack - -ctstate NEW -j ACCEPT COMMIT
ეს ტიპიური მაგალითია! iptables-ის წესების დასაყენებლად, რათა მოერგოს თქვენს ამოცანებს და ქსელის კონფიგურაციას, თქვენ უნდა გესმოდეთ, როგორ მუშაობს netfilter Linux-ში ზემოაღნიშნული სტატიების წაკითხვით.
პრობლემების მოგვარება
DNS პრობლემების იდენტიფიცირების მთავარი წყაროა. აქ არის გაშვების შეცდომების მაგალითი, როდესაც შეცდომა დავუშვი გზასთან დაკავშირებით ძირითადი სერვერის ზონის ფაილი:
ივლის 5 18:12:43 dns-სერვერი დასახელებული: იწყება BIND 9.7.3 -u bind ივლის 5 18:12:43 dns-სერვერი დასახელებულია: აშენებულია "--prefix=/usr"-ით "--mandir=/usr/ share/man" "--infodir=/usr/share/info" "--sysconfdir=/etc/bind" "--localstatedir=/var" "--enable-threads" "--enable-largefile" "- -with-libtool" "--enable-shared" "--enable-static" "--with-openssl=/usr" "--with-gssapi=/usr" "--with-gnu-ld" "- -with-dlz-postgres=no" "--with-dlz-mysql=no" "--with-dlz-bdb=yes" "--with-dlz-filesystem=ye" "--with-dlz-ldap =yes" "--with-dlz-stub=yes" "--with-geoip=/usr" "--enable-ipv6" "CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2" "LDFLAGS=" " CPPFLAGS=" Jul 5 18:12:43 dns-server named: მორგებული ლიმიტი ღია ფაილებზე 1024-დან 1048576 Jul 5 18:12:43 dns-server named: found 1 CPU, გამოყენებით 1 worker thread Jul 5 18:12: 43 dns-სერვერი დასახელებული: 4096-მდე სოკეტის გამოყენებით 5 ივლისი 18:12:43 dns-სერვერი დასახელებულია: კონფიგურაციის ჩატვირთვა "/etc/bind/named.conf"-დან 5 ივლისი 18:12:43 dns სერვერი დასახელებულია: reading აშენებული -სანდო გასაღებები ფაილიდან "/etc/bind/bind.keys" ივლის 5 18:12:43 dns-სერვერის დასახელება: ნაგულისხმევი UDP/IPv4 პორტის დიაპაზონის გამოყენებით: 5 ივლისი 18:12:43 dns-სერვერი დასახელებულია: ნაგულისხმევი გამოყენებით UDP/IPv6 პორტის დიაპაზონი: ივლისი 5 18:12:43 dns-სერვერი დასახელებული: მოსმენა IPv4 ინტერფეისზე lo, 127.0.0.1#53 5 ივლისი 18:12:43 dns-სერვერი სახელად: მოსმენა IPv4 ინტერფეისზე eth1, 192.168.1. #53 ივლისი 5 18:12:43 dns-სერვერი დასახელებულია: სესიის კლავიშის გენერირება დინამიური DNS-ისთვის 5 ივლის 18:12:43 dns-სერვერი დასახელებულია: ვერ დააკონფიგურირა root მინიშნებები "/etc/bind/db.root"-დან: ფაილი ვერ მოიძებნა 5 ივლის 18:12:43 დასახელდა dns-სერვერი: იტვირთება კონფიგურაცია: ფაილი ვერ მოიძებნა # ფაილი ვერ მოიძებნა 5 ივლის 18:12:43 dns-სერვერი დასახელდა: გასვლა (ფატალური შეცდომის გამო) ივლის 5 18:15:05 dns-server named: starting BIND 9.7.3 -u bind Jul 5 18:15:05 dns-server named: აშენებულია "--prefix=/usr" "--mandir=/usr/share/man" "- infodir =/usr/share/info" "--sysconfdir=/etc/bind" "--localstatedir=/var" "--enable-threads" "--enable-largefile" "--with-libtool" "- - enable-გაზიარებული" "--enable-static" "--with-openssl=/usr" "--with-gssapi=/usr" "--with-gnu-ld" "--with-dlz-postgres= არა " "--with-dlz-mysql=არა" "--with-dlz-bdb=დიახ" "--with-dlz-filesystem=დიახ" "--with-dlz-ldap=დიახ" "--ერთად - dlz-stub=yes" "--with-geoip=/usr" "--enable-ipv6" "CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2" "LDFLAGS=" "CPPFLAGS=" 5 ივლისი 18: 15 :05 dns-სერვერი დასახელებული: დარეგულირებული ლიმიტი ღია ფაილებზე 1024-დან 1048576 ივლის 5 18:15:05 dns-სერვერი დასახელებული: ნაპოვნია 1 CPU, გამოყენებით 1 მუშა თემა. 4096 სოკეტამდე ივლის 5 18:15:05 dns-სერვერის დასახელება: კონფიგურაციის ჩატვირთვა "/etc/bind/named.conf" ივლის 5 18:15:05 dns-სერვერი დასახელებული: ნაგულისხმევი UDP/IPv4 პორტის დიაპაზონის გამოყენებით: 5 ივლისი 18:15:05 dns-სერვერი დასახელებული: ნაგულისხმევი UDP/IPv6 პორტის დიაპაზონის გამოყენებით: 5 ივლისი 18:15:05 dns-სერვერი დასახელებული: მოსმენა IPv4 ინტერფეისზე lo, 127. 0.0.1#53 5 ივლისი 18:15:05 dns-სერვერი დასახელებული: მოსმენა IPv4 ინტერფეისზე eth1, 192.168.1.1#53 ივლისი 5 18:15:05 dns-სერვერი დასახელებული: ავტომატური ცარიელი ზონა: 254.169.IN-AD. ARPA Jul 5 18:15:05 dns-server named: automatic ცარიელი ზონა: 2.0.192.IN-ADDR.ARPA Jul 5 18:15:05 dns-server named: automatic ცარიელი ზონა: 100.51.198.IN-ADDR. ARPA ივლის 5 18:15:05 dns-სერვერი დასახელებულია: ავტომატური ცარიელი ზონა: 113.0.203.IN-ADDR.ARPA 5 ივლისი 18:15:05 dns-სერვერი დასახელებულია: ავტომატური ცარიელი ზონა: 255.255.255.255.IN-ADDR. ARPA 5 ივლისი 18:15:05 dns-სერვერი დასახელებული: ავტომატური ცარიელი ზონა: 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.0.0.0.0.0.0.IP6 .ARPA 5 ივლისი 18:15:05 dns-სერვერი დასახელებული: ავტომატური ცარიელი ზონა: 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.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 ივლის 5 18:15:05 dns-სერვერი დასახელებულია: ავტომატური ცარიელი ზონა: D.F.IP6.ARPA 5 ივლის 18:15:05 dns-სერვერი დასახელებულია: ავტომატური ცარიელი ზონა: 8.E.F.IP6.ARPA ივლის 5 18:15 :05 dns-სერვერი დასახელებულია: ავტომატური ცარიელი ზონა: 9.E.F.IP6.ARPA ივლისი 5 18:15:05 dns-სერვერი დასახელებულია: ავტომატური ცარიელი ზონა: A.E.F.IP6.ARPA 5 ივლისი 18:15:05 dns-სერვერი დასახელებულია: ავტომატური ცარიელი ზონა: B.E.F.IP6.ARPA 5 ივლისი 18:15:05 dns-სერვერი დასახელებული: ავტომატური ცარიელი ზონა: 8.B.D.0.1.0.0.2.IP6.ARPA 5 ივლისი 18:15:05 dns-სერვერი დასახელებული: ზონა 0. in-addr.arpa/IN: ჩატვირთული სერია 1 ივლისი 5 18:15:05 dns-სერვერი დასახელებული: zone 127.in-addr.arpa/IN: ჩატვირთული სერია 1 ივლისი 5 18:15:05 dns-სერვერი დასახელებულია: zone 255.in-addr.arpa/IN: ჩატვირთული სერია 1 ივლისი 5 18:15:05 dns-სერვერი დასახელდა: zone localhost/IN: ჩატვირთული სერია 2 ივლისი 5 18:15:05 dns-სერვერი დასახელდა: გაშვება # გაშვება წარმატებით დასრულდა
შესანიშნავი დიაგნოსტიკური საშუალებაა.
რეზიუმე
მიმდინარე სტატიაში მე აღვწერე BIND DNS სერვერის ძირითადი კონფიგურაციების დაყენება. სტატიის მიზანი იყო წარმოდგენა შეგვექმნა UNIX-ში BIND სერვერის მუშაობის შესახებ. მე პრაქტიკულად არ შევეხე DNS უსაფრთხოების საკითხებს და ნაკლებად შევეხე ისეთ სპეციფიკურ პარამეტრებს, როგორიცაა სერვერის მუშაობა ზღვარზე რეჟიმში, როდესაც ზონ(ებ)ის შესახებ სხვადასხვა ინფორმაცია იგზავნება სხვადასხვა ქსელში. უფრო ღრმა გაგებისთვის მე შემოგთავაზებთ დამატებითი წყაროების ჩამონათვალს, რომლებშიც, იმედი მაქვს, შეძლებთ საჭირო ინფორმაციის მოპოვებას. ამას ბოლო მოვუღო. მომავალ ჯერამდე.
დომენის სახელების სისტემა: http://citforum.ru/internet/dns/khramtsov/
მონა სერვერი- დომენის სახელები - ცნებები და საშუალებები: http://tools.ietf.org/html/rfc1034
RFC 1035- დომენის სახელები - დანერგვა და სპეციფიკაცია: http://tools.ietf.org/html/rfc1035
RFC 1537- საერთო DNS მონაცემთა ფაილის კონფიგურაციის შეცდომები: http://tools.ietf.org/html/rfc1537
RFC 1591- დომენის სისტემის სტრუქტურა და დელეგაცია: http://tools.ietf.org/html/rfc1591
RFC 1713- ინსტრუმენტები DNS გამართვისთვის: http://tools.ietf.org/html/rfc1713
RFC 2606- დაცულია უმაღლესი დონის DNS სახელები: http://tools.ietf.org/html/rfc2606
DNS უსაფრთხოება (DNSSEC): http://book.itep.ru/4/4/dnssec.htm
BIND 9 ადმინისტრატორის საცნობარო სახელმძღვანელო: http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.html
უსაფრთხო BIND შაბლონი: http://www.cymru.com/Documents/secure-bind-template.html
კონფიგურაციის პარამეტრები კარგად არის აღწერილირუსული: http://www.bog.pp.ru/work/bind.html
ზონის ფაილის ავტომატური შექმნა: http://www.zonefile.org/?lang=en#zonefile
ავტორი: პოლ კობო
გამოქვეყნების თარიღი: 2015 წლის 24 მაისი
თარგმანი: ა.პანინი
თარგმნის თარიღი: 2015 წლის 11 ივლისი
თავი 4: შესავალი DNS სერვერებზე
4.3. DNS სერვერების ქეშირება
DNS სერვერს, რომელიც არ ემსახურება DNS ზონას, მაგრამ დაკავშირებულია სხვა სახელების სერვერებთან შეკითხვის ქეშირებისთვის, ეწოდება ქეშირების DNS სერვერი. ქეშირების DNS სერვერები არ მუშაობს DNS ზონის მონაცემთა ბაზებთან, რომლებიც შეიცავს რესურსების ჩანაწერებს. ამის ნაცვლად, ისინი უკავშირდებიან სხვა სახელების სერვერებს და ქეშირებენ შესაბამის ინფორმაციას.
არსებობს ორი ტიპის DNS ქეშირების სერვერები. ეს არის DNS სერვერები, რომლებიც იყენებენ გადამისამართების DNS სერვერებს, ასევე DNS სერვერებს, რომლებიც იყენებენ root DNS სერვერებს.
4.3.1. DNS სერვერის ქეშირება, რომელიც არ იყენებს გამგზავნის
ქეშირების DNS სერვერი, რომელიც არ იყენებს გამგზავნის, უნდა მიიღოს ინფორმაცია სხვაგან. როდესაც მოთხოვნა მიიღება კლიენტისგან, ის დაუკავშირდება ერთ-ერთ root სერვერს. root სერვერი გადასცემს ინფორმაციას სერვერის შესახებ, რომელიც ემსახურება სამიზნე ზედა დონის დომენს ქეშირების სერვერზე, რომელიც თავის მხრივ გადასცემს მას სხვა DNS სერვერზე. ბოლო სერვერს შეიძლება ჰქონდეს ინფორმაცია, რომ უპასუხოს მოთხოვნას, ან გადასცეს ინფორმაცია სხვა DNS სერვერის შესახებ, რომელსაც შეიძლება ჰქონდეს ეს ინფორმაცია. საბოლოოდ ჩვენი DNS სერვერი მიიღებს იმ ინფორმაციას, რომელიც მას სჭირდება თხოვნაზე პასუხის გასაცემად და პასუხის გასაგზავნად კლიენტს.
ქვემოთ მოყვანილი ილუსტრაცია გვიჩვენებს კლიენტის მიერ მოთხოვნის გაგზავნის პროცესს IP მისამართის ინფორმაციისთვის დომენის სახელის linux-training.be. ჩვენი ქეშირების სერვერი დაუკავშირდება root სერვერს და გადამისამართდება სერვერზე, რომელიც ემსახურება .be ზედა დონის დომენს. შემდეგ ის დაუკავშირდება სერვერს, რომელიც ემსახურება .be ზედა დონის დომენს და გადამისამართდება Openminds ორგანიზაციის სახელების ერთ-ერთ სერვერზე. ერთ-ერთი ასეთი სახელების სერვერი (ამ შემთხვევაში nsq.openminds.be) უპასუხებს მოთხოვნას სერვერის IP მისამართით დომენის სახელით linux-training.be. მას შემდეგ, რაც ჩვენი ქეშირების სერვერი გადასცემს ამ ინფორმაციას კლიენტს, კლიენტი შეძლებს დაკავშირებას მოცემულ ვებსაიტთან.
როდესაც იყენებთ tcpdump sniffer-ს მოცემული დომენის სახელის გადასაჭრელად, შეგიძლიათ მიიღოთ შემდეგი გამოსავალი (თითოეული ხაზის პირველი 20 სიმბოლო წაშლილია).
192.168.1.103.41251 > M.ROOT-SERVERS.NET.domain: 37279% A? linux-tr\aining.be. (46) M.ROOT-SERVERS.NET.domain > 192.168.1.103.41251: 37279- 0/11/13 (740) 192.168.1.103.65268 > d.ns.dns.be.domain: ?3855%5 ლინუქსის ტრენინგი.\be. (46) d.ns.dns.be.domain > 192.168.1.103.65268: 38555- 0/7/5 (737) 192.168.1.103.7514 > ns2.openminds.be.domain: 608 linux-train\ing.be. (46) ns2.openminds.be.domain > 192.168.1.103.7514: 60888*- 1/0/1 A 188.93.155.\ 87 (62)
4.3.2. DNS სერვერის ქეშირება გადამგზავნი სერვერის გამოყენებით
ქეშირების DNS სერვერი, რომელიც იყენებს გამგზავნის, არის DNS სერვერი, რომელიც იღებს ყველა საჭირო ინფორმაციას გამგზავნისგან. მაგალითად, ინტერნეტ სერვისის პროვაიდერის DNS სერვერს შეუძლია იმოქმედოს როგორც გადამისამართებული DNS სერვერი.
ზემოთ მოყვანილი ილუსტრაცია აჩვენებს DNS სერვერს კომპანიის ლოკალურ ქსელში, რომელიც იყენებს ISP-ის მიერ მოწოდებულ DNS სერვერს, როგორც გადამისამართების DNS სერვერს. თუ ინტერნეტ პროვაიდერის მიერ მოწოდებული DNS სერვერის IP მისამართია 212.71.8.10, შემდეგი ხაზები უნდა იყოს წარმოდგენილი კომპანიის DNS სერვერის named.conf კონფიგურაციის ფაილში:
ექსპედიტორები ( 212.71.8.10; );
გარდა ამისა, თქვენ ასევე შეგიძლიათ დააკონფიგურიროთ თქვენი DNS სერვერი, რომ იმუშაოს პირობითი გადამგზავნით. პირობითი გადამგზავნი DNS სერვერის აღწერა კონფიგურაციის ფაილში შემდეგია:
ზონა "someotherdomain.local" ( type forward; forward only; forwarders ( 10.104.42.1; ); );
4.3.3. განმეორებითი ან რეკურსიული შეკითხვა
რეკურსიული მოთხოვნა არის DNS მოთხოვნა, რომლის გაგზავნის შემდეგ კლიენტი მოელის საბოლოო პასუხს DNS სერვერისგან (ზემოთ ილუსტრაციაზე გამოსახულია მუქი წითელი ისრით, მიმართული MacBook-დან DNS სერვერზე). განმეორებითი მოთხოვნა არის DNS მოთხოვნა, რომლის გაგზავნის შემდეგ კლიენტი არ ელის საბოლოო პასუხს DNS სერვერისგან (ზემოთ ილუსტრაციაზე გამოსახულია სამი შავი ისრით, მიმართული DNS სერვერიდან). განმეორებითი მოთხოვნები ყველაზე ხშირად ტარდება სახელების სერვერებს შორის. Root nameservers არ პასუხობენ რეკურსიულ შეკითხვებს.
DNS სერვერს, რომელიც მართავს DNS ზონას, ეწოდება ავტორიტეტული DNS სერვერი ამ ზონისთვის. გახსოვდეთ, რომ DNS ზონა მხოლოდ რესურსების ჩანაწერების კოლექციაა.
პირველ ავტორიტეტულ DNS სერვერს DNS ზონისთვის ეწოდება პირველადი DNS სერვერი. ეს სერვერი იმუშავებს DNS ზონის მონაცემთა ბაზის ასლით, რომელიც იკითხება და დასაწერადაც. თუ თქვენ გჭირდებათ მონაცემთა უსაფრთხოების გაზრდა წარუმატებლობის შემთხვევაში, სერვერის მუშაობის გაუმჯობესება ან დატვირთვის ბალანსი, შეგიძლიათ შეუკვეთოთ სხვა DNS სერვერი, რომელიც ასევე მართავს ამ DNS ზონას. ამ სერვერს დაერქმევა მეორადი DNS სერვერი.
მეორადი სერვერი იღებს DNS ზონის მონაცემთა ბაზის ასლს ძირითადი სერვერიდან DNS ზონის გადაცემის პროცესის დროს. DNS ზონის მონაცემთა გადაცემის მოთხოვნები იგზავნება მეორადი სერვერების მიერ გარკვეული დროის ინტერვალებით. ამ დროის ინტერვალების ხანგრძლივობა დადგენილია SOA რესურსის ჩანაწერში.
თქვენ შეგიძლიათ აიძულოთ DNS ზონის მონაცემების განახლება rndc პროგრამის გამოყენებით. ქვემოთ მოყვანილი მაგალითი იწყებს მონაცემთა გადაცემას fred.local DNS ზონისთვის და ბეჭდავს syslog ფაილის შესაბამის ნაწილს /var/log/syslog.
root@debian7:/etc/bind# rndc განახლება ფრედ.ადგილობრივი root@debian7:/etc/bind# grep Fred /var/log/syslog | კუდი -7 | დაჭრილი -c38- zone fred.local/IN: გაგზავნის შეტყობინება (სერიული 1) მიღებული საკონტროლო არხის ბრძანება "refresh fred.local" zone fred.local/IN: გადაცემა დაიწყო. "fred.local/IN"-ის გადაცემა 10.104.109.1#53-დან: დაკავშირებულია 10.104.33.30#57367 ზონის fred.local/IN: გადაცემული სერიული 2 გადაცემა "fred.local/IN" 10.104.109.1#53-დან: ტრანსფერი დასრულებული: 1 შეტყობინება, 10 ჩანაწერი, 264 ბაიტი, 0.001 წამი (264000 ბაიტი/წმ) ზონა fred.local/IN: გაგზავნა აცნობებს (სერიული 2) root@debian7:/etc/bind#
მეორადი DNS სერვერის DNS ზონაში დამატებისას, შეგიძლიათ დააკონფიგურიროთ სერვერი, რომ იყოს ძირითადი სერვერის მონა DNS სერვერი. პირველადი DNS სერვერი იქნება მთავარი DNS სერვერი მეორად სერვერთან მიმართებაში.
ყველაზე ხშირად, პირველადი DNS სერვერი არის მთავარი სერვერი, რომელიც აკავშირებს ყველა მონა სერვერს. ზოგჯერ slave სერვერი ასევე შეიძლება იყოს მთავარი სერვერი slave სერვერებისთვის შემდეგ დონეზე. ქვემოთ მოყვანილ ილუსტრაციაში სერვერი სახელად ns1 არის ძირითადი სერვერი, ხოლო სერვერები სახელად ns2, ns3 და ns4 არის მეორადი სერვერები. მიუხედავად იმისა, რომ მთავარი სერვერი სერვერებისთვის სახელად ns2 და ns3 არის ns1, ძირითადი სერვერი ns4-ისთვის არის ns2.
SOA რესურსის ჩანაწერი შეიცავს DNS ზონის მონაცემთა განახლების სიჩქარის მნიშვნელობას სახელწოდებით refresh. თუ ეს მნიშვნელობა დაყენებულია 30 წუთზე, slave სერვერი გაგზავნის მოთხოვნას DNS ზონის მონაცემების ასლის გადაცემის შესახებ ყოველ 30 წუთში. ეს ჩანაწერი ასევე შეიცავს მნიშვნელობას დროის ამოწურვის პერიოდის ხანგრძლივობისთვის, სახელად ხელახლა ცდა. ეს მნიშვნელობა გამოიყენება, თუ მასტერ სერვერი არ პასუხობს ბოლო DNS ზონის მონაცემთა გადაცემის მოთხოვნას. მნიშვნელობა, სახელწოდებით expiry time, ადგენს დროის პერიოდს, როდესაც slave სერვერს შეუძლია უპასუხოს კლიენტების თხოვნებს DNS ზონის მონაცემების განახლების გარეშე.
ქვემოთ მოცემულია nslookup უტილიტის გამოყენების მაგალითი DNS ზონის SOA რესურსის ჩანაწერის მონაცემების წასაკითხად (linux-training.be).
Root@debian6:~# nslookup > ნაკრების ტიპი=SOA > სერვერი ns1.openminds.be > linux-training.beსერვერი: ns1.openminds.be მისამართი: 195.47.215.14#53 linux-training.be origin = ns1.openminds.be mail adr = hostmaster.openminds.be სერიული = 2321001133 განახლება = 14400 მინიმუმ 6040 ხელახლა
DNS ზონის მონაცემების გადაცემა ხდება მხოლოდ DNS ზონის მონაცემთა ბაზების მონაცემების ცვლილებისას (ანუ, როდესაც ემატება, წაიშლება ან შეცვლილია ერთი ან რამდენიმე ძირითადი სერვერის რესურსის ჩანაწერი). slave სერვერი ადარებს SOA რესურსის ჩანაწერის საკუთარი ასლის ვერსიის ნომერს შესაბამისი ძირითადი სერვერის SOA რესურსის ჩანაწერის ვერსიის ნომერს. თუ ვერსიების ნომრები ემთხვევა, მონაცემთა განახლება არ არის საჭირო (რადგან სხვა რესურსის ჩანაწერები არ არის დამატებული, წაშლილი ან შეცვლილი). იმავე შემთხვევაში, თუ SOA რესურსის ჩანაწერის ვერსიის ნომერი slave სერვერის მხარეს ნაკლებია იმავე ჩანაწერის ვერსიის ნომერზე შესაბამისი ძირითადი სერვერის მხარეს, განხორციელდება DNS ზონის მონაცემთა გადაცემის მოთხოვნა.
ქვემოთ მოცემულია Wireshark სნაიფერის ფანჯრის სნეფშოტი DNS ზონის მონაცემთა გადაცემის დროს.
4.9. DNS ზონის მონაცემების სრული ან ნაწილობრივი გადაცემა
DNS ზონის მონაცემების გადაცემა შეიძლება იყოს სრული ან ნაწილობრივი. ამა თუ იმ რეჟიმის გამოყენების გადაწყვეტილება დამოკიდებულია მონაცემების რაოდენობაზე, რომელიც უნდა გადაიცეს DNS ზონის მონაცემთა ბაზის სრულად განახლებისთვის Slave სერვერზე. ზონის მონაცემების ნაწილობრივი გადაცემა სასურველია, როდესაც შეცვლილი მონაცემების მთლიანი რაოდენობა ნაკლებია მთელი მონაცემთა ბაზის ზომაზე. სრული DNS ზონის მონაცემების გადაცემა ხორციელდება AXFR პროტოკოლის გამოყენებით, ხოლო ნაწილობრივი DNS ზონის მონაცემების გადაცემა ხდება IXFR პროტოკოლის გამოყენებით.