🧙🏾 🙂 🕳️ DNSSECの実用化 👆🏽 🧗🏿 🕊️

この記事では、既存のDNS構造の欠点、.comおよび.orgドメインを例として使用してDNSSECを実装する完全なプロセス、DNSSECで署名された有効な自己署名 SSL証明書を作成する手順について説明します。

不良DNSとは

現在の形式のDNSシステムは、情報セキュリティが特に考えられていなかった20年以上前に開発されました。いくつかの基本的な脆弱性があります。

DNSサーバーの応答の信頼性は、決してチェックされません。これにより、ドメイン名をアドレス指定したユーザーを任意のIPアドレスに送信して、サーバーの応答を置き換えることができます。実際には、このような攻撃は次のようになります。

クライアントのリゾルバーとして機能するプロバイダーのキャッシュDNSサーバーも脆弱です：カミンスキー攻撃。

現在、DNSレコードに公開キーを保存するための技術があります。たとえば、電子メールのDKIM署名、 SSHFPレコードのSSHキーなどです。これらの技術はすべて、DNS偽造に対する保護を必要とします。

DNSSEC理論

DNSSECは、暗号化署名を使用してDNS情報の信頼性を一意に検証できる技術です。

一般的にDNSSECについては、 dxdt.ru / 2009/03/04/2163で読むことができます。

詳細はこちら： habrahabr.ru/blogs/sysadm/120620

そして、 Verisign.comで

続行する前に、上記のリンクを注意深く読むことを強くお勧めします。ゾーンに署名する手順が一見混乱しているように見えるためです。

可能な限りシンプルに、これは次のようになります。すべての第1レベルドメインに関する情報を含むルートゾーン「。」があります。比較的言えば、これはいくつかの行のセットを持つテキストファイルであり、ほとんど変更されません。公開/秘密キーのペアが作成され、このファイルの各行が署名されます（PGP / GPGの「クリアサイン」タイプにより、テキストで公然と署名するために電子メールで使用され、「BGPIN PGP SIGNATURE」で始まります）。

このペアの公開キーを取得したので、このリストの各エントリの信頼性を確認できます。たとえば、ripn.netサーバーが「ru」ゾーンを実際に担当していることを確認します。

dig -t any + dnssec @ k.root-servers.net en。

応答では、ハッシュ署名を含むRRSIGレコードを確認できます。

しかし、これは十分ではありません。ダウンストリームサーバーが解決に参加するため、その答えも確認する必要があります。次に、トップレベルドメインの所有者（たとえば、「com」）、同じキーペアを作成し、ゾーン内のすべてのレコードに署名してから、公開キーのキャストをルートゾーンに追加します。その結果、ルートゾーンの公開キーを信頼して、ゾーンキー「com」の信頼性を確認できます。それに応じて、それを信頼します。

dig -t any + dnssec @ k.root-servers.net com。

応答では、DSレコードには、ゾーン「com」が署名されているキーのキャストが含まれています。

ゾーン内の各変更後に署名が新たに行われることを理解することが重要です。ただし、ルートゾーンはゾーン「com」の公開鍵のみに署名するため、ゾーン「com」が変更されるたびにルートゾーンのエントリを再キャッシュする必要はありません。

これで、com。ドメインを担当するサーバーからの応答を認証できます。

dig + dnssec -t any @ a.gtld-servers.net verisign.com。

ドメインレコードがverisign.comであることがわかります。署名されていますが、この段階では、verisign.comドメインを担当するNSサーバーのアドレスの信頼性を確立することしかできません。 IPアドレスを解決するには、それらから応答を取得する必要があります。そのため、これらのNSサーバーの所有者は独自のキーペアを持ち、それを使用してゾーンに署名し、DSレコードに公開キースナップショットを入れます。

verisign.comのAレコードをリクエストします。

dig + dnssec -ta verisign.com @ a2.nstld.com

その結果、Aレコードverisign.comに値192.5.6.31が含まれているという事実を検証するために、次の信頼チェーンが構築されます。

ルートゾーンの公開キー "。"を事前に知っています。そして彼を信頼しています。ルートゾーンには、「com」内のすべてのエントリを指定するDSレコードがあります。ゾーンは、指定されたキーで署名され、レコード自体は、それぞれルートゾーンキーで署名されます。このエントリの信頼性を確認した後、このキーで署名された「com」ゾーンのすべてのエントリを信頼します。 com。Zoneを担当するサーバーには、com。Zoneのキーで署名された公開キーverisign.comを含むDSレコードが含まれており、verisign.comを担当するNSサーバーの応答で署名の信頼性を検証できます。

