Полезен ли DNSSEC?

Полезен ли DNSSEC?

На этот вопрос нельзя ответить (какое бы слово вы ни поставили вместо «DNSSEC» в этом предложении), пока вы не начнете описывать то, что хотите защитить.

Когда у вас есть список рисков/уязвимостей/угроз, от которых вы хотите защититься, вы можете узнать, какие решения существуют, и определить для каждого решения, насколько оно полезно или нет.

DNSSEC полезен при некоторых проблемах с DNS, но не во всех. Он представляет собой новые проблемы (постоянное обслуживание подписей и ключей для одного), но также и новые функции (агрессивное кэширование всего ниже NXDOMAIN, если оно правильно проверено DNSSEC).

Даже если преобразователь DNS подтверждает, что авторитетный сервер имен отправил правильные данные без изменений – как мы можем предотвратить отправку преобразователем DNS поддельного ответа DNS клиенту DNS?

Это ничем не отличается от сегодняшнего дня: если вы используете любой общедоступный преобразователь DNS (8.8.8.8, 1.1.1.1, 9.9.9.9 и многие другие), вы, конечно, ПОЛНОСТЬЮ рискуете этим отправка вам мусорных данных. Это компромисс. DoH/DoT здесь ничего не решает, поскольку защищает только передачу контента между вами и этим распознавателем, а не сам контент. Какой контент «защищен» DNSSEC, если доменное имя, для которого вы делаете запросы, защищено DNSSEC (это одна часть, которую вы забываете в своих вопросах и которая фактически затрудняет DNSSEC: владелец доменного имени должен включить его И Резолверы DNS должны использовать новые подписи и выполнять проверку; если одна часть этого уравнения с двумя переменными отсутствует, DNSSEC бесполезен, потому что он просто не может работать)

Таким образом, вопрос вращается больше вокруг: какой рекурсивный сервер имен использовать и где он должен работать. Конечно, для максимального контроля вы хотите, чтобы преобразователь работал на ВАШИХ машинах.Он по-прежнему может использовать внешние ресурсы и преобразователи DNS, но окончательная проверка DNSSEC должна выполняться на вашем сервере имен, а не на другом. Конечно, это требует больше работы, чем просто полагаться на любой другой ресурс, который делает всю работу с DNSSEC «бесплатно» за вас.

Если резолвер DNS не поддерживает DNSSEC, может ли он по-прежнему отправлять DNS-запросы полномочному серверу имен, для зоны которого настроен DNSSEC?

Да. Резолвер, желающий получить данные DNSSEC, должен переключить флаг «DO» в своем запросе.

Из документации dig:

        +[no]dnssec
         This option requests that DNSSEC records be sent by setting the DNSSEC OK (DO) bit in the OPT record in the additional section of the query.

Которую вы можете увидеть следующим образом:

$ dig +dnssec example.com

; <<>> DiG 9.16.18 <<>> +dnssec example.com
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40492
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
                           ^^

Или из §3.2.1 RFC 4035:

3.2.1. Бит DO

Сторона резолвера защищенного рекурсивного сервера имен ДОЛЖНА установить бит DO при отправке запросов вне зависимости от состояния DO бит в инициирующем запросе, полученном стороной сервера имен. Если бит DO в инициирующем запросе не установлен, сторона сервера имен ДОЛЖНЫ удаляться любые аутентифицирующие DNSSEC RR из ответа, но ДОЛЖНЫ НЕ удаляйте какие-либо типы DNSSEC RR, которые инициирующий запрос явно просил.

Если DNS-клиент (рекурсивный преобразователь) делает это И если запрашиваемый полномочный сервер имен имеет DNSSEC (отсюда RRSIG/NSEC/NSEC3 типы записей в зонах), то преобразователь получит эти записи и сможет выполнить проверку DNSSEC.

Когда вы (заглушка/клиент DNS, не являющийся распознавателем) запрашиваете рекурсивный распознаватель, у вас есть возможность использовать флаг CD, определенный следующим образом:

        +[no]cdflag
        This option sets [or does not set] the CD (checking disabled) bit in the query. This requests the server to not perform DNSSEC validation of responses.

(остерегайтесь возможного двойного отрицание).

Если клиент не использует CD, то проверка DNSSEC НЕ отключена, следовательно, она включена, и удаляющий сервер либо предоставит окончательный ответ (если DNSSEC включен для записи И проверка была успешно) или ответит NXDOMAIN, если проверка DNSSEC не удалась.Флаг AD будет установлен для обозначения того, что все записи были проверены как безопасные, если это так (если запрос исходит от рекурсивного сервера имен, этот флаг не может существовать от авторитетного, как вам нужно полная цепочка DNSSEC от корня IANA для проверки любой данной записи)

1. В идеале вы должны выполнять валидацию локально на клиенте (что сегодня не так распространено, но далеко не неслыханно) или иным образом полагаться на безопасный сетевой путь, который может преодолеть разрыв между клиентом и доверенным проверяющим распознавателем.
   Этот безопасный сетевой путь может означать что-то вроде DNS-over-TLS, DNS-over-HTTPS, DNSCrypt или, в некоторой степени, локальную сеть (более слабый уровень доверия, но все же полезный для подмножества сценариев атак).
2. Да