DNSSec：何であり、なぜ

まえがき

判明したように、DNSSecが何であるか、なぜ必要なのか、なぜ必要なのか、DNSSecを自宅で実装する価値があるかどうかを知っている人はあまりいません。 ロシア語ではこの主題に関する情報がほとんどないため、これらの問題を明らかにしようと思います。

DNSSecとは

ちょっとした歴史

当初、ドメインネームシステムには、応答内の情報のなりすましから保護するメカニズムがありませんでした。システムアーキテクチャでは、要求と応答の両方がクリアテキストで送信されます。 同時に、リゾルバは、リクエスト識別子のみで受信した情報の忠実度を判断しました。リクエスト識別子の長さはわずか2バイトです。 つまり、キャッシュをポイズニングするには、65,536個の値を整理する必要がありました。 彼らは90年代にそれについて話し始めました。 同時に、彼らはDNSSecの初版をゆっくりと説明し始めました。 彼女は1997年に光を見ました。2年後、次のものが現れました。 2005年に、DNSSecの最新版が登場し、誰もが一緒に作業できるようになりました。 2008年に画期的な出来事が起こりました。DanKaminskyは、10秒でキャッシュをポイズニングできることを世界に示しました。 DNSソフトウェアのメーカーは、要求識別子に加えて、送信ポートをランダムに選択し始めたと答えました。 道に沿って、ヒステリーはDNSSecの導入から始まりました。

仕組み

DNSSecは、デジタル署名と同じように機能します。 つまり、秘密鍵で署名し、公開鍵で検証します。

特徴は、DNSSecが2種類のキーを使用することです。1つはゾーン（ZSK、ゾーン署名キー）に署名し、もう1つは一連のキー（KSK、キー署名キー）に署名します。 これは、次のような理由で行われます。ゾーンは、秘密キーを取得できるほど大きくなる可能性があるため、頻繁に変更する必要があります。 KSKは少量のデータに使用されるため、より信頼性が高く、変更頻度を減らすことができます。 さらに、KSKのオープン部分からのハッシュは親ゾーンに送信する必要がありますが、これはあまり頻繁に行いません。

ZSK

このキーを使用すると、委任ポイントを除き、ゾーン（RRSET）内のすべてのレコードセットが署名されます。 つまり、example.comゾーンがあり、その中にそのような断片があるとしましょう。

 $ORGIGIN example.com. @ SOA dns.example.com ns.example.com { Serial Refresh Retry Expire nTTL } NS ns.example.com. NS ns1.example.com. DNSKEY 256 3 5 ( AwEAAfETe4xtZy3Ml+9NceWE0zTUWk5WgTs5 ogRJ1fVuJ5U2QmBb+t3ltA4BrZObLRjX2 HcMmneVC4C3IdgluAiV6Jpj7hgRZIbbG8les LaiL0/wOoH/byPvNi5T0OQpG3vgXyhoBdWxl zghFU3eQSAnWF0xP/c323rtP0irdY7v5 ) ; key id = 38754 DNSKEY 257 3 5 ( AwEAAdanjntZ82rOdV97sDS5+QH+w1pKnRJ/ b8gmuRBC91q5fQ2YiQ5zzYKi9+gENlqx/1MN jAFXJ1Fvtf0pJYKjmkiBJoHdZoEVRnJz8ODx FYgFX/fx+SBKsG3ZioaHP3CEdZQ4k3kutN6o tawolvHfErSwnJT/3IhAplXDHZrLmwXgWU3M PvMhnJRR9jd7S4f3WF10oq+3qPkBbJrqxB3x RydCSaZYfVuJ5U2QmBb+t3ltA4BB8jL8jOLS zvP2lufa6P8f0TJxtcpx/t9IfvUyWHmr9H7r inl4k8xDTVvaPnmBScxbuBc= ) ; key id = 23179 doo IN A 127.0.0.1 IN A 127.0.0.2 IN MX mail foo NS ns1.test.ru. NS ns2.test.ru. bar NS ns1.test.ru. NS ns2.test.ru. DS 4915 5 1 180DC61CD4A2772DC02EC18934AA4C024D77DC11 DS 4915 5 2 03EE2B29404BDF6D8891C0E0C89F714FE865E1D59A621F6FB4642648 4BC8C852 
      

        
        
        
      

    
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

