Вопрос или проблема
Согласно RFC 2535, при ответе на запрос для несуществующего доменного имени, помимо записи NSEC для QName, также необходимо вернуть дополнительную запись NSEC (и, конечно, ее связанный RRSIG), чтобы доказать, что подстановочный знак не существует.
5.3 Дополнительная сложность из-за подстановочных знаков
Доказательство того, что ответ на несуществующее имя является корректным или что ответ на расширение подстановочного знака является правильным, делает вещи немного более сложными.
В частности, когда возвращается ответ на несуществующее имя, должен быть возвращен NXT, показывающий, что точное имя, запрашиваемое, не существовало и, в общем, один или более дополнительных NXT должны быть возвращены, чтобы также доказать, что не было подстановочного знака, расширение которого должно было быть возвращено. (Нет необходимости возвращать несколько копий одного и того же NXT.) Эти NXT, если они есть, возвращаются в разделе authority ответа.
CloudFlare также сказал то же самое в этом блоге: https://blog.cloudflare.com/black-lies/
Второй запись NSEC также возвращается, чтобы доказать, что нет подстановочного знака, который бы включал bogus.ietf.org:
ietf.org. 1062 IN NSEC ietf1._domainkey.ietf.org. A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY SPF
Эта запись выше показывает, что подстановочный знак (*.ietf.org) существовал бы между этими двумя именами. Поскольку на *.ietf.org нет записи подстановочного знака, как это доказано этой записью NSEC, DNS-резолвер знает, что действительно ничего не должно было быть возвращено для bogus.ietf.org. Эта запись NSEC также имеет подпись:
ietf.org. 1062 IN RRSIG NSEC 5 2 1800 20170308083303 20160308073501 40452 ietf.org. homg5NrZIKo0tR+aEp0MVYYjT7J/KGTKP46bJ8eeetbq4KqNvLKJ5Yig ve4RSWFYrSARAmbi3GIFW00P/dFCzDNVlMWYRbcFUt5NfYRJxg25jy95 yHNmInwDUnttmzKuBezdVVvRLJY3qSM7S3VfI/b7n6++ODUFcsL88uNB V6bRO6FOksgE1/jUrtz6/lEKmodWWI2goFPGgmgihqLR8ldv0Dv7k9vy Ao1uunP6kDQEj+omkICFHaT/DBSSYq59DVeMAAcfDq2ssbr4p8hUoXiB tNlJWEubMnHi7YmLSgby+m8b97+8b6qPe8W478gAiggsNjc2gQSKOOXH EejOSA==
В чем смысл этого? Я не нашел документов, объясняющих цель дополнительной записи NSEC.
Ответ или решение
Вопрос о необходимости дополнительной записи NSEC для доказательства отсутствия wildcard (подстановочного символа) в контексте DNSSEC (Domain Name System Security Extensions) является достаточно сложным и требует глубокого понимания принципов работы DNSSEC и его механизмов безопасности. В данной статье мы рассмотрим теоретическую базу, примеры и применение на практике, что позволит разъяснить необходимость и важность предоставления дополнительной записи NSEC.
Теория
DNSSEC был разработан для решения проблем безопасности в DNS, который изначально не был спроектирован с учетом современных угроз. Одной из особенностей, которые добавляет DNSSEC, является возможность криптографического доказательства отсутствия существования домена, благодаря таким записям как NSEC и NSEC3.
Запись NSEC используется для верификации целостности данных и возможности доказательства негативных ответов "no such name". Она показывает диапазон имён доменов в DNS зоне и перечисляет типы записей, которые существуют для данного домена. Если элемент какого-либо запроса отсутствует, NSEC предоставляет доказательство того, почему это произошло.
Когда происходит запрос к несуществующему имени домена, DNSSEC должен не только доказать, что конкретное имя домена не существует, но также и подтвердить, что не существует wildcard записи, которая могла бы удовлетворить этот запрос. Это необходимо, потому что в DNS механизм wildcard позволяет обслуживать запросы к нескольким поддоменам без явного указания каждого из них в настройках.
Пример
Рассмотрим запрос, который не может быть разрешен через прямую запись, например bogus.ietf.org. Для этого DNSSEC возвращает NSEC запись для bogus.ietf.org, чтобы указать, что конкретно это имя не существует. Однако это также требует предоставления дополнительной записи NSEC, которая подтвердит отсутствие wildcard-записи *.ietf.org, способной покрыть запрос.
Практическим примером служит ситуация, описанная в блоге Cloudflare. Запись NSEC ietf.org. 1062 IN NSEC ietf1._domainkey.ietf.org. A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY SPF указывает на отсутствие wildcard между доменами, подтверждая, что *.ietf.org не существует и расширение не должно было произойти.
Применение
Зачем же это необходимо? Представьте, если бы не было способа проверить отсутствие wildcard записи. В этом случае каждый негативный ответ на запрос к несуществующему домену мог бы быть подвергнут спуфинг-атакам, в которых злоумышленник создает видимость, что wildcard запись могла бы существовать и вернуть неправильные данные.
Такое доказательство поддерживает целостность DNS-запросов, повышает доверие к данным, полученным из DNS и предотвращает атаки с заменой данных. Благодаря NSEC-записям клиенты DNS могут с уверенностью полагаться на то, что ответ сервера точный и безопасный.
Заключение
DNSSEC и, в частности, механизмы NSEC занимаются созданием безопасного и надежного пространства для разрешения доменных имён. Дополнительные NSEC-записи, подтверждающие отсутствие wildcard, играют ключевую роль в этом процессе, обеспечивая уверенность в том, что ни одно имя не может быть разрешено неожиданным способом, и таким образом защищая инфраструктуру DNS от потенциальных атак. Это значительно усложняет работу потенциальному злоумышленнику, обеспечивая пользователям и владельцам доменов более высокий уровень безопасности.