クラウド DNS サービス比較まとめ (Amazon Route53・Azure DNS・Google Cloud DNS)

機能比較

Amazon Route53、Azure DNS、Google Cloud DNS の機能比較です。

Amazon Route53 Azure DNS Google Cloud DNS
クラウド内部 DNS 管理
クラウド外部の DNS 管理
プライベートDNS × ×
対応レコード A
AAAA
CAA
CNAME
MX
NAPTR
NS
PTR
SOA
SPF
SRV
TXT
※SPF RR は実質非推奨。SPF は TXT に登録すること。
A
AAAA
CNAME
MX
NS
PTR
SOA
SRV
TXT
A
AAAA
CAA
CNAME
MX
NAPTR
NS
PTR
SOA
SRV
TXT
Alias レコード 使用可 × ×
テストツール なし なし
ワイルドカード
インポート 可 (コンソールから) 可 (Azure CLI にて) 可 (gcloud コマンドにて)
エクスポート △ (cli53 というツールがあるが、AWS 製ではない) 可 (Azure CLI にて) 可 (gcloud コマンドにて)
DNSSEC × × 2017/08 時点で Alpha リリース。使用するには参加リクエストが必要
ルーティングポリシー Simple, Weighted,
Latency, Failover,
Geolocation, Multivalue Answer
× (Traffic Manager で提供) × (Google Cloud Load Balancing で提供)
ドメイン購入 購入可 × (WebApps から買える) × (Google Domains から買えるが、2017/08 現在、日本からは買えない)

以下、解説していきます。

基本機能

Amazon Route53 Azure DNS Google Cloud DNS
クラウド内部 DNS 管理
クラウド外部の DNS 管理
プライベートDNS × ×

「クラウド内部 DNS 管理」は当然ながら可能です。 これは例えば「IP アドレス 10.20.30.44 はこの EC2 インスタンスに対応する」という意味で書きました。

「クラウド外部 DNS 管理」は、クラウド外、例えばオンプレミス環境にあるサーバに対して DNS 設定が可能か、 という意味で書きました。これも AWS・Azure・GCP いずれも対応しています。

「プライベート DNS」は、「内部ネットワークだけからアクセスできるゾーンを設定できるか」 「外部からは引けないゾーンを設定できるか」という意味です。 これは AWS の Route53 のみが対応しています。 例えば "hoge.local" などのゾーンを作成し、どの VPC から参照可能とするかを設定すれば、 外部からはどうやっても参照不可な DNS レコードができます。 なお、"hoge.local" というドメインを購入する必要はありませんし、 他人と重複するかを心配する必要もありません。

なお、「A レコード等に 192.168.0.1 などのプライベート IP アドレスを設定できるか」 という意味であれば、Azure・GCP でも可能です。

「対応レコード」について

まとめると、対応しているリソースレコードは下記です。
  • A/AAAA/CNAME/MX/NS/PTR/SOA/SRV/TXT は全サービス対応。
  • CAA/NAPTR は Amazon Route53/Google Cloud DNS は対応 (Azure DNS は非対応)。
  • SPF は Amazon Route53 のみ対応。

CAA (Certification Authority Authorization) は、SSL/TLS などの証明書を発行できる認証局を制限するもので、 認証局が証明書の発行する際、対象ドメインの CAA レコードを取得し、もし異なる認証局が設定されていた場合は、 証明書を発行しない、というものです。主要認証局は 2017/9 より CAA レコードのチェックを必須とすることで合意していますので、 CAA を使えるにこしたことはありません。 Azure DNS はさっさと対応するべきです。

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 とかで使う?)、現時点で実際に使えるものなんでしょうかね。

「Alias レコード」について

Amazon Route53 Azure DNS Google Cloud DNS
Alias レコード 使用可 × ×

Alias レコードは、(上記 3サービスの中では) Amazon Route 53 だけの独自機能です。 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 (そのドメインの頂点) では、 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 ではこの方法を "Alias レコード" と呼称している、というわけです。 なお、DNS サービスにより下記のように呼称が異なるようです。

  • Amazon Route53: "Alias レコード"
  • CloudFlare: "CNAME flattening"
  • DNS Made Easy: "ANAME レコード"
  • DNSimple: "Alias レコード"

最初に実装したのが誰なのか、一般的な名称はあるのかについてはわかりませんでした。

なお、なぜ CNAME が共存できないかというのは、RFC 1034 によると、 「正規の名前と別名の名前が異なることがなく、他のレコードをチェックせずに CNAME が使えるように」 だそうです。

「ルーティングポリシー」について

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
ドメイン購入 購入可 × (WebApps から買える) × (Google Domains から買えるが、2017/08 現在、日本からは買えない)

AWS では Route53 でドメインが買えますが、 Azure DNS・Google Cloud DNS では買えません。

しかしながら、Azure では WebApps からドメインが買えます。 GCP では Google Domains というのがあるのですが、 2017/08 現在、日本からはドメインが買えないようです。

AWS と Azure のどちらがあるべき姿なのか、よくわかりません。 どっちもおかしいような…。Route53 や WebApps などの各サービスからは独立しているべきなのか? 考え中。

memo: edns-client-subnetについて。 kskロールオーバーについて (edns0について、tcp について)。 他ネームサーバからの/へのゾーン転送不可。 Amazon Route 53 Auto Naming。