Posted inNetwork

Linux上のCoreDNS：マイクロサービスをより円滑に運用するためのBind9代替ソリューション

Network tutorial - IT technology blog
Network tutorial - IT technology blog

Bind9と別れて6ヶ月、CoreDNSから学んだ教訓

CoreDNSを本番環境に導入して半年が経ち、一つの結論に達しました。Bind9が質実剛健な「古いトラック」だとするなら、CoreDNSはまさに「テスラ」です。高速でレスポンスが良く、メンテナンスの手間が極めて少ない。Bind9の複雑なゾーンファイルの構文や、設定反映に数秒かかるリロードに頭を悩ませてきたなら、CoreDNSはその体験を完全に変えてくれるでしょう。

CoreDNSはGo言語で書かれており、非常に軽量です（小規模クラスターならRAM消費はわずか15〜30MB程度）。その運用はプラグイン機構に基づいています. ログを記録したい？プラグインがあります。GoogleにDNSをフォワードしたい？プラグインがあります。実際、それはKubernetesのデフォルトDNSとしても採用されています。最大の魅力は、設定ファイル（Corefile）が非常に直感的で、リクエストがどこへ処理されるのか一目で理解できる点にあります。

5分でできるCoreDNSのクイックデプロイ

理論を語るよりも、実際にUbuntu/CentOSにバイナリを直接インストールして、そのシンプルさを体感してみましょう。

1. ダウンロードとインストール

# リリース版をダウンロード (例: v1.11.1)
wget https://github.com/coredns/coredns/releases/download/v1.11.1/coredns_1.11.1_linux_amd64.tgz

# 解凍してシステムバイナリへ移動
tar -xzvf coredns_1.11.1_linux_amd64.tgz
sudo mv coredns /usr/local/bin/

2. 設定ファイル Corefile の作成

Corefile という名前のファイルを作成します。ここがDNSルーティングのロジックをすべて記述する場所です：

.:53 {
    forward . 8.8.8.8 1.1.1.1
    log
    errors
}

3. 実行

# ポート53を使用するためsudo権限で実行
sudo coredns -conf Corefile

新しいターミナルを開き、dig @localhost google.com を入力してみてください。CoreDNSのターミナルに即座にログが表示されれば、正しく設定されています。応答速度は通常、ミリ秒単位です。

Corefileの構造を紐解く

CoreDNSの構造は Server Blocks を中心に構成されています。各ブロックは特定のゾーンまたはポートを表します。その内部には、検問所のような役割を果たす Plugins が配置されます。

重要な注意点として、Corefileに記述するプラグインの順序は実行順序に 影響しません。この順序は、コンパイル時に plugin.cfg ファイル内でハードコードされています。一見不自由に思えるかもしれませんが、これによりシステムが非常に安定し、プラグイン同士の競合を防ぐことができます。

内部ドメイン（Internal Domain）の設定

例えば、.itfromzero.lan というサーバー群があるとします。サブネットを分割する際、手動計算が面倒な場合は、IP Subnet Calculator などを使ってIP範囲とブロードキャストを素早く取得すると便利です。これにより、ネットワーク設定を最初から正確に行えます。

以下は、Corefileで内部ドメインをマッピングする方法です：

itfromzero.lan {
    hosts {
        10.0.0.10 web.itfromzero.lan
        10.0.0.11 api.itfromzero.lan
        fallthrough
    }
    log
}

. {
    forward . 8.8.8.8
    cache 30
}

解説：

  • ドメイン itfromzero.lan は hosts プラグインを通じて個別に処理されます。
  • それ以外のすべてのリクエストは Google DNS に転送されます。
  • cache 30 は結果を30秒間キャッシュすることで、外部ネットワークへの負荷を大幅に軽減します。

本番環境向けの最適化

Systemd サービスとして運用する

サーバー再起動後もCoreDNSが自動的に起動するように、サービスファイルを作成しましょう。その前に、セキュリティ確保のため sudo useradd -r -s /usr/sbin/nologin coredns コマンドで専用ユーザーを作成するのを忘れないでください。

[Service]
PermissionsStartOnly=true
LimitNOFILE=1048576
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
User=coredns
ExecStart=/usr/local/bin/coredns -conf /etc/coredns/Corefile
Restart=on-failure

Plugin Rewrite: サービス名変更時の「救世主」

以前、数十のクライアント側のコードを修正せずに、API名を旧名から新名に変更する必要がありました。rewrite プラグインを使えば、一瞬で解決できます：

rewrite name old-api.lan new-api.lan

実践的なヒントと経験

1. 常に Health プラグインを有効にする： Corefileに health :8080 を追加します。Uptime Kumaやロードバランサーなどの監視ツールは、このエンドポイントを見てDNSが「生存」しているかを確認します。

2. Prometheus による監視： prometheus :9153 という行を追加するだけで、レイテンシやエラー率を確認できる本格的なダッシュボードが手に入ります。

3. ポート53の競合解決： Ubuntuでは systemd-resolved がポート53を占有していることがよくあります。CoreDNSが address already in use エラーを出した場合は、sudo systemctl stop systemd-resolved で停止させる必要があります。

4. DNS攻撃の防止： acl プラグインを使用して内部IPレンジからのクエリのみを許可し、サーバーがDNSリフレクション攻撃（DNS Amplification）に悪用されるのを防ぎます。

まとめ

CoreDNSは、柔軟性と軽量さを求めるなら最良の選択肢です。管理はBind9よりもはるかに楽になります。本番環境に導入する前に、まずはラボ環境で試してみてください。サブネットの分割やゾーン設定で困ったことがあれば、下のコメント欄で質問してくださいね！

Share:
Tags: