小回りのきく「DNSホスティングサービス」のためにがんばったこと：IIJ DNSプラットフォームサービスのスゴいところ(第4回)

はじめに

IIJ DNSプラットフォームサービスのスゴいところを紹介するシリーズの第4回です。バックナンバーはこちら。

この後もう1回ありますが、そっちではサービスのことはほとんど触れない予定なので、実質的にはこれが最終回になります。
今回はここまでの話で出てこなかった細かい機能について説明します。

ANAME

最近ではサーバを自前で運用するケースはむしろ少なくなり、CDN事業者やクラウド事業者のサービスを利用する機会が多くなっています。こういったCDNやクラウドを利用する場合、事業者側の設備構成変更などに素早く追従するため、IPアドレス(A/AAAAレコード)ではなくホスト名(CNAME)でDNSに登録してくれと求められるケースがほとんどだと思います。

しかし、CNAME以外のリソースタイプがすでに存在している名前に対して、CNAMEを設定することはできません。そして、どんなゾーンでも頂点(ゾーン名と同名のレコード)にはかならずSOAレコードとNSレコードが存在しています。よって、ゾーン頂点にCNAMEは書けません。これはDNSそのものの仕様で決まっていることなので、IIJがいくらがんばってもこれを変えることはできません。

$ORIGIN example.com.
@       IN   SOA     ...
        IN   NS      ...
        IN   CNAME   hoge.cdn-provider.example.    ; 同名でSOAとNSが存在するので不可
www     IN   CNAME   fuga.cdn-provider.example.    ; CNAME以外の名前が存在しないので可

とはいえ、ゾーン頂点に別サーバへの参照をホスト名で記述できると便利なのは事実です。便利なので、いくつかのDNSホスティング事業者ではそういった機能をALIASとかANAMEとかCNAME Flatteningとかの名前で提供しています。はい、IIJ DNSプラットフォームサービスでも実装しました。

CDN屋さんやクラウド屋さんから「この名前をCNAMEで設定してね」と言われた場合、ゾーン頂点では、かわりにANAMEとして記述してください。ANAMEは内部で名前解決され、外からはホスト名ではなくIPアドレス(A/AAAAレコード)として見えるようになります。

$ORIGIN example.com.
@       IN   SOA     ...
        IN   NS      ...
        IN   ANAME   hoge.cdn-provider.example.    ; ホスト名で書けるよ！

実は、IIJ DNSプラットフォームサービスの前身のDNSアウトソースサービスでも同様の機能をAPEXという名前で提供していましたが、こちらはAPEXを設定したそのときのIPアドレスがずっと保持され、IPアドレスが変更された場合には、手動で、あるいはAPIを叩いて更新する必要がありました。IIJ DNSプラットフォームサービスのANAMEは定期的に名前解決をおこなって、IPアドレスが変わっていたら手動更新しなくても自動で追従するようになりました。お客様の方でIPアドレス変更を監視しなくてもよくなり、CNAMEと変わらない使い勝手になっています。

ただし、CDN事業者がDNSの問い合わせ元IPアドレスによって応答を変えるような仕組み(GeoDNS)を採用していても、ANAMEにGeoDNSはなく、どこから問い合わせを受けても同じ応答を返します。これに関してはどうしようもないのであきらめてください。

さよならANY

DNSにはAとかMXとかTXTとかいろんなレコードタイプがあり、通常はどのタイプの情報が欲しいのか指定して問い合わせをおこないます。が、「とりあえず全部よこせ」という問い合わせもできます。RFC1034/1035では”*”と定義されていますが、一般的にANYと呼ばれます。

「とりあえず全部よこせ」という問い合わせに、サーバがほんとに全部返すと、場合によっては応答サイズがかなり大きくなります。問い合わせサイズは小さいのに応答が大きくなることを利用するのがDNS ampで、増幅比が大きいとDDoS攻撃の踏み台として利用されやすくなります。
そんなわけで、Cloudflareは呼びかけました。「ANYにさよならと言おう」。IIJはその呼びかけに答えます。「さよならANY」。

