※ 2022 年 6 月 3 日現在の情報をもとに作成しています
1. はじめに
本記事では、Umbrella の DNS サーバーにおける DNSSEC (Domain Name System Security Extensions) の対応状況について紹介します。
Support for DNSSEC in Umbrella
https://learn-umbrella.cisco.com/feature-briefs/support-for-dnssec-in-umbrella
2. DNSSEC とは
DNSSEC とは、DNS データの正当性を保証するために、DNS の仕様を拡張したものです。偽の DNS レスポンスを DNS キャッシュ サーバーに送り込んで、キャッシュを汚染する DNS キャッシュ ポイズニングなどの攻撃に有効だとされています。
通常の DNS の仕組みにおいては、DNS キャッシュ サーバーがユーザーから DNS リクエストを受け取ると、内部にキャッシュされた結果がなければ、再帰的に権威 DNS サーバーに問い合わせを行い、最終的な結果内容を DNS レスポンスに含めて、ユーザーに返します。
DNSSEC はこの仕組みを拡張し、DNS キャッシュ サーバーが権威 DNS サーバーから受け取った内容を DNSSEC 用の特殊なリソース レコード (RRSIG など) を使って検証し、もし正当性を確認できない場合は、DNS レスポンスに結果内容を含めません。
※ DNSSEC の詳細な仕組みや具体的な検証方法については本記事では取り扱いません
3. Umbrella の対応状況
DNS キャッシュ サーバーの役割を担う Umbrella の DNS サーバーは、下記のサポート記事にあるとおり、現在 DNSSEC の対応が行われております。
DNSSEC General Availability
https://support.umbrella.com/hc/en-us/articles/360039414411-DNSSEC-General-Availability
Umbrella の DNS サーバーは、ユーザーから DNS リクエストを受け取ると、基本的に前項で説明した DNSSEC 検証を行います。
実際のケースで考えてみると、Umbrella ユーザーがある Web サイトにアクセスした際、そのサイトの IP アドレスを調べるための DNS リクエストが Umbrella の DNS サーバーに送られます。
Umbrella の DNS サーバーは、DNSSEC 検証を行い、正当性を確認できた場合は、そのまま IP アドレスを含めた DNS レスポンスをユーザーに返します。そして、その時の DNS レスポンス内の Response Code (RCODE) には、NOERROR が設定されます。
一方、DNSSEC 検証で正当性を確認できなかった場合は、DNS レスポンスに IP アドレスを含めずに、ユーザーに返します (RCODE は SERVFAIL)。結果として、ユーザーはその Web サイトにアクセスできません。
※ 問い合わせ対象のドメインが DNSSEC に対応してない場合は、DNSSEC 検証そのものが行われません
以下は、架空のドメイン (dnssec-ok.example.com) が DNSSEC 検証で正当であった場合の dig コマンドの出力結果の抜粋です。flags の欄に ad (Authentic Data) があるのも、特徴の一つです。
$ dig dnssec-ok.example.com @208.67.222.222
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24861
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
dnssec-ok.example.com. 300 IN A X.X.X.X
以下は、架空のドメイン (dnssec-ng.example.com) が DNSSEC 検証で正当ではなかった場合の dig コマンドの出力結果の抜粋です。ANSWER SECTION がないのも特徴です。
$ dig dnssec-ng.example.com @208.67.222.222
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19881
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
なお、Umbrella には DNSSEC 検証を行わせないようにする方法が 2 種類用意されており、一つ目は DNS リクエスト内の flags に cd (Checking Disabled) を含めるというものです。
Umbrella の DNS サーバーは、DNS リクエストに cd が含まれていると、DNSSEC 検証を行いません。以下はその時の dig コマンドの出力結果の抜粋です。結果として IP アドレスは返ってきて、flags に ad は含まれません。
$ dig dnssec-ng.example.com +cd @208.67.222.222
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36055
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
dnssec-ng.example.com. 300 IN A X.X.X.X
もう一つの方法は Negative Trust Anchor (NTA) と呼ばれるもので、Umbrella 側で特定のドメインの DNSSEC 検証が行われないように設定するというものです。
実際には正当なドメインとして認識されているにもかかわらず、何らかの理由で DNSSEC 検証に失敗し、ドメインにアクセスできない場合などに、緊急回避的に Umbrella 側で使用されることがあります。
4. ユーザー側の DNSSEC 検証について
これまでの説明は、Umbrella の DNS サーバーが DNSSEC 検証を行うことを前提としたものでしたが、Umbrella の DNS サーバーが DNSSEC 検証に必要な情報を返し、ユーザー側 (または内部の DNS サーバー側) で DNSSEC 検証を行う方法も用意されています。
具体的には、DNS リクエストに DO ビットと呼ばれる特殊なオプションを設定します。dig コマンドでは、引数に +dnssec を付けることで実現できます。以下は出力結果の抜粋です。RRSIG A というのが A レコードの正当性を確認するために使われる情報です。
$ dig dnssec-ok.example.com +dnssec @208.67.222.222
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27915
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
dnssec-ok.example.com. 300 IN A X.X.X.X
dnssec-ok.exmaple.com. 300 IN RRSIG A (内容省略)
なお、この方法を利用して、組織内部の DNS サーバーが DNSSEC 検証を行うために、Umbrella の DNS サーバーに対して DO ビットを立てた DNS リクエストを送る運用をすることは、あまり推奨されません。
