いにしえのネットワーク入門

• 名前の木 ── ルート、.example、expenses.example と、段ごとに担当がいる
• リゾルバー ── PC の代わりに木をたどる。はじめては 0.166 秒（実測）
• TTL とキャッシュ ── 覚えている間は 0 ミリ秒、切れたら聞き直し（実測）
• 開発者の落とし穴 ── hosts と dig の食い違い、DNS が止まったときの症状（実測）

DNS は、TCP/IP の層で言えば第7層、アプリの層の仕組みです。それでもアプリの通信より先に必ず動くので、ここで扱います。練習用ネットワークは、PC とプロバイダのリゾルバー（Unbound）を線の手前に、3段の DNS サーバー（NSD）と申請のサーバーを、片道 20 ミリ秒のいたずら線の向こうに置きました。

www.expenses.example は、右から読みます。いちばん右の見えない点がルート、その下に example、さらに expenses、最後に www。ルートの DNS サーバーは example の担当を知っていて、example の担当は expenses の担当を知っている。この「担当を知っている」ことを委任と呼びます。

本物のインターネットでは、ルートは a から m までの 13 の名前を持ち、12 の組織が運用しています。実際には同じ中身の写しが世界中に千台以上置かれていて、近くのものが答えます。この回の練習では、ルートも筆者が作りました（a.root.lab、203.0.113.1）。

PC は、木をたどる仕事を自分ではしません。家のルーターやプロバイダが用意したリゾルバー（キャッシュ DNS サーバー）に「expenses.example の住所は？」と1回聞くだけです。リゾルバーの側で記録しました。

# リゾルバーで記録：PC の1つの問い合わせのために、リゾルバーは3か所に順に聞いた（片道 20 ms の線の向こう）
  0.000                PC → resolver          A expenses.example
  0.000          resolver → root              NS <Root>
  0.041              root → resolver          NS <Root> NS a.root.lab A 203.0.113.1
  0.042          resolver → root              A expenses.example
  0.082              root → resolver          A expenses.example NS ns1.example A 203.0.113.2
  0.083          resolver → .example          A expenses.example
  0.124          .example → resolver          A expenses.example NS ns1.expenses.example A 203.0.113.3
  0.124          resolver → expenses.example  A expenses.example
  0.165  expenses.example → resolver          A expenses.example A 203.0.113.20 NS ns1.expenses.example A 203.0.113.3
  0.166          resolver → PC                A expenses.example A 203.0.113.20

リゾルバーは、まずルートが生きているかを確かめ（ルートの NS）、それからルートに聞きます。ルートの答えは「知らない。.example は ns1.example（203.0.113.2）に聞いて」という紹介です（表紙の写真）。.example も同じように expenses.example を紹介し、最後に expenses.example の DNS サーバーが 203.0.113.20 と答えました。線を4往復して 0.166 秒です。

同じ道のりを、PC から順にたどって見せてくれるのが dig +trace です。

# dig +trace：PC が自分でルートから順にたどる（← は答えた DNS サーバー）
pc$ dig +trace expenses.example
    .  86368  IN  NS  a.root.lab.
    ← 198.51.100.53 (198.51.100.53)
    example.  86400  IN  NS  ns1.example.
    ← a.root.lab (203.0.113.1)
    expenses.example.  3600  IN  NS  ns1.expenses.example.
    ← ns1.example (203.0.113.2)
    expenses.example.  30  IN  A  203.0.113.20
    expenses.example.  3600  IN  NS  ns1.expenses.example.
    ← ns1.expenses.example (203.0.113.3)

毎回 0.166 秒かけて木をたどっていたら、Web は遅くてたまりません。そこでリゾルバーは、答えを覚えておきます。どのくらい覚えてよいかは、答えについている TTL（秒）が決めます。expenses.example の住所は、練習のため 30 秒にしました。

# PC からリゾルバー（198.51.100.53）へ。答えの TTL（あと何秒覚えておくか）と、かかった時間
pc$ dig expenses.example @198.51.100.53
    expenses.example.  30  IN  A  203.0.113.20    168 ms   ← はじめて
    expenses.example.  29  IN  A  203.0.113.20      0 ms   ← 1 秒後
    expenses.example.  19  IN  A  203.0.113.20      0 ms   ← 10 秒後
    expenses.example.  10  IN  A  203.0.113.20      0 ms   ← 20 秒後
    expenses.example.  30  IN  A  203.0.113.20     44 ms   ← 30 秒後（切れた）

覚えている間は 0 ミリ秒で、TTL は 29、19、10 と減っていきました。30 秒で切れると、リゾルバーは聞き直しますが、ルートと .example の紹介はまだ覚えている（TTL は1日と1時間）ので、expenses.example にだけ聞いて 0.044 秒でした。

DNS が答えるのは住所だけではありません。名前に結びつけた1行1行をレコードと呼び、種類があります。

