BIND DNS სერვერის 9.18.0 გამოშვება DNS-over-TLS და DNS-over-HTTPS-ის მხარდაჭერით

ორი წლის განვითარების შემდეგ, ISC კონსორციუმმა გამოუშვა BIND 9.18 DNS სერვერის ძირითადი ახალი ფილიალის პირველი სტაბილური გამოშვება. 9.18 ფილიალის მხარდაჭერა უზრუნველყოფილი იქნება სამი წლის განმავლობაში 2 წლის მე-2025 კვარტალამდე, როგორც გაფართოებული მხარდაჭერის ციკლის ნაწილი. 9.11 ფილიალის მხარდაჭერა დასრულდება მარტში, ხოლო 9.16 ფილიალის მხარდაჭერა 2023 წლის შუა რიცხვებში. BIND-ის შემდეგი სტაბილური ვერსიის ფუნქციონირების განსავითარებლად, ჩამოყალიბდა ექსპერიმენტული ფილიალი BIND 9.19.0.

BIND 9.18.0-ის გამოშვება გამოირჩევა DNS-ის მხარდაჭერით HTTPS-ზე (DoH, DNS მეტი HTTPS) და DNS-ზე TLS-ზე (DoT, DNS მეტი TLS), ასევე XoT (XFR-ზე-TLS) მექანიზმით. DNS კონტენტის უსაფრთხო გადაცემისთვის ზონები სერვერებს შორის (მხარდაჭერილია როგორც გაგზავნის, ასევე მიღების ზონები XoT-ით). შესაბამისი პარამეტრებით, ერთი დასახელებული პროცესი ახლა შეიძლება მოემსახუროს არა მხოლოდ ტრადიციულ DNS მოთხოვნებს, არამედ DNS-over-HTTPS და DNS-over-TLS გამოყენებით გაგზავნილ შეკითხვებს. კლიენტის მხარდაჭერა DNS-over-TLS-ისთვის ჩაშენებულია dig utility-ში, რომელიც შეიძლება გამოყენებულ იქნას მოთხოვნის გასაგზავნად TLS-ზე, როდესაც მითითებულია "+tls" დროშა.

DoH-ში გამოყენებული HTTP/2 პროტოკოლის დანერგვა ეფუძნება nghttp2 ბიბლიოთეკის გამოყენებას, რომელიც შედის როგორც არჩევითი ასამბლეის დამოკიდებულება. DoH და DoT სერთიფიკატები შეიძლება მომწოდებელი იყოს მომხმარებლის მიერ ან ავტომატურად გენერირებული გაშვების დროს.

მოთხოვნის დამუშავება DoH და DoT გამოყენებით ჩართულია მოსმენის დირექტივაში "http" და "tls" ვარიანტების დამატებით. დაშიფრული DNS-ზე-HTTP-ის მხარდასაჭერად, პარამეტრებში უნდა მიუთითოთ „tls none“. გასაღებები განისაზღვრება "tls" განყოფილებაში. ნაგულისხმევი ქსელის პორტები 853 DoT-სთვის, 443 DoH-სთვის და 80 DNS-over-HTTP-ისთვის შეიძლება გადაიცვალოს tls-port, https-port და http-port პარამეტრების საშუალებით. Მაგალითად:

tls local-tls { key-file "/path/to/priv_key.pem"; cert-ფაილი "/path/to/cert_chain.pem"; }; http local-http-server { endpoints { "/dns-query"; }; }; პარამეტრები { https-პორტი 443; მოსმენის პორტი 443 tls local-tls http myserver {any;}; }

BIND-ში DoH განხორციელების ერთ-ერთი მახასიათებელია TLS-ისთვის დაშიფვრის ოპერაციების სხვა სერვერზე გადატანის შესაძლებლობა, რაც შეიძლება საჭირო იყოს იმ პირობებში, როდესაც TLS სერთიფიკატები ინახება სხვა სისტემაში (მაგალითად, ინფრასტრუქტურაში ვებ სერვერებით) და შენარჩუნებულია. სხვა პერსონალის მიერ. დაშიფრული DNS-ზე-HTTP-ის მხარდაჭერა ხორციელდება გამართვის გასამარტივებლად და შიდა ქსელში სხვა სერვერზე გადამისამართების ფენად (დაშიფვრის ცალკე სერვერზე გადასატანად). დისტანციურ სერვერზე, nginx შეიძლება გამოყენებულ იქნას TLS ტრაფიკის გენერირებისთვის, ისევე, როგორც HTTPS სავალდებულოა ორგანიზებული ვებსაიტებისთვის.

