微软dns能做cname吗

This post will use the above question to explore DNS, dig, A records, CNAME records, and ALIAS/ANAME records from a beginner’s perspective. So let’s get started.

这篇文章将使用上述问题从初学者的角度探讨DNS ， dig ， A记录， CNAME记录和ALIAS/ANAME记录。 因此，让我们开始吧。

首先，一些定义 (First, some definitions)

• Domain Name System (DNS): the overall system for converting a human memorable domain name (example.com) to an IP address (93.184.216.34). The IP address is of a server, commonly a web server, where the files needed to display a webpage are stored.

  域名系统 (DNS)：将人类难忘的域名(example.com)转换为IP地址(93.184.216.34)的整体系统。 IP地址是服务器(通常是Web服务器)的IP地址，其中存储了显示网页所需的文件。

• DNS Server (also known as a name server or nameserver): Uses DNS software to store information about domain addresses. There are several levels — those belonging to each ISP, Root (13 total worldwide), Top Level Domain (TLD, e.g. ‘.com’), and Domain level DNS Servers.

  DNS服务器 (也称为名称服务器或名称服务器)：使用DNS软件存储有关域地址的信息。 有几个级别-属于每个ISP，根(全球共有13个)，顶级域(TLD，例如“ .com”)和域DNS服务器。

• Domain name: the domain (example) combined with the TLD (.com). The term ‘domain’ is often used synonymously with the domain name, though they are different. When you buy a ‘domain’ from a a registrar or reseller, you buy the rights to a specific domain name (example.com), and any subdomains you want to create (my-site.example.com, mail.example.com, etc).

  域名 ：域名(示例)与TLD(.com)组合。 术语“域”通常与域名同义使用， 尽管它们是不同的 。 当您从注册商或转售商处购买“域名”时，即购买了特定域名(example.com)以及您要创建的任何子域(my-site.example.com，mail.example.com，等等)。

高级查询流程 (High level query flow)

The high-level flow of what happens when you type “example.com” into your browser can be simplified to remove the hops to the ISP, Root, and TLD DNS Servers as below:

可以简化在浏览器中键入“ example.com”时发生的高级操作，以删除到ISP，根和TLD DNS服务器的跃点，如下所示：

A domain typically has two or more name servers, containing records relating to the domain name (example.com).

域通常具有两个或多个名称服务器，其中包含与域名(example.com)有关的记录。

Many types of records can be stored, most of which can have multiple entries per type:

可以存储多种类型的记录，每种类型中的大多数可以具有多个条目：

• A: Address records that map the domain name to an IP address

  A ：地址记录将域名映射到IP地址

• CNAME: Canonical Name Record. Used to alias one domain name (or subdomain name) to another. We’ll look at this in more detail later.

  CNAME ：规范名称记录。 用于将一个域名(或子域名)别名为另一个。 我们将在后面详细介绍。

• MX: Mail eXchange records that tell email delivery agents where they should deliver your email

  MX ：邮件eXchange记录，告诉电子邮件传递代理他们应该在哪里传递您的电子邮件

• TXT: flexible Text records, for storing strings for a variety of uses

  TXT ：灵活的文本记录，用于存储各种用途的字符串

• SOA: singular Start of Authority record kept at the top level of the domain. Contains specific required information about the domain, for example its primary name server

  SOA ：单一的“开始授权”记录保存在域的顶层。 包含有关域的特定必需信息，例如其主域名服务器

• NS: The name servers associated with the domain

  NS ：与域关联的名称服务器

When your device sends a query that reaches a name server, the server looks in the domain’s record node for an A record, and the associated stored IP address (example.com: 93.184.216.34). This is then returned to the device, to be used to send a request to the correct web server to retrieve the requested webpage or resource.

当您的设备发送查询到达名称服务器时，该服务器在域的记录节点中查找A记录以及关联的存储IP地址(example.com：93.184.216.34)。 然后将其返回给设备，用于将请求发送到正确的Web服务器以检索请求的网页或资源。

使用“挖” (Using ‘dig’)

dig (domain information groper) is a command-line tool for querying DNS servers. This command is generally used for troubleshooting, or as now to understand more about the setup of a system.

dig ( 域信息groper )是用于查询DNS服务器的命令行工具。 该命令通常用于故障排除，或者如现在一样，以了解有关系统设置的更多信息。

