Amazon Route53，Azure DNS，Google Cloud DNS服务比较

 

比较并解释云DNS服务，例如Amazon Route53，Azure DNS，Google Cloud DNS。

 

功能比较表

Amazon Route53，Azure DNS和Google Cloud DNS功能的比较。

详细说明

–	亚马逊Route53	Azure DNS	Google Cloud DNS
云内部DNS管理	◯	◯	◯
云端之外的DNS管理	◯	◯	◯
私人区域	◯	△（2018/3发行版，2018/10预览）	△（2018年10月发布，beta于2018年10月发布）
对应记录	不建议使用 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	一个 AAAA CAA CNAME MX NAPTR NS PTR SOA SRV TXT除了上述，进一步DNSSEC相关记录可
别名记录	○	○（从2018/9开始提供）	×
通配符	是的	是的	是的
从另一个名称服务器进行区域传输	×	×	○？
区域转移到另一个名称服务器	×	×	○？
汇入	是（从控制台）	是（使用Azure CLI）	是（使用gcloud命令）
汇出	△（有一个名为cli53的工具，但不是AWS制作的）	是（使用Azure CLI）	是（使用gcloud命令）
域名系统	×	×	○（2018/5 GA）
通过HTTPS的 DNS / 通过TLS的DNS	无关的	无关的	无关的
路由策略	简单，加权， 延迟，故障转移， 地理位置，多值答案	否（由流量管理器提供）	×（由Google Cloud Load Balancing提供）
域名注册	可以注册	△（无法从Azure DNS完成，但可以从WebApps注册）	△（无法从Cloud DNS完成，但可以从Google Domains注册）

要对该表进行详细说明

以下是说明。

详细说明

关于“基本功能”

–	亚马逊Route53	Azure DNS	Google Cloud DNS
云内部DNS管理	◯	◯	◯
云端之外的DNS管理	◯	◯	◯
私人区域	◯	△（2018/3发行版，2018/10预览）	△（2018年10月发布，beta于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月处于beta版。

例如，如果您创建一个区域（例如“ hoge.local”）并设置可以从哪个VPC进行引用，则可以创建无法从外部引用的DNS记录。您无需获取域“ hoge.local”，也不必担心重复。

此外，可以使用AWS / Azure / GCP，只要它表示“我可以在A记录等中设置诸如192.168.0.1之类的私有IP地址吗？” 但是，将网络配置暴露在外部不利于安全。

关于“对应记录”

–	亚马逊Route53	Azure DNS	Google Cloud DNS
对应记录	不建议使用 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	一个 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（证书颁发机构授权）限制了可以颁发证书（例如SSL / TLS）的证书颁发机构。如果设置，则不颁发证书。主要证书颁发机构已同意，必须从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 。

关于别名记录

–	亚马逊Route53	Azure DNS	Google Cloud DNS
别名记录	○	○（从2018/9开始提供）	×

Amazon Route 53和Azure DNS具有称为“别名记录”的功能。别名记录的使用方式与CNAME相同：“别名”。

因此，使用CNAME是一个好主意，但是CNAME有一个问题。1996 年发布的RFC 1912指出：

CNAME记录是不能共存与任何其他数据。
（CNAME记录，不能与其他数据共存）

也就是说，CNAME无法与NS或MX共存。但是，Zone Apex（例如example.com）（域的顶部，没有子域，如www）需要NS记录。换句话说，Zone Apex（例如example.com）不接受CNAME。那么，您怎么说“将A记录用于Zone Apex”呢？

但是，对于A记录，必须固定IP地址。尤其是在现代云时代，IP地址可能会发生很大变化，我想使用另一个IP地址进行故障转移。因此，这种限制是不可接受的。

因此，发明了一种在DNS服务器内部进行部署的方法。当DNS服务器收到解析区域Apex A记录名称的请求时，它将检查内部设置为“类似于CNAME”的IP地址，并将其作为A记录返回。由于从外部看起来像是A记录，因此RFC没有问题。

路线53和Azure DNS将此方法称为“别名记录”。另外，名称依以下DNS服务而异。

• 亚马逊Route53：“别名记录”
• Azure DNS：“别名记录”
• CloudFlare：“ CNAME展平”
• DNS轻松实现：“ ANAME记录”
• DNSimple：“别名记录”

我不知道是谁首先实现了它，或者它有什么通用名称。

根据RFC 1034，CNAME无法共存的原因是“规范名称和别名没有区别，并且可以使用CNAME而不检查其他记录”。

关于“通配符”

