☰

DNSSEC はそんなに頻繁に壊れるのでしょうか、それとも systemd-resolved が過剰なのでしょうか?

tag-icon • tag-icon dns systemd
DNSSEC はそんなに頻繁に壊れるのでしょうか、それとも systemd-resolved が過剰なのでしょうか?

systemd-resolved私は最近、DNSSEC が利用可能な場所でそれを活用するために、DNS リゾルバを に切り替えました。私の設定は次のとおりです。

[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によるとドメインの構成もすべてのチェックに合格しているわけではありません。

また、特定の DNSSEC メカニズムについては 100% 確信はありませんが、私の見解は次のとおりです。

サバンナ

これは大きな問題です。Systemd-resolved はドメインの問題を正しく検出しますが、信頼すべきではない情報に基づいて誤って拒否します。

  1. ゾーンgnu.org.には署名がありますが、その委任元org.には署名を検証するためのキーが含まれていないため、リゾルバーはそれらの署名をまったく確認するべきではありません。それらはもはや信頼チェーンの一部ではありません。ただし、systemd-resolved はとにかくそれらを確認します。

  2. 名前savannah.gnu.org.が 2 か所に存在し、互いに一致しません。この問題は DNSSEC がなければ気付かれませんが、DNSSEC を使用すると常に検証に失敗します。ただし、問題 #1 のため、systemd-resolved はこれを静かに無視するはずであるにもかかわらず、検証に失敗します。

＃2の詳細:

同じネームサーバーが、署名された親ゾーンgnu.org.と署名されていない子ゾーンの両方をホストしていますsavannah.gnu.org.。問題は、前者が後者への実際の NS 委任を欠いていることです。代わりに、この名前で単純な非委任レコードがあるだけです。

両方のゾーンが同じネームサーバーによってホストされているために、物事がうまく機能するのです。そのため、最初は、「savannah.gnu.org」で A または AAAA レコードを照会すると、署名されていない子ゾーンから自動的に回答が提供されます。

SOA レコードがあるため、別のゾーンの始まりであることは明らかです。ただし、DNSSEC バリデーターは、このゾーンに署名する必要があるかどうかを知る必要があるため、DS レコード (またはその欠如) を照会しようとします。この場合、応答は常に親ゾーンから提供されます。

署名されていないサブゾーンは、親ゾーンにDSレコードがない場合には問題ありません。これは、回答の代わりに署名されたNSECレコードを返すことで証明されます。NSECの「存在しないことの証明」は、全てこの名前に対して存在するか存在しないレコード タイプ。

つまり、親の「gnu.org」ゾーンは、「savannah.gnu.org」のDSレコードが存在しないことを正しく主張しているが、NSレコードも存在しない。つまり、名前は子ゾーンにまったく委任されません。（どうやらSSHFPの記録はあるようですが…）

バリデーターは、サブゾーンから来たことを示す元の署名されていない回答と、サブゾーンが存在することを示す署名された証明を持っているので、いいえサブゾーンへの委任の場合、検証は失敗します。

...しかし、#1で述べたように、これらのチェックはそもそも行うべきではありません。なぜなら、親子org.ゾーンはまたは、その委任がgnu.org.署名されていないことを証明します。つまり、gnu.org からの NSEC レコードは意味がありません。Systemd-resolved はそれらを調べるべきではなく、gnu.org ゾーン全体を DNSSEC がないものとして扱う必要があります。

関連情報