$ORGIGIN example.com. @ SOA dns.example.com ns.example.com { Serial Refresh Retry Expire nTTL } NS ns.example.com. NS ns1.example.com. DNSKEY 256 3 5 ( AwEAAfETe4xtZy3Ml+9NceWE0zTUWk5WgTs5 ogRJ1fVuJ5U2QmBb+t3ltA4BrZObLRjX2 HcMmneVC4C3IdgluAiV6Jpj7hgRZIbbG8les LaiL0/wOoH/byPvNi5T0OQpG3vgXyhoBdWxl zghFU3eQSAnWF0xP/c323rtP0irdY7v5 ) ; key id = 38754 DNSKEY 257 3 5 ( AwEAAdanjntZ82rOdV97sDS5+QH+w1pKnRJ/ b8gmuRBC91q5fQ2YiQ5zzYKi9+gENlqx/1MN jAFXJ1Fvtf0pJYKjmkiBJoHdZoEVRnJz8ODx FYgFX/fx+SBKsG3ZioaHP3CEdZQ4k3kutN6o tawolvHfErSwnJT/3IhAplXDHZrLmwXgWU3M PvMhnJRR9jd7S4f3WF10oq+3qPkBbJrqxB3x RydCSaZYfVuJ5U2QmBb+t3ltA4BB8jL8jOLS zvP2lufa6P8f0TJxtcpx/t9IfvUyWHmr9H7r inl4k8xDTVvaPnmBScxbuBc= ) ; key id = 23179 doo IN A 127.0.0.1 IN A 127.0.0.2 IN MX mail foo NS ns1.test.ru. NS ns2.test.ru. bar NS ns1.test.ru. NS ns2.test.ru. DS 4915 5 1 180DC61CD4A2772DC02EC18934AA4C024D77DC11 DS 4915 5 2 03EE2B29404BDF6D8891C0E0C89F714FE865E1D59A621F6FB4642648 4BC8C852







そして、あなたはこのゾーンに署名することにしました。 次のことが行われます。

1. 署名付きレコードのシーケンスが作成されます。
2. NSECエントリが追加されます（詳細は以下）。
3. SOAレコード、example.comのNSセット、DooのアドレスとMXレコード、各NSEC RRおよび各DSセットがサブスクライブされます。
4. ソフトウェアの設定によっては、DNSKEYセットも署名される場合があります。

委任ポイント、つまり 子ゾーンのNSレコードは署名されません。

KSK

このキーは、DNSKEYレコードのセットに署名します。

さらに、KSKの開いている部分からハッシュが取得され、親ゾーンに送信されます。 上記の例では、これらはDSレコード（委任署名者）です。

ルートゾーンの場合、キーの開いている部分がリゾルバーに手動で通信されると想定されます。 また、キーを変更するたびに手動で更新しないように、自動更新のメカニズムがあります。たとえば、BINDには管理キーオプションがあります。

明らかに、KSKの閉じた部分は、目の保養として保存する必要があります。まず、DNSSecの全ポイントが消え、次に、妥協した場合、KSKをすばやく変更することはできません。

次に安全

さて、ここでゾーンに署名しましたが、それでも部外者がゾーンに情報を追加できます。署名されていない場合でも、署名されたものと一緒にサーバーから提供されます。



これを防ぐために、ゾーンに署名するとき、ドメイン名はアルファベット順にソートされ、それぞれにNSECレコードが追加されます。これは、保護されている次のドメイン名とゾーンに存在するレコードを示します。 最後のNSECエントリはSOAを指します。

