DNSチュートリアル[janog53プログラム] のまとめ

概要

janog53にて紹介されていた、DNSチュートリアルの内容を、自己研鑽のためにまとめる。
この講座は、新入祐社員や新しい担当者などにもおすすめする内容。

テキストに無い内容をまとめようと思ったが、大体の内容はテキストにある事を喋っているので、pdfを見ても良い。

登壇者と会社

JPRS、森下さん、月東さん。

JPRSとは、株式会社日本レジストリサービスの略。
JPでのDNSサーバの運用を行う会社。DNSがよくわかる教科書を出している。

DNSの構成要素と分散管理の仕組み

DNSには、三種類の「構成要素がある・

• 情報が欲しい人
• 情報を探す人
• 情報を持っている人たち

なぜ～たちのになるのか？
→DNSが存在する前は、一元管理を行っていた。
HOSTS.txtにて登録などを行うという事を行っていたが、規模が大きくなり、この機能では
サービス提供に限界が訪れる。
そこで、分散管理できる仕組みを持つ、DNSという仕組みが進んでいった。

ドメイン名

管理する範囲（ドメイン）を、名前で表せるようにしたもの。
左に進むにつれて、範囲が狭まっていく。

階層化

一つのルートを起点にして、ドメイン名を階層化する。
これにより、一元管理できるようになった。

委任

階層を分割して、管理を任せられるできるようになった。
jpとexample.jpみたいな形

ゾーン

情報を持っている人達は、

• 自分が管理するドメイン名の情報
• 自分が委任したドメイン名の委任先の情報
  のみを管理する。

委任によって作られる管理単位が、ゾーンと呼ばれる。

ドメイン名を導入し名前を階層化し、委任によって管理の単位をゾーンに分割することで、
、限界を超えないように管理できるようになった。

構成要素の役割・名前解決の仕組み

上の構成要素には、名前がある。

• 情報が欲しい人
  • スタブリゾルバー
• 情報を探す人
  • フルリゾルバー
• 情報をもっている人
  • 権威DNS

ちなみに、上記3つの名前は統一されておらず、様々な名前があるのに注意する。

• スタブリゾルバ
  • DNSクライアント
• フルリゾルバ
  • DNSキャッシュサーバ、参照サーバ、ネームサーバなど。。
• 権威DNS
  • 権威サーバ、ゾーンサーバ、ネームサーバなど。

フルリゾルバと、権威DNSサーバは両方共DNSサーバと呼ばれる事があるため、構成図をみて、どちらなのか把握する事が大事である。

名前解決って？

利用者からの要求に応じて、名前に対応する情報を取り出す事。

• 対応するIPアドレスや、メールサーバホストの検索などを行う。

sample.jpのIPアドレス-> 210.150.~~.~~など。

ここで、それぞれの構成要素の役割を表すと、以下の通り。

• スタブリゾルバ
  • 名前解決の依頼する。
• フルリゾルバ
  • 名前解決を実行し、得られた応答を蓄える
• 権威DNS
  • 保持する情報を提供する。

ここで、先ほどの3つとは別の要素がある事がある。それは、フォワードである。
スタブとフルリゾルバの間に立ち、名前を転送するもの。身近な例だと、ホームルーター
が当てはまる。

これを使う事で、ISPを変更したり使い分ける際、利用者がDNS設定の変更を行わなくて良い。というメリットがある。NATとも相性が良い。

スタブの役割

ブラウザ等から名前解決依頼を行う。（名前解決要求）
「私の代わりに名前解決を実行して、結果を教えてください」という問い合
わせを送る

フルリゾルバの役割

• 名前解決要求を受け取って名前解決を実行し、結果を返す
  • ルートから始めて、権威DNSサーバーへの問い合わせを繰り返す
• 次回以降の名前解決に使うため、得られた応答を蓄える

資料を引用

権威DNSの役割

問い合わせに応じ、自分が保持する情報を提供する

• 自分が管理するゾーンの情報
• 自分が委任したゾーンの委任先の情報

例：yahoo.stream.co.jpというドメインがあるとき、

1. まずはルートサーバにフルリゾルバが問い合わせる。
2. jpを持つサーバにフルリゾルバが問い合わせる。
3. jpを持つサーバは、co.jpを持つサーバを返す
4. 次にフルリゾルバはco.jpを持つサーバに問い合わせる。
5. co.jpは、stream.co.jpを持つサーバを返す。
6. 次にフルリゾルバはstream.co.jpを持つサーバに問い合わせる。
7. stream.co.jpを持つサーバは、yahoo.stream.co.jpを返す。
8. フルリゾルバは、スタブリゾルバにyahoo.stream.co.jpを返す。

という流れをする。

こういう流れをすると、**権威DNSサーバには、委任先のドメイン名を利用するつもりであるという事のみが伝わる。**つまり、ルートのサーバやフルリゾルバの内部に、どのドメインを問い合わせたかという内容が分からないようになる。これは、近年のプライバシー上の懸念点を会けるするために実施されたアルゴリズムであり、QNAME minimisationとよぶ。

