DNSがよくわかる教科書 ch11 DNSの設定・運用に関するノウハウ
- lame delegation
- lame delegationの例
- よくあるトラブルと設定ミス
- "www"が付かないホスト名の設定方法
- $TTLを設定する場合の注意点
- 国際化ドメイン名の設定方法
- 応答サイズの大きなDNSメッセージへの応答
- 応答サイズの大きなDNSメッセージに対応するための機能拡張
- 逆引きDNSの設定
lame delegation
A lame delegation is a serious error in DNS configurations, yet a (too) common one.
lame delegationの例
- 応答そのものを返さない
- 親に登録した委任情報が誤っている場合
- 権威サーバーが動作していないIPアドレスに問い合わせが送られる
- 権威サーバーが停止している
- 親に登録した委任情報が誤っている場合
- REFUSED
- ゾーンの設定をしていない権威サーバーにそのゾーンの問い合わせが送られた場合
- SERVFAIL
- ゾーン転送が失敗しゾーンデータが無効になった場合
- ゾーンの設定をしていない権威サーバーにそのゾーンの問い合わせが送られた場合
- 権威をもたない応答を返す(AAビットが設定されていない)
lame delegationが発生するとなぜ良くないのか
- 名前解決にかかる時間が長くなる
- lame delegationによる遅延は初回のみで、以降はフルリゾルバーのキャッシュが効くため、設定ミスに気づきにくい
- 委任先の権威サーバーが全てlame delegationだと、散々タイムアウト待ちした末に名前解決がエラーとなる
- 名前解決にかかる時間が長いと、キャッシュポイズニングが成功しやすくなる
lame delegationを発生させないようにするには
レジストリにおける取り組み
- レジストリごとにさまざまな仕組みが運用されている
よくあるトラブルと設定ミス
- ゾーン転送におけるトラブル
- ゾーンファイルのメンテナンスにおけるトラブル
- 例
- SERIAL更新忘れによりゾーン転送されない
- 文法誤りにより新しいゾーンファイルが読まれず、古いゾーンファイルでサービスが継続される
- ログを確認しよう
- 例
- ファイアウォールやOSのアクセス制限におけるトラブル
- サーバーの種類とアクセス制限の設定
"www"が付かないホスト名の設定方法
- zone apexにA/AAAAを設定する
CDNサービスとの関係
- zone apexにCNAMEは設定できない
- CNAMEは他のリソースレコードと共存できない
- が、zone apexにはSOAレコードとNSレコードが必要
- 各種CDNサービスやクラウドサービスでは独自のdnsサービスを開発・提供している
$TTLを設定する場合の注意点
- $TTLディレクティブ
- ゾーンファイル先頭の
$TTLで始まる行 - TTL値の規定値を設定できて便利
- ゾーンファイル先頭の
- リソースレコードの利用側による分類
- (b) は頻繁に変わらないので、名前解決の負荷を下げるためにTTLが長いことが望ましい
- 設定指針
国際化ドメイン名の設定方法
- InternetのもととなったARPANETのHOSTSファイルでは、ホスト名にalnumと
-のみを使うことになっている - Internetもこれを踏襲
- しかし、DNSプロトコルにはそうした制限はない
- 国際化ドメイン名 (IDN: Internationalized Domain Names)
- 互換のため、Punycode方式で国際化ドメイン名のラベルを従来のalnum +
-と相互変換することになった- Punycode変換・逆変換
- U-label:
ドメイン名例.jp - A-label:
xn--eckwd4c7cu47r2wf.jp
idnコマンドも利用可能
idn -a <<< 'ドメイン名例.jp'
xn--eckwd4c7cu47r2wf.jp
応答サイズの大きなDNSメッセージへの応答
- 初期のDNSではUDPでのDNSメッセージサイズが512バイト以下に制限されていた
- DNSの利用範囲が広がるに連れてDNSメッセージサイズは増加していった
- 【補】jp.の権威サーバーを問い合わせてみるだけですでに512を超える
- 昨今ではAAAAレコードが追加されているから、というのもある
- 【補】jp.の権威サーバーを問い合わせてみるだけですでに512を超える
drill google.com. @8.8.8.8 IN ANY
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 10435 ;; flags: qr tc rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; google.com. IN ANY ;; ANSWER SECTION: ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: ;; Query time: 5 msec ;; SERVER: 8.8.8.8 ;; WHEN: Sat Apr 11 13:14:26 2020 ;; MSG SIZE rcvd: 28 ;; WARNING: The answer packet was truncated; you might want to ;; query again with TCP (-t argument), or EDNS0 (-b for buffer size)
flags: qr tc rd ra- tc: TrunCated
;; WARNING: The answer packet was truncated; you might want to ;; query again with TCP (-t argument), or EDNS0 (-b for buffer size)
- 「長すぎて切り詰められているのでTCPかEDNS0を使え」
応答サイズの大きなDNSメッセージに対応するための機能拡張
- 応答サイズの大きなDNSメッセージに対応するための方法
drill -a
drill google.com. @8.8.8.8 IN ANY -a
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 52244 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 18, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; google.com. IN ANY ... ;; Query time: 5 msec ;; EDNS: version 0; flags: ; udp: 512 ;; SERVER: 8.8.8.8 ;; WHEN: Sat Apr 11 13:27:00 2020 ;; MSG SIZE rcvd: 649
- 応答は649オクテット
-bでEDNS0のバッファサイズを指定できる- EDNS0のバッファに応答が収まらないケース: TCPにフォールバック
drill google.com. @8.8.8.8 IN ANY -a -b 600
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 36586 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 18, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; google.com. IN ANY ... ;; Query time: 8 msec ;; EDNS: version 0; flags: ; udp: 512 ;; SERVER: 8.8.8.8 ;; WHEN: Sat Apr 11 13:27:30 2020 ;; MSG SIZE rcvd: 649
- ちょっと遅い(4-5ms -> 8-9ms)
IPフラグメンテーションへの対応
- 最大転送単位 (MTU: Maximum Transmission Unit)
- あるネットワーク上でのIPパケットサイズの上限
- インターネットでは1500オクテットまで通過できることが多い
- 初期イーサネット由来
- IPフラグメンテーション
- 最大転送単位よりも大きなIPパケットを中継する際に必要となる仕組み
- IPパケットをMTUを超えないサイズに断片化する
- IPフラグメンテーションを回避しつつなるべく大きなパケットを扱うためのEDNSバッファサイズの決め方
逆引きDNSの設定
逆引きDNSで使われるドメイン名とリソースレコード
- 例: qiita.com
dig @8.8.8.8 qiita.com. A +short
3.113.189.84 18.182.160.99 13.113.17.132
18.182.160.99を逆引きしてみる
dig @8.8.8.8 99.160.182.18.in-addr.arpa. ANY
; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> @8.8.8.8 99.160.182.18.in-addr.arpa. ANY ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47323 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;99.160.182.18.in-addr.arpa. IN ANY ;; ANSWER SECTION: 99.160.182.18.in-addr.arpa. 299 IN PTR ec2-18-182-160-99.ap-northeast-1.compute.amazonaws.com. ;; Query time: 54 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat Apr 11 13:46:18 JST 2020 ;; MSG SIZE rcvd: 123
99.160.182.18.in-addr.arpa. 299 IN PTR ec2-18-182-160-99.ap-northeast-1.compute.amazonaws.com.
- AWSで動いているんだな、というのがわかる
- おそらくap-northeast-1a,c,dをまたいだALBへのAliasレコード
- IPv4では、各バイトをひっくり返して
.in-addr.arpaをつけたものが逆引き用のドメイン名になる - IPv6では、各ニブル(4ビット)をひっくり返して
.ip6.arpa.をつけたものが逆引き用のドメイン名になる - PTRレコードを設定する必要がある
- IPアドレスの配布元の権威サーバーで
- 逆引きゾーンの委任を受けて、自分の権威サーバーで
dig @8.8.8.8 www.google.com AAAA +short
2404:6800:4004:813::2004
dig @8.8.8.8 4.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.3.1.8.0.4.0.0.4.0.0.8.6.4.0.4.2.ip6.arpa. ANY
; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> @8.8.8.8 4.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.3.1.8.0.4.0.0.4.0.0.8.6.4.0.4.2.ip6.arpa. ANY ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48514 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;4.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.3.1.8.0.4.0.0.4.0.0.8.6.4.0.4.2.ip6.arpa. IN ANY ;; ANSWER SECTION: 4.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.3.1.8.0.4.0.0.4.0.0.8.6.4.0.4.2.ip6.arpa. 21599 IN PTR nrt20s17-in-x04.1e100.net. ;; Query time: 40 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat Apr 11 13:57:51 JST 2020 ;; MSG SIZE rcvd: 140
逆引きDNSの利用事例
- メールサーバーにおけるメールの受信許可
- paranoid check (偏執狂のチェック)
- IPアドレスを逆引きする
- 逆引き結果をさらに正引きする
- 結果を照合する
