Nebulaの灯台DNS：誰がどのレコードを問い合わせられるか

Nebulaの灯台ロールは、人々が自動だと決めてかかる多くの仕事をこなしますが、DNSへの応答はその一つではありません。名前の提供は既定で無効の任意リスナーであり、そのためオーバーレイ内で名前解決が問題なくできるホストでも、同僚のノートPCを解決する手段をまったく持たないことがあります。有効にする前に、この二つの答えが異なることを踏まえて、誰が到達すべきか、どのレコード種別に応答するかを決めてください。

リスナーは任意であり、既定では無効です

検出とDNSは別のサービスです。灯台はピア同士が出会うのを助け、さらに既知のホストに関する名前問い合わせにも応答できますが、この後半は構成で明示的に有効にする必要があります。

何かを有効にする前に、どのインターフェースとネットワークがリスナーに到達すべきかを決めてください。意図していないインターフェースで応答するDNSサービスは、誰も読まないログ一行も残さない小さな情報漏えいになります。判断は今のほうが、何かが誤った応答に依存してから後で狭めるよりはるかに安く済みます。設定二行のほうが、半年後のインシデント記録より説明しやすいのです。

AレコードとTXTは対象を共有しません

この二つのレコード種別は異なる条件で応答され、それらを一つのサービスとして扱うことが、本記事が防ごうとしている誤りです。

この非対称性は意図的であり、見落としではありません。名前からアドレスへの対応は外部の者にとって価値が低い一方、証明書のメタデータはオーバーレイ内の身元を記述します。同じプロセスが両方に応答するという理由だけで、一方の行の前提をもう一方へ持ち込まないでください。

灯台自身のホストについてのみ応答します

これは社内オフィス、クラウドVPC、公衆インターネット向けの汎用リゾルバではありません。灯台は与えられたホスト情報から応答するため、この機能は各ピアではなく灯台ノードに置かれます。

オーバーレイと無関係な名前が解決できない場合は、実際にそれを所有するゾーンとリゾルバを探してください。オーバーレイのリゾルバをホストの一般DNS設定に混ぜると、一部の名前は解決し他は何も応答しないため、ランダムに見える障害が生じます。

あわせてブートストラップのエンドポイントも確認してください。最初の灯台へ到達するためのホスト名は、検出がそれに依存する前に通常の経路で解決できる必要があるため、ここでの鶏と卵の問題は壊れたオーバーレイとまったく同じに見えます。報告のされ方も同じで、決して起動しないピアに明白な理由は何もありません。この順序が難しい半分から始めた人を捕まえるため、証明書に触れる前に名前解決を確認してください。

バインドアドレスを確認し、外部から試す

lighthouse.dns.host と lighthouse.dns.port は、任意のサービスが待ち受ける場所を決めます。これらの値は、バインドアドレスが意図の表明であってそれ自体はセキュリティ制御ではないため、ホストのファイアウォールとネットワークポリシーとあわせて見直してください。

dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +short

許可するつもりのネットワークから、灯台自身からではなく問い合わせてください。灯台での成功はプロセスが動いている証拠であり、外部ホストが何を尋ねられるかについては何も教えてくれませんが、本当に重要なのはそちらの問いです。

意図をもって公開する

名前と証明書のメタデータは有用な運用情報であり、有用性は両方向に働きます。リスナーをオーバーレイ専用にすべきか、許可するレコード種別、変更時に誰が構成をレビューするかを決めてください。

そして灯台の設定の隣に書き残してください。次に解決障害をデバッグする人は、そうしなければサービスが以前からずっとそこにあったと前提します。テストしている場所からいつでも到達できたとも前提します。バインドアドレス、許可ネットワーク、レコード種別を記した一段落が、その人の午後を、そしてなぜ変わったのかという問い合わせをあなたから節約します。