Після двох років розробки консорціум ISC представив перший стабільний реліз нової значної галузі DNS-сервера BIND 9.18. Підтримка гілки 9.18 буде здійснюватись протягом трьох років до 2 кварталу 2025 року в рамках розширеного циклу супроводу. Підтримка гілки 9.11 припиниться у березні, а гілки 9.16 у середині 2023 року. Для розвитку функціональності наступної стабільної версії BIND сформовано експериментальну гілку BIND 9.19.0.
Випуск BIND 9.18.0 примітний реалізацією підтримки технологій DNS поверх HTTPS (DoH, DNS over HTTPS) і DNS поверх TLS (DoT, DNS over TLS), а також механізму XoT (XFR-over-TLS) для безпечної передачі вмісту DNS- зон між серверами (підтримується як віддача, і прийом зон по XoT). При відповідних налаштуваннях один процес named тепер може обслуговувати не лише традиційні DNS-запити, а й запити, надіслані з використанням DNS-over-HTTPS та DNS-over-TLS. Клієнтська підтримка DNS-over-TLS вбудована в утиліту dig, яка може використовуватися для надсилання запитів поверх TLS при вказівці прапора +tls.
Реалізація протоколу HTTP/2, що використовується в DoH, заснована на застосуванні бібліотеки nghttp2, яка включена до числа необов'язкових складальних залежностей. Сертифікати для DoH та DoT можуть надаватися користувачем або генеруватися автоматично під час запуску.
Обробка запитів з використанням DoH та DoT включається через додавання опцій "http" та "tls" у директиві listen-on. Для підтримки незашифрованого DNS-over-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-file "/path/to/cert_chain.pem"; }; http local-http-server {endpoints{“/dns-query”; }; }; options { https-port 443; listen-on port 443 tls local-tls http myserver {any;}; }
З особливостей реалізації DoH BIND відзначається можливість винесення операцій шифрування для TLS на інший сервер, що може знадобитися в умовах, коли зберігання TLS-сертифікатів здійснюється на іншій системі (наприклад, в інфраструктурі з web-серверами) і обслуговується іншим персоналом. Підтримка незашифрованого DNS-over-HTTP реалізована для спрощення налагодження і як рівень прокидання на інший сервер у внутрішній мережі (для винесення шифрування на окремий сервер). На виносному сервері для формування TLS-трафіку може використовуватися nginx за аналогією з тим, як організується обв'язка HTTPS для сайтів.
Іншою особливістю є інтеграція DoH як загальний транспорт, який може застосовуватися не тільки для обробки запитів клієнтів до резолверу, але й при обміні даними між серверами, передачі зон авторитетним DNS-сервером і обробці будь-яких запитів, підтримуваних іншими транспортами DNS.
З недоліків, які можна буде компенсувати відключенням збірки з DoH/DoT або винесенням шифрування на інший сервер, виділяється загальне ускладнення кодової бази - до складу додається вбудований HTTP-сервер і TLS-бібліотека, які потенційно можуть містити вразливість та виступати додатковими векторами для атак. Також під час використання DoH збільшується трафік.
Нагадаємо, що DNS-over-HTTPS може виявитися корисним для виключення витоків відомостей про імена хостів через DNS-сервери провайдерів, боротьби з MITM-атаками і заміною DNS-трафіку (наприклад, при підключенні до публічних Wi-Fi), протистояння блокувань на рівні DNS (DNS-over-HTTPS не може замінити VPN в області обходу блокувань, реалізованих на рівні DPI) або для організації роботи у разі неможливості прямого звернення до DNS-серверів (наприклад, під час роботи через проксі). Якщо у звичайній ситуації DNS-запити безпосередньо відправляються на визначені в конфігурації системи DNS-сервери, то у разі DNS-over-HTTPS запит на визначення IP-адреси хоста інкапсулюється в трафік HTTPS і відправляється на HTTP-сервер, на якому резолвер обробляє запити через Web API.
DNS over TLS відрізняється від DNS over 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).
- У секції response-policy додана опція «nsdname-wait-recurse», при встановленні якої значення «no» правила RPZ NSDNAME застосовуються тільки якщо для запиту знайдені присутні в кеші авторитетні сервери імен, інакше правило RPZ NSDNAME ігнорується, але інформація витягується в фоні та застосовується до наступних запитів.
- Для записів з типами HTTPS та SVCB реалізовано обробку секції «ADDITIONAL».
- Додані типи правил update-policy — krb5-subdomain-self-rhs і ms-subdomain-self-rhs, що дозволяють обмежити оновлення записів SRV і PTR. У блоках update-policy також додано можливість встановлення обмежень кількості записів, окремих кожного типу.
- У висновок утиліти dig додані відомості про транспортний протокол (UDP, TCP, TLS, HTTPS) та префікси DNS64. Для налагоджувальних цілей dig додано можливість вказівки конкретного ідентифікатора запиту (dig +qid= ).
- Додано підтримку бібліотеки OpenSSL 3.0.
- Для вирішення проблем з IP-фрагментацією при обробці DNS-повідомлень великого розміру, позначених ініціативою DNS Flag Day 2020, з резолвера видалено код, який виконує коригування розміру буфера EDNS у разі відсутності відповіді на запит. Розмір буфера EDNS тепер встановлюється постійним (edns-udp-size) всім вихідних запитів.
- Система складання переведена на використання зв'язки з autoconf, automake та libtool.
- Припинено підтримку файлів зон у форматі «map» (masterfile-format map). Користувачам даного формату рекомендовано перетворити зони на формат raw за допомогою утиліти named-compilezone.
- Припинено підтримку старих драйверів DLZ (Dynamically Loadable Zones), на зміну яким прийшли модулі DLZ.
- Припинено підтримку збирання та запуску для платформи Windows. Останньою гілкою, яку можна встановити у Windows, залишається BIND 9.16.
Джерело: opennet.ru