Tech Learning Daily

名前解決は「どの名前を試すか」から始まる

アプリが getaddrinfo() などで名前を引くとき、実際に DNS サーバーへ問い合わせるのはアプリのプロセス内にあるスタブリゾルバ（libc などに組み込まれた、問い合わせを組み立てて DNS サーバーに投げる部品）だ。スタブリゾルバは問い合わせの前に /etc/resolv.conf を読み、どの DNS サーバーに、どの名前を、どの順で聞くかを決める。

順序を決めるのが 2 つの設定だ。search は、短い名前に補って試すドメインの一覧（search リスト）。options ndots:N は、名前に含まれる点が N 個未満なら search リストを先に試し、N 個以上なら最初から名前そのものを試す、という切り替えの閾値だ。glibc の resolv.conf(5) によれば ndots のデフォルトは 1 で、上限 15 に丸められる。

デフォルトの ndots:1 なら、点を 1 つでも含む名前はまず「そのまま」引かれる。社内ネットワークで search corp.example を設定しておけば、ssh build01 と打つだけで build01.corp.example を探してくれる。search リストはもともと、このような人間向けの省略入力のための仕組みだ。

kubelet が Pod に書く resolv.conf

Kubernetes では、kubelet が Pod ごとに /etc/resolv.conf を生成する。dnsPolicy を指定しない Pod には ClusterFirst が適用され（名前は紛らわしいが、Default はデフォルトではない）、公式ドキュメントの例では次の内容になる。

nameserver 10.32.0.10
search <namespace>.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

nameserver はクラスタ DNS（多くの場合 CoreDNS）の Service の IP だ。search リストが 3 段あるおかげで、同じ Namespace の Service は data、別 Namespace なら data.prod と書くだけで data.prod.svc.cluster.local に補完される。コードや設定ファイルに長い FQDN（ルートまで省略せずに書いた完全な名前）を書かなくて済むのは、この search リストのおかげだ。

ndots:5 という大きな値を選んだ理由は公式ドキュメントに明記されていない。ただ、Service の SRV レコード名は _port._proto.my-svc.my-ns.svc の形まで省略でき、この時点で点が 4 つある。点 4 つまでの名前をすべて「クラスタ内の短縮名かもしれない」と扱うには閾値を 5 にする必要がある、と考えると数字の辻褄は合う。

外部ドメインも「短い名前」扱いになる

search リストはクラスタ内の名前のためにあるのだから、外部ドメインには関係ないように思える。しかしリゾルバが見ているのは点の数だけだ。api.example.com の点は 2 つで 5 未満なので、default Namespace の Pod では次の順に問い合わせが進む。

Pod (ns: default)          CoreDNS
 │ api.example.com +        │
 │.default.svc.cluster.local│
 ├─────────────────────────▶│
 │◀──────────── NXDOMAIN ───┤
 │.svc.cluster.local        │
 ├─────────────────────────▶│
 │◀──────────── NXDOMAIN ───┤
 │.cluster.local            │
 ├─────────────────────────▶│
 │◀──────────── NXDOMAIN ───┤
 │ api.example.com          │
 ├─────────────────────────▶│──▶ 上流 DNS
 │◀──────────── IP ─────────┤
 ▼                          ▼

1 回の名前解決が 4 往復になる。しかも glibc はデフォルトで IPv4 用の A レコードと IPv6 用の AAAA レコードを並行して問い合わせる（resolv.conf(5) の single-request の説明より）ため、パケット数はその 2 倍になる。クラウドによっては kubelet がノード側の search ドメインも後ろに足すので、公式のデバッグ手順に載っている GKE の例のように search リストが 5 段になり、空振りがさらに増える。

1 回あたりの空振りは CoreDNS がクラスタ内の情報だけで即答するため、通常は速い。問題になるのは量と、まれな失敗だ。外部 API を毎リクエスト呼ぶサービスでは CoreDNS への問い合わせが数倍に膨らむ。さらに DNS は通常 UDP で運ばれるので、パケットが 1 つ落ちるとリゾルバは timeout（resolv.conf(5) によるデフォルト 5 秒）を待ってから再送する。往復が 4 倍あれば、この「たまに 5 秒遅い」に当たる機会も 4 倍になる。

空振りを減らす 3 つの手と、その副作用

最初に試すべきは、外部ドメインを末尾ドット付きの FQDN で書くことだ。api.example.com. のように最後に点を付けた名前は「これで完結している」という意味になり、リゾルバは search リストを使わずに 1 回だけ問い合わせる。アプリ側の変更だけで済むが、HTTP クライアントやライブラリによっては Host ヘッダや証明書の名前照合で末尾ドットの扱いが揺れることがあるため、通信先ごとに動作を確かめてから使うほうがよい。

次の手は、Pod 単位で ndots を下げることだ。dnsConfig.options に書いた値は kubelet が生成する resolv.conf にそのまま反映される。

spec:
  dnsConfig:
    options:
      - name: ndots
        value: "2"

ndots:2 にすると、点が 2 つ以上の api.example.com は最初から本来の名前で引かれ、空振りが消える。一方、data.prod（点 1 つ）は従来どおり search リストで補完されるが、data.prod.svc（点 2 つ）は先に外部へ問い合わせて NXDOMAIN を受けてから search リストに戻る。名前解決自体は成功するが、今度はクラスタ内の名前で空振りが起きる。ndots を下げるのは、その Pod が使う名前の形を把握してからにする。

3 つ目は、クラスタ側で NodeLocal DNSCache（各ノードに DaemonSet として置く DNS キャッシュ）を導入することだ。問い合わせの回数自体は変わらないが、Pod は同じノード上のキャッシュに聞くため、kube-proxy の DNAT や conntrack（Linux カーネルの接続追跡表）を経由しなくなる。公式ドキュメントは、これにより conntrack の競合で UDP パケットが落ちる問題が減り、キャッシュから CoreDNS への通信を TCP に切り替えることでタイムアウト起因のテールレイテンシも減ると説明している。