NASAのDNSSEC鍵更新失敗でComcastが非難された事例

1月10日にComcastがDNSSECに完全対応したという発表を行っていましたが、DNSSEC対応することによって、技術的には間違った設定を行ってないのに多数の抗議が来てしまうという事例が発生してしまっていたようです。 障害が発生したのは1月18日ですが、それに関するレポートが1月24日に公表されています。

• Comcast: Analysis of DNSSEC Validation Failure (PDF)
• Internet Society: Comcast Releases Detailed Analysis of NASA.gov DNSSEC Validation Failure

1月18日に、NASA.govがDNSSECでの鍵更新に失敗したため、DNSSECを使っているとNASA.govの名前が引けないという状況になりました。

その状況に気がついたComcastユーザが「Comcastによるネット検閲だ！」と騒ぎ始めました。 実際はComcastは何も間違っておらず問題があったのはNASA.gov側の設定ですが、DNSSECを一般ユーザ向けの通常サービスとして提供していない他のISPでは普通にNASA.govが引けたこともあり、Comcastが独自にブロックしているのではないかと疑ったようです。

ユーザが騒ぎ始めた背景として、1月18日がアメリカでのオンライン海賊行為禁止法法案(SOPAおよびPIPA)に対する抗議によってWikipediaなどがWebブラックアウトを行っていた日であったことと、ComcastがSOPA賛同企業であることも無関係ではないと思われます。 Comcastはケーブルテレビ事業者であるとともに、アメリカ最大のISPであり、インターネット接続性を多数のユーザに提供しているのでNASA.govの障害に気がつくユーザが多かったという要素もあるのではないかと予想しています。

本来はComcast以外のDNSSEC対応DNSキャッシュサーバもNASA.govは引けなくなっていた筈です。 しかし、現時点ではDNSSECを利用するのは、それが何であるかをわかっている技術者が中心であり、Comcastのように全ユーザに初期設定としてDNSSECを提供するISPが少ないという背景もありそうです。

Comcastへの抗議

たとえば、Comcastの公式フォーラム上で以下のような質問が掲載されています。

• NASA.gov blocked - Comcast Help and Support Forums

Comcast has blocked access to NASA.gov. I am outraged! Is this China or something worse?

(意訳) ComcastがNASA.govへのアクセスをブロックしやがった。マジムカつく！ これって中国もしくはそれよりひどい？

Twitter上でもComcastでNASA.govが見られなくなっているという多数のTweetがありました。 Comcastの報告書で指摘されているのが、@NASAWatchによるTweetと、MSNBCのサイエンスエディタAlan Boyle氏が「Google Public DNSを利用すると障害を回避できる」としたTweetです。

個人的な感想としては、@NASAWatchによるTweetはComcastに対して攻撃的な内容になっていると思いました。 報告書には詳細なURLは記載されていませんが、以下が関連すると思われるTweet一覧です。

• https://twitter.com/#!/NASAWatch/status/159687547725946880
• https://twitter.com/#!/NASAWatch/status/159688911415820288
• https://twitter.com/#!/NASAWatch/status/159699463760379904
• https://twitter.com/#!/NASAWatch/status/159703194329546753
• https://twitter.com/#!/NASAWatch/status/159704392080171008
• https://twitter.com/#!/NASAWatch/status/159708010506223616
• https://twitter.com/#!/NASAWatch/status/159709091948793856
• https://twitter.com/#!/NASAWatch/status/159709811355820032
• https://twitter.com/#!/NASAWatch/status/159714939752284160
• https://twitter.com/#!/NASAWatch/status/159716179911507968

• https://twitter.com/#!/b0yle/status/159705625826312193
• https://twitter.com/#!/b0yle/status/159706193928011777
• https://twitter.com/#!/b0yle/status/159707417763000322
• https://twitter.com/#!/b0yle/status/159713229688414208
• https://twitter.com/#!/b0yle/status/159715698472525825

障害が収まった後にBoyle氏がComcastのDNSへと設定を戻すように促したことも報告書には書かれています。

NASA.GOV障害の解説

Comcastによる報告書では、どのような設定がDNSSECの鍵更新失敗へと繋がったのかに関する解説してあります。

新旧KSKによる二重署名を行わず、ZSKの事前公開を行わなかったことが原因とあります。 要は、事前公開法も二重署名法も使わずに、単純に鍵を更新しただけだったということだと思います。

NASA.GOVのゾーンは、新しいKSKで署名される一方で、旧KSKによる署名が消された状態にあたようです。 .GOVによるNASA.GOVへのDSレコード(キャッシュされたもの？)は旧KSKを示す一方で、NASA.GOV自身は新KSKへと全て一気に切り替えたとのことです。

4 How Did the NASA.GOV Domain Fail?

The NASA.GOV domain administrators performed a Key Signing Key(KSK) rollover by (1) generating a new key and (2) signing the NASA.GOV domain with the new key.

However, they did not use a double-signing procedure for the KSK and a pre-publish procedure for the ZSK. Double-signing refers to signing a zone with two KSKs and than updating the parent zone with the new DS record so that both keys are valid at the same time.

This meant that the domain NASA.GOV was signed with the new KSK, but it was not double-signed with the old KSK. So, the new key was used for signing the zone but the old key was not. As a result, the domain could not be trusted and returned an error when trying to reach the domain.

Thus, the domain was in a situation where the DNSSEC chain of trust was broken because the Delegation Signer(DS) record pointed to the old KSK, which was no longer used for signing the zone. (A DS record provides a link in the chain of trust for DNSSEC from the parent zone to the child zone-in this case between .GOV and NASA.GOV.)

While an investigation found this to be due to a failure in updating the key, a similar breakage could have occurred if an attacker gained access to the domain’s authoritative servers and modified those records or had the domain pointed to their own rogue authoritative servers.

JPRSの方々が書かれた「実践DNS - DNSSEC時代のDNS設定と運用」の234-240ページで鍵更新が解説されているので興味のある方は、そちらをご覧頂ければと思います。

最後に

DNSSECにおける署名更新のし忘れや鍵更新失敗そのものは、これまでも色々と発生しているので、いまや特に珍しいものではありません。

しかし、NASA.govでの障害と、それに対する抗議が本来は無関係であるComcastへと向かってしまったことや、ユーザがGoogle Public DNSへと切り替えてしまったことは、ある種のリスクを暗示しているような気もしている今日この頃です。

最近のエントリ

• Interop 2023のShowNetバックボーン詳解
• Interop Tokyo 2023 ShowNet取材動画
• 「ピアリング戦記 - 日本のインターネットを繋ぐ技術者たち」を書きました！
• 1.02Tbpsの対外線！400GbE相互接続も - Interop ShowNet 2022
• Alaxala AX-3D-ViewerとAX-Sensor - Interop 2022
• SRv6を活用し、リンクローカルIPv6アドレスだけでバックボーンのルーティング - Interop ShowNet 2022

過去記事

過去記事一覧