概略的には、次のようになります。

上記の説明は非常に原始的でばかげています。「指で」作業する原理を説明することを目的として書かれています。おそらく、それはまったく理解を単純化せず、それをさらに混乱させるだけです。

DNSSEC実装プラクティス

注意！ この命令は時代遅れです。 NSEC3を使用せずにゾーンに署名すると、ゾーンのすべてのDNSレコードを検出できます。

実際の指示www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2

現在、署名されているのは、特に.net、.com、.orgなどの一部のトップレベルドメインゾーンのみです。

.ruゾーンはまだ署名されていません。.uaゾーンはテストモードで署名されています。.suゾーンは正式に署名されていますが、これまでのところ、DSレコードの追加をサポートするレジストラはありません。

ICANN Webサイトの完全なリストを参照してください。

ゾーンに署名するには、この機能がドメインレジストラーでサポートされている必要があります。 現時点では、DNSSECをサポートしている国内のレジストラについては知りません。 DNSをサポートする.ruドメインの委任を促進するR01レジストラとdnssec.ru Webサイトは、.ruゾーンが署名されていないため、馬鹿げています。この場合、R01サーバーは信頼チェーンを構築するための出発点になります。

サポートするもののうち、最大のものを区別できます。

Godaddy.com
Dyn.com
101domain.com
Gkg.net

UPD：現在、nic.ruはDNSSEC www.nic.ru/news/2012/dnssec.html もサポートしています。

部分的なリストはここにあります。

レジストラに加えて、NSSSEC対応のNSサーバーが必要です。一部のレジストラは、このようなサービスを提供しています。 Godaddyで最も安いオプションは、プレミアムDNS $ 35 /年と呼ばれます。 dyn.comで最も高価なのは、DynECT Liteと呼ばれる月額30ドルです。この記事では、BIND 9.7.3に基づいて独自のマスターDNSサーバーをセットアップする例を示します。

さらに、完全に構成された独自のDNSに委任されたドメインと、完成したゾーンファイルがあることを前提としています。

named.confでDNSSECサポートを有効にするには、オプションセクションに追加します。

オプション{
        ...
       dnssec-enable yes;
        ...
 };

キー生成およびゾーン署名ツールは、最新のBINDパッケージに含まれています。

この段階では、読者はすでにZSK（Zone Sign Key）とKSK（Key Sign Key）が何であるかを知っていると想定されます。

以下のすべての操作は、個別に作成されたフォルダーで実行する必要があります。

ZSKキー生成：

  dnssec-keygen -a RSASHA1 -b 1024 -n ZONE my-domain.com

KSKキー生成：

  dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE my-domain.com

my-domain.comは、キーが生成されるドメインです。これらのコマンドの結果、2つのキーペアが作成されます。

次に、ゾーンファイルを現在のフォルダーにコピーして署名する必要があります。

  dnssec-signzone -S -N INCREMENT my-domain.com

my-domain.comはゾーンテキストファイルです。キーとゾーンファイルと同じフォルダーにコマンドを実行することが重要です。パスなしのファイル名。

その結果、2つのファイルが作成されます。

my-domain.com.signed-ゾーン署名ファイル

dsset - my - domain.com -2つのDSレコードを含むファイル

ソースゾーンファイルは変更されません。次に、BIND構成で、ファイルを署名済みファイルに置き換える必要があります。

 ゾーン「my-domain.com」{
        タイプマスター;
        ファイル「my-domain.com.signed」;
	 allow-query {any;  };
         allow-transfer {....;  };
 };

ゾーンファイルの詳細な例は、 nox.suで表示できます。

DNSの復元力を高めるには、セカンダリサーバーをお勧めします。 DNSSEC対応のスレーブを提供する無料のサービスがいくつかあります。 http://www.frankb.us/dns/のリストの一部を次に示します。 rollernet.usを使用するため、アドレス208.79.240.3および208.79.241.3からの転送を許可します。セカンダリサーバーを使用する場合、署名する前に、それらに関するレコードがゾーンファイルに存在する必要があります。署名済みゾーンがマスターサーバーに配置された後、転送をアクティブにすることをお勧めします。

さらに、署名済みゾーンは権威主義NSサーバーで既にホストされており、外部からアクセス可能であると想定されています。

  dig + dnssec -t any @ super.vip.my.dns.com my-domain.com

チームは署名済みゾーンを返却する必要があります。

