პირველადი და მეორადი DNS. DNS სერვერის ჩართვა და კონფიგურაცია
DNS განსაზღვრავს სერვერების ორ ტიპს: პირველადი და მეორადი. ძირითადი სერვერიარის სერვერი, რომელიც აგროვებს ფაილს იმ ზონის შესახებ, რომელზეც მას აქვს უფლებამოსილება. ის პასუხისმგებელია ზონის ფაილის შექმნაზე, შენარჩუნებასა და შეცვლაზე. ზონის ფაილი გროვდება ადგილობრივ დისკზე.
მეორადი სერვერიარის სერვერი, რომელიც გადასცემს სრულ ინფორმაციას სხვა სერვერებზე (პირველად ან მეორად) და ინახავს ფაილს ადგილობრივ დისკზე. მეორადი სერვერი არ ქმნის ან ცვლის ზონის ფაილს. თუ ცვლილებაა საჭირო, მან ეს უნდა გააკეთოს პირველადი სერვერის დახმარებით, რომელიც აგზავნის შეცვლილ ვერსიას მეორადში.
ინტერნეტ DNS
DNS არის პროტოკოლი, რომელიც შეიძლება გამოყენებულ იქნას სხვადასხვა პლატფორმაზე. ინტერნეტში დომენის სახელების სივრცე (ხე) დაყოფილია სამ სხვადასხვა განყოფილებად: ზოგადი დომენი, ქვეყნის დომენი და ინვერსიული დომენი.
ზოგადი დომენი
generic domain განსაზღვრავს ჰოსტის (generic domain) რეგისტრაციას მისი ზოგადი ხასიათის მიხედვით. ეს დონეები ასოცირდება ორგანიზაციების ტიპებთან, როგორიცაა, მაგალითად, ნაჩვენებია აშშ-სთვის ცხრილში. 3.1.
თითოეული ხის კვანძი არის დომენი, რომელიც არის დომენის სახელების სივრცის ბაზის ნაწილი.
ცხრილში, ზოგადი დომენის განყოფილების პირველი დონე იძლევა შვიდ შესაძლო სამ სიმბოლოიან დონეს. ეს დონეები დაკავშირებულია ცხრილში ჩამოთვლილ ორგანიზაციების ტიპებთან. 3.1.
ქვეყნის დომენები
განყოფილება ქვეყნის დომენებიმიჰყვება იგივე ფორმატს, როგორც ზოგადი დომენები, მაგრამ იყენებს ორსიმბოლოიან ქვეყნების აბრევიატურებს (მაგალითად, ru რუსეთისთვის) სამნიშნა პირველი დონის ორგანიზაციული სტრუქტურის ნაცვლად. მეორე დონის აბრევიატურები შეიძლება იყოს ორგანიზაციული ან უფრო დეტალურად განსაზღვროს ეროვნება. რუსეთი (ru), მაგალითად, იყენებს აბრევიატურებს ცალკეული ქალაქებისთვის (მაგალითად, spb.ru). მისამართი gut.spb.ru შეიძლება გაშიფრული იყოს, როგორც ტელეკომუნიკაციების სახელმწიფო უნივერსიტეტი, სანქტ-პეტერბურგი, რუსეთი.
ინვერსიული დომენი
ინვერსიული დომენიიყენებს მისამართის სახელში ასახვას. ეს შეიძლება იყოს საჭირო, მაგალითად, როდესაც სერვერი იღებს მოთხოვნას კლიენტისგან კონკრეტული დავალების შესასრულებლად. ვინაიდან სერვერს აქვს ფაილი, რომელიც შეიცავს ავტორიტეტული კლიენტების სიას, სერვერი მხოლოდ კლიენტების IP მისამართებს ჩამოთვლის (მიღებული პაკეტიდან მათი ამოღებით). იმის დასადგენად, არის თუ არა კლიენტი დაშვებულ სიაში, სერვერს შეუძლია მოითხოვოს DNS სერვერი მისამართის სახელზე შედგენის მიზნით.
შეკითხვის ამ ტიპს ეწოდება შებრუნებული შეკითხვა, ან პოინტერის შეკითხვა. მაჩვენებლის მოთხოვნის დასამუშავებლად, ინვერსიული დომენი ამატებს პირველი დონის კვანძს, რომელსაც ეწოდება arpa (ისტორიული მიზეზების გამო) დომენის სახელების სივრცეში. მეორე დონე ასევე ეხება ერთ კვანძს, როგორც in-addr (ინვერსიული მისამართისთვის). დომენის დარჩენილი ნაწილი განსაზღვრავს IP მისამართებს.
სერვერი, რომელიც ამუშავებს ინვერსიულ დომენს, ასევე იერარქიულია. ეს ნიშნავს, რომ მისამართის ქსელის ნომრის ნაწილი (netid) უნდა იყოს უფრო მაღალ დონეზე (ამ მაგალითში 132), ვიდრე მისამართის ქვექსელის ნაწილი, ამ მაგალითში 45; ხოლო მისამართის ქვექსელის ნაწილი უნდა იყოს უფრო მაღალ დონეზე, ვიდრე ჰოსტის მისამართი (ჰოსტიდი). ეს კონფიგურაცია აქცევს დომენის იერსახეს ინვერსიულ ზოგად დომენთან და ქვეყნის დომენთან შედარებით.
სახელის ამოცნობა
სახელის მისამართზე ან მისამართის სახელზე დაფიქსირებას ეწოდება "სახელის მისამართის ამოცნობა".
გამხსნელი
DNS პროტოკოლები შექმნილია როგორც სერვერ-კლიენტის აპლიკაცია. ჰოსტი, რომელსაც სჭირდება მისამართი-სახელი ან სახელ-მისამართი რუკების შედგენა, მოუწოდებს DNS კლიენტს, რომელსაც ეწოდება გადამწყვეტი. გადამწყვეტი წვდება უახლოეს DNS სერვერს რუკების მოთხოვნით. თუ სერვერს აქვს ინფორმაცია, ის ასრულებს გადამწყვეტის მოთხოვნას; წინააღმდეგ შემთხვევაში, ის ან გადასცემს გადამწყვეტს სხვა სერვერებზე, ან თავად ითხოვს სხვა სერვერებს ამ ინფორმაციის მიწოდებას.
მას შემდეგ, რაც ამომცნობი მიიღებს ამ რუკს, ის აანალიზებს პასუხს, რათა დაინახოს, არის თუ არა ეს ნამდვილი ამოცნობა თუ შეცდომა. შედეგი საბოლოოდ მიეწოდება პროცესს, რომელმაც მოითხოვა.
სახელების დასახელება მისამართებზე
ყველაზე ხშირად, გადამწყვეტი აწვდის სახელებს სერვერს და ითხოვს შესაბამის მისამართებს. ამ შემთხვევაში, სერვერი ამოწმებს ზოგად ან ქვეყნის დომენს რუკების მოსაძებნად.
თუ დომენის სახელი არის ზოგადი განყოფილებიდან, გადამწყვეტი იღებს დომენის სახელს, როგორიცაა kafedra.gut.edu. მოთხოვნის გადამწყვეტი იგზავნება ადგილობრივ DNS სერვერზე გადასაჭრელად. თუ ლოკალური სერვერი არ ცნობს მოთხოვნას, ის ან აგზავნის გადამწყვეტს სხვა სერვერზე ან პირდაპირ ითხოვს სხვა სერვერს.
თუ დომენის სახელი არის ქვეყნის დომენების განყოფილებიდან, გადამწყვეტი იღებს დომენის სახელს, როგორიცაა kafedra.gut.spb.ru. პროცედურა იგივეა.
მისამართების დასახელება
კლიენტს შეუძლია გამოაგზავნოს IP მისამართი სერვერზე დომენის სახელის საჩვენებლად. ამას ეწოდება PTR მოთხოვნა. ასეთი მოთხოვნისთვის, DNS იყენებს ინვერსიულ დომენს. თუმცა, მოთხოვნის IP მისამართი უნდა შეიცვალოს და ორი ლეიბლი, in-addr ან arpa, უნდა დაერთოს, რათა შეიქმნას ხელმისაწვდომი დომენის ინვერსიული დომენის განყოფილების გამოყენებით. მაგალითად, თუ გადამწყვეტმა მიიღო IP მისამართი 132.34.45.121, გადამწყვეტი ჯერ აბრუნებს მისამართს და შემდეგ ამატებს ორ ტეგს გაგზავნამდე. გაგზავნილი დომენის სახელია 121.45.34.132.in-addr.arpa. იგი მიიღება ადგილობრივი DNS-ის გამოყენებით და აღიარებულია.
რეკურსიული ამოცნობა
კლიენტს (გამხსნელს) შეუძლია მოითხოვოს რეკურსიული პასუხი სახელების სერვერისგან. თუ სერვერს შეუძლია ამის გაკეთება, ის ამოწმებს მონაცემთა ბაზას და პასუხობს. თუ სერვერი არ არის ავტორიზებული, ის აგზავნის მოთხოვნას სხვა სერვერზე (ჩვეულებრივ, ზედა დინების სერვერზე) და ელოდება პასუხს. თუ ზედა ნაკადის სერვერი ავტორიზებულია, ის პასუხობს; წინააღმდეგ შემთხვევაში, ის აგზავნის მოთხოვნას სხვა სერვერზე. როდესაც მოთხოვნა საბოლოოდ აღიარებულია, პასუხი მოძრაობს უკან, სანამ საბოლოოდ მიაღწევს მოთხოვნილ კლიენტს.
განმეორებითი აღიარება
თუ კლიენტი არ ითხოვს რეკურსიულ პასუხს, რუკა შეიძლება განმეორდეს. თუ სერვერს აქვს გადაწყვეტილი სახელი, ის აგზავნის პასუხს. თუ არა, ის უბრუნებს კლიენტს სერვერის IP მისამართს, რომელსაც იგი თვლის, რომ შეუძლია უპასუხოს მოთხოვნას. კლიენტი იმეორებს მოთხოვნას მეორე სერვერზე. თუ ახლად მისამართებულ სერვერს შეუძლია მოთხოვნის ამოცნობა, ის პასუხობს IP მისამართით; წინააღმდეგ შემთხვევაში, ის უბრუნებს ახალი სერვერის IP მისამართს კლიენტს. ახლა კლიენტმა უნდა გაიმეოროს მოთხოვნა მესამე სერვერზე. ამ პროცესს ეწოდება განმეორებითი, რადგან კლიენტი იმეორებს ერთსა და იმავე მოთხოვნას რამდენიმე სერვერზე.
ქეშირება
ყოველთვის, როცა სერვერი იღებს მოთხოვნას სახელის შესახებ, რომელიც არ არის მის დომენში, მან უნდა მოძებნოს ძირითადი სერვერის მისამართების მონაცემთა ბაზა. ძიების დროის შემცირება გაზრდის ეფექტურობას. DNS ამას აკეთებს მექანიზმის საშუალებით, რომელსაც ეწოდება ქეშირება. როდესაც სერვერი ითხოვს ჩვენებას სხვა სერვერისგან და იღებს პასუხს, ის ინახავს ამ ინფორმაციას თავის ქეშ მეხსიერებაში, სანამ სხვა კლიენტს გაუგზავნის. თუ იგივე ან სხვა კლიენტი ითხოვს ჩვენებას, მას შეუძლია შეამოწმოს მისი ქეში და ამოიცნოს ნომერი. თუმცა, კლიენტის ინფორმირებისთვის, რომ პასუხი მოვიდა ქეშიდან და არა ავტორიტეტული წყაროდან, სერვერი აღნიშნავს პასუხს, როგორც არაავტორიზებულს.
ქეშირება აჩქარებს ამოცნობას, მაგრამ ასევე შეუძლია პრობლემების შექმნა. თუ სერვერი დიდხანს ინახავს ეკრანს, მან შეიძლება გაუგზავნოს მოძველებული ჩვენება კლიენტს. ამის საწინააღმდეგოდ გამოიყენება ორი მეთოდი.
პირველ მათგანთან ერთად, ავტორიტეტული სერვერი ყოველთვის ამატებს ინფორმაციას ეგრეთ წოდებული „ცხოვრების დრო“ (TTL - დრო სიცოცხლისთვის). ის განსაზღვრავს დროს წამებში, როდესაც მიმღებ სერვერს შეუძლია ინფორმაციის ქეშირება. ამ დროის ამოწურვის შემდეგ, რუკა არასწორია და ნებისმიერი მოთხოვნა შეიძლება ხელახლა გაიგზავნოს ავტორიტეტულ სერვერზე.
მეორე მეთოდი არის ის, რომ DNS მოთხოვნა, რომელსაც თითოეული სერვერი ინახავს მეხსიერებაში, შეიცავს TTL - შეზღუდული დრო თითოეული რუკისთვის. ქეში პერიოდულად სკანირდება და ამოღებულია ვადაგასული "ცხოვრების დრო" (TTL) რუკებები.
DNS შეტყობინებები
DNS-ს აქვს შეტყობინების ორი ტიპი: მოთხოვნა და პასუხი. ორივე ტიპს აქვს იგივე ფორმატი. მოთხოვნის შეტყობინება შეიცავს სათაურს, მოთხოვნის ჩანაწერს, პასუხის ჩანაწერს, ავტორიტეტის ჩანაწერს და დამატებით ჩანაწერებს (სურათი 4.1).
ბრინჯი. 4.1.მოითხოვეთ შეტყობინება და ჩანაწერები
სათაური
როგორც მოთხოვნის, ასევე პასუხის შეტყობინებებს აქვთ სათაურის ერთი და იგივე ფორმატი, საპასუხო შეტყობინებებისთვის რამდენიმე ველი დაყენებულია ნულზე. სათაური არის 12 ბაიტი და მისი ფორმატი ნაჩვენებია (ცხრილი 4.2).
სათაურის ველები შემდეგია:
იდენტიფიკაცია. ეს 16-ბიტიანი ველი გამოიყენება კლიენტის მიერ პასუხის მოთხოვნასთან შესადარებლად. კლიენტი იყენებს განსხვავებულ საიდენტიფიკაციო ნომერს ყოველ ჯერზე, როდესაც ის აკეთებს მოთხოვნას. სერვერი იმეორებს ამ ნომერს შესაბამის პასუხში.
დროშები. ეს 16-ბიტიანი ველი, რომელიც შეიცავს ქვეველებს, ნაჩვენებია (სურათი 4.2).
ბრინჯი. 3.2.დროშების ველი
თითოეული დროშის ქვეველების მოკლე აღწერა მოცემულია ქვემოთ.
1. QR (query/response) - მოთხოვნა/პასუხი. ეს არის ერთბიტიანი ქვეველი, რომელიც განსაზღვრავს შეტყობინების ტიპს. თუ ეს არის 0, შეტყობინება არის მოთხოვნა. თუ ის უდრის 1-ს, მაშინ შეტყობინება არის პასუხი.
2. OpCode (ოპერაციული კოდი). ეს არის 4-ბიტიანი ქვეველი, რომელიც განსაზღვრავს მოთხოვნის ან პასუხის ტიპს (0 - სტანდარტული ტიპი, 1 - ინვერსიული ტიპი და 2 - სერვერის მოთხოვნის სტატუსი).
4. TC (შეკვეცილი - შეკვეცილი). ეს არის ერთბიტიანი ველი. როდესაც ის დაყენებულია (მნიშვნელობა 1), ეს ნიშნავს, რომ პასუხი იყო 512 ბაიტზე მეტი და შემცირდა 512-მდე. გამოიყენება, როდესაც DNS იყენებს UDP სერვისს.
5. RD (რეკურსია სასურველი - რეკურსია სასურველია). ეს არის ერთბიტიანი ქვეველი. როდესაც ის დაყენებულია (მნიშვნელობა 1), ეს ნიშნავს, რომ კლიენტს სურს რეკურსიული პასუხი. ის მითითებულია მოთხოვნის შეტყობინებაში და მეორდება საპასუხო შეტყობინებაში.
6. RA (ხელმისაწვდომია რეკურსია - შესაძლებელია რეკურსია). ერთბიტიანი ქვეველი. როდესაც ის დაყენებულია პასუხში, ეს ნიშნავს, რომ შესაძლებელია რეკურსიული პასუხი. დააყენეთ მხოლოდ საპასუხო შეტყობინებაში.
7. დაცულია. ეს არის სამ ბიტიანი ქვეველი ნულოვანი კომპლექტით.
8. rCode (r-კოდი). ეს არის 4-ბიტიანი ველი, რომელიც მიუთითებს პასუხის შეცდომის სტატუსზე. რა თქმა უნდა, ასეთი შეფასება მხოლოდ ავტორიტეტულ სერვერს შეუძლია.
ცხრილი 4.2. აჩვენებს ამ ველის შესაძლო მნიშვნელობებს.
| მნიშვნელობა |
ინტერნეტის მომხმარებელთა უმეტესობამ იცის, რომ DNS სერვერი უზრუნველყოფს ვებსაიტების სახელების IP მისამართებად თარგმნას.და ჩვეულებრივ აქ მთავრდება ცოდნა DNS სერვერის შესახებ. ეს სტატია შექმნილია იმისათვის, რომ უფრო ღრმად შევხედოთ მის ფუნქციებს.
ასე რომ, წარმოვიდგინოთ, რომ თქვენ უნდა გამართოთ ქსელი, რომლისთვისაც პროვაიდერმა გამოყო "სამართლიანი" მისამართების ბლოკი, ან დააყენოთ თქვენი საკუთარი DNS სერვერი ლოკალურ ქსელში. სწორედ აქ ჩნდება ყველა სახის საშინელი სიტყვა, როგორიცაა "ზონა", "გადაცემა", "გამგზავნი", "in-addr.arpa" და ა.შ. მოდით, ეს ეტაპობრივად მოვაგვაროთ.
ძალიან აბსტრაქტულად შეგვიძლია ვთქვათ, რომ ინტერნეტში ყველა კომპიუტერს აქვს ორი ძირითადი იდენტიფიკატორი - დომენის სახელი (მაგალითად, www..0.0.1). მაგრამ აბსტრაქცია მდგომარეობს იმაში, რომ კომპიუტერს შეიძლება ჰქონდეს რამდენიმე IP მისამართი (უფრო მეტიც, თითოეულ ინტერფეისს შეიძლება ჰქონდეს საკუთარი მისამართი, გარდა ამისა, რამდენიმე მისამართი შეიძლება ეკუთვნოდეს ერთ ინტერფეისს), ასევე შეიძლება იყოს რამდენიმე სახელი. უფრო მეტიც, მათ შეუძლიათ დაუკავშირდნენ ერთ ან რამდენიმე IP მისამართს. და მესამე, კომპიუტერს შეიძლება საერთოდ არ ჰქონდეს დომენის სახელი.
როგორც უკვე აღვნიშნეთ, DNS სერვერის მთავარი ამოცანაა დომენური სახელების IP მისამართებად თარგმნა და პირიქით. ინტერნეტის გარიჟრაჟზე, როდესაც ის ჯერ კიდევ ARPANET იყო, ეს მოგვარდა ყველა კომპიუტერული ქსელის გრძელი სიების შენარჩუნებით. ამ შემთხვევაში, ასეთი სიის ასლი უნდა იყოს თითოეულ კომპიუტერზე. ბუნებრივია, ქსელის ზრდასთან ერთად ეს ტექნოლოგია აღარ გახდა მომხმარებლისთვის მოსახერხებელი, რადგან ეს ფაილები დიდი ზომის იყო და მათ სინქრონიზაციასაც სჭირდებოდათ. სხვათა შორის, ამ მეთოდის ზოგიერთი ასეთი „წარსულის გამოძახილი“ დღესაც გვხვდება. ასე შეგიძლიათ შეიყვანოთ სერვერების მისამართები, რომლებთანაც რეგულარულად მუშაობთ HOSTS ფაილში (როგორც UNIX-ში, ასევე Windows-ში).
ასე რომ, მოუხერხებელი „ერთფაილის“ სისტემა შეიცვალა DNS-ით - იერარქიული სახელების სტრუქტურა, რომელიც გამოიგონა დოქტორ პოლ მოკაპეტრისმა.
ასე რომ, არსებობს "ხის ფესვი" - "." (წერტილი). იმის გათვალისწინებით, რომ ეს ფესვი ყველა დომენისთვის ერთნაირია, წერტილი ჩვეულებრივ არ არის განთავსებული სახელის ბოლოს. მაგრამ ის გამოიყენება DNS აღწერილობაში და თქვენ უნდა გახსოვდეთ ეს. ამ „ძირის“ ქვემოთ არის პირველი დონის დომენები. რამდენიმე მათგანია - com, net, edu, org, mil, int, biz, info, gov (და ა.შ.) და სახელმწიფო დომენები, მაგალითად, ua. კიდევ უფრო დაბალია მეორე დონის დომენები და კიდევ უფრო დაბალია მესამე დონის დომენები და ა.შ.
რა არის "აღმავალი იერარქია"
დაყენებისას მითითებულია მინიმუმ ერთი DNS სერვერის მისამართი, მაგრამ, როგორც წესი, არის ორი. შემდეგი, კლიენტი აგზავნის მოთხოვნას ამ სერვერზე. სერვერი, რომელიც იღებს მოთხოვნას ან პასუხობს, თუ პასუხი მისთვის ცნობილია, ან აგზავნის მოთხოვნას „უმაღლეს“ სერვერზე (თუ ცნობილია), ან პირდაპირ ძირეულ სერვერზე, რადგან თითოეულმა DNS სერვერმა იცის root-ის მისამართები. DNS სერვერები.
შემდეგ მოთხოვნა იწყება დაბლა - root სერვერი აგზავნის მოთხოვნას პირველი დონის სერვერზე, რომელიც გადასცემს მას მეორე დონის სერვერზე და ა.შ.
ამ „ვერტიკალური კავშირის“ გარდა, არის ასევე „ჰორიზონტალური“ „პირველადი - მეორადი“ პრინციპის მიხედვით. და თუ ვივარაუდებთ, რომ სერვერი, რომელიც ემსახურება დომენს და მუშაობს „სარეზერვო ასლის გარეშე“ მოულოდნელად გახდება მიუწვდომელი, მაშინ ამ დომენში განთავსებული კომპიუტერებიც მიუწვდომელი გახდებიან! სწორედ ამიტომ, მეორე დონის დომენის დარეგისტრირებისას საჭიროა, მიუთითოთ მინიმუმ ორი DNS სერვერი, რომელიც მოემსახურება ამ დომენს.
ინტერნეტის ზრდასთან ერთად, უმაღლესი დონის ყველა დომენი დაიყო ქვედომენებად ან ზონებად. თითოეული ზონა დამოუკიდებელი დომენია, მაგრამ სახელების მონაცემთა ბაზაში შესვლისას ის კითხულობს მთავარ დომენს. მშობლის ზონა უზრუნველყოფს ბავშვის ზონის არსებობის უფლებას და პასუხისმგებელია მის ქცევაზე ონლაინ (ისევე როგორც რეალურ ცხოვრებაში). თითოეულ ზონას უნდა ჰქონდეს მინიმუმ ორი DNS სერვერი, რომლებიც ინახავს DNS მონაცემთა ბაზას ამ ზონისთვის.
ერთ ზონაში DNS სერვერების მუშაობის ძირითადი პირობაა ინტერნეტთან ცალკეული კავშირის არსებობა და მათი განთავსება სხვადასხვა ქსელში შეცდომების ტოლერანტობის უზრუნველსაყოფად. ამიტომ, ბევრი ორგანიზაცია ეყრდნობა ინტერნეტ სერვისის პროვაიდერებს, რათა მართონ მათთვის მეორადი და მესამეული DNS სერვერები.
რეკურსიული და არარეკურსიული სერვერები
DNS სერვერები შეიძლება იყოს რეკურსიული ან არარეკურსიული. მათ შორის განსხვავება ისაა, რომ რეკურსიულები ყოველთვის უბრუნებენ პასუხს კლიენტს, რადგან ისინი დამოუკიდებლად აკვირდებიან რეფერალებს სხვა DNS სერვერებზე და კითხულობენ მათ, ხოლო არარეკურსიული უბრუნებს ამ მიმართვებს კლიენტს და კლიენტმა დამოუკიდებლად უნდა მოითხოვოს მითითებულ სერვერზე. .
რეკურსიული სერვერები ჩვეულებრივ გამოიყენება დაბალ დონეზე, მაგალითად, ლოკალურ ქსელებში, რადგან ისინი ქეშირებენ ყველა შუალედურ პასუხს და, შესაბამისად, მასზე შემდგომი მოთხოვნის შემთხვევაში, პასუხები უფრო სწრაფად დაბრუნდება. და არარეკურსიული სერვერები ხშირად არიან იერარქიის ზედა ნაწილში, რადგან ისინი იღებენ იმდენ მოთხოვნას, რომ უბრალოდ არ არის საკმარისი რესურსი პასუხების ქეშისთვის.
Forwarders - მოთხოვნის ექსპედიტორები და სახელების გადაწყვეტის ამაჩქარებლები
DNS სერვერებს აქვთ საკმაოდ სასარგებლო თვისება - ეგრეთ წოდებული "ფორვარდების" გამოყენების შესაძლებლობა. „პატიოსანი“ DNS სერვერი დამოუკიდებლად კითხულობს სხვა სერვერებს და პოულობს სასურველ პასუხს. მაგრამ თუ თქვენი ქსელი დაკავშირებულია ინტერნეტთან ნელი ხაზით (მაგალითად, dial-up), მაშინ ამ პროცესს შეიძლება დიდი დრო დასჭირდეს. ამიტომ, შეგიძლიათ გადამისამართოთ ეს მოთხოვნები, მაგალითად, პროვაიდერის სერვერზე და ამის შემდეგ უბრალოდ მიიღოთ მისი პასუხი.
ასეთი „ექსპედიტორების“ გამოყენება შეიძლება სასარგებლო იყოს მსხვილი კომპანიებისთვის, რომლებსაც აქვთ რამდენიმე ქსელი. ასე რომ, თითოეულ ქსელში შეგიძლიათ დააინსტალიროთ შედარებით სუსტი DNS სერვერი და მიუთითოთ უფრო მძლავრი მანქანა უფრო სწრაფი ხაზით, როგორც "გამგზავნი". ასე რომ, გამოდის, რომ ყველა პასუხი შეინახება ამ უფრო მძლავრი სერვერის მიერ, რაც გამოიწვევს სახელის უფრო სწრაფ გარჩევადობას მთელი ქსელისთვის.
თითოეული დომენი ინახავს საკუთარ DNS მონაცემთა ბაზას, რომელიც ჰგავს მარტივი ტექსტური ფაილების კომპლექტს. ისინი განლაგებულია პირველად (მთავარ) DNS სერვერზე და დროდადრო კოპირდება მეორად სერვერებზე. და სერვერის კონფიგურაცია მიუთითებს, თუ რომელი ფაილი შეიცავს ზონის აღწერილობებს, ასევე არის თუ არა სერვერი ამ ზონისთვის პირველადი თუ მეორადი.
უნიკალური მისამართი
უნიკალური ინტერნეტ მისამართი იქმნება ჰოსტის სახელზე დომენის სახელის დამატებით. ამრიგად, კომპიუტერს, მაგალითად, "fred" დომენში, მაგალითად, "smallorg.org" დაერქმევა fred.smallorg.org. სხვათა შორის, დომენი შეიძლება შეიცავდეს როგორც ჰოსტებს, ასევე ზონებს. მაგალითად, დომენი smallorg.org შეიძლება შეიცავდეს ჰოსტს fred.smallorg.org და ამავდროულად მასპინძლობს ზონას acctg.smallorg.org, რომელიც არის ქვედომენი და შეიძლება შეიცავდეს სხვა ჰოსტს barney.acctg.smallorg.org. მიუხედავად იმისა, რომ ეს ამარტივებს სახელების მონაცემთა ბაზას, ის ართულებს მასპინძლების ძებნას ინტერნეტში.
DNS სისტემა ახორციელებს სამ სცენარს მონაცემთა ბაზაში IP მისამართის მოსაძებნად.
- კომპიუტერი, რომელსაც სჭირდება იმავე ზონის სხვა კომპიუტერთან დაკავშირება, აგზავნის მოთხოვნას ზონის ადგილობრივ DNS სერვერზე, რათა მოძებნოს დისტანციური კომპიუტერის IP მისამართი. ადგილობრივი DNS სერვერი, რომელსაც აქვს ეს მისამართი მისი ლოკალური სახელების მონაცემთა ბაზაში, უბრუნებს მოთხოვნილ IP მისამართს კომპიუტერს, რომელმაც გაგზავნა მოთხოვნა.
* კომპიუტერი, რომელსაც სჭირდება სხვა ზონის კომპიუტერთან დაკავშირება, ითხოვს მისი ზონის ლოკალურ DNS სერვერს. ადგილობრივი DNS სერვერი აღმოაჩენს, რომ სამიზნე კომპიუტერი სხვა ზონაშია და კითხულობს root DNS სერვერს. root DNS სერვერი ჩამოდის DNS სერვერების ხეზე და პოულობს შესაბამის ადგილობრივ DNS სერვერს. მისგან იღებს მოთხოვნილი კომპიუტერის IP მისამართს. შემდეგ root DNS სერვერი გადასცემს ამ მისამართს ადგილობრივ DNS სერვერს, რომელმაც გაგზავნა მოთხოვნა. ადგილობრივი DNS სერვერი აბრუნებს IP მისამართს კომპიუტერს, საიდანაც მოხდა მოთხოვნა. IP მისამართთან ერთად გადადის სპეციალური მნიშვნელობა - TTL (სიცოცხლის დრო) სიცოცხლის ხანგრძლივობა. ეს მნიშვნელობა ეუბნება ადგილობრივ DNS სერვერს, რამდენ ხანს შეუძლია შეინახოს დისტანციური კომპიუტერის IP მისამართი მის ქეშში. ეს ზრდის შემდგომი მოთხოვნების დამუშავების სიჩქარეს.
* კომპიუტერი, რომელსაც სჭირდება ხელახლა დაკავშირება სხვა ზონის კომპიუტერთან, კითხულობს მისი ზონის ლოკალურ DNS სერვერს. ადგილობრივი DNS სერვერი ამოწმებს, არის თუ არა სახელი მის ქეშში და თუ TTL ჯერ არ გასულა. თუ მისამართი ჯერ კიდევ ქეშშია და TTL-ს ვადა არ გაუვიდა, მაშინ IP მისამართი იგზავნება მომთხოვნ კომპიუტერზე. ეს განიხილება არაავთენტიფიცირებულ პასუხად, რადგან ადგილობრივი DNS სერვერი თვლის, რომ დისტანციური კომპიუტერის IP მისამართი არ შეცვლილა ბოლო მოთხოვნის შემდეგ.
სამივე შემთხვევაში კომპიუტერს სჭირდება მხოლოდ ადგილობრივი DNS სერვერის IP მისამართი კომპიუტერის ინტერნეტში მოსაძებნად. შემდგომი მუშაობა მოთხოვნილი სახელის შესაბამისი IP მისამართის მოსაძებნად ხორციელდება ადგილობრივი DNS სერვერის მიერ. როგორც ხედავთ, ახლა ყველაფერი ბევრად უფრო მარტივია ადგილობრივი კომპიუტერისთვის.
როგორც DNS ხე გაიზარდა, ახალი მოთხოვნები განთავსდა დომენის სისტემის სერვერებზე. როგორც უკვე აღვნიშნეთ, მშობელ DNS სერვერებს უნდა ჰქონდეთ მათი შვილი DNS სერვერების IP მისამართები, რათა სწორად დაამუშავონ DNS მოთხოვნები სახელიდან IP მისამართის გადაწყვეტისთვის. იმისათვის, რომ DNS მოთხოვნები სწორად დამუშავდეს, DNS ხეების ძიება უნდა დაიწყოს კონკრეტულ წერტილში. ინტერნეტის ჩვილობის პერიოდში სახელების უმეტესობა ლოკალური ჰოსტების სახელებისთვის იყო მოძიებული. DNS ტრაფიკის დიდი ნაწილი ლოკალურ ზონაში იყო და მხოლოდ უარეს შემთხვევაში მიაღწია მშობელ DNS სერვერებს. თუმცა, ინტერნეტის და, კერძოდ, ვებსაიტის მზარდი პოპულარობის ფონზე, უფრო და უფრო მეტი DNS მოთხოვნა გენერირდება დისტანციურ ჰოსტებზე ლოკალური ზონის გარეთ. როდესაც DNS სერვერმა ვერ იპოვა ჰოსტის სახელი მის მონაცემთა ბაზაში, ის იძულებული გახდა შეეკითხა დისტანციური DNS სერვერი. დისტანციური DNS სერვერებისთვის ყველაზე შესაფერისი კანდიდატი, ბუნებრივია, იყო უმაღლესი დონის DNS სერვერები, რომლებსაც აქვთ სრული ინფორმაცია დომენის ხის შესახებ და შეუძლიათ იპოვონ სასურველი DNS სერვერი, რომელიც პასუხისმგებელია იმ ზონაზე, რომელსაც ეკუთვნის მოთხოვნილი ჰოსტი. შემდეგ ისინი აბრუნებენ სასურველი ჰოსტის IP მისამართს ადგილობრივ DNS სერვერზე. ეს ყველაფერი იწვევს DNS სისტემის root სერვერების კოლოსალურ გადატვირთვას. საბედნიეროდ, არც ისე ბევრია და ყველა თანაბრად ანაწილებს ტვირთს ერთმანეთში. ადგილობრივი DNS სერვერები მუშაობენ ზედა დონის დომენის DNS სერვერებთან DNS პროტოკოლის გამოყენებით, რომელიც განხილულია ამ თავში მოგვიანებით.
DNS სისტემა არის ორმხრივი გზა. DNS არა მხოლოდ პოულობს IP მისამართს მოცემული ჰოსტის სახელზე დაყრდნობით, არამედ შეუძლია შეასრულოს საპირისპირო ოპერაცია, ე.ი. განსაზღვრეთ ჰოსტის სახელი ქსელში IP მისამართის გამოყენებით. ინტერნეტში არსებული მრავალი ვებ და FTP სერვერი ზღუდავს წვდომას იმ დომენის მიხედვით, რომელსაც ეკუთვნის კლიენტი, რომელსაც მათზე წვდომა აქვს. კლიენტისგან კავშირის მოთხოვნის მიღების შემდეგ, სერვერი გადასცემს კლიენტის IP მისამართს DNS სერვერზე, როგორც საპირისპირო DNS მოთხოვნა. თუ კლიენტის DNS ზონა სწორად არის კონფიგურირებული, მოთხოვნა დააბრუნებს კლიენტის ჰოსტის სახელს, რის საფუძველზეც მიიღება გადაწყვეტილება იმის შესახებ, დაშვებულია თუ არა კლიენტი სერვერზე.
DNS სერვერი არის ძალიან სასარგებლო ფუნქცია თქვენი კომპიუტერის მავნე საიტებისგან დასაცავად. პროცესი დამწყებთათვის რთული ჩანს, მაგრამ სინამდვილეში ყველაფერი გაცილებით მარტივია და DNS სერვერის დაყენების პროცედურა დიდ დროს არ მიიღებს.
DNS არის აკრონიმი, რომელიც მიღებულია დომენის სახელების სისტემიდან. ინგლისურიდან რუსულად ეს ითარგმნება როგორც „დომენის სახელების სისტემა“ მათი IP მისამართების შეცვლა. და DNS სერვერი ინახავს შესაბამის მისამართებს მონაცემთა ბაზაში.
სამუშაო ხორციელდება ამ გზით: ბრაუზერი, რომელიც მიდის საიტზე, დაუკავშირდება DNS სერვერს სასურველი მისამართის გასარკვევად. სერვერი იდენტიფიცირებს საიტს, უგზავნის მას მოთხოვნას და მიღებულ პასუხს უგზავნის მომხმარებელს.
როგორ გავარკვიოთ, ჩართულია თუ არა DNS სერვერი თქვენს კომპიუტერში
მიმდინარე DNS სერვერის პარამეტრები განისაზღვრება შემდეგნაირად:
- „პანელი“ -> „ქსელი და ინტერნეტი“ -> „ქსელის სტატუსისა და ამოცანების ნახვა“. აირჩიეთ თქვენი ქსელის კავშირი, გადადით "ზოგადი" პანელზე, შემდეგ გადადით თვისებებზე.
- გადადით "ინტერნეტ პროტოკოლის ვერსია 4 (TCP/IPv4)" თვისებებზე.
- გახსენით ჩანართი "ზოგადი". თუ შემდეგი DNS სერვერის მისამართების გამოყენების ვარიანტი გააქტიურებულია, ეს ნიშნავს, რომ ის სამუშაო რეჟიმშია.
გაიმეორეთ წინა ნაბიჯები, გააქტიურეთ "გამოიყენეთ DNS სერვერი". ამის შემდეგ, თქვენ უნდა მიუთითოთ პირველადი DNS სერვერი, შემდეგ კი მეორადი.
როგორ დავაკონფიგურიროთ/შეცვალოთ DNS
ცვლილებების ან დამატებითი პარამეტრების შეტანისას, თქვენ არ დაგჭირდებათ მრავალი მოქმედების შესრულება. თქვენ უნდა გამოიყენოთ ადრე გახსნილი ფანჯარა და გადადით "Advanced" პუნქტზე. აქ ხორციელდება DNS სერვერებზე წვდომის დეტალური კორექტირება. Windows 7-ში ამ ყველაფრის კონფიგურაცია თავად შეგიძლიათ. ამიტომ, კითხვა, თუ როგორ უნდა შეცვალოთ DNS სერვერი საკუთარ თავს, არ გამოიწვევს პრობლემებს.
DNS სუფიქსები ასევე ხელმისაწვდომია მართვისთვის. საშუალო მომხმარებელს არ სჭირდება ისინი. ეს პარამეტრი, რომელიც ხელს უწყობს რესურსების მოხერხებულად გაზიარებას, შეიქმნა პროვაიდერებისთვის.
wi-fi როუტერზე
როუტერის გამოყენებისას, თქვენ უნდა დააყენოთ მისი IP მისამართი DNS პარამეტრებში. ამ მანიპულაციების შესასრულებლად დაგჭირდებათ DNS რელე და DHCP სერვერის ჩართვა.
როუტერის ინტერფეისი შექმნილია შემოწმებისთვის და შემდგომი დეტალური პარამეტრებისთვის. ჯერ უნდა შეამოწმოთ DNS WAN პორტში. DNS რელე გააქტიურებულია LAN პორტის პარამეტრებში.
კომპიუტერზე
Windows 10-ში DNS სერვერის დაყენება მსგავსია OS-ის წინა ვერსიებში. ჯერ უნდა აირჩიოთ „ინტერნეტ პროტოკოლის ვერსია 4 (TCP/IPv4)“ თვისებები. გადადით დამატებით ვარიანტებზე და დააკონფიგურირეთ სერვერების სია.
DNS სერვერის დაყენება კომპიუტერზე და ლეპტოპზე იგივეა.
ტაბლეტზე
დაინსტალირებული ოპერაციული სისტემის მიხედვით, მოქმედებები გარკვეულწილად განსხვავდება, მაგრამ ყველა მათგანს აქვს შემდეგი საერთო პუნქტები:
- გახსენით "Wi-Fi" მენიუ, რომელიც მდებარეობს "პარამეტრებში".
- გადადით მიმდინარე ინტერნეტ კავშირის თვისებებზე.
- დააჭირეთ "ქსელის შეცვლას", შემდეგ "დამატებითი პარამეტრების ჩვენება".
- გადადით DNS სერვერების პუნქტზე, შემდეგ დაარეგისტრირეთ ისინი.
სმარტფონზე
ვინაიდან ახლა დიდი განსხვავება არ არის ტელეფონისა და ტაბლეტის ოპერაციულ სისტემებს შორის, საჭირო DNS სერვერების დასაყენებლად, საკმარისია იცოდეთ ზემოთ აღწერილი ინსტრუქციები.
შესაძლო შეცდომები და როგორ გამოვასწოროთ ისინი
ინტერნეტის მუშაობასთან დაკავშირებული პრობლემები წარმოიქმნება მაშინ, როდესაც DNS სერვერის პარამეტრები არასწორია, მათ შორის, როდესაც ისინი მოულოდნელად იშლება.
რა უნდა გააკეთოს, თუ სერვერი არ პასუხობს ან არ არის აღმოჩენილი
ყველაზე ხშირად, ეს პრობლემა ჩნდება სერვერის გათიშვის ან პარამეტრების დაკარგვისას. ამისათვის გახსენით "პანელი", გადადით "სისტემა და უსაფრთხოება", შემდეგ "ადმინისტრაცია". დააჭირეთ "სერვისებს", იპოვეთ "DNS კლიენტი" და ორჯერ დააწკაპუნეთ მასზე. სტატუსის ზოლში მითითებულია ბრძანება "გაშვებული". წინააღმდეგ შემთხვევაში, თქვენ უნდა აირჩიოთ ავტომატური გაშვების ტიპი ზემოთ ჩამოსაშლელი სიიდან.
თუ სერვისი მუშაობს, მაგრამ შეცდომა მაინც გამოჩნდება, სერვერის პრობლემებია. პირველ რიგში, უმჯობესია შეცვალოთ DNS სერვერის მისამართები ზემოაღნიშნული ინსტრუქციის მიხედვით. თუმცა, ჯერ კიდევ შესაძლებელია ქსელის ბარათის დრაივერების ხელახლა ინსტალაცია, ინტერნეტის კავშირის შემოწმება და პროვაიდერისთვის შესაძლო ტექნიკური პრობლემების შესახებ.
არ წყვეტს სახელებს სწორად
თუ ეს შეცდომა მოხდა, თქვენ უნდა შეამოწმოთ თქვენი DNS სერვერის პარამეტრების სისწორე. უმჯობესია უბრალოდ შეცვალოთ DNS სერვერის მისამართი პრობლემის თავიდან ასაცილებლად.
პრობლემები ასევე შესაძლებელია ოპერატორის სერვერებზე და პრობლემა მოგვარებულია იმავე გზით - DNS-ის შეცვლით.
გამოუცდელი მომხმარებლისთვის არის მაღალი ხარისხის და უფასო სერვერების სია:
მისამართები: 8.8.8.8; 8.8.4.4
Google-ის ყველა სერვისის მსგავსად, ის თავის დავალებებს ეფექტურად ასრულებს, მაგრამ აქვს ცნობილი მინუსი - აგროვებს და ინახავს მომხმარებლის სტატისტიკას. ამის მიუხედავად, სერვერს არავითარი წვდომა არ აქვს პერსონალურ მონაცემებზე, ამიტომ არ არის საჭირო უსაფრთხოებაზე ფიქრი.
თუ გსურთ გაიგოთ მეტი სერვერის მუშაობის შესახებ, საინფორმაციო საიტზე არის ოფიციალური დოკუმენტაცია.
OpenDNS
მისამართები: 208.67.222.222; 208.67.220.220
პოპულარული სერვერი ფილტრების ფართო სპექტრის არსებობისა და პერსონალური მონაცემების ქურდობისგან დაცვის გამო. ძირითადი ფუნქციები უფასოა, მაგრამ შესაძლებელია პრემიუმ წვდომის შეძენა, რაც საშუალებას გაძლევთ შექმნათ „ჩაკეტილი ქსელის გარემო“ და გაზარდოთ კავშირის სიჩქარე.
DNS.WATCH
მისამართები: 84.200.69.80; 84.200.70.40
არ საჭიროებს რეგისტრაციას გამოსაყენებლად, უზრუნველყოფს უფრო სერიოზულ დონეს. ერთადერთი უარყოფითი არის დაბალი სიჩქარე.
Norton ConnectSafe
მისამართები: 199.85.126.10; 199.85.127.10
ის ასევე არ „ითხოვს“ წინასწარ რეგისტრაციას და უსაფრთხოდ ინახავს მომხმარებლის მონაცემებს. შექმნილია Norton ანტივირუსის დეველოპერების მიერ, დამატებითი რეკლამის საჭიროების გარეშე.
დონე 3 DNS
მისამართები: 4.2.2.1; 4.2.2.2
ვარგისია არა მხოლოდ პირადი მოხმარებისთვის, არამედ კორპორატიული მიზნებისთვისაც. სრულიად უფასო რესურსი, იგი მესამე ადგილზეა მსოფლიო პოპულარობით.
Comodo Secure DNS
მისამართები: 8.26.56.26; 8.20.247.20
ძირითადი ვერსია უფასოა, მაგრამ გარკვეული თანხით შეგიძლიათ შეიძინოთ დიდი რაოდენობით სასარგებლო მომსახურება. ის უზრუნველყოფს მონაცემთა საიმედო დაცვას ფასიან და უფასო ვერსიებში.
OpenNIC DNS
მისამართები: თქვენ უნდა გადახვიდეთ პროექტის ვებსაიტზე, ის შეარჩევს საუკეთესოებს მომხმარებლის ადგილმდებარეობის მიხედვით.
უზარმაზარი დაფარვის გამო, ის საშუალებას გაძლევთ მოხერხებულად შეისწავლოთ ინტერნეტი მსოფლიოს ნებისმიერ წერტილში.
DHCP სერვერი: რა არის და რა არის მისი მახასიათებლები
ყველაზე შესაფერისია კომპიუტერების დიდი რაოდენობის მქონე ქსელებისთვის, მათი ქსელის პარამეტრების ყველა დაკავშირებულ მოწყობილობაზე გადაცემის გამო.
ასეთი სერვერი საშუალებას აძლევს ადმინისტრატორს მიუთითოს სერვერის ჰოსტების დიაპაზონი და თავიდან აიცილოს დიდი დროის დაკარგვა დეტალურ ოპტიმიზაციაზე.
ის მუშაობს მხოლოდ IP მისამართის პარამეტრებთან და თავად მისამართებთან.
დასკვნა
DNS სერვერების მთავარი ამოცანაა IP მისამართის გადაცემა. სხვა კომპანიების სერვერები, რომელთაგან ზოგიერთი ზემოთ აღწერილია, შეუძლიათ დააჩქარონ და მნიშვნელოვნად გაამარტივონ ინტერნეტ სერფინგი. თუმცა, ის არ საჭიროებს მტკივნეულ კონფიგურაციას და მრავალი შეცდომის მოგვარება შესაძლებელია სხვა სერვერის გამოყენებით.
ხელით კონფიგურაცია. ფანჯრები.
MS Windows-ში DNS სერვერის მისამართი, დომენის სახელი და ჰოსტის სახელი დაყენებულია ქსელის პარამეტრებში (აირჩიეთ TCP/IP პროტოკოლი, გადადით მის თვისებებზე და აირჩიეთ DNS ჩანართი).
მინიმუმ ორი სერვერი პასუხისმგებელია თითოეულ DNS ზონაზე. დანარჩენი მეორეხარისხოვანია. პირველადი სერვერი შეიცავს ორიგინალურ DNS მონაცემთა ბაზის ფაილებს მისი ზონისთვის. მეორადი სერვერები იღებენ ამ მონაცემებს ქსელის მეშვეობით პირველადი სერვერიდან და პერიოდულად ითხოვენ პირველადი სერვერისგან მონაცემების განახლებას (მონაცემთა განახლების ნიშანი არის სერიული ნომრის ზრდა SOA ჩანაწერში - იხილეთ ქვემოთ). თუ პირველადი სერვერის მონაცემები განახლებულია, მეორადი სერვერი ითხოვს "ზონის გადაცემას" - ე.ი. საჭირო ზონის მონაცემთა ბაზა. ზონის გადაცემა ხდება TCP პროტოკოლის გამოყენებით, პორტი 53 (განსხვავებით იმ მოთხოვნებისგან, რომლებიც იგზავნება UDP/53-ზე).
DNS მონაცემთა ბაზაში ცვლილებები შეიძლება განხორციელდეს მხოლოდ ძირითად სერვერზე. კლიენტის მოთხოვნების მომსახურების თვალსაზრისით, პირველადი და მეორადი სერვერები ყველა იდენტურია ავტორიტეტულიპასუხები. რეკომენდირებულია, რომ პირველადი და მეორადი სერვერები იყოს სხვადასხვა ქსელში, რათა გაიზარდოს მოთხოვნის დამუშავების საიმედოობა იმ შემთხვევაში, თუ რომელიმე სერვერის ქსელი მიუწვდომელია. DNS სერვერებს არ მოეთხოვებათ იმ დომენში ყოფნა, რომელზეც ისინი პასუხისმგებელნი არიან.
შენიშვნა. მეორადი სერვერი სულაც არ იღებს მონაცემებს უშუალოდ პირველადი სერვერიდან; სხვა მეორადი სერვერი ასევე შეიძლება იყოს მონაცემთა წყარო. ორივე შემთხვევაში, ამ მეორადი სერვერის წყარო სერვერს ეწოდება "მასტერი". ამ განყოფილების დარჩენილი ნაწილისთვის, ჩვენ ვვარაუდობთ, რომ მეორადი სერვერი იღებს ზონის მონაცემებს პირდაპირ პირველადი სერვერიდან.
23.2. SNiP მოთხოვნები კომპიუტერული ქსელის აღჭურვილობისთვის
მოთხოვნა SCS-ისთვის
დოკუმენტები:
დაპროექტებული და/ან ექსპლუატირებული SCS უნდა გაკეთდეს შემდეგი მარეგულირებელი დოკუმენტების დებულებების შესაბამისად:
– GOST R 53245-2008 საინფორმაციო ტექნოლოგიები. სტრუქტურირებული საკაბელო სისტემები. სისტემის ძირითადი კომპონენტების დაყენება. ტესტის მეთოდები;
– GOST R 53246-2008 საინფორმაციო ტექნოლოგიები. სტრუქტურირებული საკაბელო სისტემები. სისტემის ძირითადი კომპონენტების დიზაინი;
– ISO/IEC 11801:2010 საინფორმაციო ტექნოლოგიები – ზოგადი კაბელი მომხმარებელთა შენობებისთვის – შესწორება 2 (საინფორმაციო ტექნოლოგია. სტრუქტურირებული საკაბელო სისტემა მომხმარებელთა შენობებისთვის. მე-2 გამოცემა);
– ISO/IEC 14763-1:1999 საინფორმაციო ტექნოლოგიები – მომხმარებელთა შენობების კაბელირების განხორციელება და ექსპლუატაცია – ნაწილი 1: ადმინისტრირება;
– ISO/IEC 14763-2:2000 საინფორმაციო ტექნოლოგია. მომხმარებლის ტერიტორიის კაბელების განხორციელება და ექსპლუატაცია – ნაწილი 2: დაგეგმვა და მონტაჟი (საინფორმაციო ტექნოლოგია. საკაბელო სისტემის შეყვანა და ექსპლუატაცია მომხმარებლის შენობაში. ნაწილი 2. დაგეგმვა და მონტაჟი);
– ISO/IEC 14763-3:2006 საინფორმაციო ტექნოლოგია. მომხმარებელთა შენობის კაბელების განხორციელება და ექსპლუატაცია - ნაწილი 3: ოპტიკური ბოჭკოვანი კაბელის ტესტირება.
მოთხოვნები SCS სტრუქტურისთვის:
SCS სტრუქტურა უნდა შეიცავდეს ხერხემალს (ვერტიკალურ) და განაწილების (ჰორიზონტალურ) საკაბელო კომპონენტებს. ამ შემთხვევაში, რეკომენდირებულია გამოიყენოთ კატეგორიის მრავალ წყვილი კაბელი, რომელიც არ არის დაბალი ვიდრე 5e SCS-ის მთავარი სატელეფონო კაბელის კომპონენტისთვის. 5e კატეგორიის კაბელის ძირითადი მახასიათებლები არ უნდა იყოს უარესი:
– სიგნალის გამტარობა - 100 MHz;
- დამახასიათებელი წინაღობა 100 MHz - 100 ± 15 Ohms;
– სიგნალის გავრცელების სიჩქარე (NVP) - 68%;
– DC წინააღმდეგობა - ≤ 10 Ohm/100 m;
– გრეხილი წყვილის სიმძლავრე - ≤ 56 nF/კმ;
– დაყოვნების დროის გადახრა (delay skew) 100 MHz - 45 ns/100 m;
– სიგნალის გავრცელების შეფერხება 100 MHz – 536 ns/100 m.
რეკომენდირებულია გამოიყენოთ მულტიმოდური ან ერთრეჟიმიანი ოპტიკური კაბელი SCS-ის საკაბელო კომპონენტისთვის აქტიური LAN აღჭურვილობისთვის, შესაბამისად:
– არ არის უარესი OM3-ზე 2000 MHz×km სიჩქარით ეფექტური რეჟიმის გამტარუნარიანობისთვის (EMB) 850 ნმ-ზე, საკაბელო სტრუქტურით 50/125 მკმ მსუბუქი ტალღების სიგრძით 850 ნმ, 1300 ნმ;
- არა უარესი OS1-ზე 9(8)/125 მკმ საკაბელო სტრუქტურით მსუბუქი ტალღებისთვის 1310 ნმ სიგრძით, 1550 ნმ.
მცირე ქსელებისთვის (120-მდე პორტი, იხილეთ პუნქტი 6.4.2) ადგილზე LAN კონცენტრატორების განთავსებით და მათ პორტებს შორის 90 მ-ზე მეტი სიგრძის შესაბამისობით, ნებადართულია სპილენძის UTP კაბელის გამოყენება. კატეგორიის, რომელიც უზრუნველყოფს ქსელის ხერხემლის მონაკვეთის საჭირო გამტარუნარიანობას.
ოპტიკური საყრდენი არხები სასურველია იყოს დაპროექტებული ზედმეტად სქემის მიხედვით, რომელიც ითვალისწინებს LAN-ის ორგანიზაციულ სტრუქტურას და გამორიცხავს ხერხემლის ქსელის უკმარისობის ერთ წერტილს. საბარგულის კაბელებში ოპტიკური ბოჭკოების რაოდენობა უნდა იყოს მინიმუმ 4.
SCS-ის ოპტიკური ხერხემლის კომპონენტის დაპროექტებისას უზრუნველყოფილი უნდა იყოს ობიექტის LAN სისტემასთან თავსებადობა აქტიური აღჭურვილობის ოპტიკური მოდულების, მათში გამოყენებული ოპტიკური კონექტორების და ოპტიკური ბოჭკოს ტიპის მიხედვით.
ერთი და იმავე ობიექტის შენობებს შორის მთავარი კაბელების გაყვანისას მაქსიმალურად უნდა იქნას გამოყენებული ობიექტზე არსებული დაბალი დენის სისტემებისთვის შესაბამისი არხის ფორმირების კანალიზაცია. ამ უკანასკნელის არარსებობის შემთხვევაში მაგისტრალური კაბელების გაყვანა უნდა განხორციელდეს მიწაში. დაუშვებელია საჰაერო საკომუნიკაციო ხაზების ორგანიზება.
ზოგადად, SCS სტრუქტურა უნდა მოიცავდეს მთავარ ჯვარედინი კავშირს, რომელიც დამონტაჟებულია სასურველია ობიექტის პირველ სართულებზე, და იატაკის გადართვის ცენტრებს (შემდგომში ECC), რომლებიც დამონტაჟებულია შენობის სართულებზე ან იმ ადგილებში, სადაც დიდი რაოდენობით მომხმარებლები კონცენტრირებულები არიან. ძირითადი ჯვარი შეიძლება გაერთიანდეს ECC-თან.
SCS-ის ძირითადი ჯვარედინი კავშირი უნდა დამონტაჟდეს აღჭურვილობის ოთახში (შემდგომში - PA), ECC - ცალკეულ ოთახებში სართულებზე. თუ შეუძლებელია ECC-სთვის ცალკეული შენობების გამოყოფა, დასაშვებია მათი განთავსება დაწესებულების დერეფნებში, ტექნოლოგიურ ან ოფისში. ამ შემთხვევაში, სატელეკომუნიკაციო კაბინეტი აღჭურვილი უნდა იყოს საკეტით. ძირითადი სადისტრიბუციო და ECC აღჭურვილობა უნდა იყოს დამონტაჟებული სტანდარტული 19 დიუმიანი იატაკზე ან კედელზე დამაგრებულ კარადებში, რომელთა სიმაღლე უნდა განისაზღვროს დიზაინით.
სამუშაო ადგილებზე ორი RJ‑45 საინფორმაციო სოკეტი უნდა იყოს დაყენებული (თუ ტექნიკურ მახასიათებლებში სხვა რამ არ არის განსაზღვრული) იმავე ბლოკში მდებარე კოლოფში ელექტრო სოკეტებით. დასაშვებია, საბოლოო მომხმარებელთან შეთანხმებით, საინფორმაციო სოკეტების დაყენება კედელში დამალულ გარკვეულ ადგილებში, თავზე, ლუქებში ან მომსახურების თაროებში, ელექტრო ბუდეებთან ერთად ან ცალკე.
ობიექტებზე დამონტაჟებული SCS პორტების რაოდენობამ უნდა გაითვალისწინოს დაწესებულებების განვითარების პერსპექტივები დასაქმებულთა რაოდენობის გაზრდის თვალსაზრისით, ხოლო პორტების საერთო რაოდენობა უნდა განისაზღვროს საბოლოო მომხმარებელთან შეთანხმებით.
SCS ძირითადი კაბელების დაგება უნდა განხორციელდეს ცალკე ლითონის უჯრებში, სადაც ეს შესაძლებელია, შენობის ყალბი ჭერისა და ამწეების მიღმა არსებული სივრცის მაქსიმალური გამოყენებით. PA-ს ფარგლებში, საკაბელო კონსტრუქცია უნდა განხორციელდეს აწეული სართულების სივრცეში, ან ამ უკანასკნელის არარსებობის შემთხვევაში, სატელეკომუნიკაციო კაბინეტების ზემოთ ლითონის უჯრებში. უჯრები უნდა იყოს დამიწებული დამცავი დამიწების ავტობუსზე PUE-ის მოთხოვნებისა და სამუშაო დოკუმენტაციის მოთხოვნების შესაბამისად.
SCS-ის ჰორიზონტალური კომპონენტის კაბელის გაყვანა უნდა განხორციელდეს კედლის ყუთებში. ჰორიზონტალური საკაბელო კომპონენტის ნაწილი, ძირითადის მსგავსი, შეიძლება განთავსდეს უჯრებში, მათ შორის ადგილზე არსებულის ჩათვლით, თუ მათში საკმარისი თავისუფალი ადგილია. დასაშვებია ობიექტების გარკვეულ ადგილებში სკს-ის ჰორიზონტალური კომპონენტის კაბელების გაყვანა, საბოლოო მომხმარებელთან შეთანხმებით, კედელში ან იატაკში დამალული არხის ფორმირების პლასტმასის მილების გამოყენებით. SCS-ის ჰორიზონტალური კომპონენტისა და ელექტრული კაბელის ერთ ყუთში გაერთიანებისას, ყუთი უნდა შეიცავდეს ორ განყოფილებას, რომლებიც გამოყოფილია დანაყოფით.
საინფორმაციო საშუალებების მდებარეობა უნდა შეესაბამებოდეს საბოლოო მომხმარებლის მიერ მოწოდებულ სამუშაო სადგურის გეგმებს. საინფორმაციო სოკეტების განთავსება, რომლებიც განკუთვნილია ადგილზე უსადენო წვდომის სისტემების (Wi-Fi), საინჟინრო სისტემების, უსაფრთხოების სისტემების (დისპეტჩერიზაციის, ვიდეოთვალთვალის, წვდომის კონტროლის სისტემის (შემდგომში ACS) და ა.შ. დასაკავშირებლად), SCS გადაცემის გამოყენებით. საშუალო, უნდა განხორციელდეს ამ სისტემების დიზაინერების მიერ გაცემული ტექნიკური მახასიათებლების შესაბამისად.
23.3. SNiP მოთხოვნები კომპიუტერული ქსელების დიზაინისთვის შენობების აღჭურვილობისთვის
მოთხოვნები აღჭურვილობის ოთახების აღჭურვილობისთვის
PA-ს აღჭურვილობა უნდა განხორციელდეს სამშენებლო კოდების CH512 მოთხოვნების შესაბამისად.
PA უნდა განთავსდეს მუდმივ კორპუსში სარდაფის ზემოთ სართულებზე, სველი და მტვრიანი ტექნოლოგიური პროცესების მქონე ოთახებისგან (ტუალეტები, სამზარეულოები) და იმ ადგილებისგან, სადაც განლაგებულია ძლიერი ელექტრო დანადგარები (ლიფტები, გენერატორის კომპლექტები). სარდაფის ქვემოთ ოთახის არჩევისას უნდა იქნას მიღებული ზომები PA-ს წყალგაუმტარი. სატრანზიტო მილების (წყალმომარაგება, გათბობის მაგისტრალი) და საკაბელო ხაზების არსებობა დაუშვებელია PA-ში.
PA-ს ზომები უნდა განისაზღვროს აღჭურვილობის განლაგების დიზაინის მოთხოვნებით, სამონტაჟო, სარემონტო და ტექნიკური სამუშაოების ტექნოლოგიური გადასასვლელები, აგრეთვე კონდიცირების სისტემის მოთხოვნები აღჭურვილობის განთავსებისთვის საჭირო პირობების შესახებ, რათა მეტი ეფექტურად შეინარჩუნოს საჭირო კლიმატური სტანდარტები.
PA-ები აღჭურვილი უნდა იყოს კონდიცირების სისტემებით შემდეგი კლიმატური პარამეტრების შესანარჩუნებლად:
ხანძრის შემთხვევაში აღჭურვილობის შესანარჩუნებლად, ხანძარსაწინააღმდეგო სისტემაში უნდა დამონტაჟდეს ავტომატური გაზის ხანძარსაწინააღმდეგო დანადგარები.
PA იატაკი უნდა იყოს დაფარული ანტისტატიკური მასალით - ლინოლეუმი ან სხვა, რომელიც არ აგროვებს სტატიკური ელექტროენერგიას, წინააღმდეგობის მინიმუმ 106 Ohms. დასაშვები განაწილებული და კონცენტრირებული დატვირთვები PA იატაკზე უნდა შეირჩეს SNiP 2.01.07-ის შესაბამისად, PA-ში დაყენებული აღჭურვილობის წონის გათვალისწინებით.
აღჭურვილობის ტემპერატურისა და ტენიანობის მუშაობის პირობებიდან გამომდინარე, დასაშვებია, საბოლოო მომხმარებელთან შეთანხმებით, გამოიყენოს ბუნებრივი ვენტილაცია აღჭურვილობიდან ზედმეტად სითბოს გადასატანად.
PA-ში, ელექტრული პანელი საერთო შეყვანის დენის ჩამრთველით უნდა იყოს დამონტაჟებული მითითებული შენობის ყველა მომხმარებლისთვის. შეყვანის გადამრთველის ზომები და მისი დაყენების DIN რელსი უნდა დაუშვას ამომრთველების დაყენება ყველა მომხმარებლის დასაკავშირებლად, რომელიც განისაზღვრება ელექტრომომარაგების პროექტით PA აღჭურვილობისთვის.
დენის კაბელების გაყვანა PA-ში უნდა განხორციელდეს ამაღლებულ იატაკზე ან (მისი არარსებობის შემთხვევაში) ცალკე ლითონის უჯრებში, რომლებიც დამონტაჟებულია TS-ის ზემოთ. დენის კაბელების გაშვება და საყოფაცხოვრებო სოკეტების დაყენება PA-ში უნდა განხორციელდეს კედლის ყუთებში.
მცირე (60-მდე) მომხმარებელთან ITS ობიექტების ფორმირებისას, სადაც არ არის საჭირო აღჭურვილობის გარანტირებული უწყვეტი მუშაობის უზრუნველყოფა ან არაპრაქტიკული, შეიძლება გამოყენებულ იქნას PA-ს აღჭურვის გამარტივებული მოთხოვნები, საბოლოო მომხმარებელთან შეთანხმებით. ამავდროულად, დაცული უნდა იყოს ყველა საჭირო სტანდარტის, ნორმის, წესის და რეკომენდაციის მოთხოვნები ელექტრომომარაგების, ხანძარსაწინააღმდეგო და სიცოცხლის უსაფრთხოების შესახებ.
ECC-ის შენობაში, ხელით კედელზე დამონტაჟებული გაზის ცეცხლმაქრები უნდა დამონტაჟდეს ხანძარსაწინააღმდეგო აგენტის საკმარისი მოცულობით, რომელიც შეესაბამება დაცული შენობების მოცულობას SP 9.13130.2009-ის შესაბამისად, და დაცული უნდა იყოს ხანძარსაწინააღმდეგო სხვა სტანდარტები რუსეთის ფედერაციის სახანძრო წესების შესაბამისად (დამტკიცებულია დადგენილებით "ტექნიკური რეგლამენტი ხანძარსაწინააღმდეგო მოთხოვნების შესახებ".
ECC-ში უნდა იყოს დამონტაჟებული ელექტრული პანელი ზოგადი შეყვანის დენის გადამრთველით და ავტომატური გადამრთველებით აქტიური LAN მოწყობილობების დასაკავშირებლად.
ECC მდებარეობების არჩევისას, უპირატესობა უნდა მიენიჭოს შენობის დაბალი დენის ამწეების მახლობლად მდებარე შენობებს ან იმ ადგილების მახლობლად, სადაც მომხმარებლების დიდი რაოდენობაა კონცენტრირებული. ECC-სთვის შენობების ზომები უნდა განისაზღვროს აღჭურვილობის განლაგების დიზაინის მოთხოვნებით, სამონტაჟო, სარემონტო და ტექნიკური სამუშაოების ტექნოლოგიური გადასასვლელები. ECC-მ უნდა უზრუნველყოს აღჭურვილობის მუშაობისთვის საჭირო კლიმატური პარამეტრები.
თქვენს ყურადღებას წარმოგიდგენთ გუნდის ახალ კურსს Codeby- "ვებ აპლიკაციების შეღწევადობის ტესტირება ნულიდან." ზოგადი თეორია, სამუშაო გარემოს მომზადება, პასიური ფუზირება და თითის ანაბეჭდი, აქტიური ფუზირება, მოწყვლადობები, პოსტ-ექსპლუატაცია, ინსტრუმენტები, სოციალური ინჟინერია და მრავალი სხვა.
დომენებს აქვთ მინიმუმ ორი DNS სერვერი, ერთს უწოდებენ პირველადი სახელების სერვერს (ns1) და მეორეს უწოდებენ მეორად სახელების სერვერს (ns2). მეორადი სერვერები ჩვეულებრივ გამოიყენება პირველად DNS სერვერთან დაკავშირებული პრობლემების შემთხვევაში: თუ ერთი სერვერი მიუწვდომელია, მეორე ხდება აქტიური. უფრო რთული სქემები ასევე შესაძლებელია დატვირთვის დაბალანსების, ფაიერვოლებისა და კლასტერების გამოყენებით.
ყველა DNS ჩანაწერი კონკრეტული დომენისთვის ემატება ძირითადი სახელების სერვერს. მეორადი სერვერი უბრალოდ სინქრონიზებს პირველადი სერვერიდან მიღებულ ყველა ინფორმაციას, პირველადი სერვერზე მითითებულ პარამეტრებზე დაყრდნობით.
ეს ინსტრუქცია აღწერს, როგორ შევქმნათ პირველადი DNS სერვერი, რომელიც მუშაობს CentOS-ზე. გთხოვთ გაითვალისწინოთ, რომ ამ სახელმძღვანელოში წარმოდგენილი DNS სერვერი იქნება საჯარო DNS, რაც ნიშნავს, რომ სერვერი უპასუხებს თხოვნას ნებისმიერი IP მისამართიდან. როგორ შეზღუდოთ სერვერზე წვდომა აღწერილია ამ სახელმძღვანელოში.
სანამ დავიწყებდეთ, მინდა აღვნიშნო, რომ DNS შეიძლება დაინსტალირდეს chroot jail გარემოში ან მის გარეშე. chroot jail გარემო ზღუდავს DNS სერვერს სისტემის კონკრეტულ დირექტორიაში, სერვერზე სისტემის სრული წვდომისგან განსხვავებით. ამ გზით, ნებისმიერი DNS სერვერის დაუცველობა არ დააზარალებს მთელ სისტემას. DNS სერვერის შეზღუდვა კონკრეტულ დირექტორიაში (პროცესი სახელწოდებით chrooting) ასევე სასარგებლოა სატესტო გარემოში.
სამიზნე
ჩვენ დავაყენებთ DNS სერვერს ტესტის პირობებში, მაგალითად.tst დომენისთვის, რომელიც არის ჰიპოთეტური (არარსებული) დომენი. ამ გზით, ჩვენ შემთხვევით არ ჩავერევით არცერთ რეალურ დომენში.
ამ დომენში არის სამი შემდეგი სერვერი.
| სერვერი | IP მისამართი | მასპინძლობს სერვისები | FQDN |
| სერვერი A | 172.16.1.1 | ფოსტა | mail.example.tst |
| სერვერი B | 172.16.1.2 | ვებ, FTP | www.example.tst ftp.example.tst |
| სერვერი C | 172.16.1.3 | ძირითადი DNS სერვერი | ns1.example.tst |
ჩვენ დავაკონფიგურირებთ პირველადი DNS სერვერს და დავამატებთ საჭირო დომენს და DNS ჩანაწერებს, როგორც ნაჩვენებია ცხრილში.
ჰოსტების სახელების დაყენება
ყველა ჰოსტი სწორად უნდა იყოს იდენტიფიცირებული FQDN-ის მიხედვით. ეს შეიძლება გაკეთდეს შემდეგი მეთოდის გამოყენებით.
ვისაც გრაფიკული ინტერფეისი მოსწონს, შეუძლია გამოიყენოს NetworkManaget ინსტრუმენტები. ამისათვის ჩაწერეთ ბრძანება nmtui. გაიხსნება შემდეგი ფსევდოგრაფიკული ინტერფეისი:
აირჩიეთ „ჰოსტის სახელის შეცვლა“ და შეიყვანეთ ns1.example.tst
როცა მზად იქნება, დააწკაპუნეთ OK.
სხვა გზა, მხოლოდ ერთი ბრძანებით:
Hostnamectl set-hostname ns1.example.tst
ინსტალაციის შემდეგ, ჰოსტის სახელი შეიძლება შემოწმდეს შემდეგი ბრძანებით.
# ჰოსტის სახელი ns1.example.tst
Hostnamectl სტატუსი
სანამ შემდეგ ეტაპზე გადახვიდეთ, დარწმუნდით, რომ ყველა სერვერის ჰოსტის სახელი სწორად არის დაყენებული.
პაკეტების ინსტალაცია
ჩვენ გამოვიყენებთ bind-ს DNS-სთვის, რომლის დაყენებაც მარტივად შეიძლება yum ბრძანებით.
DNS-ის ინსტალაცია chroot-ის გარეშე:
# yum install bind
DNS-ის დაყენება chroot-ით:
# yum install bind bind-chroot
კონფიგურაციის ფაილების მომზადება
როგორც უკვე აღვნიშნეთ, bind-ის კონფიგურაცია შესაძლებელია chroot-ით ან მის გარეშე. ბილიკები ოდნავ განსხვავდება იმისდა მიხედვით, დაინსტალირებული იყო თუ არა chroot.
| გზა კონფიგურაციის ფაილამდე | ზონის ფაილების გზა | |
| არა chroot | /etc/ | /var/named/ |
| chroot-ით | /var/named/chroot/etc/ | /var/named/chroot/var/named/ |
შეგიძლიათ გამოიყენოთ named.conf კონფიგურაციის ფაილი, რომელიც მოწოდებულია ნაგულისხმევად. თუმცა, ჩვენ გამოვიყენებთ სხვა მაგალითის კონფიგურაციის ფაილს მარტივად გამოყენებისთვის.
/etc/named.conf ფაილის სარეზერვო ასლის გაკეთება
Cp /etc/named.conf /etc/named.conf.bak
# cp /usr/share/doc/bind-9.9.4/sample/etc/named.rfc1912.zones /etc/named.conf
# cp /usr/share/doc/bind-9.9.4/sample/etc/named.rfc1912.zones /var/named/chroot/etc/named.conf
ახლა, როდესაც არის კონფიგურაციის ფაილის სარეზერვო ასლი და თავად ორიგინალი ფაილი შეიცვალა, ჩვენ გადავდივართ.
# vim /etc/named.conf
# vim /var/named/chroot/etc/named.conf
შემდეგი სტრიქონები დამატებულია/შეცვლილია.
ოფციები (## გზა ზონის ფაილებისკენ ## დირექტორია "/var/named"; ## გადაგზავნის მოთხოვნა Google-ის საჯარო DNS სერვერზე არალოკალური დომენებისთვის ## გადამგზავნი ( 8.8.8.8; ); ); ## პირდაპირი ზონის დეკლარაცია, მაგალითად.tst ## ზონა "example.tst" IN ( ტიპი master; ფაილი "example-fz"; ## ფაილი პირდაპირი ზონისთვის მდებარეობს /var/named ## allow-update (არცერთი;); ## საპირისპირო ზონის დეკლარაცია ქსელისთვის 172.16.1.0 ## ზონა "1.16.172.in-addr.arpa" IN ( ტიპი master; ფაილი "rz-172-16-1"; ## ფაილი საპირისპირო ზონისთვის არის მდებარეობს /var / named ## allow-update ( none; );
ზონის ფაილების მომზადება
ნაგულისხმევი ზონის ფაილები ავტომატურად იქმნება /var/named ან /var/named/chroot/var/named (chroot-ისთვის).
თუ ვივარაუდებთ, რომ ნაგულისხმევი ზონის ფაილები არ არის, ჩვენ შეგვიძლია დავაკოპიროთ ფაილების ნიმუში /usr-დან.
# cp /usr/share/doc/bind-9.9.4/sample/var/named/named.* /var/named/
# cp /usr/share/doc/bind-9.9.4/sample/var/named/named.* /var/named/chroot/var/named
დიდი. ახლა ნაგულისხმევი ზონის ფაილები მზად არის, ჩვენ ვქმნით საკუთარ ზონის ფაილებს, მაგალითად.tst და ქსელის 172.16.1.0. სანამ ჩვენ ვქმნით ზონის ფაილებს, უნდა გვახსოვდეს შემდეგი.
- სიმბოლო '@' ნიშნავს NULL ზონის ფაილებში.
- ყოველი სრულად კვალიფიციური დომენის სახელი (FQDN) მთავრდება წერტილით '.'. mail.example.tst. წერტილის გარეშე, პრობლემები იქნება.
1. პირდაპირი ზონა
პირდაპირი ზონა შეიცავს თარგმანების რუკას სახელებიდან IP მისამართებამდე. საჯარო დომენებისთვის, ჰოსტინგის სერვისებზე განთავსებული DNS დომენები შეიცავს პირდაპირი ზონის ფაილს.
# vim /var/named/example-fz
# vim /var/named/chroot/var/named/example-fz $TTL 1D @ IN SOA ns1.example.tst. mial.example.tst. (0; სერიული 1D; განახლება 1H; ხელახლა სცადეთ 1W; ვადა 3H) ; მინიმალური IN NS ns1.example.tst. IN 172.16.1.3 ფოსტაში IN A 172.16.1.1 IN MX 10 mail.example.tst. www IN A 172.16.1.2 ns1 IN A 172.16.1.3 ftp IN CNAME www.example.tst.
ახსნა: ზონის ფაილში SOA ნიშნავს ავტორიზაციის დაწყებას. ეს არის ავტორიტეტული სახელების სერვერის სრულად კვალიფიციური დომენის სახელი. სრული დომენის სახელის შემდეგ არის საკონტაქტო ელექტრონული ფოსტის მისამართი. რადგან ჩვენ არ შეგვიძლია გამოვიყენოთ "@"-ში [ელფოსტა დაცულია], ჩვენ ხელახლა ვწერთ ელფოსტის მისამართს, როგორც mial.example.tst.
- ნ.ს.: სერვერის სახელი
- ა: ჩანაწერი ან მისამართის ჩანაწერი არის IP მისამართი
- MX: ფოსტის გადამცვლელის ჩანაწერი. აქ ჩვენ ვიყენებთ მხოლოდ ერთ MX-ს პრიორიტეტით 10. რამდენიმე MX-ის შემთხვევაში შეგვიძლია გამოვიყენოთ სხვადასხვა ციფრული პრიორიტეტები. ქვედა რიცხვი იმარჯვებს. მაგალითად, MX 0 უკეთესია ვიდრე MX 1.
- CNAME: სახელი კანონიკური ფორმით. თუ სერვერი მასპინძლობს ბევრ სერვისს, ძალიან სავარაუდოა, რომ მრავალი სახელი გადაწყდეს ერთ სერვერზე. CNAME მიანიშნებს, რომ სერვერს შეიძლება ჰქონდეს სხვა სახელები და მიუთითებს A ჩანაწერში მოცემულ სახელზე.
2. უკუ ზონა
საპირისპირო ზონა შეიცავს IP მისამართებიდან სახელებზე გადაყვანის რუკას. აქ ჩვენ ვქმნით საპირისპირო ზონას ქსელისთვის 172.16.1.0. რეალურ დომენში, საჯარო IP ბლოკის მფლობელის DNS სერვერი შეიცავს საპირისპირო ზონის ფაილს.
# vim /var/named/rz-172-16-1
# vim /var/named/chroot/var/named/rz-172-16-1 $TTL 1D @ IN SOA ns1.example.tst. sarmed.example.tst. (0; სერიული 1D; განახლება 1H; ხელახლა სცადეთ 1W; ვადა 3H) ; მინიმალური IN NS ns1.example.tst. 1 IN PTR mail.example.tst. 2 IN PTR www.example.tst. 3 IN PTR ns1.example.tst.
ახსნა: უკუ ზონაში გამოყენებული პარამეტრების უმეტესობა წინა ზონის იდენტურია, გარდა ერთისა.
- PTR: PTR ან მაჩვენებლის ჩანაწერი, ის მიუთითებს დომენის სრულად კვალიფიციურ სახელზე
დასრულება
ახლა, როდესაც ზონის ფაილები მზად არის, ჩვენ დავაკონფიგურირებთ ზონის ფაილების გარჩევადობას.
# chgrp დასახელებული /var/named/*
# chgrp დასახელებული /var/named/chroot/var/named/*
ახლა ჩვენ დავაყენებთ DNS სერვერის IP მისამართს.
# vim /etc/resolv.conf სახელების სერვერი 172.16.1.3
საბოლოოდ, ჩვენ შეგვიძლია დავიწყოთ DNS სერვისი და დავრწმუნდეთ, რომ ის დაემატება ავტომატურ დაწყებას.
# სერვისი სახელად გადატვირთვა # chkconfig დასახელებულია
DNS ტესტირება
ჩვენ შეგვიძლია გამოვიყენოთ dig ან nslookup DNS-ის შესამოწმებლად. პირველ რიგში, ჩვენ დავაყენებთ საჭირო პაკეტებს.
# yum install bind-utils
1. პირდაპირი ზონის ტესტირება თხრილის გამოყენებით
# dig example.tst ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31184 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 86400 IN A 172.16.1.3 ;; AUTHORITY SECTION: example.com. 86400 IN NS ns1.example.com. ;; ADDITIONAL SECTION: ns1.example.com. 86400 IN A 172.16.1.3
2. შეამოწმეთ PTR თხრილის გამოყენებით
როდესაც იყენებთ თხრილს ტესტირებისთვის, ყოველთვის უნდა მოძებნოთ "NOERROR" სტატუსი. ნებისმიერი სხვა პირობა ნიშნავს, რომ რაღაც არასწორია.
# dig -x 172.16.1.1 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27415 ;; QUESTION SECTION: ;1.1.17.172.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.1.16.172.in-addr.arpa. 86400 IN PTR mail.example.tst. ;; AUTHORITY SECTION: 1.16.172.in-addr.arpa. 86400 IN NS ns1.example.tst. ;; ADDITIONAL SECTION: ns1.example.tst. 86400 IN A 172.16.1.3
3. MX-ის შემოწმება dig-ის გამოყენებით
# dig example.tst mx ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35405
;; QUESTION SECTION:
;example.tst. IN MX
;; ANSWER SECTION:
example.tst. 14366 IN MX 10 mail.example.tst.
პრობლემის გადაჭრის რჩევები
- მე გამორთული მაქვს SELinux.
- დარწმუნდით, რომ თქვენი firewall არ ბლოკავს UDP პორტს 53
- /var/log/messages უნდა შეიცავდეს სასარგებლო ინფორმაციას იმ შემთხვევაში, თუ რამე არასწორია
- დარწმუნდით, რომ ზონის ფაილების მფლობელი არის მომხმარებლის სახელი
- დარწმუნდით, რომ DNS სერვერის IP მისამართი ჩამოთვლილია პირველ რიგში /etc/resolv.conf-ში
- თუ იყენებთ example.tst-ს ლაბორატორიულ გარემოში, დარწმუნდით, რომ გათიშეთ სერვერი ინტერნეტიდან, რადგან example.tst არის არარსებული დომენი.
შეჯამებისთვის, ეს სახელმძღვანელო ფოკუსირებულია მაგალითი.tst დომენის ჰოსტინგი ლაბორატორიულ პარამეტრებში სადემონსტრაციო მიზნებისთვის. გახსოვდეთ, რომ ეს არ არის საჯარო DNS სერვერის შექმნის სახელმძღვანელო, როგორიცაა DNS სერვერი, რომელიც პასუხობს ნებისმიერი IP მისამართის თხოვნას. თუ თქვენ აყენებთ წარმოების DNS სერვერს, დარწმუნდით, რომ შეამოწმეთ რომელი წესები ვრცელდება საჯარო DNS-ზე. კიდევ ერთი გაკვეთილი მოიცავს მეორადი DNS-ის შექმნას, DNS სერვერზე წვდომის შეზღუდვას და DNSSEC-ის განხორციელებას.
გარანტი არის სანდო შუამავალი მონაწილეებს შორის გარიგების დროს.