DNSがよくわかる教科書 ch11 DNSの設定・運用に関するノウハウ

DNS勉強メモ

出典: 


lame delegation

  • 委任元(親)ゾーンに委任情報として登録されている権威サーバーが、委任先(子)ゾーンの権威サーバーとして動作していない状態
  • DNS運用直後から問題となっていた
  • rfc1713

A lame delegation is a serious error in DNS configurations, yet a (too) common one.

lame delegationの例

  • 応答そのものを返さない

    • 親に登録した委任情報が誤っている場合
    • 権威サーバーが動作していないIPアドレスに問い合わせが送られる
    • 権威サーバーが停止している
  • REFUSED

    • ゾーンの設定をしていない権威サーバーにそのゾーンの問い合わせが送られた場合
  • SERVFAIL

    • ゾーン転送が失敗しゾーンデータが無効になった場合
    • ゾーンの設定をしていない権威サーバーにそのゾーンの問い合わせが送られた場合
  • 権威をもたない応答を返す(AAビットが設定されていない)

    • 権威サーバーとフルリゾルバーが同じIPアドレスで動作していて権威サーバーの設定が無効になった場合

lame delegationが発生するとなぜ良くないのか

  • 名前解決にかかる時間が長くなる

    • ゾーンの委任先には複数の権威サーバーホスト名を設定できる (NS)
    • 権威サーバーホスト名には複数のIPアドレスを設定できる (A, AAAA)
    • フルリゾルバーは正しい応答が得られるまですべての権威サーバーに問い合わせを送る
    • 応答がないことはタイムアウトしてはじめてわかる
  • lame delegationによる遅延は初回のみで、以降はフルリゾルバーのキャッシュが効くため、設定ミスに気づきにくい
  • 委任先の権威サーバーが全てlame delegationだと、散々タイムアウト待ちした末に名前解決がエラーとなる
  • 名前解決にかかる時間が長いと、キャッシュポイズニングが成功しやすくなる

    • UDPの場合コネクションレスなのでソースポートが割れると割り込まれる

lame delegationを発生させないようにするには

  • コマンドラインツール
  • 監視ツール
  • DNSチェックサイト

    • 例: Zonemaster, dnscheck.jp
    • 委任前チェックが可能
    • レジストリに委任情報を登録する前のチェック

レジストリにおける取り組み

  • レジストリごとにさまざまな仕組みが運用されている

    • 委任前チェック
    • 登録済のドメイン名に対する定期的なlame delegationチェック
    • lame delegationが長期にわたって続いた場合、委任情報を自動削除

よくあるトラブルと設定ミス

  • ゾーン転送におけるトラブル

    • ゾーン転送のテストを行おう
    • プライマリのSOAリソースレコードのSERIAL値のみ更新してゾーン転送を行い、セカンダリに反映されていることを確認する
  • ゾーンファイルのメンテナンスにおけるトラブル

    • SERIAL更新忘れによりゾーン転送されない
    • 文法誤りにより新しいゾーンファイルが読まれず、古いゾーンファイルでサービスが継続される
    • ログを確認しよう
  • ファイアウォールやOSのアクセス制限におけるトラブル

    • TCP/UDP両方の53番を許可しよう
    • DNSの仕様上、TCP/UDPいずれも使用してもよいことになっている
    • TCPはUDPの代替ではない
    • 断片化されたIPパケットの先頭以外も受け取れるようにしよう
    • 先頭以外のパケットにはTCP/UDPヘッダがないため捨てられがち
    • 断片化が発生しない範囲で運用するか、パケットを再構築してから判定するF/Wを使う
    • プライマリ->セカンダリの53番を許可しよう
    • ゾーン転送のDNS NOTIFY用
  • サーバーの種類とアクセス制限の設定

    • 権威サーバーはインターネット全体に公開する
    • フルリゾルバーは、基本ISPや組織内のみにサービス提供範囲を限定する
    • インターネット上の権威サーバーからの戻りのパケットは通過させる必要あり

“www”が付かないホスト名の設定方法

  • zone apexにA/AAAAを設定する

CDNサービスとの関係

  • zone apexにCNAMEは設定できない

    • CNAMEは他のリソースレコードと共存できない
    • が、zone apexにはSOAレコードとNSレコードが必要
  • 各種CDNサービスやクラウドサービスでは独自のdnsサービスを開発・提供している

    • Cloudflare: DNS Flattening
    • AWS Route53: Aliasレコード
    • 内部的に単なるAレコードに展開される

$TTLを設定する場合の注意点

  • $TTLディレクティブ

    • ゾーンファイル先頭の$TTLで始まる行
    • TTL値の規定値を設定できて便利
  • リソースレコードの利用側による分類

    • (a) スタブリゾルバーが問い合わせるもの
    • 一般的なA/AAAA,MXなど
    • (b) フルリゾルバーが階層構造をたどる際に問い合わせるもの
    • NS、権威サーバーのA/AAAA
  • (b) は頻繁に変わらないので、名前解決の負荷を下げるためにTTLが長いことが望ましい
  • 設定指針

    • $TTLで長い値を指定しておき、(a)のTTL値を個別に短くする
    • $TTLで短い値を指定しておき、(b)のTTL値を個別に長くする

国際化ドメイン名の設定方法

  • InternetのもととなったARPANETのHOSTSファイルでは、ホスト名にalnumと-のみを使うことになっている
  • Internetもこれを踏襲
  • しかし、DNSプロトコルにはそうした制限はない
  • 国際化ドメイン名 (IDN: Internationalized Domain Names)

    • 非英語圏から「各国語で表記された名前をドメイン名として使用したい」という要求があがった
  • 互換のため、Punycode方式で国際化ドメイン名のラベルを従来のalnum + -と相互変換することになった

  • idnコマンドも利用可能
idn -a <<< 'ドメイン名例.jp'
xn--eckwd4c7cu47r2wf.jp

応答サイズの大きなDNSメッセージへの応答

  • 初期のDNSではUDPでのDNSメッセージサイズが512バイト以下に制限されていた

    • IPv4仕様に由来する
    • 「一度に受信可能なデータグラム(ヘッダ含むパケット)は576バイトを保証しなければならない」 (下限)

      • ヘッダ64 + データブロック512
    • DNSメッセージを1つのIPパケットで送受信できることを保証するための制限
  • DNSの利用範囲が広がるに連れてDNSメッセージサイズは増加していった

    • 【補】jp.の権威サーバーを問い合わせてみるだけですでに512を超える
    • 昨今ではAAAAレコードが追加されているから、というのもある
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メッセージに対応するための方法

    • TCPにフォールバックする
    • EDNS0を使用し、UDPで512バイトを超えるDNSメッセージを扱う
  • drill -a

    • man
    • まずEDNS0によるフォールバックを試みる(デフォルト4096オクテット)
    • それでも収まらなければTCPにフォールバック
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バッファサイズの決め方

    • 1220
    • DNSSECでサポートしなければならないと定められているサイズ
    • 1232
    • IPv6の最小MTU1280 - IPv6ヘッダ40 - UDPヘッダ8

逆引き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 (偏執狂のチェック)

    1. IPアドレスを逆引きする
    2. 逆引き結果をさらに正引きする
    3. 結果を照合する