DNSキャッシュサーバ
設計と運用のノウハウ
東 大亮
DNS Summer Days 20142014 / 6 / 26

はじめに•

DNSが正しく動作しないと、インターネットのサービス利用に多大な影響が出る•

キャッシュサーバは、DNSの重要な要素の一つだが、安定動作のためのノウハウがあり、個別に語られることはあるが、まとまったものはあまり無い（と思う）

2

DNSキャッシュサーバを動かすだけなら簡単•

BIND9もUnboundも、設定ファイル無しでキャッシュサーバとして動いてしまう# named -c /dev/null!

# unbound -c /dev/null“-c”は設定ファイ
ルの指定

BIND9やUnboundは、（その版がリリースされた時点での）ルートヒントも内蔵しているので、設定情報としてルートヒントを与える必要もない
上記設定では、localnets; localhost (BIND9)・localhost (Unbound)からの再帰クエリを受け付ける
DNSキャッシュサーバとして動作
3

動かすだけなら簡単…でも、•デフォルト設定は、ハードウェアの性能を最大限に発揮できるとは限らないため、ある程度の規模以上の用途ではチューニングが必要•

トラブルを防ぐための、ネットワーク環境も含めた正しい設定が必要•

それでも発生し得るトラブルに対する備えもあった
ほうがよい4今日のお話•トラブル無く（ちゃんと名前解決できる）、安定したDNSキャッシュサーバを運用するために知られているノウハウをいくつか紹介•

パフォーマンスチューニング

•トラブルを避けるための設計と運用•（それでも起こってしまう）トラブルに備える•

セキュリティについて5注意！
• 本発表では、具体的なDNSキャッシュサーバの設定や構成の例を多く紹介しますが、全ての環境に適する設定とは限りません（きわどいのもあります）。
• この発表の設定例を実環境に投入する場合は、事前に十分な検証を行ってください。
• 本発表ではキャッシュサーバの実装として利用者が多いBIND 9とUnboundの設定例を含みます。各実装のバージョンは以下の通り。
• BIND 9.9.5-P1• Unbound 1.4.22•

本発表はDNSキャッシュサーバ専用で動作しているDNSサーバを前提としています。権威ネームサーバの話はしません。
6

パフォーマンスチューニング

パフォーマンスチューニングの必要性• 多くのDNSキャッシュサーバ実装のデフォルト設定は、システムの資源を浪費しないようにリミッターがかかっている• ハードウェアの性能を最大限に発揮できる設定ではないため、チューニン

グ不足だと以下の現象が起こる：• CPU使用率が高くないのに、クライアントからの再帰検索要求をドロップしてしまう• 秒間あたりの再帰検索要求(QPS)が低いのに、なぜかCPU使用率が高い• 検索速度が遅い（キャッシュヒット率が上がらない）• トラフィックが小さい(〜数百QPS)ならばチューニングは不要だが、大きくなってくるとチューニングは必要
8

「DNSキャッシュサーバ
チューニングの勘所」•キャッシュサーバのチューニングは、これだけのテーマでお話しても1時間以上かかるネタです•というわけで別冊にしました•

http://www.slideshare.net/hdais/dns-32071366•「DNSキャッシュサーバ

チューニングの勘所」で検索すればslideshareで出てきます•

以下はハマりやすいポイントをご紹介します9チューニング
これだけはやっておこう(1)••クライアントから受信した、未解決（権威サーバに問合せ処理中）の再帰検索要求の処理状態を管理・保持する領域のサイズの引き上げ•

BIND9のデフォルト値 recursive-clients 1000•

Unboundのデフォルト値 num-queries-per-threads 512 or 1024

数千QPS以上のDNSキャッシュサーバでは小さすぎるため、適切な値に引き上げる必要がある
10

DNSキャッシュサーバ
内部構造
キャッシュサーバ
プロセス

ワーカー

インターネット（権威サーバ）

スレッド
ワーカー