権限のあるサーバーが応答NXDOMAIN（RCODE = 3）またはNODATA（RCODE = 0）を返す場合、NSECレコードが応答に存在する必要があります。 そのような答えの例：

 ; <<>> DiG 9.7.3 <<>> jhbczxccva.se +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8766 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;jhbczxccva.se. IN A ;; AUTHORITY SECTION: se. 300 IN SOA catcher-in-the-rye.nic.se. registry-default.nic.se. 2011053104 1800 1800 864000 7200 se. 300 IN RRSIG SOA 5 1 172800 20110613123930 20110531090447 24825 se. JJGWAvmcB/Bq7t5z7iTQGLr9c0LzQkdwpNFsrIClJctZUn/Z3YN2EMVQ 0r6DvufTGk1L8JMvTaxkI43ZmvasFeNNzfUFjr+td8Mv9h7FF5kTfEO5 R7JMh4j0Kxl/Gy4j+Ofcm0ZiCZTtcnNdHwCIHaVpz9KA6uIubnlJNSLw YXI=
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

NXDOMAIN応答には常にSOAレコードが付随するため、SOAとその署名は署名済みゾーンで返されます。

 se. 300 IN RRSIG NSEC 5 1 7200 20110613011140 20110530130445 24825 se. dKL3iGCxNI51FSNjx4p0NmAMtjhJVqLeAShrRH0rRmdV0Ej1nAH/Z/ip zn7PqB+7j6PguNPfEU4ySHfS8BTprvmod60J//Asi9/2ymadcNkB5VXg fJD1DMBpnCK1aUqG8ieJFsMQuMrrYRkhy0TdrCxGtZmTCpOOxfOMtmKR rcQ= se. 300 IN NSEC 0-0.se. NS SOA TXT RRSIG NSEC DNSKEY
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     // Asi9 / 2ymadcNkB5VXg fJD1DMBpnCK1aUqG8ieJFsMQuMrrYRkhy0TdrCxGtZmTCpOOxfOMtmKR RCQ = se. 300 IN RRSIG NSEC 5 1 7200 20110613011140 20110530130445 24825 se. dKL3iGCxNI51FSNjx4p0NmAMtjhJVqLeAShrRH0rRmdV0Ej1nAH/Z/ip zn7PqB+7j6PguNPfEU4ySHfS8BTprvmod60J//Asi9/2ymadcNkB5VXg fJD1DMBpnCK1aUqG8ieJFsMQuMrrYRkhy0TdrCxGtZmTCpOOxfOMtmKR rcQ= se. 300 IN NSEC 0-0.se. NS SOA TXT RRSIG NSEC DNSKEY
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このNSECエントリは、指定された名前がマスクに該当しないことを示します。

 jhbatar.se. 300 IN RRSIG NSEC 5 2 7200 20110613032526 20110530130445 24825 se. DWXq1ZlzuA9w0McNHWjpLO55H08rkWjtBDd8TewUCYnljM//1oXEvVcJ ORT9AxXoz9TMOEku2wFGydceX5zs4PZLwnEC+ieXu3ri/B0S533XpmKe 6CgQTda6maCvoF8d1gOc2nIbd7zKjdOl2ujMVJKCb6Bv3yoy4WjL3gka Ufk= jhbatar.se. 300 IN NSEC jhbeagleklubb.se. NS RRSIG NSEC
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     6CgQTda6maCvoF8d1gOc2nIbd7zKjdOl2ujMVJKCb6Bv3yoy4WjL3gka Ufk = jhbatar.se. 300 IN RRSIG NSEC 5 2 7200 20110613032526 20110530130445 24825 se. DWXq1ZlzuA9w0McNHWjpLO55H08rkWjtBDd8TewUCYnljM//1oXEvVcJ ORT9AxXoz9TMOEku2wFGydceX5zs4PZLwnEC+ieXu3ri/B0S533XpmKe 6CgQTda6maCvoF8d1gOc2nIbd7zKjdOl2ujMVJKCb6Bv3yoy4WjL3gka Ufk= jhbatar.se. 300 IN NSEC jhbeagleklubb.se. NS RRSIG NSEC
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、すでにこのNSECレコードは、ドメイン名が見つからなかったことを示しています。



NSECの欠点は明らかです。名前ごとにこのエントリをポーリングするだけで、だれでもゾーンの内容を取得できます。 この点で、メカニズムが完成し、ドメイン名がハッシュされたNSEC3エントリが登場しました。

