Amazon Route53、Azure DNS、Google Cloud DNS など、クラウドの DNS サービスを比較・説明します。
最終更新
目次
機能比較表
Amazon Route53、Azure DNS、Google Cloud DNS の機能比較です。
以下、解説していきます。
詳細解説
「基本機能」について
| – | Amazon Route53 | Azure DNS | Google Cloud DNS |
|---|---|---|---|
| クラウド内部 DNS 管理 | ◯ | ◯ | ◯ |
| クラウド外部の DNS 管理 | ◯ | ◯ | ◯ |
| プライベートゾーン | ◯ | △ (2018/3 リリース。2018/10 現在プレビュー) | △ (2018/10 リリース。2018/10 現在ベータ) |
「クラウド内部 DNS 管理」は、例えば「IP アドレス 10.20.30.44 はこの EC2 インスタンスに対応する」という名前解決ができるかという意味で書きました。これは AWS・Azure・GCP いずれも対応しています。
「クラウド外部 DNS 管理」は、クラウド外、例えばオンプレミス環境にあるサーバに対して DNS 設定が可能か、 という意味で書きました。これも AWS・Azure・GCP いずれも対応しています。
「プライベートゾーン」は、「内部ネットワークだけからアクセスできるゾーンを設定できるか」 「外部からは引けないゾーンを設定できるか」という意味です。 これは AWS の Route53 が正式対応で、Azure DNS は 2018/10 現在プレビュー、 GCP の Cloud DNS は 2018/10 現在ベータです。
例えば “hoge.local” などのゾーンを作成し、どの VPC から参照可能とするかを設定すれば、 外部からはどうやっても参照不可な DNS レコードができます。 なお、”hoge.local” というドメインを取得する必要はありませんし、 他人と重複するかを心配する必要もありません。
なお、「A レコード等に 192.168.0.1 などのプライベート IP アドレスを設定できるか」 という意味であれば、AWS・Azure・GCP いずれも可能です。ただネットワーク構成が外部に見えてしまうのはセキュリティ上よろしくはありません。
「対応レコード」について
| – | Amazon Route53 | Azure DNS | Google Cloud DNS |
|---|---|---|---|
| 対応レコード | A AAAA CAA CNAME MX NAPTR NS PTR SOA SPF SRV TXT ※SPF RR は実質非推奨。SPF は TXT に登録すること。 | A AAAA CAA CNAME MX NS PTR SOA SRV TXT | A AAAA CAA CNAME MX NAPTR NS PTR SOA SRV TXT 上記に加え、さらに DNSSEC 関連レコードが利用可能 |
まとめると、対応しているリソースレコードは下記です。
- A/AAAA/CAA/CNAME/MX/NS/PTR/SOA/SRV/TXT は全サービス対応。
- NAPTR は Amazon Route53/Google Cloud DNS は対応 (Azure DNS は非対応)。
- SPF は Amazon Route53 のみ対応。
CAA (Certification Authority Authorization) は、SSL/TLS などの証明書を発行できる認証局を制限するもので、 認証局が証明書の発行する際、対象ドメインの CAA レコードを取得し、もし異なる認証局が設定されていた場合は、 証明書を発行しない、というものです。主要認証局は 2017/9 より CAA レコードのチェックを必須とすることで合意していたものです。Azure DNS のみ対応が遅れていましたが、2017/11 より CAA に対応しました。
SPF はメール送信の際の IP アドレス認証の仕組みです。大変紛らわしいのですが、 もともと「SPF」という仕組みは「SPF リソースレコード」か「TXT リソースレコード」のいずれかで設定する、 というものでした。その後、新しい RFC にて「SPF は TXT リソースレコードを使う」となりましたので、 2017/08 現在、「SPF リソースレコード」は不要です。 しかし Amazon Route53 では念のため残していて、 Azure DNS と Google Cloud DNS では、現在は不要な「SPF リソースレコード」は使えないようにしているのでしょう。 なので、Azure DNS・Google Cloud DNS も、問題なく「SPF 設定」は行なえます。
NAPTR はよくわからないのですが (SIP とかで使う?)、現時点で実際に使えるものなんでしょうかね。
SRV はこちらをどうぞ。
「Alias レコード」について
| – | Amazon Route53 | Azure DNS | Google Cloud DNS |
|---|---|---|---|
| Alias レコード | ○ | ○ (2018/9より利用可) | × |
Amazon Route 53 と Azure DNS は「Alias レコード」という機能を持っています。 Alias レコードの用途は CNAME と同じで、「別名を付けること」です。
じゃあ CNAME 使えばいいじゃんという話ではあるんですが、CNAME にはひとつ問題があります。 1996年発行の RFC 1912 には下記のように書いてあります。
A CNAME record is not allowed to coexist with any other data.
(CNAME レコードは、他のデータと共存できない)
つまり、CNAME は NS や MX と共存できない。 しかしながら、example.com のような Zone Apex (そのドメインの頂点、www などのサブドメインがつかない形のこと) では、 NS レコードが必要です。 言い換えると、example.com のような Zone Apex では CNAME が使えない。 じゃあどうすればというと、「Zone Apex には A レコードを使え」というわけです。
しかしながら、A レコードということは IP アドレスを固定にしないといけない。 特にいまどきのクラウド時代、IP アドレスが変わることは大いにあるわけだし、 別 IP アドレスを振ってのフェイルオーバーだってしたい。 なので、この制限はちょっと受け入れがたい。
そこで、DNS サーバ内部で展開してあげる方法が発案されました。 DNS サーバに Zone Apex の A レコードの名前解決要求が届くと、 内部的に「CNAME 的なもの」として設定されたものの IP アドレスを調べて、A レコードとして返してあげます。 外部から見ると A レコードに見えるので RFC 的には問題ありません。
Route 53 や Azure DNS ではこの方法を “Alias レコード” と呼称している、というわけです。 なお、DNS サービスにより下記のように呼称が異なるようです。
- Amazon Route53: “Alias レコード”
- Azure DNS: “Alias レコード”
- CloudFlare: “CNAME flattening”
- DNS Made Easy: “ANAME レコード”
- DNSimple: “Alias レコード”
最初に実装したのが誰なのか、一般的な名称はあるのかについてはわかりませんでした。
なお、なぜ CNAME が共存できないかというのは、RFC 1034 によると、 「正規の名前と別名の名前が異なることがなく、他のレコードをチェックせずに CNAME が使えるように」 だそうです。
「ワイルドカード」について
| – | Amazon Route53 | Azure DNS | Google Cloud DNS |
|---|---|---|---|
| ワイルドカード | 可 | 可 | 可 |
DNS におけるワイルドカードとは、”*” を設定しておけばどのようなドメインにもマッチするような仕組みです。例えば “*.example.com” は www.example.com にも mydomain.example.com にもマッチしますので、全部同じ A レコードを返すといった用途に使います。
Amazon Route 53 ・Azure DNS・Google Cloud DNS いずれも、ワイルドカードに対応しています。
「ゾーン転送」について
| – | Amazon Route53 | Azure DNS | Google Cloud DNS |
|---|---|---|---|
| 他ネームサーバからのゾーン転送 | × | × | ○? |
| 他ネームサーバへのゾーン転送 | × | × | ○? |
Amazon Route53・Azure DNS・Google Cloud DNS いずれも、 他のネームサーバへからのゾーン転送はできません。 他のネームサーバへのゾーン転送もできません。
これの意味するところは下記です。
- 外部 DNS サーバをプライマリとし、Amazon Route53・Azure DNS・Google Cloud DNS をセカンダリとすることはできない。
- Amazon Route53・Azure DNS・Google Cloud DNS をプライマリ、外部 DNS サーバをセカンダリとすることはできない。
- Amazon Route53 をプライマリ、Azure DNS・Google Cloud DNS をセカンダリとすることはできない。
そのようなことをどうしても行いたい場合、下記のインポート・エクスポートを参照してください。
2019/01/15 beta ですが、Cloud DNS に DNS forwarding という機能が追加されているとのこと。まだちゃんと読んでませんが外部 DNS サーバとの連携ができそうな雰囲気です。
「インポート」について
| – | Amazon Route53 | Azure DNS | Google Cloud DNS |
|---|---|---|---|
| インポート | 可 (コンソールから) | 可 (Azure CLI にて) | 可 (gcloud コマンドにて) |
他の DNS サーバにて管理している DNS 情報を、クラウド DNS サービスにインポートできるか。
Amazon Route53、Azure DNS、Google Cloud DNS いずれもゾーンファイルをインポートすることが可能です。 Amazon Route53 はコンソール (管理画面) から可能ですが、コマンドラインからはできないようです。 Azure DNS は Azure CLI を使います (azure network dns zone import)。 Google Cloud DNS は gcloud コマンドを使います (gcloud dns record-sets import)。 Google Cloud DNS が対応しているファイル形式は、BIND ゾーンファイル形式と YAML 形式です。
「エクスポート」について
| – | Amazon Route53 | Azure DNS | Google Cloud DNS |
|---|---|---|---|
| エクスポート | △ (cli53 というツールがあるが、AWS 製ではない) | 可 (Azure CLI にて) | 可 (gcloud コマンドにて) |
その逆のエクスポートは、Azure DNS・Google Cloud DNS のみ可能です。 Google Cloud DNS が対応している形式は、インポートと同じく、BIND ゾーンファイル形式と YAML 形式です。
Amazon Route53 の場合、cli53 というツールがありますが、AWS 製ではなく非公式ツールです。 なお、Amazon の場合、ファイルに吐くことはできませんが、 CLI で aws route53 を頑張って叩いて、全情報を引き出すことは可能です。
「DNSSEC」について
| – | Amazon Route53 | Azure DNS | Google Cloud DNS |
|---|---|---|---|
| DNSSEC | × | × | ○ (2018/5 GA) |
DNSSEC とは、DNS のリクエスト・レスポンスについて、改ざんや偽造を防止するための仕組みです。DNS は主に UDP プロトコルを使用するため、「DNS スプーフィング」や「DNS キャッシュポイズニング」という攻撃に弱いという欠点がありました。DNSSEC は公開鍵暗号方式による署名を行い、署名を検証することで改ざんを検知し、不正な DNS 情報を破棄するための仕組みです。DNS と DNSSEC は、http と https の関係性に似ていますが、DNSSEC で行うのは署名による改ざん検知であり、暗号化はしません。ただ、DNSSEC の仕組みは 2000年代前半から提唱されているにもかかわらず、普及が進んでいないのが実情です。
現在、Google Cloud DNS は DNSSEC に対応しています。Amazon Route53・Azure DNS は非対応です。
参考までに DNSSEC で何が防げるかという事例をあげておきます。2018年に Route 53 がハイジャックされ、1600万円相当の仮想通貨が盗まれるという事件がありました。これは Route 53 に脆弱性があったわけではありません。犯人は AWS とは全く関係のない ISP 内に侵入し、BGP という経路情報を伝えるプロトコルを流すことで Route53 の IPアドレスを偽の DNS サーバに誘導しました。これにより、仮想通貨サービスの利用者は、偽の仮想通貨サーバにアクセスしてしまったため、仮想通貨が盗まれてしまったということです。この件について、AWS も仮想通貨サービス業者も被害者です。AWS にも仮想通貨サービス事業者も、彼らの全く関与していないネットワーク・サーバで悪さをされたので、防ぎようがないためです。
詳細は Amazon のRoute 53 DNSサービスで起きたBGPハイジャック事件の真相 をどうぞ。
「DNS over HTTPS/DNS over TLS」について
| – | Amazon Route53 | Azure DNS | Google Cloud DNS |
|---|---|---|---|
| DNS over HTTPS/ DNS over TLS | 無関係 | 無関係 | 無関係 |
DNS over HTTPS・DNS over TLS について軽く触れておきます。我々一般利用者がブラウザ等で DNS を使う場合、DNS サーバへのリクエスト・レスポンスは主に UDP プロトコルを使用しています。データは暗号化されずに平文で流れます。盗聴・改ざんの危険性があります。
これをなんとかしようというのが DNS over HTTPS や DNS over TLS という技術です。これはブラウザ ⇔ DNS キャッシュサーバ間のセキュリティを高めるための技術です。しかしながら、この技術は Amazon Route53・Azure DNS・Google Cloud DNS には関係ありません。なぜならばこれらの DNS サービスは「権威サーバ」であって、「フルサービスリゾルバーではない」からです。
フルサービスリゾルバーを提供しているのは、BIGLOBE や Nifty 等のプロバイダです。また、公開 DNS サービスとして Google Public DNS (IP アドレス 8.8.8.8) や CloudFlare の DNS サービス (IP アドレス 1.1.1.1) などがありますが、これもフルサービスリゾルバーです。
下記、JRPS にわかりやすい画像がありましたので参考にしてください。DNS over HTTP/TLS は、スタブリゾルバーとフルサービスリゾルバーの間のセキュリティを高める技術です。 繰り返しですが、 Amazon Route53・Azure DNS・Google Cloud DNS は権威サーバを提供するサービスであり、 フルサービスリゾルバーではありません。
なお、Google Public DNS や CloudFlare の DNS サービスは、DNS over HTTPS・DNS over TLS いずれも対応しています。
「ルーティングポリシー」について
| – | Amazon Route53 | Azure DNS | Google Cloud DNS |
|---|---|---|---|
| ルーティングポリシー | Simple, Weighted, Latency, Failover, Geolocation, Multivalue Answer | × (Traffic Manager で提供) | × (Google Cloud Load Balancing で提供) |
Route53 だけすごそうな機能が付いてます。 Route53 の場合、ラウンドロビンや、重み付け、フェイルオーバーなどが実現できます。 ただ、Azure では Azure DNS ではなく Traffic Manager がその役割を果たしていますし、 Google の場合は Google Cloud Load Balancing があります。 Route53 が素晴らしいか (DNS がそういう機能を持つことがよいことか) は改めて考えてみたいと思います。
「ドメイン登録」について
| – | Amazon Route53 | Azure DNS | Google Cloud DNS |
|---|---|---|---|
| ドメイン登録 | 登録可 | △ (Azure DNS からはできないが、WebApps から登録できる) | △ (Cloud DNS からはできないが、Google Domains から登録できる) |
AWS では Route53 でドメインが登録 (取得) できますが、 Azure DNS・Google Cloud DNS ではできません。
しかしながら、Azure では WebApps からドメインが登録できます。 GCP も、Google DNS からは登録できませんが、Google Domains から買えます (以前は日本からドメイン取得できなかったのですが、 2017/07 より日本からも登録可となりました)。
AWS と Azure のどちらがあるべき姿なのか、よくわかりません。 どっちもおかしいような…。Route53 や WebApps などの各サービスからは独立しているべきなのか? 考え中。
以下メモ。edns-client-subnetについて。 kskロールオーバーについて (edns0について、tcp について)。 Amazon Route 53 Auto Naming。 Route53 レゾルバーとは?