$ dig example.com results in a long response printed to the terminal, the default output detailed here, of which we are interested in the ANSWER SECTION.

$ dig example.com导致打印到终端的响应很长，这是此处详细介绍的默认输出 ，我们对ANSWER SECTION感兴趣。

;; ANSWER SECTION:
example.com.       72703      IN     A       93.184.216.34

And there we go, we can see that example.com returns an A record of 93.184.216.34. Sometimes domains will have more than one A record, if more than one web server can provide the information needed.

93.184.216.34 ，我们可以看到example.com返回A记录93.184.216.34 。 如果多个Web服务器可以提供所需的信息，则有时域将具有多个A记录。

There’s more! If we try out some other examples, we can soon see that another common record appears: CNAME.

还有更多！ 如果我们尝试其他一些示例，我们很快就会看到另一个通用记录出现了： CNAME 。

$ dig www.skyscanner.net:

$ dig www.skyscanner.net ：

;; ANSWER SECTION:
www.skyscanner.net. 169 IN CNAME www.skyscanner.net.edgekey.net.
www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.
e11316.a.akamaiedge.net. 20 IN A 23.217.6.192

www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.

e11316.a.akamaiedge.net. 20 IN A 23.217.6.192

Using the +short flag allows us to clearly see the path formed:

使用+short标志可以使我们清楚地看到形成的路径：

$ dig www.skyscanner.net +short

$ dig www.skyscanner.net +short

www.skyscanner.net.edgekey.net.
e11316.a.akamaiedge.net.
23.217.6.192

CNAME (CNAME)

A CNAME record allows a domain name to be used as an alias for another canonical (true) domain.

CNAME记录允许将域名用作另一个规范(true)域的别名。

When the DNS server returns a CNAME record, it will not return that to the client. Rather it will again look up the returned domain name, and in turn return the A record’s IP address. This chain can continue many CNAME levels deep, but then suffers minor performance hits from multiple lookups before caching takes place.

DNS服务器返回CNAME记录时，不会将其返回给客户端。 而是它将再次查找返回的域名，然后返回A记录的IP地址。 该链可以深入许多CNAME级别，但是在进行缓存之前，多次查找会对性能造成轻微影响。

A simple example of this could be if you have a server where you keep all your photos. You may normally access it through photos.example.com. However, you might also want it to allow access via photographs.example.com. One way to make this possible is to add a CNAME record that points photographs to photos. This means that when someone visits photographs.example.com they would be given the same content as photos.example.com.

一个简单的例子就是如果您有一台服务器来保存所有照片。 您通常可以通过photos.example.com访问它。 但是，您可能还希望它允许通过photographs.example.com进行访问。 使之成为可能的一种方式是添加CNAME记录是点photographs到photos 。 这意味着，当有人访问photographs.example.com他们将被给予相同的内容photos.example.com 。

Using the query $ dig photographs.example.com we would see:

使用查询$ dig photographs.example.com我们将看到：

photographs.example.com    IN   CNAME photos.example.com
photos.example.com         IN   A     xx.xxx.x.xxx

It’s important to note that the CNAME is that piece to the right hand side. The left hand side is the alias name, or label.

请务必注意， CNAME在右侧。 左侧是别名或标签。

Another common use is for the www subdomain. Having purchased example.com you likely also want users who type in www.example.com to see the same content.

另一个常见用途是www子域。 购买了example.com您可能还希望输入www.example.com用户看到相同的内容。

It is worth noting here that example.com can be called the apex, root, or naked domain name.

在这里值得注意的是example.com可以称为顶点，根或裸域名。

One option would be to set up another A record, pointing to the same IP address as for example.com. This is completely valid, and is what the real example.com does, but it does not scale well. What happens if you need to update the IP address that example.com points to? You would also need to update it for the www subdomain, and any others you may use.

一种选择是设置另一个A记录，指向与example.com相同的IP地址。 这是完全有效的，并且是真正的example.com所做的，但是扩展性不好。 如果您需要更新example.com指向的IP地址，该怎么办？ 您还需要针对www子域以及您可能使用的其他任何域进行更新。

If a CNAME record was used to alias www.example.com to point to example.com then only the root domain would have to be updated, as all other nodes point to it.

如果使用CNAME记录为www.example.com别名以指向example.com则只需更新根域，其他所有节点都指向该域。

CNAME限制 (CNAME limitations)