DNS
リクエスト
クライアントスレッド

ソケットバッファ

ワーカー
スレッド

udp/53

ワーカー
スレッド

説明しやすいように簡略化している。また、DNSサーバの実装によって細かい差がある

再帰検索要求処理状態管理メモリ

11

キャッシュメモリ

DNS再帰検索処理(1)キャッシュサーバ
プロセス

ワーカー

インターネット（権威サーバ）スレッド
ワーカー

クライアント

udp/53

スレッド

ソケットバッファ

ワーカー
スレッド
ワーカー

①クライアントからのDNS検索要求受信、ソケットバッファにキュー
イング

スレッド

再帰検索要求処理状態管理メモリ

12

キャッシュメモリ

DNS再帰検索処理(2)キャッシュサーバ
プロセス

ワーカー

インターネット（権威サーバ）

スレッド
ワーカー
スレッド

udp/53
クライアント

ソケットバッファ

ワーカー
スレッド
ワーカー
スレッド

②ワーカースレッドが、ソケットから取り出し、リクエスト管理メモリに格納

再帰検索要求処理状態管理メモリ

13

キャッシュメモリ

DNS再帰検索処理(3)キャッシュサーバ
プロセス

ワーカー

インターネット（権威サーバ）

スレッド
ワーカー
スレッド

udp/53
クライアント

ソケットバッファ

ワーカー
スレッド
ソケット

ワーカー

③ワーカースレッドは、キャッシュメモリを参照したり、インターネットの権威サーバに問合せたりしながら、答えを検索

スレッド

再帰検索要求処理状態管理メモリ

14キャッシュメモリ

DNS再帰検索処理(4)キャッシュサーバ
プロセス

ワーカー

インターネット（権威サーバ）

スレッド
ワーカー
スレッド

udp/53
クライアント

ソケットバッファ

ワーカー
スレッド
ワーカー
スレッド

④得られたDNSの答えを、クライアントに送り返す

再帰検索要求処理状態管理メモリ

15キャッシュメモリ

高負荷なDNSキャッシュサーバの状態と、要求処理状態管理メモリ量の引き上げ
キャッシュサーバ
プロセス

ワーカー

インターネット（権威サーバ）スレッド

udp/53

ワーカー

ソケット

スレッド
ソケット
ソケットバッファ

クライアント

ワーカー
スレッド

ソケット
ソケット

クライアントから送られてくる多数のリクエストについて、処理①〜④が同時並行に行われている

再帰検索要求の解決は、１個あた
スレッドり数秒要することもあるため、クライアントからのQPSが多いと管再帰検索要求キャッシュメモリ
処理状態管理メモリ
理メモリを多数消費する→管理メモリ上限の引き上げ要
ワーカー

16

チューニング
これだけはやっておこう(2)• キャッシュメモリのサイズ•

BIND9のデフォルト値

max-cache-size 制限無し(キャッシュされたRRSetのTTLが切れるまで保持)••システムのメモリを食い尽くしてしまうおそれがあるため、制限をかける

Unboundのデフォルト値 rrset-cache-size: 4MB / msg-cache-size:
4MB•

4MB / 4MBは多数のクライアントを収容するキャッシュサーバとしては小さすぎるため、引き上げる
17

トラブルを避ける設計と運用

DNSキャッシュサーバの特徴
全体外観
クライアント側と権威ネームサーバ側の通信に大きく分かれる
クライアントキャッシュサーバ

権威ネームサーバ(スタブリゾルバ)(フルサービスリゾルバ)(インターネット上に分散配置)
root

再帰検索要求応答
再帰検索要求問合せ・応答

com

jp

info

応答
再帰検索要求応答

example.com example2.com

19

example.jp

example.co.jp example.info

DNSキャッシュサーバの特徴
クライアント側•クライアントキャッシュサーバ(スタブリゾルバ)(フルサービスリゾルバ)

クライアント（スタブリゾルバ）からの再帰検索要求を受信、検索結果を応答!