この段階で、セカンダリサーバーをアクティブにし、AXFRを介してゾーンを同期できます。

次に、ドメインレジストラーパネルでDSレコードを追加する必要があります。それらはdnssec-signzone中に生成され、次のようにdsset-my-domainファイルにあります。

 my-domain.com。  IN DS 40513 5 1 6198D29A9FB9797719CDFD2316986BDFF5C29323
 my-domain.com。  IN DS 40513 5 2 1AAB29EC7B67013F45865AEB06D93899B45C598D65A4E4D5522BC39E B5B9212F

これは、GoDaddyパネルにDSレコードを追加するためのフォームです。

編集後、「詳細モード」に切り替えて、両方の行をコピーする必要があります。 TTL値を追加し、キーのフィンガープリントの2行目のスペースを削除する必要があります。そうしないと、フォームはエラーを返します。その結果、コピーされた行は次のようになります。

 my-domain.com。  86400 IN DS 40513 5 1 6198D29A9FB9797719CDFD2316986BDFF5C29323
 my-domain.com。  86400 IN DS 40513 5 2 1AAB29EC7B67013F45865AEB06D93899B45C598D65A4E4D5522BC39EB5B9212F

エントリが追加されるのは、マスターサーバー上のゾーンが使用可能で、正しく署名されている場合のみです。

DSレコードのフィールド値：

86400-このエントリのTTL

40513-キータグ

5-アルゴリズム

1/2-ダイジェストタイプ

上記の例では、キーを生成するためにRSA-SHA1アルゴリズムが使用されたため、レコードは5番です。

アルゴリズム番号表：

数	アルゴリズム
1	RSAMD5
2	DH
3	DSA / SHA1
4	ECC
5	RSA / SHA-1
6	DSA-NSEC3-SHA1
7	RSASHA1-NSEC3-SHA1
8	RSA / SHA-256
9	-
10	RSA / SHA-512
11	-
12	GOST R 34.10-2001

上記の例のダイジェストタイプ、最初のレコードは1、2番目のレコードは2です。

ダイジェストタイプ番号表：

数	ダイジェストタイプ
1	SHA-1
2	SHA-256
3	SHA-512

Dyn.comなどの一部のレジストラでは、DSレコードを追加するためのフォームでは行をコピーできませんが、すべてのフィールドに個別に入力する必要があります。

Dyn.comには、順序が正しくなく、番号のラベルが付いていないアルゴリズムのリストがあるため、混乱が生じます。このフォームから追加する場合、2番目のキーの指紋のスペースも削除する必要があります。

DSレコードを追加した後、トップレベルドメインを担当するサーバー上でそれらの外観を確認できます。ドメイン「com」の場合、次のようになります。

  dig + dnssec -t DS @ a.gtld-servers.net my-domain.com

この場合、 VerisignのDNSSECデバッガーと署名チェーンビジュアライザーを使用して、ゾーンが正しく署名されていることを確認できます。

ゾーンエントリを変更するたびに、再署名する必要があることを思い出させてください。 DSレコードを更新する必要はありません。

すべてが正しければ、クライアント側の構成に進むことができます。

クライアントリゾルバーの構成

クライアント側で署名を検証するには、この機能がアドレス解決が発生するシステムDNSでサポートされている必要があります。 GoogleのパブリックDNS 8.8.8.8はDNSSECレコードをサポートしますが、検証しません。詳細はFAQをご覧ください。

UPD： 2013年3月19日以降、Google Public DNSはDNSSEC署名を検証しており、無効な署名の場合、 googleonlinesecurity.blogspot.com / 2013/03 / google-public-dns-now-supports-dnssec.htmlを 解決しません。

最も簡単なオプションは、 FirefoxとChromeのプラグインです。

このプラグインは、バイパスシステムDNSの解決を可能にし、DNSSEC検証をサポートする独自のサーバーが事前にインストールされています。デフォルトでは、プラグインはシステムDNSを使用します。プラグイン設定でこれを変更できます。CZ.NICまたは217.31.57.6を選択します

digユーティリティに署名の検証を教えるには、ルートゾーンキーを使用してファイルを作成することにより、信頼チェーンの開始点を作成する必要があります。

dig +nocomments +nostats +nocmd +noquestion -t dnskey . > /etc/trusted-key.key

その後、 / etc / trusted-key.keyファイルの行を削除する必要があります。

 ;; Truncated, retrying in TCP mode.

これが行われない場合、digは以下を返します。

 No trusted keys present

