DNS
DNS(Domain Name System)は、ドメイン名とIPアドレスを対応を管理するシステムです。
以下のように、ドメイン名とIPアドレスのどちらかを元に名前解決を行うことが可能です。
- 正引き: ドメイン名からIPアドレスを解決する
example.com -> 192.0.2.0 - 逆引き: IPアドレスからドメイン名を解決する
192.0.2.0 -> example.com
DNSの構成要素
リゾルバ
リゾルバ（resolver）とはドメイン名からIPアドレス、IPアドレスからドメイン名を検索することで名前解決を行う仕組み（ソフトウェアプログラム）です。リゾルバには以下の2種類があります。
| リゾルバ | 概要 |
|---|---|
| スタブリゾルバ（Stub Resolver） | 一般的なPCのOS等に搭載されており、フルサービスリゾルバに対して名前解決要求を行う。 |
| フルサービスリゾルバ（Full-Service Resolver） | 後述する |
DNSサーバ
DNSサーバには、大きく分けてコンテンツサーバとキャッシュサーバの２種類があります。
| DNSサーバ | 概要 |
|---|---|
| コンテンツサーバ（権限DNSサーバ、ゾーンサーバ） | ドメイン名とIPアドレスの対応表をゾーンという単位で管理し、自身が管理するゾーンの名前解決にのみ応じる。 |
| キャッシュサーバ（フルサービスリゾルバ） | スタブリゾルバからの要求を受けて、後述するコンテンツサーバに非再帰問合せ行い、結果を返却する。名前解決をした内容は一定時間キャッシュに保存し再利用する。 |
※ 再帰問合せと非再帰問合せ
- 再帰問合せ: 名前解決が完了するまでコンテンツサーバを辿る問合せ
- 非再帰問合せ: そのサーバが返せる情報のみを要求する問合せ（他のサーバへの問合せは行わない）
※ オープンリゾルバ
問合せ元IPアドレスや問合せ対象ドメインに制限元なく、どんなクライアントからの名前解決要求であっても応じるDNSサーバ。オープンリゾルバはDNSキャッシュポイズニング攻撃やDNS Amp攻撃に対して脆弱です。
DNSサーバによる名前解決
リソースレコード
DNSサーバはドメイン名とIPアドレスの対応をデータベースとして保持している。そのデータベース内のデータをリソースレコードと呼ぶ。以下に、主なリソースレコードを記載します。
| レコード名 | 概要 |
|---|---|
| A（Address） | ホスト名に対応するIPアドレス（IPv4） |
| AAAA | ホスト名に対応するIPアドレス（IPv6） |
| CNAME（Canonical Name） | ホスト名の別名 |
| MX（Mail Exchange） | メールサーバのホスト名 |
| NS（Name Server） | DNSサーバ（コンテンツサーバ）のホスト名 |
| SOA（Start Of Authority） | プライマリDNSサーバ（コンテンツサーバ）のホスト名、DNSサーバの動作に関する情報等 |
| PTR（PoinTeR） | ホスト名の別名逆引き。1バイト毎に逆さまにしたIPアドレスの末尾に、IPv4の場合は「.in-addr.arpa.」を、IPv6では「.ip6.arpa.」を付与する |
| TXT（Text） | ホスト名に対するテキスト情報（任意の値）。SPFやDKIMの設定で使用される |
| OPT(Option) | EDNSに関する情報等 |
※ その他のリソースレコードについてはDNSレコードタイプの一覧を参照
A/AAAAレコード
// フォーマット
[owner] [ttl] [class] A [address]
// 例
ns1.exmaple.com. 86400 IN A 192.0.2.1
ns2.exmaple.com. 86400 IN A 192.0.2.2
server1.example.com. 86400 IN A 192.0.2.1
server2.example.com. 86400 IN A 192.0.2.2
server1.example.com. 86400 IN AAAA 2001:db8::1
server2.example.com. 86400 IN A 2001:db8::2
CNAMEレコード
// フォーマット
[owner] [ttl] [class] CNAME [canonical-name]
// 例
info.example.com. 86400 IN CNAME server1.example.com.
shop.example.com. 86400 IN CNAME server2.example.com.
MXレコード
// フォーマット
[owner] [ttl] [class] MX [preference] [exchange-dname]
// 例
example.com 86400 IN MX 10 mx1.example.com // preferenceの小さい方が優先される
example.com 86400 IN MX 20 mx2.example.com
NSレコード
// フォーマット
[owner] [ttl] [class] NS [name-server-dname]
// 例
example.com 86400 IN NS ns1.example.com
IN NS ns2.example.com
コンテンツサーバの冗長化
コンテンツサーバは、障害が発生するとそのゾーンの名前解決ができなくなるため、通常、複数台で運用されます。この時、複数台のDNSサーバは対象ゾーンの情報を共有することで、どのサーバに名前解決要求が行われても同じ情報を返却できるようにしています。ゾーン情報を共有する仕組みをゾーン転送、ゾーン情報の転送元をプライマリ（マスタ）サーバ、転送先をセカンダリ（スレイブ）サーバと呼びます。
DNSサーバに対する攻撃
ゾーン転送要求による登録情報の収集
プライマリサーバに対してゾーン転送要求を行い、ゾーン情報を取得することで、ターゲットサイトのネットワーク構成やサーバ構成を把握する手法。
DNSキャッシュポイズニング攻撃
偽のDNS応答をフルサービスリゾルバー（キャッシュDNSサーバー）にキャッシュさせることで、利用者のアクセスを攻撃者が用意したサーバーに誘導し、フィッシングや送信された電子メールの窃盗などを図る攻撃手法です。
カミンスキー攻撃（Kaminsky's attack）
カミンスキー攻撃は、存在しないFQDNに対する名前解決要求を行い、コンテンツサーバからの応答を偽り、存在するFQDNとIPアドレスを応答することでキャッシュされているレコード情報を汚染する攻撃手法です。存在しないFQDNを使用することで、キャッシュサーバはコンテンツサーバに対して必ず名前解決要求を行うため、攻撃が成功するまでほぼ無限に試行するこができます。
DNS amp 攻撃（DNSリフレクション攻撃）
DNS amp攻撃は、送信元IPアドレスを攻撃対象のIPアドレスに偽った状態でDNS問合せを大量に行うことで、応答メッセージを攻撃対象に大量に送りつけることでサービス不能状態に陥らせる攻撃手法です。DNSは問合せよりも応答メッセージのデータサイズが大きくなるため、小さなクエリパケットで大きな攻撃パケットを生成することができます。また、DNSサーバに侵入し、TXTレコードなどに大量のメッセージを設定することでより大きな攻撃パケットを生成することも可能です。
ランダムサブドメイン攻撃（DNS水責め攻撃）
ランダムサブドメイン攻撃は、ランダムなサブドメインを付与したDNS問合せを大量に発行することで、コンテンツサーバへの問合せを集中させることでサービス不能状態に陥らせる攻撃手法です。
DNSサーバに対する攻撃の対策
ソースポートランダマイゼーション
ソースポートランダマイゼーションは、キャッシュサーバからコンテンツサーバへの名前解決要求の送信元ポート番号をランダムに変化させる手法です。DNSキャッシュポイズニング攻撃/カミンスキー攻撃を成功させるには、送信元のポート番号を正規のポート番号と一致させる必要があるので、ポート番号をランダムに変化させることで攻撃が成功する確率を低減することができます。
ゾーン情報の分離
内部的なゾーン情報を管理するDNSと外部に公開するゾーン情報を分離することで、外部に内部のゾーン情報が漏れないようにします。
ゾーン転送の制限
インターネットからのゾーン転送要求をファイアウォールで制限したり、セカンダリDNSのみを許可することでゾーン転送の範囲を最小限にします。
キャッシュサーバを利用可能なホストと問い合わせ数の制限
キャッシュサーバに問合せを行えるホストや問合せ数を制限することで、Dos攻撃に対する防御を行う。
DNSサーバの最新家とバージョン情報の隠蔽
DNSサーバをバージョンアップし常に最新にすることで脆弱性を減らしたり、バージョン情報を任意の文字列に置き換えることで攻撃者に情報を提供しないようにします。
DNSSEC
DNSSEC（DNS Security Extensions）は、コンテンツサーバが名前解決要求に対する応答にデジタル著名を付与し、キャッシュサーバでそれを検証することで応答レコードの正当性、完全性を保証する方式です。