# expenses.example のいろいろなレコード（数字は TTL、秒）
    expenses.example.  29  IN  A  203.0.113.20
    expenses.example.  30  IN  AAAA  2001:db8::20
    www.expenses.example.  300  IN  CNAME  expenses.example.
    expenses.example.  3600  IN  MX  10 mail.expenses.example.
    expenses.example.  3600  IN  TXT  "kiji practice zone for part 9"
    expenses.example.  3600  IN  NS  ns1.expenses.example.

CNAME の名前には、ほかのレコードを置けません。ドメインのてっぺん（ここでは expenses.example そのもの）には NS や SOA が必ずあるので、てっぺんを CNAME にはできない、という決まりは知っておくとよいでしょう。

# ない名前を聞く
pc$ dig nosuch.expenses.example
    status: NXDOMAIN
    expenses.example.  60  IN  SOA  ns1.expenses.example.  admin.expenses.example.  2026102501  1800  900  604800  60
# 「ない」という答えも、SOA の最後の数（60 秒）のあいだ覚えておく
    1回目: 40 ms    2回目: 0 ms

ない名前を聞くと、答えは NXDOMAIN（そんな名前はない）です。答えには SOA が添えられていて、その最後の数（60 秒）が「ない」という答えを覚えておいてよい時間です。2回目は 0 ミリ秒でした。打ち間違いの名前に何度アクセスしても、毎回木をたどらずに済みます。逆に、新しい名前を登録する前にうっかり引いてしまうと、「ない」をしばらく覚えられてしまいます。

いよいよ --resolve なしで、curl に申請を送らせます。リゾルバーのキャッシュを空にしてから2回続けました。

# curl で HTTPS の申請（--resolve なし）。リゾルバーのキャッシュを空にしてから2回
    1回目  namelookup 0.1667  connect 0.208  tls 0.252  total 0.294  (201)
    2回目  namelookup 0.0006  connect 0.041  tls 0.087  total 0.144  (201)

1回目は、名前を引くのに 0.167 秒。そのあと第6回の TCP、第8回の TLS と続きます。2回目は 0.0006 秒で、全体も 0.294 秒から 0.144 秒になりました。初めてのサイトがほんの少し遅いのは、こういうことです。

アプリ（curl やブラウザ）は、DNS に聞く前に、手前の場所から探します。中でも hosts ファイルは、DNS より先に見られます。開発中に書いた1行が残っていると、こうなります。

# PC の hosts に、古い住所 203.0.113.21 が書き残されていたら
    /etc/hosts:  203.0.113.21  expenses.example
# OS の名前引き（hosts を先に見る）
pc$ getent ahostsv4 expenses.example
    203.0.113.21  STREAM  expenses.example
# dig（DNS にしか聞かない）
pc$ dig +short expenses.example
    203.0.113.20
# curl（OS の名前引きを使う）
    curl: (28) Failed to connect to expenses.example port 3443 after 3002 ms: Timeout was reached

dig は 203.0.113.20 と正しく答えるのに、curl は hosts の古い住所 203.0.113.21 へつなぎに行って、3 秒で時間切れになりました。dig は DNS にしか聞かないので、hosts を見ません。「dig では合っているのに、アプリだけつながらない」ときは、hosts と、OS やブラウザのキャッシュを疑いましょう。

# リゾルバーのプログラムが止まっている（「そこには誰もいない」と ICMP が返る）
    curl: (6) Could not resolve host: expenses.example
    total 0.0001 s
# リゾルバーまで届かない（線が切れている）
    curl: (6) Could not resolve host: expenses.example
    total 6.023 s

リゾルバーのプログラムだけが止まっている場合は、OS が「そこには誰もいない」（第7回の ICMP）と知らせるので、curl はすぐ Could not resolve host になりました。ところがリゾルバーまで届かない場合は、6 秒待たされてから同じエラーになりました。ここでは PC がリゾルバーの MAC を ARP で6回尋ねた分です。途中で消える場合は、Linux の既定（resolv.conf の timeout 5 秒、attempts 2 回）に従って、さらに長く待つこともあります。

この回の記録はすべて、UDP の 53 番で、聞いた名前がそのまま読める DNS でした。第8回で、HTTPS にしても名前（SNI）が見えると書きましたが、DNS の問い合わせからも名前はわかります。

そこで、DNS の問い合わせ自体を TLS で包む DoT（853 番）や、HTTPS で包む DoH（443 番）が使われるようになりました。いまの主なブラウザや OS は、設定で DoH を使えます。ただし、リゾルバー自身には名前が見えるので、どのリゾルバーを信頼するかは別の問題として残ります。なお、答えが大きいと UDP から TCP に切りかえて聞き直すしくみもあり（第7回の 1232 バイト）、TCP の 53 番も DNS の番号です。

dig の答えの2列目が TTL です。同じ名前を何度か引いて、数が減っていくのを見てみましょう。