本記事では，DNS master resolverと，Bind9 secondary resolver間で，Catalog Zone (RFC 9432) を利用したZone自動同期の動作を検証する． ## Catalog Zoneとは **Catalog Zone** (RFC 9432) は，DNSゾーンのメタデータを管理するための特別なゾーンのこと．従来，セカンダリDNSサーバーに新しいゾーンを追加するには `named.conf` を手動で編集し，サービスをリロードする必要がある． Catalog Zoneを利用すると： - **設定ファイルの編集不要**：セカンダリの `named.conf` を変更せずにゾーンを追加/削除が可能 - **自動同期**：マスターでCatalog Zoneを更新するだけで，セカンダリが自動的に追従 - **スケーラビリティ**：大量のゾーンを管理する環境で特に有効 ### Catalog Zoneの構造 ```plain text ; catalog.internal ゾーンの内容 $ORIGIN catalog.internal. @ SOA ns1.catalog.internal. hostmaster.catalog.internal. ( 2024010101 3600 600 86400 300 ) NS ns1.catalog.internal. ns1 A 10.0.2.10 version TXT "2" ; Catalog Zone バージョン (RFC 9432) ; メンバーゾーンの登録 (PTRレコード) $ORIGIN zones.catalog.internal. example-com PTR example.com. ; example.com をメンバーとして登録 team-jj-com PTR team-jj.com. ; team-jj.com をメンバーとして登録 ``` **Catalog Zoneの特徴** - `.zones.` の形式でPTRレコードを作成 - PTRレコードの値がメンバーゾーン名 ### ゾーン同期の全体フロー ```plain text ┌─────────────────────────────────────────────────────────────────────────────┐ │ ゾーン同期フロー (時系列) │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ Master Secondary │ │ │ │ │ │ │ [1] example.com ゾーン作成 │ │ │ │ (メモリ上にレコード保持) │ │ │ │ │ │ │ │ [2] catalog.internal に PTR 追加 │ │ │ │ example-com.zones.catalog.internal. PTR ... │ │ │ │ │ │ │ │ [3] NOTIFY 送信 │ │ │ │─────────────────────────────────────────────────────>│ │ │ │ (catalog.internal の更新を通知) │ │ │ │ │ │ │ │ [4] AXFR リクエスト │ │ │ │<─────────────────────────────────────────────────────│ │ │ │ (catalog.internal のゾーン転送要求) │ │ │ │ │ │ │ │ [4] AXFR レスポンス │ │ │ │─────────────────────────────────────────────────────>│ │ │ │ (catalog.internal の全レコード送信) │ │ │ │ │ │ │ │ [5] Catalog Zone 解析 │ │ │ PTR レコードから │ │ │ example.com を発見 │ │ │ │ │ │ │ [6] AXFR リクエスト (example.com) │ │ │ │<─────────────────────────────────────────────────────│ │ │ │ │ │ │ │ [6] AXFR レスポンス │ │ │ │─────────────────────────────────────────────────────>│ │ │ │ (example.com の全レコード送信) │ │ │ │ │ │ │ │ [7] ゾーンファイル保存 │ │ │ 名前解決可能に！ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` ### AXFRとは DNSのZone転送手法の一種で，都度Zone内の全ての情報を同期する仕組みのこと． ### AXFR通信の流れ ```plain text Secondary Master │ │ │──── TCP接続 (ポート53) ─────────────────>│ │ │ │──── AXFR Request ───────────────────────>│ │ QNAME: catalog.internal. │ │ QTYPE: AXFR (252) │ │ │ │<─── AXFR Response (1) ───────────────────│ │ SOA (開始) │ │ │ │<─── AXFR Response (2) ───────────────────│ │ NS, A, TXT, PTR レコード │ │ │ │<─── AXFR Response (3) ───────────────────│ │ SOA (終了マーカー) │ │ │ │──── TCP切断 ────────────────────────────>│ ``` ## Catalog Zone動作検証動作検証にあたって，以下のような構成を考える． ### アーキテクチャ概要 ```plain text ┌─────────────────────────────────────────────────────────────────────┐ │ 検証環境構成 │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────────────┐ ┌──────────────────────┐ │ │ │ Go Master DNS │ NOTIFY │ BIND9 Secondary │ │ │ │ (10.0.2.10:53) │─────────>│ (10.0.2.11:53) │ │ │ │ │ │ │ │ │ │ ・catalog.internal. │<─────────│ catalog-zones { │ │ │ │ ・example.com. │ AXFR │ zone "catalog..." │ │ │ │ ・team-jj.com. │ │ } │ │ │ └──────────────────────┘ └──────────────────────┘ │ │ │ │ │ │ │ Docker Network │ │ │ └──────────── 10.0.2.0/24 ─────────┘ │ │ │ │ │ ┌────┴────┐ │ │ │ Host │ │ │ │ :5353 │ (master) │ │ │ :5354 │ (secondary) │ │ └─────────┘ │ └─────────────────────────────────────────────────────────────────────┘ ``` - 実際に作成したRepo：https://github.com/Zu-rin/DNS-playground ### Step 1: マスターでのゾーン作成 Go製マスターサーバーでは，起動時にゾーンデータをメモリ上に構築します． - main.go でのゾーン定義 ```go // example.com zone exampleZone := &Zone{ Name: "example.com.", Serial: 2024010101, Records: []dns.RR{ s.newSOA("example.com.", 2024010101), s.newNS("example.com.", "ns1.example.com."), s.newA("ns1.example.com.", "10.0.2.10"), s.newA("www.example.com.", "192.168.1.100"), s.newA("mail.example.com.", "192.168.1.101"), s.newMX("example.com.", 10, "mail.example.com."), s.newTXT("example.com.", "v=spf1 mx -all"), }, } s.zones["example.com."] = exampleZone ``` - 確認コマンド ```bash # マスターに直接クエリして，ゾーンが存在することを確認 $ dig @localhost -p 5353 example.com SOA +short ns1.example.com. hostmaster.example.com. 2024010101 3600 600 86400 300 $ dig @localhost -p 5353 www.example.com A +short 192.168.1.100 ``` ### Step 2: Catalog Zoneへのメンバー登録 `example.com` をセカンダリに自動同期させるため，Catalog Zoneにメンバーとして登録します． - main.go でのCatalog Zone定義 ```go // Catalog Zone (RFC 9432) catalogZone := &Zone{ Name: "catalog.internal.", Serial: 2024010101, Records: []dns.RR{ s.newSOA("catalog.internal.", 2024010101), s.newNS("catalog.internal.", "ns1.catalog.internal."), s.newA("ns1.catalog.internal.", "10.0.2.10"), // Catalog zone version (RFC 9432 必須) s.newTXT("version.catalog.internal.", "2"), // メンバーゾーン登録: PTRレコードで指定 s.newPTR("example-com.zones.catalog.internal.", "example.com."), s.newPTR("team-jj-com.zones.catalog.internal.", "team-jj.com."), }, } s.zones["catalog.internal."] = catalogZone ``` - PTRレコードの命名規則 ```plain text .zones.. PTR . ``` | 要素 | 説明 | 例 | | --- | --- | --- | | `unique-id` | 任意の一意識別子 | `example-com` | | `zones` | 固定サブドメイン | `zones` | | `catalog-zone-name` | Catalog Zone名 | `catalog.internal.` | | `member-zone-name` | 登録するゾーン名 | `example.com.` | 確認コマンド ```bash # Catalog Zoneのメンバー一覧を確認 $ dig @localhost -p 5353 example-com.zones.catalog.internal PTR +short example.com. $ dig @localhost -p 5353 team-jj-com.zones.catalog.internal PTR +short team-jj.com. ``` ### Step 3: NOTIFYによる変更通知マスターはゾーン更新時にセカンダリへNOTIFYメッセージを送信し，変更を通知します． - main.go でのNOTIFY実装 ```go // sendNotifyForZone sends NOTIFY for a specific zone func (s *DNSServer) sendNotifyForZone(zoneName string) { m := new(dns.Msg) m.SetNotify(zoneName) // NOTIFYメッセージを構築 c := new(dns.Client) c.Net = "udp" addr := s.secondaryIP + ":53" // 10.0.2.11:53 reply, _, err := c.Exchange(m, addr) if err != nil { log.Printf("NOTIFY to %s for %s failed: %v", addr, zoneName, err) return } log.Printf("NOTIFY sent to %s for %s, response: %s", addr, zoneName, dns.RcodeToString[reply.Rcode]) } ``` - NOTIFYパケット構造 ```plain text +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | メッセージID +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| Z | RCODE | QR=0, Opcode=4 (NOTIFY) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | 1 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | catalog.internal. SOA | Question Section +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ ``` - マスターログでの確認 ```bash $ docker compose logs master | grep NOTIFY dns-master | 2026/01/29 06:44:15 NOTIFY sent to 10.0.2.11:53 for catalog.internal., response: NOERROR ``` ### Step 4: セカンダリでのCatalog Zone取得 (AXFR) セカンダリはNOTIFYを受信すると，マスターにAXFR (ゾーン転送) を要求します． - BIND9 named.conf.local の設定 ```plain text zone "catalog.internal" { type secondary; // セカンダリとして動作 primaries { 10.0.2.10; }; // マスターのIPアドレス file "/var/cache/bind/catalog.internal.db"; allow-transfer { none; }; }; ``` - main.go でのAXFR実装 ```go func (s *DNSServer) handleAXFR(w dns.ResponseWriter, r *dns.Msg) { zoneName := strings.ToLower(r.Question[0].Name) zone, exists := s.zones[zoneName] // SOAを取得 var soa *dns.SOA for _, rr := range zone.Records { if rr.Header().Rrtype == dns.TypeSOA { soa = rr.(*dns.SOA) break } } ch := make(chan *dns.Envelope) tr := new(dns.Transfer) go func() { // 1. SOAで開始 ch <- &dns.Envelope{RR: []dns.RR{soa}} // 2. 全レコードを送信 var records []dns.RR for _, rr := range zone.Records { if rr.Header().Rrtype != dns.TypeSOA { records = append(records, rr) } } ch <- &dns.Envelope{RR: records} // 3. SOAで終了 ch <- &dns.Envelope{RR: []dns.RR{soa}} close(ch) }() tr.Out(w, r, ch) } ``` 確認コマンド ```bash # 手動でAXFRを実行してゾーン転送を確認 $ dig @localhost -p 5353 catalog.internal AXFR ; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> @localhost -p 5353 catalog.internal AXFR ;; QUESTION SECTION: ;catalog.internal. IN AXFR ;; ANSWER SECTION: catalog.internal. 3600 IN SOA ns1.catalog.internal. hostmaster.catalog.internal. 2024010101 3600 600 86400 300 catalog.internal. 3600 IN NS ns1.catalog.internal. ns1.catalog.internal. 300 IN A 10.0.2.10 version.catalog.internal. 300 IN TXT "2" example-com.zones.catalog.internal. 3600 IN PTR example.com. team-jj-com.zones.catalog.internal. 3600 IN PTR team-jj.com. catalog.internal. 3600 IN SOA ns1.catalog.internal. hostmaster.catalog.internal. 2024010101 3600 600 86400 300 ``` 正常にZoneの情報が送信されることがわかる． ### Step 5: セカンダリでのメンバーゾーン自動登録 BIND9はCatalog Zoneを解析し，PTRレコードから自動的にメンバーゾーンを登録します． - BIND9 named.conf.options の設定 ```plain text options { // ... // Catalog Zone 自動登録設定 catalog-zones { zone "catalog.internal" default-primaries { 10.0.2.10; } // メンバーゾーンのマスター in-memory no // ディスクに保存 zone-directory "/var/cache/bind"; // ゾーンファイル保存先 }; }; ``` **BIND9の内部処理** 1. `catalog.internal` のゾーンデータを受信 1. `.zones.catalog.internal.` のPTRレコードを検索 1. 各PTRレコードの値（例: `example.com.`）をメンバーゾーンとして登録 1. `default-primaries` で指定されたマスターへAXFRを要求セカンダリログでの確認 ```bash $ docker compose logs secondary | grep catz dns-secondary | 29-Jan-2026 06:56:06.882 catz: updating catalog zone 'catalog.internal' with serial 2024010101 dns-secondary | 29-Jan-2026 06:56:06.882 catz: adding zone 'example.com' from catalog 'catalog.internal' - success dns-secondary | 29-Jan-2026 06:56:06.882 catz: adding zone 'team-jj.com' from catalog 'catalog.internal' - success dns-secondary | 29-Jan-2026 06:56:06.886 catz: catalog.internal: reload done: success ``` `catz: adding zone 'example.com'` のログが，zone `example.com.` の自動登録に成功したことを示す． ### Step 6: メンバーゾーンのAXFR取得 Catalog Zoneによって自動登録された `example.com` ゾーンについて，BIND9はマスターへAXFRを要求します．セカンダリログでの確認 ```bash $ docker compose logs secondary | grep "example.com" dns-secondary | 29-Jan-2026 06:56:07.372 zone example.com/IN: Transfer started. dns-secondary | 29-Jan-2026 06:56:07.372 transfer of 'example.com/IN' from 10.0.2.10#53: connected using 10.0.2.10#53 dns-secondary | 29-Jan-2026 06:56:07.372 zone example.com/IN: transferred serial 2024010101 dns-secondary | 29-Jan-2026 06:56:07.372 transfer of 'example.com/IN' from 10.0.2.10#53: Transfer status: success dns-secondary | 29-Jan-2026 06:56:07.372 transfer of 'example.com/IN' from 10.0.2.10#53: Transfer completed: 3 messages, 8 records, 470 bytes, 0.001 secs (470000 bytes/sec) (serial 2024010101) ``` **生成されるゾーンファイル** Catalog Zone経由で登録されたゾーンは，特別な命名規則でファイルが作成されます． ```bash $ ls -la ./secondary/zones/ -rw-r--r-- 1 bind bind 499 Jan 29 16:00 catalog.internal.db -rw-r--r-- 1 bind bind 440 Jan 29 16:00 __catz___default_catalog.internal_example.com.db -rw-r--r-- 1 bind bind 390 Jan 29 16:00 __catz___default_catalog.internal_team-jj.com.db ``` **ファイル名の形式：**`__catz____.db` ゾーンファイルの内容 ```bash $ cat ./secondary/zones/__catz___default_catalog.internal_example.com.db $ORIGIN . $TTL 3600 ; 1 hour example.com IN SOA ns1.example.com. hostmaster.example.com. ( 2024010101 ; serial 3600 ; refresh (1 hour) 600 ; retry (10 minutes) 86400 ; expire (1 day) 300 ; minimum (5 minutes) ) NS ns1.example.com. MX 10 mail.example.com. $TTL 300 ; 5 minutes TXT "v=spf1 mx -all" $ORIGIN example.com. mail A 192.168.1.101 ns1 A 10.0.2.10 www A 192.168.1.100 ``` ### Step 7: セカンダリでの名前解決ゾーン転送が完了すると，セカンダリでも名前解決が可能になります．確認コマンド ```bash # セカンダリ (ポート5354) に対してクエリ $ dig @localhost -p 5354 www.example.com A +short 192.168.1.100 $ dig @localhost -p 5354 mail.example.com A +short 192.168.1.101 $ dig @localhost -p 5354 example.com MX +short 10 mail.example.com. $ dig @localhost -p 5354 example.com TXT +short "v=spf1 mx -all" ``` - マスターとセカンダリの比較 ```bash # マスター (ポート5353) $ dig @localhost -p 5353 www.example.com A +short 192.168.1.100 # セカンダリ (ポート5354) $ dig @localhost -p 5354 www.example.com A +short 192.168.1.100 # 同じ結果が返る = 同期成功！ ``` ## まとめ ### 同期フローの要点 | Step | 場所 | 処理内容 | | --- | --- | --- | | 1 | Master | ゾーンデータをメモリに保持 | | 2 | Master | Catalog ZoneにPTRレコードでメンバー登録 | | 3 | Master→Secondary | NOTIFY送信 | | 4 | Secondary←Master | Catalog Zone AXFR取得 | | 5 | Secondary | PTRレコード解析，メンバーゾーン自動登録 | | 6 | Secondary←Master | メンバーゾーン AXFR取得 | | 7 | Secondary | 名前解決可能に | ### Catalog Zoneのメリット 1. **運用効率化：** `named.conf` の手動編集が不要！ 1. **一元管理：** マスターでCatalog Zoneを更新するだけ 1. **スケーラビリティ：** 大量のゾーン管理に対応 **設定ファイル一覧** | ファイル | 役割 | | --- | --- | | `master/main.go` | ゾーン定義，AXFR/NOTIFY実装 | | `secondary/config/named.conf.options` | `catalog-zones` 設定 | | `secondary/config/named.conf.local` | Catalog Zoneのセカンダリ定義 | | `docker-compose.yaml` | コンテナオーケストレーション | ----- ## 参考資料 - [RFC 9432 - DNS Catalog Zones](https://datatracker.ietf.org/doc/html/rfc9432) - [BIND 9 Administrator Reference Manual - Catalog Zones](https://bind9.readthedocs.io/en/latest/chapter6.html#catalog-zones) - [miekg/dns - Go DNS library](https://github.com/miekg/dns) - https://github.com/Zu-rin/DNS-playground