კიდევ ერთი მახასიათებელია DoH-ის, როგორც ზოგადი ტრანსპორტის ინტეგრაცია, რომელიც შეიძლება გამოყენებულ იქნას არა მხოლოდ კლიენტის მოთხოვნების მოსაგვარებლად, არამედ სერვერებს შორის კომუნიკაციისას, ავტორიტეტული DNS სერვერის მიერ ზონების გადაცემისას და სხვა DNS-ის მიერ მხარდაჭერილი ნებისმიერი შეკითხვის დამუშავებისას. ტრანსპორტირება.

ნაკლოვანებებს შორის, რომელთა კომპენსირება შესაძლებელია build-ის გამორთვით DoH/DoT-ით ან დაშიფვრის სხვა სერვერზე გადატანით, გამორჩეულია კოდის ბაზის ზოგადი გართულება - დამატებულია ჩაშენებული HTTP სერვერი და TLS ბიბლიოთეკა, რომელიც შესაძლოა შეიცავდეს დაუცველობა და მოქმედებს როგორც დამატებითი ვექტორები შეტევებისთვის. ასევე, DoH-ის გამოყენებისას, ტრაფიკი იზრდება.

შეგახსენებთ, რომ DNS-over-HTTPS შეიძლება სასარგებლო იყოს პროვაიდერების DNS სერვერების მეშვეობით მოთხოვნილი ჰოსტების სახელების შესახებ ინფორმაციის გაჟონვის თავიდან ასაცილებლად, MITM შეტევებისა და DNS ტრაფიკის გაყალბების წინააღმდეგ (მაგალითად, საჯარო Wi-Fi-თან დაკავშირებისას), დაპირისპირება. დაბლოკვა DNS დონეზე (DNS-over-HTTPS ვერ ჩაანაცვლებს VPN-ს DPI დონეზე განხორციელებული ბლოკირების გვერდის ავლით) ან სამუშაოს ორგანიზებისთვის, როდესაც შეუძლებელია პირდაპირ DNS სერვერებზე წვდომა (მაგალითად, პროქსის მეშვეობით მუშაობისას). თუ ნორმალურ სიტუაციაში DNS მოთხოვნები პირდაპირ იგზავნება DNS სერვერებზე, რომლებიც განსაზღვრულია სისტემის კონფიგურაციაში, მაშინ DNS-ზე-HTTPS-ის შემთხვევაში, ჰოსტის IP მისამართის განსაზღვრის მოთხოვნა ინკაპსულირებულია HTTPS ტრაფიკში და იგზავნება HTTP სერვერზე, სადაც. გადამწყვეტი ამუშავებს მოთხოვნებს ვებ API-ით.

„DNS TLS-ზე“ განსხვავდება „DNS-ზე HTTPS“-ისგან სტანდარტული DNS პროტოკოლის გამოყენებით (ჩვეულებრივ გამოიყენება ქსელის პორტი 853), რომელიც შეფუთულია დაშიფრული საკომუნიკაციო არხით, რომელიც ორგანიზებულია TLS პროტოკოლის გამოყენებით ჰოსტის მოქმედების შემოწმებით დამოწმებული TLS/SSL სერთიფიკატებით. სერტიფიცირების ორგანოს მიერ. არსებული DNSSEC სტანდარტი იყენებს დაშიფვრას მხოლოდ კლიენტისა და სერვერის ავთენტიფიკაციისთვის, მაგრამ არ იცავს ტრაფიკს თვალთვალისგან და არ იძლევა მოთხოვნის კონფიდენციალურობის გარანტიას.

რამდენიმე სხვა ინოვაცია:

