DNS における Master/Slave vs Primary/Secondary の現状（2020/06）
BLM の関係でコンピュータ業界の Master / Slave という言葉遣いにもメスが入ろうとしているいま、 DNS ではどうなっているんだっけ、というのがふと気になった。
というのも mattn さんの blacklist/whitelist master/slave に関する情報集め を見たから。あとコメントもしたから。
で、調べて行ったところ、ひとことで言えば既に Primary / Secondary になってるんだけど、そもそもこの用語自体そんな使わないよな、と思ったのだけど、そのあたりを解説するのは元記事の関心ごとと全く違うってことで、改めて自分のブログの記事にしてみたというわけ。
DNS は趣味でしかないので、ツッコミ大歓迎です。
Primary/Secondary が正しい用語です
用語に困ったら RFC 8499 (Jan, 2019) が正しい参照先。こう書いてある：
Slave server: See "Secondary server".
Secondary server: "An authoritative server which uses zone transfer
to retrieve the zone." (Quoted from [RFC1996], Section 2.1)
Secondary servers are also discussed in [RFC1034]. [RFC2182]
describes secondary servers in more detail. Although early DNS
RFCs such as [RFC1996] referred to this as a "slave", the current
common usage has shifted to calling it a "secondary".
Master server: See "Primary server".
Primary server: "Any authoritative server configured to be the
source of zone transfer for one or more [secondary] servers."
(Quoted from [RFC1996], Section 2.1) Or, more specifically,
[RFC2136] calls it "an authoritative server configured to be the
source of AXFR or IXFR data for one or more [secondary] servers".
Primary servers are also discussed in [RFC1034]. Although early
DNS RFCs such as [RFC1996] referred to this as a "master", the
current common usage has shifted to "primary".
Current common usage has shifted to "primary/secondary". こちらを使うことが推奨されている。 これ自体は以前からそうだったけど、 2015 年に RFC 7719 （8849 の前身）が出るまではどちらも併用されてしまっていたのだろう。 とはいえ用語としては Primary / Secondary の方が推奨はされていた記憶はある。歴史が気になってきた。
そもそも Primary / Secondary, Master / Slave とはどこから来たか
もともと Paul Mockapetris が RFC 1034, RFC 1035 （November, 1987）やその前身である RFC 882, RFC 883 （November, 1983）を書いたときの用語は Primary server / Secondary server だった。この時点で Zone transfer の機能は DNS のプロトコルにあった。
続いて BIND の開発をしていた Paul Vixie が 1996 年に RFC 1996（August, 1996）を書いた。これは DNS NOTIFY の機能を提供するための OPCODE NOTIFY を定義したもの。ここで初めて Master Slave という言葉が明に出てくる。 NOTIFY は Primary server が Secondary server を叩いて更新を知らせる仕組みなので、このプロトコルのうえで master / slave と言いたくなる気持ちはわからんでもない。サーバ機能を見るときとプロトコルを見るときとで若干インピーダンスが違うよね。
その翌年 1997 年 5 月に BIND 8 がリリースされる。 Zone transfer の設定における master slave の設定項目は BIND 8 から出てきたとの噂（要出典）。当時の BIND の開発責任者には Paul Vixie がいる（ここは事実）ので、自分の書いた RFC を参照して用語を決めるのは自然なことだったと推察される（ここは曖昧な記述）。
なお、同年 7 月に出た RFC 2182 では Secondary DNS サーバの運用方法について書いているが、ここでの用語は Primary / Secondary 推しだ。 Master / Slave という言い方が存在することにも触れているが。
Primary Server An authoritative server for which the zone
information is locally configured. Sometimes
known as a Master server.
Secondary Server An authoritative server that obtains
information about a zone from a Primary Server
via a zone transfer mechanism. Sometimes
known as a Slave Server.
その後長い混乱の時期が続いたあと、 2015 年に RFC 7719 として正式に Primary server / Secondary server が master / slave を override することになった。
BIND 以外のサーバでは？
とは言っても、 DNS は BIND そのもののことではなく、他にいろんなサーバ実装が存在している。他ではどうなっているのかみてみよう。
NSD, Unbound (NLnet Labs)
NLnet Labs の DNS 実装、 NSD / Unbound では Primary / Secondary という言い方をしている。また、設定ファイル内にはゾーン転送を示す xfr しかない。つまり、設定ファイルの中に primary / secondary や master / slave という言葉が入り込まない。実に素晴らしい。
PowerDNS
PowerDNS は BIND こそ DNS と思っているようなところがある（超偏見、多分そんなことない）ので、 Master / Slave という用語をバリバリ使っている。 ゾーンファイルも BIND 形式だしなあ。
↑ブクマにてご指摘いただきました。ゾーンファイルは RFC 1035 の MASTER FILE として定義されているので、これに従っていること自体を BIND と結びつけるのは微妙であるとのこと、たしかにですね
djbdns
DJB 大先生の書いた DNS サーバ。脆弱性が出ないことで有名。 edns0 に対応してないくらい古いのでもう使うべきではないけれども。
DJB 大先生は master / slave の表現を取っているが、 primary / secondary という呼び方にも言及している。が、そもそも rsync + ssh の方がよっぽどいいのにわざわざ脆弱性の多い zone transfer 機能を使うなんてアホかとズタボロにけなしている。今なら git で同期することも簡単だし、さすが大先生、先見の明がありすぎる。
https://cr.yp.to/djbdns/tcp.html
けなしつつ、一応 AXFR するための仕組みは用意してくれるあたりさすが大先生。
https://cr.yp.to/djbdns/axfrdns.html
Bundy
ISC が BIND9 の実装をつらいと考え、次世代 BIND10 としてモジュール型の DNS サーバを 2009 年に開発開始した。モジュール型というか多プロセスシステムというと Postfix を思わせる。
しかしこの BIND10, 最終的には BIND9 をリファクタリングした方がマシという結論になってしまい、2014年に Bundy プロジェクトとして OSS になった。その後はほぼ放置されていて、野性味溢れる草が生える気持ちである。
さて Bundy ではゾーン転送は基本的に primary / secondary である。ただし設定の中には secondary_zones master と、用語が混在しているようで、うーん……。
Windows DNS Server
正直詳しくないのでわかっていないけれど、 FAQ を見る限りでは Primary / Secondary の方の用語を使っている模様。
いまどき DNS の Primary / Secondary
さて、そんなこんなでゾーン転送に関わる Primary / Secondary VS Master / Slave 論争を見てきた。が、さまざまな技術が発展してきた現代においてゾーン転送はいまでも主流なんだろうか。
まあ多分メインストリームの一つではあるんだろうけど、とはいえもっと違う構成がどんどん出てきているのも事実。
- 隠れマスタ構成
- OctoDNS 等、ソフトウェア的同期
- Google Public DNS の事例
隠れマスタ (hidden master) 構成
書いて名の通り、 master (primary) サーバは公開せずに、その master サーバから xfr を受けるサーバだけをインターネット上に公開する方法。 xfr 周りは実装が複雑なため脆弱性も多く、ここをインターネットに晒さないだけで守れる部分が多いということ、 master が多少死んでも顧客影響がないので運用しやすいこと、インターネット公開するサーバ実装をたとえば NSD と PowerDNS Authoritative にするなどベンダ冗長をとりやすいということなど、何かと利点が多い。
下の記事がこのあたりをわかりやすくまとめている。
このほかの記事としては、以下のものも参考になる。
- https://dnsops.jp/event/20130719/20130719-dns-design-yamaguchi-2.pdf
- 私は多分この発表で知った気がする。 P26, 27 を参照
- DNSベストプラクティスとは「隠す」そして「重ねる」 − ＠IT
- 2007 年にもう知られた概念だったのか。ここでは「ヒドゥンプライマリ」という言い方をしている
で、隠れマスタ構成になってくると、もう primary サーバはユーザからは見えないわけで、用語としての primary / secondary に意味あるかなあ？となってくる。
OctoDNS 等、ソフトウェア的同期
DJB も言っていたように、ゾーン転送 xfr はあくまでサーバ間同期のひとつの手段でしかない。今であれば DNS サーバを autoscaling で増やすようなことも可能なわけで、ソフトウェアやサービスを使った同期というのは現実的だ。
また、そもそもゾーンの更新はデプロイであると考えると、 Web 系のデプロイツールや構成管理ツールが便利に使える。つまり、 Chef, Ansible, Puppet のような構成管理ツールで外からサーバを特定の状態にしたり、 Capistrano や Fabric のようなデプロイツールで最新の設定ファイルを配ったりできる。さらには、 consul/serf や AWS SSM のようなツールでもって、同期イベントを発行するようなパターンも考えられる（イベントを受けた各ホストでは git pull でも docker pull でもすればいい）。ゾーンファイルを同期するなんて目的のために、わざわざ xfr する必要はない。
そんな状況下、 OctoDNS を使うという手が提示された。これがおもしろい。
https://dnsops.jp/bof/20191128/octodns-takizawa.pdf
OctoDNS は、各種 DNS サービスへレコードを同期させるだけのソフトウェア。 AWS, GCP, Azure のようなクラウドだけではなく、 DynDNS, Akamai, Cloudflare, DigitalOcean などにも対応しているのが素晴らしい。設定ファイルとゾーンファイルがあれば、あとはそれを自動的に対象プロバイダに同期させてくれる。
同期、というのがポイントで、レコードを追加するだけではなくて削除もこのコマンド一発である。なので野性味溢れる状態のレコードを持っている場合は対応が難しい。
一方で、単一のゾーンファイルを持っていれば、そのゾーンファイルを複数の DNS プロバイダに展開することができる、というのが素晴らしく強い。いまどき単一の DNS プロバイダでも十分すぎるほど冗長化されていたりするけれど、そのプロバイダの根元がやられることっていうのは今でも時々はあるので、まあ、要件によるしクライアント側の実装にもよるんだけど、プロバイダ冗長をしておきたいような人には便利このうえないツールとなるかもしれない。
また、これらの DNS プロバイダはゾーンのマスタ情報として利用することもできる。つまり設定ファイル一発でゾーンを別サービスに丸コピできる。しかも SOA と NS は更新されないので引越しの調整を手でできる。おっそろしく便利。もうここにサポートされていないサービスは使いたくないお……
Google Public DNS の構造
Google Public DNS は Full Resolver なのでそもそも Authoritative Server 側のゾーン転送の仕組みとは全然別の話ではあるんだけど、大規模な DNS サービスの中で既存の DNS の仕組みを使っていない（あるいは大幅なハックが行われている）事例として紹介したい。
世界中に地域分散させたフルリゾルバが二段階のキャッシュをしていると。とはいえキャッシュだけであれば forwarder を設定すれば BIND でも二段階にできる。 ここで Google Public DNS の性能に関する解説を見てみると、 Google 側で明らかに「何か」をしているのが垣間見える。
曰く、「一次受けサーバはローカルにもっともよく使われるキャッシュだけ保持する。二次受けクラスタではその他全てのクエリを受け、キャッシュを保持したサーバへ渡るよういいかんじにロードバランシングする」。二次受け側で FQDN 別のロードバランシングをしているのも実装どころだけど、一次受けサーバで DoS 対策をしてある（Bogus なクエリの Negative Cache だけでキャッシュが埋め尽くされない）仕組みの方も結構なもの。いずれにせよ、全体として明らかにソフトウェア的に対策をしている。
いまどきの DNS 構成
そんなわけで、そもそも今時の DNS 構成では master だ primary だということを考えるシーンは少ない。それこそ DNS サービスプロバイダ以外はほとんど使うことはないだろう、と言いたいところだけどまあ情シスは必要なことも多いか。
さて、だいぶ話がずれてしまった。
元々は DNS において Master / Slave, あるいは Primary / Secondary とはどういう風に言葉が使われてきたか・これから使われていくか、という話だった。だらだら書きたいことを書いてしまったが、最後に結論を述べて終わりにしたいと思う。
結論
DNS においては Master / Slave ではなく Primary / Secondary というのが正式な言葉遣いであると 2015 年に定められた（2019 年に更新されてもいる）。今後はこれを使うのが正しい用法である。
ただ、歴史的経緯により未だに BIND9 等のサーバ実装には設定に master / slave という項目が残っている。一方、 BIND 以外の DNS サーバ実装では、新しいものでは primary / secondary を使う傾向にある。
また、ゾーン転送の仕組みがそもそも必要ではないシーンも増えてきている。完全になくなることはないだろうが、今後 Primary / Secondary という言葉を使う機会自体が減るのかもしれない。
いずれにせよ、 DNS が未来に向かい、 Master / Slave という用語が完全に過去のものとなってくれることを願う。