NSEC3はソルトを使用してハッシュを計算できます。ソルトに加えて、反復回数を指定できます。 反復回数が増えると、リゾルバーと権限のあるサーバーの両方の負荷が増加し、権限のあるサーバーは大幅に増加することに注意してください。 これは、NXDOMAINを返すために、権限のあるサーバーがハッシュではなくハッシュを計算する必要があるという事実によるものです。 このプロセスはRFC 5155で説明されています 。



さらに、NSEC3エントリには、NSECにはないフラグフィールドがあります。 現時点では、1つのフラグのみが定義されています-OPT-OUT。これにより、ゾーン全体（大きなサイズでは非常に長いプロセスになる可能性があります）ではなく、DSレコードがあるドメイン名のみに署名できます。

一方で、OPT-OUTは署名時間を大幅に短縮できますが、それを使用する場合、攻撃者がゾーンファイルにアクセスできるようにすることで、保護されていないエントリを追加できるため、将来問題が発生する可能性があります。

仕事の仕組み

アドレスtest.bar.example.comを知りたいとしましょう：

1. リゾルバにドメイン名を要求します。
2. リゾルバーはDOビットを設定し、ルートサーバーからtest.bar.example.comを要求します。
3. リゾルバーは、ルートドメインゾーンが署名されていることを知っています。キーまたはキーハッシュ（いわゆるトラストアンカー）を持っているため、ルートDNSKEYサーバーにルートゾーンのエントリを照会し、既存のゾーンと比較します。
4. ルートサーバーはそのようなドメイン名を知らず、一般に、comゾーンがどのサーバーにあるかを知る最大値は、comゾーンのDSレコードと共にこれらのサーバーのアドレスをリゾルバーに報告します。
5. リゾルバは、受信および検証されたZSKルートゾーンキーを使用してDSレコードを検証します。
6. リゾルバは、comゾーンが署名されていることを認識しているため、DNSサーバーDNSKEYに問い合わせて検証し、その後bar.example.comに関心があります。 当然、ゾーンcomのサーバーはこれらについて知りません。ゾーンexample.comがns.example.comとns1.example.comに存在することだけを知っています。これは、DSレコードでリゾルバーに答えます。
7. そのため、リゾルバはexample.comへの信頼チェーンを構築し、bar.example.comゾーンとそのDSのネームサーバーを認識します。
8. 最終的に、リゾルバーはbar.example.comを担当するサーバーのDNSアドレスを繰り返し学習し、それらに行き、最終的に必要なものを取得し、すべての情報を検証し、アドレスレコードを提供して、応答のADビットを設定します。

何かを検証できない場合、リゾルバーはservfailを返します。

効果

1. 信頼できるDNSサーバーの発信トラフィックは約4倍増加します。
2. 署名後（OPT-OUTなし）のゾーンファイルのサイズは6〜7倍になります。
3. キーの長さを長くすると、qpsリゾルバーの顕著な減少につながり、権限のあるサーバーへの影響はより少なくなります。
4. それどころか、NSEC3を使用すると、反復回数が増加します。
5. DNSSecはDNS応答の大幅な増加につながるため、すべてのネットワーク機器が512バイトを超えるDNSパケットで正しく動作する必要があります。

なぜそれが必要ですか

これは難しい質問です。 まず、作成された効果を考慮する必要があります。 第二に、キー用の信頼できるストレージを整理する必要があります。 第三に、キーの回転を監視します。 4番目に、署名の有効期限を監視します。 5番目に、DNSSecは増幅されたddosの効果を高めます。

これはすべて、信頼できるDNSサーバーから受信した情報を確認するための価格です。 しかし、今ではコミュニティは収益化のためにDNSSecに他に何を含めることができるかを考えています。たとえば、AFNIC科学評議会のメンバーである「DNSSECが証明書業界を崩壊させるでしょうか？」この評議会のワークショップで。

このトピックに関する読み物

• ここから発掘を始める価値があります。
• 非常に詳細な実装ガイド 。
• ゾーンRU、SU、XN-P1AIについて説明します。
• そして、もちろん、rfc 4033-4035。