RFC8482が標準化され、ANYの問い合わせにサイズが小さくなるような特別な応答が認められるようになりました。IIJ DNSプラットフォームサービスはこれを実装し、ANYの問い合わせを受けても大きな応答を返しません。また、第3回で説明したとおり、楕円曲線暗号の採用でDNSSECの署名サイズも小さくなっており、ANY以外の問い合わせでもそれほど大きな応答を返さないようになっています。

ANYの応答サイズ削減は比較的新しめのバージョンのDNS実装であればたいてい対応しています。BINDならminimal-any、Knotはdisable-anyという項目で設定できるので、オンプレ運用の方は試してみてください。NSDは最近のバージョンならとくに設定しなくてもデフォルトでANYに大きな応答を返さないようになっています。

qmailとANY

ANYの話が出てきたので、ついでに関連する話をちょっとだけ(IIJ DNSプラットフォームサービスとは関係ありません)。

DNSの仕様にANYは含まれますが、通常はアプリケーションがANYを問い合わせることはありません。しかし、ANYを問い合わせる数少ないものとして、qmailがあります。

qmailがANYを問い合わせるのは特定のバグあり実装に対するワークアラウンドなのですが、qmailが開発された1990年代ならともかく、今はそのようなバギーな実装は動いておらず、もはやANYを問い合わせる理由は完全に失われています。世の中はANYを使わない方向に動いており、理由もなくいまだに使い続けるのは時代に逆行してると言わざるを得ない状況です。使うなとは言いませんが、90年代のソフトウェアをいまだに使い続けるのであれば、時代に合わせた修正を適宜おこなっていただくようお願いします。

ANYを使うワークアラウンド適用前の本来の動作に戻すパッチはこちらからどうぞ。これとは別に、512バイト以上のDNS応答を扱えない不具合に対処するパッチの適用もしてください。

なお、qmailがANYを問い合わせる先はキャッシュDNSサーバであり権威サーバではないので、権威サーバであるIIJ DNSプラットフォームサービスのRFC8482対応でqmailが影響を受けることはありません。

履歴管理

DNSをオンプレ運用している方であれば、ゾーンファイルを書き換えた後、git commitしてからrndc reloadという手順は当たり前にやっていると思います(やってなければやってください)。しかし、ゾーン情報をWebUIで管理する権威DNSサービスでは、こういった履歴管理が非常に苦手なことが多いです。

しかし、IIJ DNSプラットフォームサービスはゾーンファイルを履歴管理しています。WebUIからのゾーン編集のみならず、セカンダリサーバとして利用する場合でも、転送されてきたゾーンの履歴が残ります。過去のある時点のゾーンファイルをダウンロードしたり、ゾーンの差分を比較したりといったことも容易にできるようになっています。ブランチを切ったりするような高度な機能はなく、さかのぼれる期間にも制限がありますが、メンテナンスで一時的にゾーンを変更し、メンテが終わったら元に戻す、といった作業がやりやすくなっています。

また、ゾーン編集だけでなくそれ以外の各種操作についても、いつ誰がどんな操作をしたのか履歴を参照できるようにしています。この変更いつやったんだっけ、といった調査に有用ですので必要に応じてご利用ください。

共通設定

ここまでかなりの分量を費してIIJ DNSプラットフォームサービスの機能を説明してきました。本サービスはたくさんの機能を持つため、設定項目もたくさんあります。複数のゾーンを契約いただいている場合、これらの設定項目をゾーンごとに変更していくのはかなり手間のかかる作業になりますし、設定漏れがあったりして意図しない動作をしてしまう危険性も高くなります。

そこで、「共通設定」という機能を用意しました。要はテンプレートです。共通設定の方で設定を済ませておけば、ゾーンがいくつあってもその共通設定にしたがうので、ゾーンごとに細かい設定をする必要がなくなります。設定変更も、共通設定を変更すればそれを参照するすべてのゾーンに反映されます。また、共通設定は複数持てるので、一部のゾーンだけを異なる設定にするといったことも簡単にできます。

ロードマップ

