DNS over https とは(3)

 前回の「DNS over https とは(2)」でDNS over https を用いてDNSクエリが返って来るまでの流れについて書いてみました。(参考:DNS over https とは(1)

 DNS over https を使って保護される通信区間は、クライアントPCとDNSキャッシュサーバの間になります。これはこれでいいのですが、DNS over httpsを使う場合に意識しておく点を挙げてみます。

  • 組織内DNSキャッシュサーバをバイパスすることになる
  • DNS over https対応サーバは問い合わせに443/tcpを使っているとは限らない
  • イントラネット側で独自にDNSコンテンツサーバを立てていた場合にどうするか
  • DNS over https対応パブリックDNSサーバ等を使わせないようにするのは現実的なのか

 などが考えられます。

 組織内DNSキャッシュサーバを指定せずに、たとえばCloudFlareGoogleのようなパブリックDNSサーバを指定したとします。これらのサーバに対してDNSクエリを投げることが出来ないようにするためには、1.1.1.1:443や8.8.8.8:443などをFWで塞いでしまえば通信は遮断出来ます。
 クライアントPCからの問い合わせを受ける組織内DNSキャッシュサーバが代表して外部に問い合わせる形になっている場合は、同サーバからのみDNS over https対応サーバに問い合わせるようにFWでフィルタリングすれば良いことになります。

 そして、DNS over https対応サーバが全ての情報をキャッシュしているわけではありません。キャッシュを保持していなければ、目的とするDNSコンテンツサーバに問い合わせる必要があります。
 この際、当該DNSコンテンツサーバとDNS over https対応サーバ間の通信が443/tcpで行われているのかどうかは分かりません。そもそも、問い合わせを受けるDNSサーバ側がDNS over httpsに対応しているとは限りません。普通に53/udpによる通信が行われている可能性は高いでしょう。
 そのため、end to endで安全であるとは言い切れない側面があります。

 次に、イントラネット側に独自にDNSコンテンツサーバを立てた場合についてです。クライアントPC側でDNS over https対応のパブリックDNSサーバを指定された場合、イントラネット内の各種サーバの情報を引くことは出来ません。外部に公開されている自組織Webサーバについては、一旦パブリックDNSサーバに問い合わせてから自組織のDNSコンテンツサーバのIPアドレスを得るという遠回りな通信が発生します。
 なので、クライアントPCは自組織DNSキャッシュサーバを経由して問い合わせをするようにFWなりルータやL3スイッチでのアクセス制限やフィルタリングを実施しておく必要があります。

 これらのことを意識して、俯瞰的な設計を行うことがポイントになります。
dns over https

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

コメントをどうぞ