クライアントがDNS名前検索が必要となる
root
たびに要求がある!
• ISP環境のキャッシュサーバでは、多数のクライアントを収容するため、秒間あたりのcomjp
info
問合せ・応答
要求数 (QPS)が大きい!
• EDNS0オフのクライアントが多い (UDP
メッセージは512バイトまで)
example.com
example2.com example.jp
example.co.jp example.info•

再帰検索要求応答
再帰検索要求応答
再帰検索要求応答

20

DNSキャッシュサーバの特徴
権威ネームサーバ側!
•

再帰検索要求を解決するために、インターネット上の多数の権威サーバと通信を行う。jpドメインの名前解決でも、海外のサーバに問合せが必要なこともある!
•

最近のキャッシュ・権威サーバ実装では、EDNS0は有効。特にDNSSEC署名されたゾーンからの応答はメッ
再帰検索要求セージサイズが大きいため、IPフラグメントされたUDP応答が返ることもある
応答
再帰検索要求問合せ・応答rootcom

jp

info

応答
再帰検索要求応答

example.com example2.com

example.jp

example.co.jp example.info

キャッシュサーバ

権威ネームサーバ(フルサービスリゾルバ)(インターネット上に分散配置)

21

DNSキャッシュサーバ
におけるトラブル•

トラブルは無数に起こりえるが、ありがちなトラブルと、それを防止・回避する設定を紹介•IPフラグメントが届かない問題の回避•

TCPクエリに対応しないクライアントの問題の回避

22

IPフラグメントが届かない問題(1)•

権威サーバ→キャッシュサーバ方向のDNS応答が巨大な場合、UDP応答がIPフラグメント化されてキャッシュサーバへ送信されることがある•

検索対象ドメインがDNSSEC署名されていた場合に多い

DNS問合せメッセージは小さい(=<512B)ため、フラグメントされることはほぼ無い

DNS問合msg UDP IP

DNS問合せ
権威ネームサーバ

キャッシュサーバ

IP UDP DNSmsg前半 IP DNSmsg後半

IP UDP DNS msg

応答がNWのMTUに比べて大きいため権威サーバが送信（しに、途中のルータや権威サーバ自身によってフラグメントされたDNS(UDP)応答ようと）した巨大な
DNS応答

23

IPフラグメントが届かない問題(2)• 途中のネットワーク経路上の問題により、IPフラグメントが疎通せず、キャッシュサーバが応答を受け取れないことがある→対象ドメイン名の解決が不可(SERVFAIL)になる• 「おたくのキャッシュで特定のドメイン名が引けないんだけど（他では引ける)」系トラブルの原因！
• フラグメントされるような巨大なDNS応答の時だけ問題が起こるため、厄介• 以前から指摘されていますが、今でもDNS技術系ML等でも現役の頻出Q&Aです（私もハマりました）
権威ネームサーバ

キャッシュサーバ

IP UDP DNSmsg前半 IP DNSmsg後半•24

ありがちなパターン：経路上のファイアーウォールやロードバランサの設定ミスやバグでフラグメントを正しく転送できない

IPフラグメントが届かない問題(3)•

通常は問題ないよう見えても、FWやLBの設定不良やバグにより特定の条件でフラグメントが疎通できない場合がある•

FWの不具合事例（私の自宅のBBルータのNAT機能と、某FW製品が該当…）• フラグメントの先頭が先に届かないと、2番目以降のフラグメントを通さないFWが存在する• インターネットの経路によってはフラグメントが高確率で順序が逆転して届くことがあるため、そのようなFWがあるとフラグメントが疎通しない
権威サーバ側から届いたフラグメントされた応答キャッシュサーバ

フラグメントの前半が先に届かないとドロップするFW

IP DNSmsg後半 IP UDP DNSmsg前半

IP UDP DNSmsg前半 IP DNSmsg後半

逆転25