–	亚马逊Route53	Azure DNS	Google Cloud DNS
通配符	是的	是的	是的

如果设置了“ *”，则DNS中的通配符是一种与任何域匹配的机制。例如，“ * .example.com”与www.example.com和mydomain.example.com都匹配，因此使用它返回相同的A记录。

Amazon Route 53，Azure DNS和Google Cloud DNS均支持通配符。

关于“区域转移”

–	亚马逊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不能是辅助的。

如果您确实要这样做，请参见下面的导入/导出。

据说DNS转发已于2019/01/15 beta版添加到Cloud DNS中。我还没有阅读过，但是看起来我可以使用外部DNS服务器。

关于“导入”

–	亚马逊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网络dns区域导入）。Google Cloud DNS使用gcloud命令（gcloud dns记录集导入）。Google Cloud DNS支持BIND区域文件格式和YAML格式。

关于“出口”

–	亚马逊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”

–	亚马逊Route53	Azure DNS	Google Cloud DNS
域名系统	×	×	○（2018/5 GA）

DNSSEC是一种防止伪造和伪造DNS请求/响应的机制。因为DNS主要使用UDP协议，所以它具有易受“ DNS欺骗”和“ DNS缓存中毒”攻击的缺点。DNSSEC是一种机制，该机制使用公钥密码术执行签名，通过验证签名来检测篡改，并丢弃非法的DNS信息。DNS和DNSSEC与http和https之间的关系类似，但是DNSSEC所做的是通过签名检测篡改并且不进行加密。但是，尽管自2000年代初以来就提出了DNSSEC机制，但事实是它尚未传播。

目前，Google Cloud DNS支持DNSSEC。不支持Amazon Route53和Azure DNS。

以下是DNSSEC可以做什么的一些示例，供您参考。在2018年，发生了一起案例，其中53号公路被劫持，价值1600万日元的虚拟货币被盗。这并不意味着53号公路是脆弱的。罪魁祸首闯入了与AWS无关的ISP，并通过流经BGP路由协议将Route53的IP地址定向到了伪造的DNS服务器。这意味着虚拟货币服务的用户访问了伪造的虚拟货币服务器，并且虚拟货币被盗。AWS和加密货币服务提供商都是此事的受害者。AWS和加密货币服务提供商都没有受到他们不参与的网络服务器的伤害，并且没有办法阻止它们。

了解有关Amazon Route 53 DNS服务上发生的BGP劫持事件的更多信息。

关于“ HTTPS上的DNS / TLS上的DNS”

–	亚马逊Route53	Azure DNS	Google Cloud DNS
通过HTTPS的 DNS / 通过TLS的DNS	无关的	无关的	无关的

我将简要提及基于HTTPS的DNS和基于TLS的DNS。当我们在浏览器等上使用DNS时，对DNS服务器的请求和响应主要使用UDP协议。数据无加密直接传输。有窃听和篡改的风险。

通过HTTPS的DNS和通过TLS的DNS是管理此问题的技术。这是一种提高浏览器和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中易于理解的图像，因此请参考它。HTTP / TLS上的DNS是一项技术，可提高存根解析器和完整服务解析器之间的安全性。同样，Amazon Route53，Azure DNS和Google Cloud DNS是提供权威服务器的服务，而不是提供全方位服务的解析器。

Google Public DNS和CloudFlare的DNS服务同时支持HTTPS上的DNS和TLS上的DNS。

关于“路由策略”

–	亚马逊Route53	Azure DNS	Google Cloud DNS
路由策略	简单，加权， 延迟，故障转移， 地理位置，多值答案	否（由流量管理器提供）	×（由Google Cloud Load Balancing提供）

只有Route53具有如此强大的功能。在Route53的情况下，可以实现轮询，加权和故障转移。但是，在Azure中，流量管理器将代替Azure DNS扮演角色，并且Google具有Google Cloud Load Balancing。我想重新考虑Route53是否很棒（DNS应该具有这样的功能）。

关于“域名注册”

–	亚马逊Route53	Azure DNS	Google Cloud DNS
域名注册	可以注册	△（无法从Azure DNS完成，但可以从WebApps注册）	△（无法从Cloud DNS完成，但可以从Google Domains注册）

在AWS上，您可以使用Route53注册（获取）域，但不能使用Azure DNS / Google Cloud DNS注册（获取）。

但是，您可以在Azure中从WebApp注册您的域。GCP不能从Google DNS注册，但可以从Google Domains购买（以前无法从日本获得域名，但是从2017/07开始可以在日本注册）。