午前2時の悪夢と、従来のDNSの限界
午前2時、電話が鳴り響きました。電話の向こうでは、ラボでK3sを動かしている10台のRaspberry Pi 4クラスターを前に、開発チームがパニックになっていました。問題は厄介なものでした。ノード数が頻繁に変わるため、静的IPを割り当てたくない。しかし、24時間ごとにDHCPでIPが再割り当てされると、Pythonスクリプトが接続できなくなってしまうのです。
最初に思いついたのは、Bind9サーバーにログインして手動でレコードを追加することでした。しかし、想像してみてください。新しい仮想マシンができるたびに起きてゾーンファイルを修正するなんて？ まっぴらごめんです。かつてトラフィックが500Mbpsに達したときにパケットロスが発生した際のデバッグが、人生で最も困難なネットワークトラブルでしたが、あれだけで十分です。社内DNSのレコードをいちいち手入力することに、これ以上労力を使いたくありませんでした。
そんな時に救世主となったのがAvahiです。このツールはmDNS（Multicast DNS）とDNS-SDの仕組みを実装しています。ネットワーク内のデバイスが自ら「私は web-server.local です、IPアドレスはこちら！」と「叫ぶ」ことができるようにします。中央のDNSサーバーを介さず、すべてが自動的に行われます。
なぜ従来の手法ではなくAvahiを選ぶのか？
コマンドを入力する前に、あの夜に私が検討した選択肢を振り返ってみましょう。
- /etc/hosts ファイル: 最も簡単ですが、メンテナンスは地獄です。あるマシンで修正しても、他のマシンには古い情報が残ったままになります。
- 集中管理型DNS (Bind9/Unbound): 大規模なProductionシステムには非常に強力です。しかし、ラボ環境やホームネットワークには大がかりすぎます。デバイスを追加するたびにレコードを再設定しなければなりません。
- Avahi (mDNS): 中央サーバーは不要です。デバイス同士がマルチキャストアドレス
224.0.0.251を介して直接通信します。インストールすればすぐに動きます。デメリットは？ 同一ネットワークセグメント（レイヤー2）内でしか動作しない点です。
クイック比較表
| 項目 | 静的Hosts | Bind9 DNS | Avahi (mDNS) |
|---|---|---|---|
| 設定 | 各マシンで手動 | 集中的だが複雑 | 100%自動 |
| 柔軟性 | 非常に低い | 普通 | 非常に高い |
| 範囲 | 全体 | 全体 | LAN内のみ |
LinuxへのAvahiのインストール
UbuntuやFedoraなどのディストリビューションでは、通常Avahiがプリインストールされています。しかし、Minimal版やServer版では容量最適化のために省かれていることがよくあります。まずは avahi-daemon パッケージをインストールする必要があります。
Ubuntu/Debianの場合：
sudo apt update
sudo apt install avahi-daemon avahi-utils -yCentOS/RHEL/AlmaLinuxの場合：
sudo dnf install avahi
sudo systemctl enable --now avahi-daemonインストール後、サービスが稼働しているか確認します：
sudo systemctl status avahi-daemon設定：.localドメインのカスタマイズ
デフォルトでは、Avahiは [hostname].local という形式でホスト名を通知します。マシンの名前が srv-web-01 であれば、別のマシンからすぐに ping srv-web-01.local で疎通確認ができます。
システム全体のホスト名に影響を与えずに、この表示名を変更したい場合は、メインの設定ファイルを編集します：
sudo nano /etc/avahi/avahi-daemon.conf[server] セクション内の host-name 行を探し、コメントアウトを解除して書き換えます：
[server]
host-name=my-cool-server
use-ipv4=yes
use-ipv6=yes変更を反映させるためにデーモンを再起動します：
sudo systemctl restart avahi-daemonサービスの通知 (Service Advertising)
これが最も「価値のある」機能です。例えば、開発チームがポート8080でWebサーバーを動かしているとします。他のマシンがIPアドレスを尋ねることなく、そのサーバーを自動的に見つけられるようにしたい場合、Avahiでは /etc/avahi/services/ ディレクトリ内にサービス定義ファイルを作成することでこれを実現できます。
HTTPサービス用の新しいファイルを作成してみましょう：
sudo nano /etc/avahi/services/http-8080.service以下のXML内容を貼り付けます：
<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name>開発チームのWebサービス</name>
<service>
<type>_http._tcp</type>
<port>8080</port>
</service>
</service-group>ファイルを保存すると、Avahiは自動的にスキャンしてこのサービスを通知します。デーモンの再起動は不要です。
確認とデバッグ：誰がオンラインか？
ネットワーク内でどのようなサービスが稼働しているかを確認するには、通常 avahi-browse コマンドを使用します。これは、開発チームのPiが「オンライン」になったかどうかを確認する最も速い方法です。
稼働中のすべてのサービスをスキャンする：
avahi-browse -all -ignore-local -resolve_http._tcp という行とマシン名が表示されれば成功です。もしリストが空の場合は、ファイアウォールを確認してください。
ファイアウォールに関する重要な注意点
Avahiが反応しない最も一般的な原因は、ファイアウォールがマルチキャストポートをブロックしていることです。Avahiは UDP 5353 ポートを使用します。Ubuntuで ufw を使用している場合は、すぐに許可設定を行う必要があります：
sudo ufw allow 5353/udpCentOS/RHELの firewalld の場合：
sudo firewall-cmd --permanent --add-service=mdns
sudo firewall-cmd --reload結論
あの日のラボクラスターにAvahiを導入した後、私の電話が鳴ることはなくなりました。開発チームは自由にマシンを追加したり削除したりできるようになりました。彼らは適切なホスト名を設定し、末尾に .local をつけてアクセスするだけで済むようになったのです。
ただし、数千台のデバイスがあるような大規模なProductionシステムでAvahiを乱用しないでください。あまりに多くのデバイスが常にパケットを通知し続けると、マルチキャストトラフィックによってネットワークが混雑する可能性があります。しかし、オフィス規模やラボ環境であれば、Avahiは無意味な夜勤からあなたを解放してくれる真に役立つツールです。もしLAN内でKVM仮想マシンやコンテナを管理しているなら、今すぐAvahiを試してみてください。