IPフラグメントが届かない問題(4)•FWだけでなくルータやL3SWのACLにおいても、フラグメントを意図通りに通さないものも存在する•

以下は53/udp宛のパケットを通すACLであるが、IPフラグメント（特に２番目以降のフラグメント）が許可なのか拒否なのかは、ベンダによって異なる
access-list 100 permit udp any any eq 53

26

IPフラグメントが届かない問題(5)•

レイヤ4以上のフィールドを見てアクセス制限やフォワードしている部分については、IPフラグメントの扱いを確認しましょう•

LBやFWの選定・設定・検証においては、IPフラグメントの扱いに細心の注意を払いましょう•

LBやFWのベンダ様各位におかれましては、IPフラグメント周りのバグには特にご注意頂きますようお願いいたします（実装が大変なのは、分かりますけど）•些細な問題のようですが、ハマるとかなりきついです27

IPフラグメントが届かない問題(6)• フラグメント問題を解消できない場合の回避策•

キャッシュサーバが権威ネームサーバに問合せる時に、EDNS0でUDP応答サイズの最大値を指定可能(BIND9/Unboundともにデフォルト4096B)。

•

この値をフラグメントされないサイズまで小さくすることで、フラグメントを回避できる•

DNS応答が指定サイズに収まらない場合は、TCPで再問合せ(TCPフォー
ルバック)
問合せ＋UDP応答は1220Bまでにしてね☆

権威ネームサーバ

キャッシュサーバ(1220B以下のUDP応答)
28

IPフラグメントが届かない問題(7)応答サイズ指定方法

BIND9Unbound

権威サーバを特定(192.0.2.1)して応答サ

Unboundは、全権威サーバ共通イズ指定する場合指定のみ可

server 192.0.2.1 {edns-udp-size 1220;};

edns-buffer-size: 1220;
UDP応答が1220バイトに収まらずTCP問合せが行われると負荷が高いので、可能なら権威サーバ指定が良い

全権威サーバに対して共通で指定する時はoptions節で記載

options {edns-udp-size 1220;};

Unbound/BIND9ともに、未指定時のデフォ
ルトは4096バイト
29

IPフラグメントが届かない問題(8)DNSキャッシュサーバのFWが、フラグメントを通すかどうかの簡易試験ツール
DNS-OARCのサービスが便利
https://www.dns-oarc.net/oarc/services/replysizetest

ただし、逆転したフラグメントが通らない等の特定条件の問題は見つからないこともあります30

IPフラグメントが届かない問題(9)キャッシュサーバから特定の権威サーバへの通信が、フラグメント問題に該当しているか調べる方法
キャッシュサーバ上から、digで問題の権威サーバにDNS問合せを送信してみる。
このとき DO=1 (DNSSEC OK)かつEDNS0バッファサイズを4096に指定(BIND9 / Unboundのデフォルト)① dig @192.0.2.1 www.example.com A +norec +dnssec +bufsize=4096

次にバッファサイズを小さくして問合せてみる② dig @192.0.2.1 www.example.com A +norec +dnssec +bufsize=1220①で応答が得られず、②で応答(TCPフォールバック後)が得られた場合、フラグメント問題に該当している可能性が高い
31

TCPに対応しないクライアン
トの対応(1)•

クライアント(スタブリゾルバ) キャッシュサーバ間は、EDNS0無効のことが多く、DNS応答が512Bを超える時はTCPが使われる•

TCPに対応せず、512Bを超える応答が扱えないクライアントが存在し、そのようなクライアントでは名前解決できないドメインが存在する•

家庭用ブロードバンドルータ内蔵のDNSフォワーダに多い④DNS/TCPに対応しないため、DNS応答が得られない②再帰検索要求(UDP)①再帰検索要求③応答が512B以上なのでTCPでやり直してね☆

DNS/TCPに対応しない
DNSフォワーダ

32

キャッシュサーバ(フルサービスリゾルバ)

