通常、新しいタスクが表示されるので、それを考え直して、何らかの解決策を見つけます。 さらに、この決定を実践する必要があり、ここから楽しみが始まります...
会社のインフラストラクチャとそのプロジェクトを自動管理に移行するという大きな仕事がありました。 その後、脳の活動が長引くため、Webインターフェイスとしてansibleとjenkinsを使用することが一貫して選択されました。 すべてのビジネスプロセスとサーバーとサービスのシステムを理解したので、IaC（コードとしてのインフラストラクチャ-コードとしてのインフラストラクチャ）の全体像をすでにはっきりと見ました。 パイロットプレイブックと役割の後、部分的な実装を開始します。アンサンブルでは、管理する必要があるサーバーのリストを動的に収集する素晴らしい機会があります。 多数のサーバーとそれらに必要なすべての変数を保存するために、私は最初の段階で独自のDNSサーバーを使用し、badooのアイデアを活用することにしました（皆さんがしゃっくりするように）。
あなたが最高のものを望んだが、いつものように判明したとき。 Googleの世界の奥深くまで進んでください。
DNSクエリセキュリティ
もちろん、タスクに適したテクノロジーを選択した後に最初に心配すべきことは安全性です。 サーバーからの回答であることをクライアントが要求することを保証するために、DNSSECを実装する予定ですが、すべてに十分な時間はありません。 AXFRリクエストは、ゾーン全体のリストを取得するために使用されますこれは、ほとんどのDNSサーバーの標準機能であり、DNSスレーブ間でデータを複製するためにも使用されます。 しかし、ゾーン全体を必要とするすべての人に配布することは受け入れられません。不正なリクエストの実行から保護するためのオプションは多くありません。 まず、これは、使用する内部IPv4サブネットに対するサーバー側の制限です。 次に、TSIGまたはGSS-TSIG認証です。 GSS-TSIGの設定は、必要なアクションの数が多いために長くなりますが、将来的にはすべて同じように使用する可能性があります。 したがって、選択はTSIGに委ねられました。TSIGには、 RFC 2845標準の非常に単純な文書があります 。
TSIGガッツ
TSIG認証の仕組みについては、ドキュメントやGoogleのロシア語では説明しません。 RFCは、DNSサーバーへのリクエストを含むパケットの形式など、あらゆる種類の詳細を通知しますが、キーファイルの形式については記述されていませんが、どの認証が機能するかに基づいたハッシュアルゴリズムのリストがあります。
- アルゴリズム名リファレンス
- gss-tsig RFC 3645
- HMAC-MD5.SIG-ALG.REG.INT RFC 2845
- hmac-sha1 RFC 4635
- hmac-sha224 RFC 4635
- hmac-sha256 RFC 4635
- hamc-sha384 rfc 4635
- hmac-sha512 RFC 4635
MD5は10年以上衝突の対象となっていますが、より永続的なハッシュのオプションがあるため、それらを見てみましょう。 おそらく、sha1が衝突しやすいなどということを既に聞いたことがあるでしょう。 私は追加の作業を恐れず、多数のDNSコールを期待していません。次に、利用可能な最も安定したアルゴリズムであるsha512を選択します。 アルゴリズムが選択されました。次に、キーを作成し、dnsサーバーへのクエリを試します。これを行うには、bind-utilsパッケージをインストールして、コマンドを実行します。
dnssec-keygen -a HMAC-SHA512 -b 512 -n USER abracadabra.example.com
キーを作成しました。次に、DNSに設定サーバーを挿入し、ストーリーのメイントピックに戻ります。 クエリをテストし、
abracadabra.example.com. IN KEY 512 3 165 qxkDE9ZBykFEk4VBNUnB5s+mvJDWhP2dHi4Gd0PeSHf4ckOSMTlThnXD oXz3Av5zcXhIgAKlVkJ7j/Ru4qzSFg== name class rrtype keysize protocol algorithm data
最後から始めましょう。大きなHMAC-SHA512はudpパケットの512バイトに収まらず、キー行はスペースで区切られていました。 貼り付けません。TCPに送信します。
さらに、ここでのアルゴリズムは理解できないtsiferki（記事を書くようになったのはこれらのtsiferkiです）で、今はスキップしましょう。
プロトコル、それが何であるか、RFCの理解できない数字もこれについて何も述べていません。
さらに分析し、すべてが明確になっています。キーを作成するときに512バイトを指定しました。ここでキーの長さを確認し、それをよく覚えます（この情報は役に立ちませんでした）。
リソースレコードのタイプ、dnsがあるので、これがキーであることをdnsサーバーに伝えます。
リソースレコードクラス。 DNSはTCP / IPだけでなく、他のタイプのネットワークでも使用できると理論的には考えられています。クラスフィールドのコードがネットワークのタイプを決定します（役に立たないレガシー）。
まあ、それに応じて、私たちの名前。
求める、求める
あいまいなフィールドが2つあります。理解しましょう。 始めるために、私はどんな種類のプロトコル識別子を見つけようとしました。 しかし、 1〜250の範囲があり、この範囲の3番がdnssecに属しているという事実以外に、私は何も認識していませんでした。
次に、アルゴリズムの識別子を探すことにしました。詳細がありました。 私はそのようなIANA管理ページに出くわしました。
そのようなタブレット
数  | 説明 | ニーモニック | ゾーン
署名 | トランス
秒 | 参照先 |
|---|---|---|---|---|---|
| 0 | DSを削除 | 削除 | N | N | [ RFC4034 ] [ RFC4398 ] [ RFC8078 ] |
| 1 | RSA / MD5（非推奨、5を参照） | RSAMD5 | N | Y | [ RFC3110 ] [ RFC4034 ] |
| 2 | ディフィー・ヘルマン | DH | N | Y | [ RFC2539 ] [提案された標準] |
| 3 | DSA / SHA1 | DSA | Y | Y | [ RFC3755 ] [提案された標準] [ RFC2536 ] [提案された標準] [連邦情報処理標準公開（FIPS PUB）186、
デジタル署名標準、1994年5月18日。] [連邦情報処理標準出版物（FIPS PUB）180-1 セキュアハッシュ標準、1995年4月17日。 （1993年5月11日付FIPS PUB 180に置き換わります。）] |
| 4 | 予約済み | [ RFC6725 ] | |||
| 5 | RSA / SHA-1 | RSASHA1 | Y | Y | [ RFC3110 ] [ RFC4034 ] |
| 6 | DSA-NSEC3-SHA1 | DSA-NSEC3-SHA1 | Y | Y | [ RFC5155 ] [提案された標準] |
| 7 | RSASHA1-NSEC3-SHA1 | RSASHA1-NSEC3-SHA1 | Y | Y | [ RFC5155 ] [提案された標準] |
| 8 | RSA / SHA-256 | RSASHA256 | Y | * | [ RFC5702 ] [提案された標準] |
| 9 | 予約済み | [ RFC6725 ] | |||
| 10 | RSA / SHA-512 | RSASHA512 | Y | * | [ RFC5702 ] [提案された標準] |
| 11 | 予約済み | [ RFC6725 ] | |||
| 12 | GOST R 34.10-2001 | ECC-GOST | Y | * | [ RFC5933 ] [標準化過程 ] |
| 13 | SHA-256を使用したECDSAカーブP-256 | ECDSAP256SHA256 | Y | * | [ RFC6605 ] [標準化過程 ] |
| 14 | SHA-384を使用したECDSAカーブP-384 | ECDSAP384SHA384 | Y | * | [ RFC6605 ] [標準化過程 ] |
| 15 | Ed25519 | ED25519 | Y | * | [ RFC8080 ] [標準化過程 ] |
| 16 | Ed448 | ED448 | Y | * | [ RFC8080 ] [標準化過程 ] |
| 17-122 | 未割り当て | ||||
| 123-251 | 予約済み | [ RFC4034 ] [ RFC6014 ] | |||
| 252 | 間接キー用に予約済み | 間接的 | N | N | [ RFC4034 ] [提案された標準] |
| 253 | プライベートアルゴリズム | プライベートDNS | Y | Y | [ RFC4034 ] |
| 254 | プライベートアルゴリズムOID | プライベート | Y | Y | [ RFC4034 ] |
| 255 | 予約済み | [ RFC4034 ] [提案された標準] |
識別子テーブルの一部はありますが、識別子番号は165であり、予約スペースに含まれています。 このスペースからの表のリンクは、アルゴリズムの識別子に関する情報を含まない他の標準につながります。 そしてOstapは苦しみました...私はこれらの法外な相互参照に突入し始めました。 その結果、私は吐き出してbind-utilsのソースに飛び込みました 。 そこで定義のリストを見つけました
/* DST algorithm codes */ #define DST_ALG_UNKNOWN 0 #define DST_ALG_RSAMD5 1 #define DST_ALG_RSA DST_ALG_RSAMD5 /*%< backwards compatibility */ #define DST_ALG_DH 2 #define DST_ALG_DSA 3 #define DST_ALG_ECC 4 #define DST_ALG_RSASHA1 5 #define DST_ALG_NSEC3DSA 6 #define DST_ALG_NSEC3RSASHA1 7 #define DST_ALG_RSASHA256 8 #define DST_ALG_RSASHA512 10 #define DST_ALG_ECCGOST 12 #define DST_ALG_ECDSA256 13 #define DST_ALG_ECDSA384 14 #define DST_ALG_HMACMD5 157 #define DST_ALG_GSSAPI 160 #define DST_ALG_HMACSHA1 161 /* XXXMPA */ #define DST_ALG_HMACSHA224 162 /* XXXMPA */ #define DST_ALG_HMACSHA256 163 /* XXXMPA */ #define DST_ALG_HMACSHA384 164 /* XXXMPA */ #define DST_ALG_HMACSHA512 165 /* XXXMPA */ #define DST_ALG_INDIRECT 252 #define DST_ALG_PRIVATE 254 #define DST_ALG_EXPAND 255 #define DST_MAX_ALGS 255
私のPythonコードに一部を追加しました
HashMap = { '160': 'gss-tsig', '157': 'HMAC-MD5.SIG-ALG.REG.INT', '161': 'hmac-sha1', '162': 'hmac-sha224', '163': 'hmac-sha256', '164': 'hmac-sha384', '165': 'hmac-sha512' }
ここに書かれていること
AXFRリクエストの場合、キーから必要なフィールドは3つだけです。名前、アルゴリズム、キー自体です。 実際、私は自分の課題を解決しましたが、成功とは考えていません。
一般的に、物語はおそらくあまり明確に書かれていませんが、結論は簡単です。 このような困難に遭遇した場合、他の人でもこれが繰り返されます。 17年前の基準により、理解するための情報を探すのに12時間以上費やしました。 標準の検索、一般的な実装の確認、そこからの情報の借用に数時間以上費やさないでください。ソースコードはよりシンプルで理解しやすいものです。 人気のあるプロジェクトのソースコードでは、他の人がすでにこのすべての作業を行っているため、時間を節約できます。
PS
ほとんどの情報が見つからなかったので、私や他の人々に役立つかもしれない以下の資料へのリンクを本当に感謝します。
- TSIG秘密鍵フォーマット
TSIGPrivate-key-format: v1.3
Algorithm: 165 (HMAC_SHA512)
Key: qxkDE9ZBykFEk4VBNUnB5s+mvJDWhP2dHi4Gd0PeSHf4ckOSMTlThnXDoXz3Av5zcXhIgAKlVkJ7j/Ru4qzSFg==
Bits: AAA=
Created: 20170902233427
Publish: 20170902233427
Activate: 20170902233427
- TSIGキー形式
- プロトコル識別子リストの完全な表
- アルゴリズム識別子リストの完全な表
UPD
スポイラーを秘密鍵と混同し、修正しました。