機能はこれからも強化されます。ここでは予定されているもののうち大きなものだけ紹介します。

まず、年内にAPIを提供します。WebUIをブラウザでぽちぽちいじるだけでなく、APIで操作できるようになります。

グローバルロードバランシングサービスという新しいサービスが追加されます。これは旧DNSアウトソースサービスにおけるサイトフェイルオーバーオプションの後継で、お客様サーバを死活監視し、応答がないサーバをDNSから自動で取り除くといった「動的なDNS」を提供するものになります。現在提供されているマネージドDNSサービスの機能強化ではなく、別途契約が必要なサービスという位置付けになります。こちらはだいぶ先になる予定です。気長にお待ちください。

これとは別に、既存サービスの終了も予定されています。DNSセカンダリサービスはすでに新規に契約できません。既存のお客様についても、2021年1月をもってサービスを停止します。DNSアウトソースサービスはまだ契約も可能ですが、こちらも近いうちに新規契約の停止、既存契約のサービス停止と進んでいく予定です。

 

できないこと

最後に、IIJ DNSプラットフォームサービスでできないことを箇条書きで挙げておきます。

• キャッシュサーバとしての機能
  • 権威サーバなので
• ドメインの登録・管理
  • 権威サーバなので
  • 必要であれば、IIJドメイン管理サービスをご利用ください
  • 他社サービスで管理されていても、NSを変更できるなら移管せずに利用できます
• DoH/DoT
  • DoH/DoTもキャッシュサーバのお仕事なのです
  • 将来ADoT(権威サーバへのDoT)が標準化されたら検討するかも
• TLDゾーンのホスティング
  • 最近はgTLDが増えていきてますが、TLDのゾーンは置けません
  • 念の為、ルートゾーンも置けません
  • DNSプラットフォームサービスとしては対応していませんが、個別案件として別途対応はできるかもですので、興味があればお問い合わせください
• view (split brain DNS)
  • 問い合わせ元IPアドレスによって応答する内容を変えることはできません
    • 特定のIPアドレスからの問い合わせには応答しない、というアクセス制限もできません
  • GeoIPも対応していません
• クエリログ
  • 提供しません
• 逆引き自動生成
  • IPアドレスの問い合わせに対してPTRレコードを動的生成して答えてくれるような機能はありません
  • 旧DNSアウトソースサービスでは、正引きゾーンにA/AAAAを設定すると対応するPTRレコードを逆引きゾーンに自動で追加する機能がありましたが、廃止されました

つづく

というか、おしまい、というか。
いちおう次回が最終回ですが、前回の記事で予告した「DNSSECを自前で動かしてみよう」というHowto記事になります。IIJ DNSプラットフォームサービスのことはほとんど出てこないので、サービス紹介としては今回が最後になります。

IIJは新サービスをこのように実装しました。しかし、ここはそうじゃなくてあっちの手法を使った方がよかったのでは、という意見もあるかもしれません。そう思われる方がいれば、ぜひその手法で運用してみてください。同業他社さん、ぜひその手法を使ったサービスをリリースしてください。IIJのやり方が唯一無二の解だとは思っていません。場合によっては弱点となることもあるかもしれません。そんなときでも、他の手法を実装した権威DNSサービスも併用することで補完しあえます。われわれは多様性を重視しています。それでもコストやら何やらのしがらみでとても自前では運用できない、複数サービスを併用できない、というのであれば、ぜひこのサービスをご利用ください。

バックナンバー

• モダンなDNSの構成：IIJ DNSプラットフォームサービスのスゴいところ(第1回)
• DNSの可用性をさまざまな方法で高める：IIJ DNSプラットフォームサービスのスゴいところ(第2回)
• DNSの完全性を守るためにすべきこと：IIJ DNSプラットフォームサービスのスゴいところ(第3回)
• 小回りのきく「DNSホスティングサービス」のためにがんばったこと：IIJ DNSプラットフォームサービスのスゴいところ(第4回) 本記事です
• やってみようDNSSEC (自分で頑張りたい方へ)：IIJ DNSプラットフォームサービスのスゴいところ(第5回)