TCPに対応しないクライアン
トの対応(2)•

pixiv.netの事例
pixivではDNSラウンドロビンを限界まで使ってみたことがあるという。ぶら下げるWebサーバの数が一定数を超えると「DNSレコードがUDPパケットに収まらなくて、ユーザーの環境によっては“画像が見えない”ということが起こった」という。DNSでは応答が512バイトを超えると、TCPにフォールバックしようとするが、家庭用ルータにはこの仕組みがうまく扱えないものもあるからだ。

引用(強調は東)：http://www.atmarkit.co.jp/news/201007/21/pixiv.html

2010年の記事ですが、現在でも同じ原因で、他のドメイン名が「引けない」という騒ぎが時々あります。
33

TCPクエリに対応しないクライアントの対応(3)minimal-responses••

DNS応答のauthority section/additional sectionを(プロトコル上許される範囲で)省略する機能•

DNS応答サイズが削減され、TCPが必要になる可能性が減る•BIND9minimal-responses yes;

•Unboundminimal-responses: yes

常にminimal-responses応答を行うDNSキャッシュサーバも多い•

PowerDNS recursor、dnscache (djbdns)、GooglePublic DNS等
34

TCPクエリに対応しないクライアントの対応(4)minimal-responsesの効果•応答からAuthority/Additional sectionが省略され、DNS応答サイズが小さくなっている$ dig www.kernel.org

minimal-responses no!

;; QUESTION SECTION:;www.kernel.org.

!

!

!

;; QUESTION SECTION:;www.kernel.org.

IN A;; ANSWER SECTION:
www.kernel.org.
600 IN
pub.all.kernel.org. 600 IN
pub.all.kernel.org. 600 IN
pub.all.kernel.org. 600 IN$ dig www.kernel.org minimal-responses yes!

IN A;; ANSWER SECTION:
www.kernel.org.
600 IN
pub.all.kernel.org. 600 IN
pub.all.kernel.org. 600 IN
pub.all.kernel.org. 600 IN

CNAME pub.all.kernel.org.
A 198.145.20.140
A 149.20.4.69
A 199.204.44.194!

;; AUTHORITY SECTION:
kernel.org.
86400 IN NS ns0.kernel.org.
kernel.org.
86400 IN NS ns1.kernel.org.
kernel.org.
86400 IN NS ns2.kernel.org.

;; MSG SIZE

CNAME pub.all.kernel.org.
A 199.204.44.194
A 198.145.20.140
A 149.20.4.69

rcvd: 102!

;; ADDITIONAL SECTION:
ns0.kernel.org.
86400
ns1.kernel.org.
86400
ns1.kernel.org.
86400
ns2.kernel.org.
86400
ns2.kernel.org.
86400

!

;; MSG SIZE

IN
ININ
IN
IN

512バイト問題を100%回避できるとは限らないが、効果は高い

A 198.145.19.196
A 149.20.20.144
AAAA
2001:4f8:8:10::1:1
A 149.20.4.80
AAAA
2001:4f8:1:10::1:1

rcvd: 26035

それでも起こるトラブルへの備えトラブルに備える•

DNSキャッシュサーバの監視•

トラフィックログの取得

37

DNSキャッシュサーバの監視(1)•

基本的な監視••CPU、メモリ使用量、ロードアベレージ、ネットワークトラフィック量

キャッシュサーバの正常性の監視•

各種統計情報の取得•

ドメイン名が正しく引けるか？
38

DNSキャッシュサーバの監視(2)
統計情報•

様々な統計情報が有るが、モニタしておくとよい項目がある•

異常時にすぐに状況が確認できるように、MRTG的なものでグラフ化すると良い•閾値監視（一定値範囲から外れたらアラーム）もするとよいが、負荷状況によって正常値が上下するので難しいかも39

DNSキャッシュサーバの監視(3)
統計情報
BIND9 XML stats

Unbound(isc/bind/statistics/server/nsstat/)unbound-control stats̲noreset

