DNS over https とは(1)

 今回は DNS over https について取り上げます。
 たとえば、www.google.co.jp に接続するために、同サーバのIPアドレスを問い合わせるとします。
 その場合、クライアント(PCやスマホなどですね)がDNSサーバに対して、www.google.co.jpのIPアドレスの問い合わせを依頼します。一般的にはwww.google.co.jpを管理しているDNSサーバに直接問い合わせるのではなく、プロバイダなどが提供するDNSサーバが受け取ります。
 依頼を受け取ったDNSサーバは、自身がwww.google.co.jpのIPアドレスに関する情報を持っていればそのまま返します。持ち合わせていなければ、www.google.co.jpに関する情報を管理しているDNSサーバに問い合わせに行きます。
 ここで、DNSサーバの役割についての分類や、情報問い合わせの手順などについては割愛します。
(別の機会に改めて書くことにします)

 クライアントからの問い合わせと、DNSサーバからの応答において通信が発生します。(当然ですが)
 ポイントはこれらの通信はUDPを使っています。TCPと違って応答確認をしない「投げっぱなし」です。
受信側は送信元の確認をせずに受け取ります。そのため、悪意ある第三者による中間者攻撃が成立する危険性もあります。それにより、データ改竄や盗聴がなされることが考えられます。
 中間者攻撃によって、返されたIPアドレスが偽の値を掴まされ、攻撃者のサーバに誘導されることもあり得ます。

 これらの問題が起きないように対策を打つ必要があります。データの改竄を検知可能にした仕組みがDNSSECです。DNSSEC対応のDNSサーバからの応答には電子署名が付与されており、DNSサーバから送られてきた電子署名を検証することで改竄されていないことを確認します。
 一見良さそうに見えますが、問い合わせ側・応答側のサーバ双方が対応していないと機能しません。
 そして、改竄検知には使えますが、盗聴には対応出来ないという欠点があります。

 盗聴に対しては、DNSSECでは対応出来ませんので、通信経路の暗号化を検討する必要があります。
今までにもDNS over TLSやDNS over DTLSのようなプロトコルが提案されてきました。前者は853/tcpを後者は853/udpを使います。その関係で、多くの組織では同ポートが閉じられていることが多いのではないでしょうか。仮に開いていたとしても、DNSサーバソフトウェア側でTLS対応になっていないことも考えられます。この2点のハードルが意外に高いのかもしれません。(技術的な理由よりも政治的な理由の方が大きそうです)

 もし、自組織ののFWで上記ポートを通して、DNSサーバもTLSに対応させたとしても、他のDNSサーバが対応していなければどうにもならないという問題があります。

 では、どうすればいいのか?ということですが、これらの問題を解決すべく登場したのがDNS over httpsです。httpsは443/tcpを使い、このポートを通していないFWはまずないだろうと考えられます。そのため、導入のハードルは一気に下がります。

 もう少し詳しい話は後日お送りします。少々お待ち下さい。

  • このエントリーをはてなブックマークに追加

コメントをどうぞ