モダンなDNSの構成：IIJ DNSプラットフォームサービスのスゴいところ(第1回)
2020年04月23日 木曜日
CONTENTS
はじめに
先日、「IIJ DNSプラットフォームサービス」という新たな権威DNSサービスをリリースしました。プレスリリースはこちら。
そしたら、どーまえさんから「新サービスでやってるスゴいことについて記事書いてよ、それも主なものだけかいつまんで紹介するんじゃなくて細かいところまで全部！」とリクエストされました。「え、まじで全部書くんすか？！むっちゃ多いっすよ──。」
IIJのDNSサービスはかなり頑張ってるつもりですが、うちだけじゃなく、同業他社さんや、あるいは自前でDNSサーバを構築運用している企業さんにも頑張ってもらいたいんですよね。営業の立場からすると「ぜんぶIIJに任せてくれや」となるんでしょうけれど、売り文句にマルチプロバイダとあるように、IIJ単独じゃなくて複数のDNS事業者で同じゾーンを持つことで耐障害性を高めよう、ということも今回のサービスのポイントなのです。
IIJのサーバだけでなく、IIJのサーバと連携する他社さんやお客様のサーバも強くなれば、そのぶん耐障害性は上がるのです。
ということで、せっかくぜんぶ書けと言われた機会なので、新サービスで新たに採用したことだけじゃなく以前からずっとやってたことも、お金のかからないことからむっちゃコストのかかるものまで、いろいろやってることをできるだけ書いていきます。
オンプレ運用のみなさま、どんどん真似してください。他社さんもどんどん後追いサービスを作ってください。お客さんが増えても担当営業の人事評価が上がるだけで俺の評定は変わんないし、むしろこの記事を参考にして真似してくれる人が増えた方がイニシアティブを発揮した、IIJのプレゼンスを高めたということになって俺の評定は上がるので、どんどん参考にしてください。
単発記事じゃとても収まらない分量になるので5回ぐらいにわけて書きます。
それでは第1回、DNSのシステム構成のお話から。
古典的DNSサーバの役割分担
「IIJ DNSプラットフォームサービス」について説明する前に、それ以前からあったサービスについて説明しましょう。
旧サービスは「DNSアウトソースサービス」、「DNSセカンダリサービス」といいました。過去形で書きましたがいちおう現役のサービスです(近いうちに終了します)。オンラインマニュアルでは、前者はプライマリDNSサーバとセカンダリDNSサーバの両方を、後者はセカンダリのみを提供するサービスと説明されています。
古い。古いですね。
プライマリとセカンダリで役割分担するという考え方がどうしようもなく古いのです。これはゾーン転送の主従に着目した役割分担です(※1)。が、「注目のポイントそこなの？」 外から見ればプライマリもセカンダリも区別はありません。重要なのはどの権威サーバも矛盾のない応答を返すことであり、それが担保されるのであればプライマリ/セカンダリという構成でなくてもいいはずです。
※1：まずプライマリに問い合わせて、障害などでプライマリから応答が得られない場合のみセカンダリが使われる、と勘違いされている人が稀にいますが、そのような動作はしません。
図1: プライマリ/セカンダリ構成
実際古いのです。社内資料によると、DNSアウトソース/セカンダリサービスは2000年3月にはじまったサービスだそうです。20世紀に立ち上げたサービスがいまだに動いてるのです。今となっては古くても、当時としては妥当な考え方で設計されており、20年前にサービスを設計した人を責めることはできません。もちろん20年前からずっと変わっていないわけではなく、時代にあわせて常に変化・強化しつづけていて、今でも国内事業者による権威DNSサービスでDNSアウトソースサービスに比肩しうるものは存在しないという自負はあります。
しかし、いろいろ変化は続けてきているけれど、どうしても旧サービスの改造では限界があります。そもそもサービスのラインナップが古い概念にもとづいている以上、これを修正するにはこれまでのサービスをあきらめて新しいサービスを作るしか方法がありません。だから作りました。それが IIJ DNSプラットフォームサービスです。
現代的DNSサーバの役割分担
では、今はどのように役割分担を考えるべきなのでしょうか。
モダンな権威DNSの構成では、「プライマリ」と「セカンダリ」ではなく、「ゾーン情報の管理」と「外部からのDNSクエリへの応答」で役割を分担します。
DNSクエリへの応答は外部に対するサービスであり、世界中のどこからでもアクセスできるようにしておく必要があります。一方で、ゾーン管理は権限を持った一部の人だけに限定する必要があります。とくにDNSSECの秘密鍵など決して外部に漏らしてはならない情報は、外部からアクセスされるサーバに置かずにすむならそれにこしたことはありません。
旧来の概念におけるプライマリサーバは、この両方の役割を担うものです。外部からアクセスされるDNSサーバに、外部からアクセスされてはならないゾーン管理機能が同居している。セキュリティ的によくないですね。原始的なCGIから始まったWeb上のサービスは、今では外からアクセスされる フロントエンドのWebサーバと、各種情報を管理するバックエンドのDBその他のサーバで分離するのが常識になりました。それと同じです。DNSもフロントエンドとバックエンドで役割分担しましょう。
図2: DNSの役割分担
DNSアウトソースサービスは仕様上では「プライマリとセカンダリどちらも」、セカンダリサービスは「セカンダリのみ」を提供するサービスでした。しかし、もう何年も前に(いつだったか覚えてないけど10年ぐらい前のような気がする)この役割分担を見直し、前者は「DNSサーバとゾーン管理機能どちらも」、後者は「DNSサーバのみ」を提供するサービスと定義しなおして内部構成が変更されています。
そして、新しいIIJ DNSプラットフォームサービスではこの役割分担の考え方をさらにおしすすめ、このふたつの構成要素をお客様自身でデザインできるように設計しました。ゾーン管理機能、DNSサーバどちらも提供します。しかし、それをどのように組み合わせるのかはお客様の自由です。新サービスの紹介ページにはマルチインプット・マルチアウトプットという図が掲載されています。
図3: マルチインプット・マルチアウトプット
インプットはすなわちゾーン情報管理です。いろんな方法で管理できます。WebUIから編集することも、手元のテキストエディタで編集したゾーンファイルをアップロードすることも、お客様のプライマリサーバからゾーン転送することもできます。APIでゾーン編集できる機能も開発中です提供中です。（2023/05/09 修正）
アウトプットはすなわちDNSサーバです。いろんなサーバでDNSクエリに応答することができます。IIJのサーバで応答することも、IIJと提携する海外事業者のサーバで応答することもできます。お客様自身が管理するサーバや他社ホスティングサービスなどの外部サーバで応答するよう設定することもできます。
これらの組み合わせにより、従来のDNSアウトソースサービスのようにも、DNSセカンダリサービスのようにも使うことができます。これまで対応していなかった、お客様サーバをセカンダリとして使うような構成も可能です。なんならWebUIからのゾーン編集やDNSSEC署名の機能だけを使って外からのDNSクエリには一切応答しないというゾーン管理に特化した使い方だって可能です。
なお、そういう考え方で設計してそういう内部構成になっているというだけで、この役割分担の考え方を理解しなければサービスを使えないというわけではありません。WebUI上の説明やオンラインマニュアルではあえて馴染み深い旧来のプライマリ/セカンダリという用語を使ってます。
hidden master構成
さて、今回の記事は「新サービスすげーぜ！」というだけでなく、「みんなも真似してね！」という趣旨であることを最初に説明しました。ということでみなさんもやってみましょう。
図4: hidden master構成
フロントエンドとバックエンドを分離したDNSサーバの構成図です。この箱をそのまま作ればいいだけです。
- ゾーン管理サーバは旧来のプライマリサーバとほぼ同等の設定
- ただし、外部からのクエリを受けるサーバ以外からのアクセスを制限し、DMZの内側に設置するなど、外部から見えないようにする
- SOAレコードの最初のパラメータ(mname)は本来プライマリサーバを記載するものだが、この構成では一部の例外(※2)を除いて参照されないのでてきとーな値を入れておく
- NSレコードは外部からクエリを受けるサーバだけを記載
- 外部からのクエリを受けるサーバは旧来のセカンダリサーバとまったく同じ
※2：RFC2136による動的更新(dynamic update)を利用する場合、mnameで指定されたサーバにDNS updateのクエリが送られるので、このケースにかぎりmnameはゾーン管理サーバを指定しておく必要があります。
要するに、従来のプライマリ/セカンダリ構成でセカンダリを1台増やし、プライマリにアクセス制限をかけるだけです。このゾーン管理に特化したサーバのことを、hidden masterといいます。shadow masterとか隠れプライマリとかいう呼び方をすることもあります。DNSSECを運用するならば、秘密鍵を公開サーバに置かずにすむhidden master構成にすべきですが、DNSSECを使わない場合でもメリットは大きいので、今後DNSサーバを作り替える機会があるならばこの構成を強く推奨します。
DNSプロバイダダイバーシティ
この役割分担の考え方をさらに発展させます。
DNSサーバをすべて自前で持つ必要はありません。IIJ DNSプラットフォームサービスを契約していただいても、旧サービスのDNSセカンダリサービスでもかまいません。あるいは他社の同様のサービスを使うこともできます。そして、たくさんのサービスの中からどれかひとつを選ばなければならない理由もありません。複数のサービスを併用してもまったくかまわないのです。
図5: DNSプロバイダダイバーシティ
次回の記事でも触れる予定ですが、DDoS攻撃の規模は年々拡大し、一般的な企業が持っている回線でこれを受け止めるのは今や現実的ではありません。2016年にアメリカの大手DNSホスティングサービスDynが攻撃を受けた事例のように、十分なDDoS対策をしたサービスであっても耐えきれないほどの大規模攻撃にあうこともあります。しかし、あるDNSプロバイダが障害になっても、複数の事業者のサービスを併用していれば、障害の起きていない事業者の方で名前解決は継続できます。DNSプロバイダダイバーシティという考え方です。
海外ではこのように複数のDNSプロバイダを併用する構成になっているドメインは珍しくありません。たとえば、dig ns amazon.com とか dig ns github.com とかいったコマンドを実行してみてください。NSレコードが複数の事業者にまたがっていることがわかるかと思います。日本ではまだあまり浸透していない考え方ですが、この構成を採用する国内ドメインもちらほら出てきています。
IIJ DNSプラットフォームサービスはプレミアムプランで契約すると、自動的にゾーンを海外の提携事業者に同期してこの構成になります。ラクチンですね。月額12万円ですけど。でも、高額なプレミアムプランを契約いただかなくても、自身で選定した複数のDNSプロバイダにゾーン転送するだけでこの構成になるわけですから、無理に高い方のプランを契約いただかなくても実現できます。先日の DNSOPS.JP BoF で発表された滝澤さんの資料は大いに参考になるでしょう。
つづく
ということで、第1回では権威DNSのシステム構成について説明しました。
次回は可用性を高める取り組みについて触れる予定です。
