Быстрая альтернатива
QUIC — это транспортный протокол на базе UDP, который представили инженеры из IETF и Google. Он вполне соответствует своему названию и обладает большей производительностью по сравнению с аналогами. Например, позволяет установить соединение со знакомым сервером в одно рукопожатие. В то же время протокол предлагает дополнительные защитные механизмы — шифрует данные и требует аутентификации получателя пакетов.
Эти особенности полезны при работе с DNS, поэтому в прошлом году IETF одобрили стандарт DNS-over-QUIC (DoQ). Его даже оформили в формате RFC 9250, хотя это событие прошло без ярких заголовков.
Протокол решает проблему head-of-line-blocking и заточен под нестабильные сети с потерями пакетов. При этом он подходит для работы как с рекурсивными, так и авторитативными DNS-серверами. Так, по сравнению с классическим DNS-over-HTTPS, DoQ применим на большем спектре задач.
Разумеется, не стоит ждать, что новый протокол получит широкое распространение в ближайший месяц. Но спецификация находилась в разработке пять лет, поэтому некоторые реализации уже существуют. Есть больше тысячи резолверов с поддержкой DoQ. Среди них 45% работает в Азии, 32% в Европе и 18% в Северной Америке.
Существует и несколько реализаций DoQ. Quicdoc, основанный на Picoquic и написанный на C, библиотека aioquic на Python и DNS-инструмент для функционального тестирования Flamethrower. Со временем число таких решений продолжит расти. Как минимум потому, что с приходом HTTP/3 классический DoH будет поддерживать работу с QUIC.
Специально для интернета вещей
DNS-over-QUIC не единственный протокол, который приходит на арену шифрования DNS-запросов. На прошлой неделе международная группа инженеров предложила стандарт DNS-over-CoAP (DoC), ориентированный на развертку в сетях IoT.
Он подразумевает передачу DNS-сообщений по Constrained Application Protocol (CoAP) с протоколом безопасности Object Security for Constrained RESTful Environments (OSCORE). Он основан на объектах данных и позволяет обмениваться сообщениями CoAP через промежуточные узлы со сквозной защитой.
DoC-клиент шифрует DNS-запрос в одном или нескольких CoAP-сообщениях (RFC8132). Запрос поступает DoC-серверу, который его обрабатывает. Он может работать как stub-резолвер (RFC8499) или рекурсивный резолвер (RFC8499). В целом процесс работы с DNS-сообщениями может выглядеть следующим образом:
FETCH coaps://[2001:db8::1]/
Content-Format: application/dns-message
Accept: application/dns-message
Payload: 00 00 01 20 00 02 00 00 00 00 00 00 07 65 78 61 [binary]
6d 70 6c 65 03 6f 72 67 00 00 1c 00 01 c0 0c 00 [binary]
01 00 01 [binary]
Протокол находится на ранних этапах обсуждения, поэтому авторам предстоит проделать еще много работы — в частности, дополнить механизмы безопасности, чтобы противостоять более широкому набору кибератак. Внести предложения до 13 сентября 2023 года могут все желающие — для этих целей драфт документа разместили в репозитории на GitHub.