At the time when the DNS standards were written, some rules were set out to govern their use. RFC 1912 and RFC 2181 set out that:

在制定DNS标准时，制定了一些规则来管理其使用。 RFC 1912和RFC 2181规定：

• SOA and NS records are mandatory to be present at the root domain

  根域中必须存在SOA和NS记录

• CNAME records can only exist as single records and can not be combined with any other resource record ( DNSSEC SIG, NXT, and KEY RR records excepted)

  CNAME记录只能作为单个记录存在，不能与任何其他资源记录(DNSSEC SIG ， NXT和KEY RR记录除外)结合使用

This excludes a CNAME being used on the root domain, as the two rules would contradict each other.

这不包括在根域上使用的CNAME ，因为这两个规则会相互矛盾。

What’s important here is that this is a contractual limitation, not a technical one. It is possible to use a CNAME at the root, but it can result in unexpected errors, as it is breaking the expected contract of behavior.

这里重要的是，这是合同限制，而不是技术限制。 可以在根目录使用CNAME ，但由于它破坏了预期的行为约定，因此可能导致意外错误。

An example of this is told by Cloudflare, describing problems they encountered with Microsoft Exchange mail servers after having used a CNAME on their root domain:

Cloudflare讲述了一个这样的示例，描述了他们在根域上使用CNAME之后在Microsoft Exchange邮件服务器上遇到的问题：

Domains generally designate the servers that handle their email through what’s known as a MX Record. The problem was that Exchange servers … could pick up the CNAME at the root record and then not properly respect the CNAME set at the MX record. You can’t really blame Exchange. They were operating under the assumptions laid out by the DNS specification.

域通常指定通过所谓的MX记录来处理其电子邮件的服务器。 问题是Exchange服务器…可能会在根记录中选择CNAME，然后不能正确遵守MX记录中设置的CNAME。 您不能真正责怪Exchange。 它们是在DNS规范提出的假设下运行的。

Here you see the downside that can appear in several server softwares or libraries. Because a standard is in place for a CNAME to be the only record at a node, no other records are looked for. All other records will be silently ignored, without warning or error messages. Even if an MX record was set to receive email, the MX will be ignored as if it doesn’t exist because the CNAME is evaluated first. The same is true if there were an A record: the CNAME would take precedence and the A record would not be read.

在这里，您会看到可能出现在几种服务器软件或库中的缺点。 由于已经建立了将CNAME作为节点上唯一记录的标准，因此不会寻找其他记录。 所有其他记录将被静默忽略，而不会发出警告或错误消息。 即使将MX记录设置为接收电子邮件，该MX也将被忽略，因为它不存在，因为会首先评估CNAME 。 如果有一条A记录，也是这样： CNAME优先，并且A记录不会被读取。

现代互联网 (The modern internet)

So why is this a problem? Why would you ever want to use a CNAME for your root domain anyway? Surely that is the end of the path when looking for the IP address of the web server hosting your content?

那么为什么这是一个问题呢？ 您为何仍要为根域使用CNAME ？ 当寻找托管您内容的Web服务器的IP地址时，路径肯定结束了吗？

In the modern internet landscape, that is no longer the case. The world is very different from when the DNS standards were written.

在现代互联网环境中，情况已不再如此。 与编写DNS标准时的世界大不相同。

You may choose to use a Platform as a Service (PaaS) provider like Heroku and store content on their web servers. You control the content, but not the infrastructure, and the PaaS provider does the heavy lifting of the network maintenance. They typically provide you with a URL (my-app.herokuapp.com) that is a subdomain of their root domain, and you can view the IP addresses for the web server(s) your content is on. But these are entirely under the PaaS provider’s control, and will change without warning.

您可以选择使用像Heroku这样的平台即服务(PaaS)提供程序，并将内容存储在其Web服务器上。 您可以控制内容，但不能控制基础结构，而PaaS提供程序可以极大地减轻网络维护的负担。 他们通常为您提供URL( my-app.herokuapp.com )，该URL是其根域的子域，并且您可以查看内容所在的Web服务器的IP地址。 但是这些完全在PaaS提供商的控制之下，并且会随时更改而不会发出警告。

The scale and frequency of backend changes made by the PaaS provider can make it hard to maintain your root domain A record pointing at a single IP address. Ideally you would wish to do this:

PaaS提供商进行的后端更改的规模和频率可能使维护指向单个IP地址的根域A记录变得困难。 理想情况下，您希望这样做：

example.com      IN   CNAME    my-app.herokuapp.com.www.example.com  IN   CNAME    my-app.herokuapp.com.example.com      IN   CNAME    my-app.herokuapp.com.
www.example.com  IN   CNAME    my-app.herokuapp.com.

to allow Heroku (or your chosen host provider) to manage updating the A record that the CNAME points to without any changes made on your side. However, as we now know, this breaks the DNS specification, so is a very bad idea.

允许Heroku(或您选择的托管服务提供商)管理CNAME指向的A记录的更新，而无需您做任何更改。 但是，正如我们现在所知，这违反了DNS规范，所以这是一个非常糟糕的主意。

It is possible to simply implement a 301/302 redirect from example.com to www.example.com. However, that instruction takes place either on the web server (so still having the problem of needing to use a fixed A record in DNS to point to that web server), or a custom DNS provider redirect (that suffers complications with HTTPS).

可以简单地实现从example.com到www.example.com.的301/302重定向www.example.com. 但是，该指令发生在Web服务器上(因此仍然存在需要在DNS中使用固定的A记录指向该Web服务器的问题)或自定义DNS提供程序重定向( 使用HTTPS会带来麻烦 )。

This also has the side effect of changing the domain that you see in the URL bar, which you may not want. This method is intended for when your website has permanently moved, or when you’re trying to preserve SEO rankings, rather than solving our problem of pointing to a complex changing backend in a scaleable way.

这也具有更改您可能不希望在URL栏中看到的域的副作用。 此方法适用于您的网站永久移动或试图保留SEO排名的情况 ，而不是解决我们的问题，即以可伸缩的方式指向复杂的不断变化的后端。

解决方案 (The solution)

Several DNS providers have now developed custom solutions to work around this problem, including:

现在，一些DNS提供商已经开发了解决此问题的自定义解决方案，包括：

• ALIAS at DNSimple

  DNSimple的ALIAS

• ANAME at DNS Made Easy

  DNS轻松实现ANAME

• ANAME at easyDNS

  easyDNS的ANAME

• CNAME (virtual) at CloudFlare

  CloudFlare的CNAME (虚拟)

These are all virtual record types that provide CNAME like behaviour, with none of the downsides. The exact implementation can differ, but at a high level when the DNS server sees one of these virtual record types, it acts as a DNS resolver. It follows the chain created by the alias until it resolves at an A record (or records) and returns these A records to the DNS server. This ‘flattens’ the CNAME chain into the A record(s) returned, and is indistinguishable to the sent query. The query sees only a pure A record, which doesn’t break the DNS specification, and doesn’t have any of the disadvantages of a CNAME.

这些都是提供CNAME行为的虚拟记录类型，没有缺点。 确切的实现可能有所不同，但是在较高级别上，当DNS服务器看到这些虚拟记录类型之一时，它将充当DNS解析器。 它遵循别名创建的链，直到解析为一个A记录(或多个记录)并将这些A记录返回到DNS服务器。 这会将CNAME链“拉平”到返回的A记录中，与发送的查询没有区别。 该查询仅看到纯A记录，该记录没有违反DNS规范，并且没有CNAME任何缺点。

These virtual records can sit alongside other records at the root without any fear of unintended behaviours. Depending on the provider’s method of DNS resolution when following the CNAME chain, they may also have performance benefits from caching previous lookups.

这些虚拟记录可以与其他记录一起位于根目录，而无需担心意外行为。 根据遵循CNAME链时提供商的DNS解析方法的不同，它们还可以通过缓存以前的查询而获得性能上的好处。

For a DNSimple setup, we would then configure as below. This solution has all the advantages of domain name aliasing, and none of the risks of using it at root level.

对于DNSimple设置，我们将进行如下配置。 此解决方案具有域名别名的所有优点，并且没有在根级别使用它的风险。

example.com      IN   ALIAS    my-app.herokuapp.com.www.example.com  IN   CNAME    my-app.herokuapp.com.

Thanks for reading! ?

谢谢阅读！ ？

As always, open to any corrections or additional points.

与往常一样，可以进行任何更正或其他要点。

翻译自: https://www.freecodecamp.org/news/why-cant-a-domain-s-root-be-a-cname-8cbab38e5f5c/

微软dns能做cname吗