• დამატებულია tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer და udp-send-buffer პარამეტრები, რათა დააყენოთ ბუფერების ზომები, რომლებიც გამოიყენება TCP და UDP-ზე მოთხოვნის გაგზავნისა და მიღებისას. დატვირთულ სერვერებზე შემომავალი ბუფერების გაზრდა თავიდან აიცილებს პაკეტების ვარდნას ტრაფიკის პიკის დროს, ხოლო მათი შემცირება დაგეხმარებათ თავიდან აიცილოთ მეხსიერების ჩაკეტვა ძველი მოთხოვნებით.
• დამატებულია ჟურნალის ახალი კატეგორია „rpz-passthru“, რომელიც საშუალებას გაძლევთ ცალკე დაარეგისტრიროთ RPZ (Response Policy Zones) გადამისამართების მოქმედებები.
• პასუხის პოლიტიკის განყოფილებაში დამატებულია „nsdname-wait-recurse“ ოფცია, როდესაც დაყენებულია „არა“-ზე, RPZ NSDNAME წესები გამოიყენება მხოლოდ იმ შემთხვევაში, თუ მოთხოვნისთვის მოიძებნება ქეშში არსებული ავტორიტეტული სახელების სერვერები, წინააღმდეგ შემთხვევაში RPZ NSDNAME წესი იგნორირებულია, მაგრამ ინფორმაცია იხსნება ფონზე და ვრცელდება შემდგომ მოთხოვნებზე.
• HTTPS და SVCB ტიპის ჩანაწერებისთვის განხორციელდა "დამატებითი" განყოფილების დამუშავება.
• დამატებულია მორგებული განახლების პოლიტიკის წესების ტიპები - krb5-subdomain-self-rhs და ms-subdomain-self-rhs, რაც საშუალებას გაძლევთ შეზღუდოთ SRV და PTR ჩანაწერების განახლება. განახლების პოლიტიკის ბლოკები ასევე ამატებენ შესაძლებლობას დააწესონ შეზღუდვები ჩანაწერების რაოდენობაზე, ინდივიდუალური თითოეული ტიპისთვის.
• დამატებულია ინფორმაცია სატრანსპორტო პროტოკოლის (UDP, TCP, TLS, HTTPS) და DNS64 პრეფიქსების შესახებ dig utility-ის გამოსავალზე. გამართვის მიზნით, dig-მა დაამატა კონკრეტული მოთხოვნის იდენტიფიკატორის მითითების შესაძლებლობა (dig +qid= ).
• დამატებულია მხარდაჭერა OpenSSL 3.0 ბიბლიოთეკისთვის.
• IP ფრაგმენტაციასთან დაკავშირებული პრობლემების გადასაჭრელად DNS Flag Day 2020-ის მიერ გამოვლენილი დიდი DNS შეტყობინებების დამუშავებისას, კოდი, რომელიც არეგულირებს EDNS ბუფერის ზომას, როდესაც მოთხოვნაზე პასუხი არ არის, ამოღებულია გადამწყვეტისაგან. EDNS ბუფერის ზომა ახლა დაყენებულია მუდმივზე (edns-udp-size) ყველა გამავალი მოთხოვნისთვის.
• Build სისტემა გადართულია ავტოკონფის, ავტომატური და libtool-ის კომბინაციაზე.
• ზონის ფაილების მხარდაჭერა „რუკის“ ფორმატში (მასტერფაილი ფორმატის რუკა) შეწყვეტილია. ამ ფორმატის მომხმარებლებს რეკომენდირებულია გადაიყვანონ ზონები ნედლეულ ფორმატში სახელდებული კომპილაზონის პროგრამის გამოყენებით.
• ძველი DLZ (დინამიურად ჩატვირთული ზონების) დრაივერების მხარდაჭერა შეწყდა და შეიცვალა DLZ მოდულები.
• Windows პლატფორმის მხარდაჭერა და გაშვება შეწყდა. ბოლო ფილიალი, რომელიც შეიძლება დაინსტალირდეს Windows-ზე, არის BIND 9.16.

წყარო: opennet.ru