最初の仕様（2016年）では、NSレコードを用いて問い合わせを行っていたが、現在の仕様（2021年）では、A/AAAAレコード（IPv4と、IPv6アドレスを対応付けたレコード）の使用を推奨している。

QNAME minimisationの名前解決の流れ

• フルリゾルバは、ルートゾーンの一覧を事前に持っている。
• ルートサーバに、jpの委任先を問い合わせる。その後、.毎に委任先の情報を順序問い合わせていく。

2回目以降になると、いちいち問い合わせる繰り返しのやり取りがなくなり、負荷と時間を減らして効率化できる。
なぜなら、フルリゾルバが経路の情報をキャッシュとして蓄えているから

なお、これは途中の情報もキャッシュ・活用できる。

資料を引用

例えば、www.example.jpのIPv4アドレスを名前解決した直後に
www.example2.jpのIPv6アドレスが問い合わされた場合、
ルートサーバーへの問い合わせを省略して、jpのサーバーから問い合わせを
始めることができる

また、フルリゾルバがデータをキャッシュしてよい時間は、管理者が自分のZoneの権威DNSサーバで設定できる。
これを、TTL（time to live）とよぶ。
以下の例なら、sample.jpのTTLが1時間である。

sample.jp 3600 IN A 192.0.2.1

また、存在しないという事もキャッシュとして活用され、次回以降の応答で使用される。
*ネガティブキャッシュのTTLも管理者が自分の権威DNSサーバで設定している。

現場のトラブルシューティングにおけるポイント

今回は二つのケースが紹介されていた。
実際の運用では、これ以上にトラブルのケースがあると思うが、以下の点には、紹介される理由が2点ある。

• 2種類の問い合わせがあることを理解し、調査対象により使い分け
  ることで、トラブルの原因切り分け・対応に役立つ
• 2種類の不在応答があることを理解し、機器ベンダーやサービスプロ
  バイダーの実装を調査することで、トラブルの原因切り分け・対応に役立つ

役割が異なる2種類の問い合わせ

DNSには再帰的問い合わせと非再帰的問い合わせという、役割が異なる2種類
の問い合わせが存在する。

これらは、問い合わせという意味では一緒で同じポートを使うが、役割が異なる。

• 再帰的問い合わせ：スタブリゾルバーからフルリゾルバーへの問い合わせ
  • 名前解決の要求：リカーシブルクエリ
• 非再帰的問い合わせ：フルリゾルバーから権威DNSサーバーへの問い合わせ
  • 名前解決の実行：ノンリカーシブルクエリ

直感的には逆なイメージがするが、これは最初に名付けた人がそうつけたものなのだ。。
技術書などを見ても間違える事があるので、注意する事。

実際にコマンドで問い合わせるには

digコマンドは、両方の問い合わせに対応している。

+rec（デフォルト）で、再帰的問い合わせを送る。
+norecで、非再帰的問い合わせを送る。

権威DNSサーバを調べるときは、+norecをつける事で調査できる。
権威DNSサーバとの疎通、トラブルシューティングを行う時は上記のオプションをつけよう。

これをオプションで分けているメリット

資料を引用

- 今どちらのサーバーを調べているか、明確に意識付けできるようになる
    - 調査対象が権威DNSサーバーかフルリゾルバーか、常に意識することが重要
        - どちらかわからないと、うまくトラブルシューティングできない
- BINDで運用されているサーバーなど、過去の経緯などにより双方の機能を兼用しているサーバーを調べる際に、特に役立つ
    - もちろん、権威DNSサーバーとフルリゾルバーはそもそも兼用しない方がよい

意味が異なる2種類の不在応答

権威DNSが返す応答は、以下6種類に分類される。2と3が存在しないパターン。

資料から引用

① 問い合わされた名前・タイプに合致するレコードが存在する

② 問い合わされた名前とそのサブドメインにはレコードが一つも存在しない
③ 問い合わされた名前・タイプに合致するレコードは存在しない
（他のタイプのレコードや、サブドメインは存在するかもしれない）

④ 問い合わされた名前は別名である
⑤ 問い合わされた名前は他のサーバーに委任している
⑥ 問い合わされた名前を管理も委任もしていない（管理範囲外）

• 2の方は、そもそも存在しない。
• 3の方は、合致する情報では存在しない。
  • 例えば、Ipv4ではあるけど、IPv6では存在しないみたいなケース。
  • レコード違いであればある

4番は、別名である。というパターンであり、レコードはCNAMEで表される。
6番は、通常運用では問い合わされないハズ。

ここでは注目すべきパターンは、2と3である。

2の応答例。存在しない名前を名前解決したときには、以下のような項目が出力される。
statusがNXDOMAIN

• flagsにaaがセット
• ANSWERが0
• AUTHORITYが1
• 内容はそのゾーンのSOAレコード

資料から引用

3の応答例。似ているけど、statusがNOERRORとなっている事がある。
しかし、ANSWERが0である。この応答を、NODATA応答と呼ばれる。

NODATAを返すべき時に、誤ってNXDOMAINを返す設定になってしまっているサーバというのが存在する事があるという時に、違いを理解しておくと調査できるので、覚えておこう。