web-dev-qa-db-ja.com

CNAMEとAレコードを同時に使用したDNSの間違った回答

ドメインのCNAMEレコードを設定した顧客がいました。どういうわけか彼はそれを管理してAレコードも設定しましたが、これは不可能であり、DNSによって禁止されています。しかし、結果は次のとおりです。

$ Dig @ns1.your-server.de tippspiel-bl1.unternehmen-frische.de 
...
;; ANSWER SECTION:
tippspiel-bl1.unternehmen-frische.de. 7200 IN CNAME www.kicktipp.de.
tippspiel-bl1.unternehmen-frische.de. 7200 IN A 78.46.10.156

2番目のレコードは違法です。しかし、これにより、他のキャッシングDNSサーバーが混乱し、78.46.10.156について尋ねられたときにwww.kicktipp.deが返されました。しかし、これは完全に間違っています。

他のDNSサーバーは両方の回答を使用し、それらを混合していました。最終結果：www.kicktipp.deにアクセスしたユーザーは、78.46.10.156のIPであるunternehmen-frische.deに送信されました。

CNAMEとAレコードを持つドメインにDNSを設定すると、ドメインを乗っ取ることができるようです。これは既知のバグですか？ドメインをそれから保護するにはどうすればよいですか？

domain-name-systemcachespoofing
3
Janning

あなたの質問に具体的に取り組むために：

  • いいえ、これは頻繁に発生する問題ではありません。とはいえ、中毒は発生しますが、通常はスプーフィングされた応答に依存し、Aと一緒に存在するCNAMEレコードには依存しません。 _。 DNSSECは、中毒攻撃を念頭に置いて設計されました。
  • DNSSECがここに実装されている場合、Aレコードがあなたによって署名されていないことをリゾルバーを検証することは明らかです。この問題に影響を与えたであろう自分のゾーン内でできることは他にありません。

追加情報が不足しているため、ISPに相談する必要があります。引用するRFCを定義する最も適切な標準は、他のデータと共存するCNAMEに関して RFC1034 よりも曖昧さが少ないため、 RFC2181 です。 （RFC1034はそれに眉をひそめ、RFC2181はレコードがDNSSECに関連していない限りそれを禁止します）

とはいえ、私はあなたが説明したとおりの問題であることにいくぶん懐疑的です。 tippspiel-bl1.unternehmen-frische.de. IN Aがwww.kicktipp.de. IN Aで衝突を引き起こすのは、確かに厄介なバグです。

4
Andrew B

DNSサーバーを自分で管理している場合は、そのようなものを保護するために有効にできるカスタムチェックがあります。 RFCから直接取得した以下のポイントをお読みください。これは単なる人為的エラーであり、ゾーン構成を再ロードする前に、スクリプトまたはチェックを使用して防止できます。

CNAMEレコード

CNAMEレコードを他のデータと共存させることはできません。つまり、suzy.podunk.xxがsue.podunk.xxのエイリアスである場合、suzy.podunk.eduのMXレコード、Aレコード、またはTXTレコード。特に、CNAMEとNSこのようなレコードを組み合わせようとしないでください！：

   podunk.xx.      IN      NS      ns1
                   IN      NS      ns2
                   IN      CNAME   mary
   mary            IN      A       1.2.3.4

これは、ドメイン名をホストにするための明白な方法として、経験の浅い管理者によって試みられることがよくあります。ただし、BINDなどのDNSサーバーはCNAMEを認識します。その名前の他のリソースの追加を拒否します。他のレコードはCNAMEと共存できないため、NSエントリは無視されます。

MX、CNAME、PTR、NSなどの他の名前を指すRRとCNAMEを組み合わせて使用​​しないでください。 （クラスレスのアドレス内委任を実装する場合、PTRは例外です。）たとえば、これは強くお勧めしません。

       podunk.xx.      IN      MX      mailhost
       mailhost        IN      CNAME   mary
       mary            IN      A       1.2.3.4

[RFC 1034] セクション3.6.2は、これを行うべきではないと述べています。 [RFC 974] は、MXレコードがCNAMEで定義されたエイリアスを指してはならないことを明示的に示しています。これにより、データへのアクセスに不要な間接参照が発生し、DNSリゾルバーとサーバーは答えを得るためにより多くの作業を行う必要があります。本当にこれを実行したい場合は、ホストファイルでm4などのプリプロセッサを使用して同じことを実行できます。

また、CNAMEを指すCNAMEなどのチェーンレコードがあると、管理の問題が簡単になる場合がありますが、ループを正しくチェックできない一部のリゾルバーのバグをくすぐることが知られています。その結果、一部のホストはそのような名前を解決できない場合があります。

NSレコードがCNAMEを指していることは悪いことであり、現在のBINDサーバーとひどく競合する可能性があります。実際、現在のBIND実装はそのようなレコードを無視し、委任が不十分になる可能性があります。ある程度の量があります。 DNS NSレコードのスプーフィングを防ぐために、BINDで行われるセキュリティチェックの送信されるDNS要求のストリーム。

4
Pratap