これで、digを使用して署名の信頼性を検証できます。

 dig +sigchase @217.31.57.6 whitehouse.gov

署名検証機能を使用して再帰リゾルバーを構成する方法については、こちらをご覧ください。

実用的なメリット

DNSSEC標準はまだ開発中であるという事実にもかかわらず、すでにその恩恵を受けることが可能です。

SSH公開鍵

SSHサーバーに初めて接続するとき、クライアントはサーバーの公開キーのフィンガープリントを個別に検証し、yesを入力するように要求します。その後、サーバーの公開キーはknown_hostsファイルに保存されます。

DNSSECの出現により、公開鍵はSSHFPタイプのDNSレコードに配置でき、サーバーに初めて接続するときに、要求なしで自動的にチェックされます。この機能を有効にするには、SSHクライアント設定にVerifyHostKeyDNS = yesオプションを追加する必要があります。また、システムリゾルバーがDNSSEC検証をサポートしている必要があります。

自己署名SSL証明書（HTTPS）

UPD： sslキーをDNSに保存するための標準が公開され、DANE ru.wikipedia.org/wiki/DANEという名前になった後、以下はもはや関係ありません。GoogleはChromeからDANEサポートを削除しました。 Chrome開発者github.com/agl/dnssec-tls-tools/issues/4とのディスカッション

DNSSECを使用すると、ブラウザで「有効」になるSSL証明書に個別に署名できます。

この実験的な機能は現在活発に開発されており、現在Google Chrome / Chromiumブラウザでのみサポートされています。

ドラフト標準： tools.ietf.org/html/draft-agl-dane-serializechain-01

この技術は、Adam Langleyという名前のGoogle従業員によって開発されており、彼には非常に興味深いブログhttp://www.imperialviolet.org/があります。

この技術に関する投稿。

さらに、証明書が生成されるドメインはDNSSECによって署名されていると想定されています。

dnssec-tls-toolsをダウンロードします。

  git clone git：//github.com/agl/dnssec-tls-tools.git

そしてコンパイル：

  gcc -o gencert gencert.c -Wall -lcrypto

RSAキー生成：

  openssl genrsa 1024> privkey.pem
 openssl rsa -pubout -in privkey.pem> pubkey.pem

キーフィンガープリントの作成：

  python ./gencaa.py pubkey.pem

dnssec-tls-toolsパッケージのgencaa.pyファイルはどこにあります。

コマンドは次の形式の行を返します。

  EXAMPLE.COM。  60タイプ257 \＃70 020461757468303e3039060a2b06010401d6790203010 ...

これは、EXAMPLE.COMの代わりにゾーンファイルに追加する必要があるDNSレコードです。その意味。ゾーンがまだ署名されていない場合は、これを行う必要があります。レコードが既に署名済みのゾーンに追加されている場合、それぞれ署名を再度実行する必要があります。

DNSの正しいキーを確認します。

  dig + dnssec + sigchase -t type27 example.com

コマンドは、 DNSSEC検証が正常であることを返す必要があります：SUCCESS

type27レコードが使用可能になり署名された後、DNSSEC信頼チェーンを生成できます。

  python ./chain.py example.comチェーン

そして、証明書自体：

  ./gencert privkey.pem chain> cert.pem

Nginxで証明書を接続すると次のようになります。

サーバー{
         ...
	 ssl on;
	 ssl_certificate cert.pem;
	 ssl_certificate_key privkey.pem;
         ...
  }

DNSSEC署名チェーンは変更される可能性があるため、チェーンの作成と証明書の生成（最後の2つのコマンド）をクラウンに追加して、たとえば1日に1回実行する必要があります。

結果は次のようになります： https : //dnssec.imperialviolet.org/

DNSSECチェーン全体が証明書に配置されるという事実により、ブラウザは完全なチェーンチェックを実行する必要がないため、システムリゾルバがDNSSEC検証をサポートしていなくても証明書は「有効」になります。

PSこの記事では、DNSSECキーの有効性については説明していません。代替のDLVEC Look-aside Validation DLV信頼チェーンについては説明していません。これらの問題を理解し、説明してくれる人々に感謝します。

PPS私は、このようなターンベースのHOWTOが、理解せずにチームを無意識にコピーすることにつながる悪影響を知っています。しかし、この問題に関する情報がほとんどなく、一部の場所では矛盾しているという事実により、この記事が私が直面しなければならなかった混乱を誰かが避けるのに役立つことを願っています。協議と彼の記事をくれたAlexander Venedyukhinに感謝します。

DNSSECの実用化