☰

DNSSEC так часто ломается или systemd-resolved слишком усердствует?

tag-icon • tag-icon dns systemd
DNSSEC так часто ломается или systemd-resolved слишком усердствует?

Недавно я переключил свой DNS-резолвер на , systemd-resolvedчтобы начать использовать DNSSEC там, где он доступен. Моя конфигурация:

[Resolve]
DNS=8.8.8.8 8.8.4.4
DNSOverTLS=yes

(включая закомментированное значение по умолчанию DNSSEC=allow-downgrade)

Кажется, все работает отлично для большинства сайтов, как с включенным DNSSEC, так и без него. Однако иногда я попадаю на сайт, который не разрешается:

$ resolvectl query savannah.gnu.org
savannah.gnu.org: resolve call failed: DNSSEC validation failed: failed-auxiliary
$ resolvectl query keys.mailvelope.com
keys.mailvelope.com: resolve call failed: DNSSEC validation failed: failed-auxiliary
$ resolvectl query d1dkupr86d302v.cloudfront.net
d1dkupr86d302v.cloudfront.net: resolve call failed: DNSSEC validation failed: failed-auxiliary

Я попытался проверить это черезАнализатор DNSSEC (для savannah.gnu.org). Однако мне сложно понять результат. Я не вижу, чем он отличается от любого другого домена, не включающего DNSSEC.

У меня такой вопрос: DNSSEC так часто ломается или systemd-resolved делает что-то не так?

решение1

Вероятно, и то, и другое. В целом, основываясь на предыдущих отчетах, я бы склонился к последнему (systemd-resolved в некоторых случаях слишком строг). Однако,по данным DNSViz, конфигурация доменов также не проходит все проверки.

Я также не уверен на 100% относительно некоторых механизмов DNSSEC, но вот мое мнение:

savannah.gnu.org

Это огромный беспорядок. Systemd-resolved правильно обнаруживает проблему с доменом... но неправильно отклоняет ее на основе информации, которой не следует доверять.

  1. Зона gnu.org.имеет подписи, но ее делегирование из org.не включает никаких ключей для их проверки, поэтому резолвер вообще не должен смотреть на эти подписи — они больше не являются частью цепочки доверия. Однако systemd-resolved все равно смотрит на них.

  2. Имя savannah.gnu.org.существует в двух местах, и они не согласуются друг с другом. Эта проблема осталась бы незамеченной без DNSSEC, но всегда не прошла бы проверку с DNSSEC. Однако из-за проблемы № 1 она не проходит проверку, хотя systemd-resolved должен был бы ее спокойно игнорировать.

Подробнее о #2:

Те же серверы имен размещают как подписанную родительскую зону, gnu.org.так и неподписанную дочернюю зону savannah.gnu.org.. Проблема в том, что у первой нет фактического делегирования NS для второй; вместо этого у нее есть только простые записи о неделегировании для этого имени.

Все работает только потому, что обе зоны размещены на одних и тех же серверах имен, поэтому сначала, когда вы запрашиваете записи A или AAAA на «savannah.gnu.org», ответ автоматически отправляется из неподписанной дочерней зоны.

Ясно, что это начало отдельной зоны, поскольку у нее есть запись SOA. Но валидатор DNSSEC должен знать, должна ли эта зона быть подписана или нет, поэтому он пытается запросить записи DS (или их отсутствие), и на этот раз ответ всегда подается из родительской зоны.

Неподписанная подзона допустима, если родительская зона не имеет для нее никаких записей DS, что подтверждается возвратом подписанной записи NSEC вместо ответа; «доказательство несуществования» NSEC указывает навсетипы записей, которые присутствуют или отсутствуют для этого имени.

Итак, родительская зона "gnu.org" справедливо утверждает, что записи DS для "savannah.gnu.org" не существуют... но она также утверждает, чтоЗаписи NS также не существуют.т.е. имя вообще не делегируется дочерней зоне.(Однако, судя по всему, есть запись SSHFP...)

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

...Но, как уже упоминалось в пункте 1, ни одна из этих проверок не должна проводиться изначально, поскольку родительско-родительская org.зонатакжедоказывает, что его делегирование gnu.org.не подписано, что означает, что любые записи NSEC, исходящие от gnu.org, не имеют смысла. Systemd-resolved не должен их просматривать – он должен рассматривать всю зону gnu.org как не имеющую DNSSEC.

Связанный контент