Обговорюємо думки експертів і компаній, які виступають за і проти впровадження DNS over HTTPS і DNS over TLS, а також специфікації EDNS.

Специфікація EDNS і небезпека для ПД

Стандартизований в 1987 році ( RFC1035 ) механізм роботи DNS не брав до уваги багато змін і вимоги до безпеки, які прийшли з розвитком інтернету. Навіть автор системи доменних імен - Пол Мокапетріс (Paul Mockapetris) - в одному з інтерв'ю зазначив, що не очікував настільки широкого поширення свого творіння. За його оцінками DNS повинна була працювати з десятками мільйонів IP-адрес, але їх кількість перевищила 300 млн.

Спочатку можливостей для розширення функціональності DNS було небагато. Але ситуація змінилася в 1999 році, коли опублікували специфікацію EDNS0 ( RFC2671 ). У неї додали новий тип псевдозаписів - OPT. Вона містить 16 прапорів, що описують властивості DNS-запиту.

Відзначимо, що стандарт EDNS0 повинен був стати тимчасовим рішенням. У перспективі його б замінила оновлена версія EDNS1. Але замість перетворення в EDNS1 (для якого є драфт ), специфікація почала обростати опціями і інтеграціями і використовується до цих пір.

EDNS0 також дозволила прикріплювати до DNS-записів інформацію про підмережі клієнта. Такий підхід застосовує мережу розповсюдження контенту Akamai, щоб визначати найближчий до користувача сервер для підвищення якості обслуговування. 

Однак Джефф Хастон (Geoff Huston), провідний науковий співробітник інтернет-реєстратора APNIC, зазначає , що так сервери, керуючі DNS-зонами, отримують можливість ідентифікувати користувача, що відправив запит на скачування того чи іншого файлу. Ще новий запис збільшує навантаження на локальні резолвери. Вони змушені додавати ключі пошуку (lookup key) для підмереж в свій кеш, знижуючи його ефективність.

Незважаючи на побоювання, нову функціональність впровадили такі провайдери, як Google Public DNS і OpenDNS. Можливо, в майбутньому в специфікацію EDNS0 внесуть відповідні правки, які поліпшать ситуацію з безпекою ПД. Наприклад, подібні модифікації можуть зробити в EDNS1, якщо вона все ж вийде зі статусу чернетки.

Суперечки навколо DoH / DoT

Протокол DNS не шифрує повідомлення, що передаються між клієнтом і сервером. Тому якщо хакер зможе перехопити запити, то він дізнається, які ресурси відвідує користувач. Для вирішення проблеми в жовтні минулого року інженери з IETF і ICANN опублікували стандарт DNS over HTTPS (DoH). Новий підхід пропонує відправляти DNS-запити не безпосередньо, а приховувати їх в HTTPS-трафіку. Приймаючий сервер витягує необхідні дані за допомогою набору API. Обмін даними йде через стандартний порт 443, і якщо хтось вирішить прослухати трафік, то він не одержить від неї DNS-інформацію.

На підтримку нового протоколу висловилися великі ІТ-компанії - Google і Mozilla - і інтегрували функціональність DNS over HTTPS в свої браузери. Джефф Хастон з APNIC також зауважив , що DoH спростить структуру мереж за рахунок скорочення числа використовуваних портів і прискорить перетворення адрес.

Але цю думку поділяють не всі. За словами Пола Віксі (Paul Vixie), розробника DNS-сервера BIND, новий стандарт, навпаки, ускладнює адміністрування мереж в компаніях - сисадміни не можуть блокувати шкідливі сайти. При цьому DoH зовсім не гарантує анонімність запитів. Визначити, до яких хостів звертається користувач, можна по SNI і відповідей OCSP. За даними дослідження APNIC, третій стороні (наприклад, інтернет-провайдеру) не потрібні DNS-записи для визначення ресурсів, які відвідує користувач. Їх можна встановити з точністю в 95% тільки за IP.

З цієї причини частина експертів пропонує використовувати альтернативний підхід - DNS over TLS ( DoT). У цьому випадку передача DNS-запитів відбувається по виділеному порту 853. Так, дані раніше шифруються, але при цьому спрощується настройка мереж.

Поки складно сказати, який із стандартів переможе. Вже зараз багато хмарних провайдерів і розробники браузерів підтримують обидва протоколи. Який з них отримає більше поширення покаже тільки час - в будь-якому випадку на це може піти не одне десятиліття.