はじめに
NTTのフレッツ ひかり電話対応ONUは、L2TPによるVPNサーバー機能を内蔵しています。PPTPとは異なり、LSN*1によるアドレス割当が標準になった移動通信網においても、L2TPによるVPNは問題なく通過することができるため、非常に重宝する機能です。これまで、自宅ONUへの接続は Value Domain（以下VD）が提供するDDNS機能を用い、独自ドメインによる名前解決を行ってきました。
しかしながら、
- VD提供のDDNS機能では、IPアドレスの更新にHTTP Getが必要なこと（IPアドレスの変更を検知し、HTTP Getを行う機器がLAN内部に別途必要）
- IPアドレスの変更反映に非常に（酷いときには30分ほど）時間がかかること*2
- なによりVDがGMO傘下ブランドになったため、登録レジストラをGMO（お名前.com）に移転するよう露骨に誘導していること
に嫌気が差しており、今後、GMO以外のレジストラに転出した場合も視野に入れ、独自にDDNSシステムを構築することを検討しました。
基本仕様
一般的なDDNSサービスはieServer.netやDynDNSなど、古くから多数展開されています。が、その大半は HTTP Get によるIPアドレス更新しか対応しておらず、現状からの改善はあまり望めません。
また、以前使っていたDynDNSではサービス変更に伴い、あまり更新を行っていなかったために半強制的にアカウント抹消の憂き目に遭ったという苦い経験があり、一方でこれだけCDNが普及し、網側での（広義の）負荷分散が当然になっている中で、ネームサーバーのような重要な機能を貧弱な回線の下に数えるほどしかぶら下げていないというのは、流石にちょっとどうかと思うわけです。
というわけで自前でシステムを組むことになるのですが、ところで、フレッツ ひかり電話対応ONUには、L2TP VPNサーバー機能の一環として、IPアドレスの変更通知機能があります。これはIPアドレスが変更された際、変更後のIPアドレスを含むメールが自動的に送信されるというものであり、DDNSシステムの構築に際し、本機能による通知を主軸に据えることとしました。
個人ユースのDDNSシステムを動かすだけのためにVPSの面倒を見るのはこのご時世にあまりに馬鹿らしいため、SaaSベースのDNSを使い、メール解析は別途PaaSで走らせることとしました。
DNSホスティングは実際のところ、自社サービスのHTTPホスティングとセットで提供、というスタンスの会社が多く、DNSのみ単体で提供しているのはRoute53を筆頭に数える程度しかありません。加えて、個人用途で高々数ゾーン、クエリ数も月間4桁行かないような状況ではできるだけ安上がりなサービスを使いたくなるというのが人情です。候補としては、
あたりでしょうか。実際にコードを書いた際にはサービスインしていなかったサービスや、後日知ったサービスもあるので後付感は否めないのですが…。
他にも海外系サービスはありますが、
という条件を満たし、かつ DNSPref で最速値を叩き出しながら無料サービスとして展開している CloudFlare で行くことにしました。
CloudFlareはどちらかといえば分散コンテンツ配信の面で有名ですが、実はDNS単体での提供もしています。本当はセットで使うとより良いのでしょうが…。余談ですが、CloudFlareの本業である分散配信の性格上、エッジサーバーは国内主要ISPとのピアリング、あるいは大手IXへの直接接続によって維持されていることが推測でき、イコール応答性能の良さが期待できます。
メール解析はどこでも良かったのですが、個人的に使い慣れていて、標準でメール受信をトリガーにスクリプトを走らせてくれる Google App Engine (GAE)にすることにしました。この辺はHerokuでもAWSでも何でも問題ないと思います。
実装
ここまでくれば、あとはコード書くだけです。IPアドレスの変更通知メールから正規表現で変更後のアドレスを抜き出し、それをAPI叩いて反映させる、という簡単な話です。
CloudFlareのAPIドキュメントを見ながら書けば良いと思いますが、実際には http://torb.at/cloudflare-dynamic-dns みたいに同じこと考える人もいるので、その辺参考に。
感想
ちょお快適。
IPアドレスの変更がDNSレコードに反映されるまでのタイムラグはほぼゼロとなりました。実際のところIPアドレスはそう頻繁に変わるわけではないものの、変更に即座に追随できないのは致命的といえるので、大幅に性能向上したことになります。
また、webPushによる手持ちのスマフォへの通知機能も併せて実装したため、これまでのように変更通知メールがメールボックスの片隅に埋もれる、ということもなくなり、加えてレジストラへの依存がなくなったことから、これでいつでも脱出できる準備が整いました。
余談：セキュリティ的なやつ
メールベースでのやりとりであるため、悪意のある第三者がGAE側受信アドレスにIPアドレスを書いたメールを流し込めば、DNS Hijackingが成立してしまいます。ただ、GAE側の受信アドレスは自身で変更できるので、複雑なアドレスにしつつ、発信元アドレスが正しいかどうかを判定してやれば疑似的にではありますが認証のような形を取ることは可能です。
なお、より詳細に検討するのであれば、実際にメール本文に記載されているIPアドレスが、メールヘッダ（Received ヘッダ）に記載されているIPアドレスと一致しているかどうかを確認する、あるいはDKIM対応サーバーからメール送信を行うようONUに指定し、受信スクリプト側でDKIMの判定ルーチンを組み込む、などの対応を行えばよりセキュアになるでしょう。ただ、悪用されたところで個人使用のドメインが指すアドレスが変更されるだけであり、ONUの再起動等で修正が可能であることから、実害としてどこまで影響があるかというのは微妙です。