検索要求数

ΔRequestv4+ΔRequestv6

Δtotal.num.queries

キャッシュヒット率(ΔRequestv4+ΔRequestv6 - ΔQryRecursion)

Δtotal.num.cachehits

成功した検索要求(QNAME&QTYPEが見つかった)

NODATA(QNAME存在するがQTYPE無)NXDOMAIN(QNAME無し)

その他エラー
検索要求管理メモリの長さ(ΔRequestv4+ΔRequestv6 )Δtotal.num.queries

ΔQrySuccessΔnum.answer.rcode.NOERROR Δnum.answer.rcode.nodata

ΔQryNxrrset

Δnum.answer.rcode.nodata

ΔQryNXDOMAIN

Δnum.answer.rcode.NXDOMAINΔQrySERVFAIL,

Δnum.answer.rcode.SERVFAIL,

ΔQryFORMERR

Δnum.answer.rcode.FORMERR

rndc status コマンドの出力の“recursive clients”

total.requestlist.current.all「Δ」は前回サンプリング時からの増分値を表す。キャッシュヒット率・検索要求管理メモリの長さ以外については、値をサンプリング時間で割って単位時間あたりの値をモニタ対象にしてもよい
40

DNSキャッシュサーバの監視(4)
統計情報の激変時
極端な増加時に考えられる事象
検索要求数

キャッシュサーバへの大量トラフィック

極端な減少時に考えられる事象
NW障害等でクライアントがキャッシュサー
バに到達不能／大規模イベント（W杯等）
キャッシュサーバに対するDoS／NW障害等キャッシュヒット率でキャッシュサーバが権威サーバに到達不能／キャッシュポイズニング攻撃

NXDOMAIN

キャッシュサーバに対するDoS／キャッシュポイズニング攻撃
SERVFAIL: NWの障害でキャッシュサー

その他エラーバが多数の権威サーバに到達できない／キャッシュへのDoS攻撃

検索要求管理メモリの長さ

キャッシュサーバに対するDoS攻撃／キャッシュサーバが権威サーバに到達不能

41

DNSキャッシュサーバの監視(5)ドメイン名が正しく引けるか？
•キャッシュサーバの正常性監視として、当該キャッシュサーバで複数のドメイン名が正常に引けるか常時監視すると良い•監視対象として適当と思われるもの•Alexa Top 500の上位ドメイン (google.com, facebook.com,youtube.com, …)••

http://www.alexa.com/topsites

TTLが短め(10秒程度)のドメイン名(自前で作ってもよい)•

キャッシュメモリからの応答ではなく、キャッシュサーバ 権威サーバ間の再帰検索による応答が可能であるかの監視
42

トラフィックログの取得(1)•

障害調査のため、DNSキャッシュサーバがやりとりしているトラフィックログを取得することは有益だが、以下の問題がある•

BIND9もUnboundも、クライアントからの検索要求ログの取得は可能だが、トラフィックが多いサーバではログの出力自体が大きな負荷になり現実的ではない••

上記を理由として、敢えてクエリログ機能を実装していないDNSサーバもある(NSD等)

キャッシュサーバ 権威サーバ間の問合せ・応答を出力することはデバッグレベルのログが必要なことが多く、通常運用状態では現実的ではない
43

トラフィックログの取得(2)•

トラフィックが多いDNSキャッシュサーバを収容するL3SW/
L2SWは、ポートミラーリングが可能なものにしましょう•

DNSサーバに影響を与えずにトラフィックログを取れます•キャッシュサーバ自体でtcpdump動かしてディスクに貯めるのも負荷になるので•可能であれば、パケットキャプチャ用のマシンをあらかじめ用意して、ミラーポートに接続しておくくらいでもいいです44キャプチャしたパケットの解析•

Wireshark•

