DNSのCAAリソース・レコード、使っていますか? 17
ストーリー by hylom
そんな仕組みがあったのか 部門より
そんな仕組みがあったのか 部門より
iida曰く、
英文WikipediaのDNS Certification Authority Authorizationの記事からResults on Ballot 187 - Make CAA Checking Mandatoryへのリンクが張られていた。このリンク先はCA/Browserフォーラムの動議187号の採決結果で、これによって2017年9月8日よりTLS（SSL） サーバー証明書の発行に先立って、DNSのCAAリソース・レコードの確認が必須になるようだ（アールエムエスの解説記事）。
皆さん、DNSのCAAリソース・レコード、使っていますか?
DNSのCAAレコードはRFC 6844で提案されているもので、ドメイン名やサブドメイン名の情報に認証局情報を追加するもの。これにより、認証局は証明書の発行時に対象ドメインのCAAレコードをチェックし、異なる認証局が設定されていた場合は誤った発行申請の可能性があるとして証明書の発行をペンディングするという仕組み。
CAAリソースでぐぐってトップがこの日記 (スコア:1)
スラドのSEOぱねぇっす…
Re: (スコア:0)
あなたがスラドをよく利用しているという点も含めての上位では？
Re: (スコア:0)
ログアウト時の検索内容の保存を無効にしても普通にトップに来たよ。
ほかにCAAリソースに言及している日本語サイトがほとんどないだけだと思うけど。
Re: (スコア:0)
ログアウト時の検索内容の保存を無効にしても普通にトップに来たよ。
これだけじゃストーカー広告はストーカーやめないよ。
使ってません！ (スコア:0)
レンタル鯖で非TLSなサイトを動かしてるだけだし・・・
そもそもCAAに対応してるか確認してない
Re:使ってません！ (スコア:1)
CAA レコードは、認証局/証明書発行機関/CAが、対象となるドメインの所有者を確認する方法だよね。
証明書を発行してもらう側から言わせてもらうと、CA が CAA レコードを要求しないなら、CAA レコードは「使わない」し、要求するなら、DNS に CAA レコードを追加するだけ。
なので、この「使ってますか?」という問は主に CA に対して発するべきじゃないかと思うね。
ところで、ちょっと違うけど、Google Apps は、ドメインの所有を確認するために、Google の指定した cookie 的な文字列を TXT レコードとして追加させるね。
SPF とかとも似てるのかな。
Re: (スコア:0)
そもそもはいろむがCA向けであることを理解していないのではないか疑惑。リンク先にもちゃんと書いてるのに。
Re: (スコア:0)
使ってますか、というより、設定(または登録)してますか、の方が妥当かな。
自分はLet'sEncrypt使ってるけど、CAA確認してるのだろうか。
Re: (スコア:0)
自分はLet'sEncrypt使ってるけど、CAA確認してるのだろうか。
Let'sEncryptがCAAの設定を要求してきましたか？
要求したのならば確認しているだろう。じゃなきゃ確認していないであろう。
ま書いておくと
Let'sEncryptはCAA設定をしていればそれにしたがって証明書をだし
設定がしていなければそれ以外の証明書を出しているはずです。
Re: (スコア:0)
つまりCAAの設定を要求しないけど黙ってCAA確認してるっておい二行目と矛盾してんぞ
ググレカス大先生曰く (スコア:0)
"CAA" "letsencrypt" "bind 9"
https://www.google.co.jp/search?q=%22CAA%22+%22letsencrypt%22+%22bind+9%22 [google.co.jp]
ほかにもググってみたけど
「(´・ω・`)CAAとか知らんがな」
ってかんじですね
# 徒労の成果にこんなん見つけた CAA Record Generator : https://sslmate.com/labs/caa/ [sslmate.com]
Re:ググレカス大先生曰く (スコア:1)
「DNS CAA」で検索すると色々出てくるからキーワードが悪いだけじゃないかな。
# CAAという略語自体がググラビリティが低いというのも原因ぽい。
Re: (スコア:0)
https://tools.ietf.org/html/draft-ietf-acme-acme-06
適用されるとDNSSECも対応必須だろうから、ちょっと面倒そう。
理想はわかるけど… (スコア:0)
直接ゾーン情報を編集・管理できるドメイン名ならともかく、主流になりつつあるクラウド型DNSサービス(設定できるRRTypeに制限がある)で対応できるのかな。
いろいろ間違ってる感じ (スコア:0)
DNS cache poisoning 攻撃を考えると、CAAはDNSSECと組み合わせないと意味がないというか、
むしろ信頼性が低下する。
でも、DNSSECがちゃんと普及するなら、そのDNSSEC的な公開鍵配布の仕組みを用いて、
SSL証明書のドメイン認証レベルまでは実現できたはず。
（企業認証やEV認証もその延長線上で実現する手だってあっただろう）
SSL証明書が、DNSのドメイン階層とまったく関係ないOSIのX.509証明書を流用したおかげで、
同じようなことを二重に実装することになって世の中の複雑度が上がってるんじゃないか。
DNSSECが本格的な普及せずに終われば二重じゃなくてすむけど。
DDoS amplifier的に意味では、DNSSECはむしろ問題源となるプロトコルだし。
Re: (スコア:0)
だから誤発行の防止だって言ってるじゃん。最初から目的にもしていないMiTM防御の役に立たないとか言いがかりつけられても
Re: (スコア:0)
> だから誤発行の防止だって言ってるじゃん。
DNSSEC使ってない限り、誤発行の防止にさえ使えない。つまりDNSSEC必須な仕組み。
DNSSEC必須であれば、現行のSSL証明書の仕組みが屋上屋を重ねる感じでなんだかなあ。
って話なんだけど...？