フラグメントしたDNSパケットでもリアセンブルして解析できるので便利。巨大なpcapファイルは取込めないことがあるので、一旦tcpdumpでパケットキャプチャした内容を、tcpdump -r -w で特定の通信のみフィルタしてWiresharkに入力すると良い•dnstop／dsc•

DNSパケットをキャプチャしながら統計を取ることができるツール•

dsc http://dns.measurement-factory.com/tools/dsc/•

dnstop http://dns.measurement-factory.com/tools/dnstop/45

セキュリティについて

セキュリティについて•

DNSキャッシュサーバにおける一般的なセキュリ
ティ関連対策について•

アクセス制限（オープンリゾルバにしない）•

キャッシュポイズニング対策•

ポートランダマイズ•

ポートランダマイズ以外の対策
47

アクセス制限の必要性•

インターネット上のどのクライアントからも再帰検索要求を受け付けるキャッシュサーバ（オープンリゾルバ）を構築してはいけません。すでに運用していた場合は速やかにアクセス制限を行いましょう•

アクセス制限の仕方は、本日の山口さんのチュートリアルを参考•

オープンリゾルバだと・・・•

DNS amp攻撃の踏み台に使われる（他人への迷惑）•

DNS amp攻撃の踏み台にされることで負荷が増し動作が不安定になる•

DNSキャッシュポイズニング攻撃がやりやすくなる48

アクセス制限する前提での構築・運用•

組織がIPアドレスを獲得したら、DNSキャッシュサーバ担当へ連絡が行われてそのIPからのアクセス制限を解除する体制の構築が必要•

すでに、オープンリゾルバになってるキャッシュサーバにアクセス制限かけるのは非常に苦労します！（皆、大変苦労しています）•

参考事例「オープンリゾルバ機能停止の取り組み」•NEC BIGLOBE小野さん / InternetWeek2013
https://www.nic.ad.jp/ja/materials/iw/2013/proceedings/d2/

49ソースポートランダマイズ•

キャッシュポイズニング攻撃からの最低限の防御•

必ずやりましょう•

詳細は本日の山口さんのチュートリアルを参考

50

ポートランダマイズ以外の対策•

カミンスキー型攻撃の発表からすでに６年が経過••

DNSサーバやネットワークの性能の向上等により、従来のポートランダム化、TXIDランダム化
だけでは今後不足する可能性もある

DNSSECで攻撃の検知と防御は可能だが、ここでは、敢えてDNSSEC以外の対策を紹介
51

dns-0x20•

ポートランダマイズ・TXIDランダマイズに加えて、QUESTION SECTIONのQNAMEをランダム化に利用しカミンスキー型攻撃等のブラインド攻撃をやりにくくするテクニック••

DNSの問合せに対して、権威サーバは大文字小文字は無視して検索・応答するが、DNS
応答のQNAMEは、DNS問合せのQNAMEをそのままコピーする仕様を利用

キャッシュサーバはQNAMEをランダムに大文字小文字に変換して権威サーバに送信。権威サーバから全く同じQNAMEの応答が戻ってきたら応答が偽装されていないと判断

問合せ
QNAME: wWw.eXamPle.cOm QTYPE=A?
QNAME: wWw.eXamPle.cOm QTYPE=A?
キャッシュサーバANSWER: www.example.com A 192.0.2.1

応答52

権威ネームサーバ

dns-0x20•

dns-0x20を利用できるキャッシュサーバは、フリーなものではUnboundのみ•use-caps-for-id: yes
なんで0x20 ? → ʼAʼ + 0x20 = ʻaʼ53dns-0x20•

0x20の問題点•

QNAMEを完全コピーせずに全部小文字（または大文字）に変換して応答する権威サーバや、QNAMEが全部小文字でないと応答しない権威サーバもあり、そのような権威サーバが保持するゾーンが引けない等の問題が発生し得る

QNAME=wWw.eXamPle.cOm QTYPE=A?
QNAME= www.example.com QTYPE=A?
キャッシュサーバANSWER: www.example.com A 192.0.1.1
54

権威ネームサーバソースIPランダム化•

UnboundやPowerDNS recursor等の一部のキャッシュサーバでは、クエリソースIPアドレスを複数指定可能•

TXID・クエリソースポートに加え、ソースIPもランダム化されるためカミン
スキー型キャッシュポイズニング攻撃が成功する確率の低減が期待できる•

IPv4アドレス枯渇のため、大量にIPアドレスを付与することはできないかもしれないが、多数のユーザを収容するキャッシュサーバでは実施する価値あり
outgoing-interface: 192.0.2.1
outgoing-interface: 192.0.2.2
outgoing-interface: 192.0.2.3
outgoing-interface: 192.0.2.4
outgoing-interface: 192.0.2.5
outgoing-interface: 192.0.2.6
outgoing-interface: 192.0.2.7
outgoing-interface: 192.0.2.8

Unboundでの設定例→(ソースIP 8個でランダム化)

55

まとめ•

DNSが正しく動作しないと、インターネットのサービス利用に多大な影響が出る•

キャッシュサーバはDNSの重要な要素の一つだが、安定動作のためのノウハウがある•

パフォーマンスチューニング

•トラブルを防ぐための設定と環境•トラブルへの備え•

セキュリティ
56

END

backup slides

IPフラグメントが届かない問題(補足)••

DNSのメッセージサイズにありがちな誤解•「DNSは512バイトまではUDPを使う、それを超えるとTCPを使う。MTUは普通1500バイト近くあるのでUDPパケットのフラグメントは起こらないのでは？」•「DNSSECとかいうのを使うと512バイト以上でもUDP使うみたいだけど、うちのキャッシュサーバはDNSSEC検証してないし関係ないよ」•「UDPで応答が得られなくても、TCPでやり直すのでは？」キャッシュサーバ 権威サーバ間の通信に関しては、キャッシュサーバとしてBIND9やUnbound等の最近の実装を利用する限り上記はほぼ間違いです。
フラグメントの問題は、ほぼ全てのキャッシュサーバの運用者に関係します。
59

IPフラグメントが届かない問題(補足)•

DNSメッセージサイズの実際•

キャッシュサーバ 権威サーバ間の通信は、ほとんどの実装でEDNS0が有効のため、512バイト超えるDNSメッセージでもUDPを使用する。DNS応答が巨大になるとフラグメントされる•

権威サーバ側でDNSSEC署名をされている場合、キャッシュサーバでDNSSEC検証の有無に関わらずDNSSEC署名つきの巨大な応答が返る•

権威サーバからUDP応答が得られない場合、TCPで問合せをやり直す
キャッシュサーバ実装もあるが、DNSの規格でそう決まっているわけではない。必ずそうするわけではない。
60

Tips(1):ルートヒントの設定•

BIND9/Unboundはリリース時点の最新のルートヒント（ルート権威サーバのリスト）を内蔵しており、ルートヒントを設定しなくてもDNSキャッシュサーバとしては正常に動作する•

ルートヒント（ルートネームサーバのリスト）は時々変更されるため、明示的にルートヒントを与える設定にしておくのが良い•（別の意見）古いルートヒントを更新せずに使う人もいるし、どうせDNSキャッシュサーバのセキュリティ脆弱性が出て替えるのだから、明示的にルートヒント与えないほうがいいのでは？

61

Tips(2): UnboundでAAAAFilter•

できないと（２年前に）言ったな、あれはウソだ••

private-address: ::/0

本来はDNS rebinding攻撃の防御として、ユーザへのDNS応答に含まれるプライベート・リンクローカルアドレスのA/AAAAレコードを落とすためのオプションだが、AAAAフィルタとして流用可能•

ただし、BIND9のAAAA Filterとは少し動作が異なるので注意•

BIND9: AAAAのみ存在する名前(IPv6 onlyなサイト)はフィルタしない•

上記設定のUnbound: AAAAは常にフィルタしてしまう

62