微軟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.

這篇文章將使用上述問題從初學(xué)者的角度探討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.

  域名系統(tǒng) (DNS)：將人類難忘的域名(example.com)轉(zhuǎn)換為IP地址(93.184.216.34)的整體系統(tǒng)。 IP地址是服務(wù)器(通常是Web服務(wù)器)的IP地址，其中存儲(chǔ)了顯示網(wǎng)頁(yè)所需的文件。

• 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服務(wù)器 (也稱為名稱服務(wù)器或名稱服務(wù)器)：使用DNS軟件存儲(chǔ)有關(guān)域地址的信息。 有幾個(gè)級(jí)別-屬于每個(gè)ISP，根(全球共有13個(gè))，頂級(jí)域(TLD，例如“ .com”)和域DNS服務(wù)器。

• 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)組合。 術(shù)語“域”通常與域名同義使用， 盡管它們是不同的 。 當(dāng)您從注冊(cè)商或轉(zhuǎn)售商處購(gòu)買“域名”時(shí)，即購(gòu)買了特定域名(example.com)以及您要?jiǎng)?chuàng)建的任何子域(my-site.example.com，mail.example.com，等等)。

高級(jí)查詢流程 (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:

可以簡(jiǎn)化在瀏覽器中鍵入“ example.com”時(shí)發(fā)生的高級(jí)操作，以刪除到ISP，根和TLD DNS服務(wù)器的躍點(diǎn)，如下所示：

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

域通常具有兩個(gè)或多個(gè)名稱服務(wù)器，其中包含與域名(example.com)有關(guān)的記錄。

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

可以存儲(chǔ)多種類型的記錄，每種類型中的大多數(shù)可以具有多個(gè)條目：

• 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 ：規(guī)范名稱記錄。 用于將一個(gè)域名(或子域名)別名為另一個(gè)。 我們將在后面詳細(xì)介紹。

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

  MX ：郵件eXchange記錄，告訴電子郵件傳遞代理他們應(yīng)該在哪里傳遞您的電子郵件

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

  TXT ：靈活的文本記錄，用于存儲(chǔ)各種用途的字符串

• 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 ：單一的“開始授權(quán)”記錄保存在域的頂層。 包含有關(guān)域的特定必需信息，例如其主域名服務(wù)器

• NS: The name servers associated with the domain

  NS ：與域關(guān)聯(lián)的名稱服務(wù)器

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.

當(dāng)您的設(shè)備發(fā)送查詢到達(dá)名稱服務(wù)器時(shí)，該服務(wù)器在域的記錄節(jié)點(diǎn)中查找A記錄以及關(guān)聯(lián)的存儲(chǔ)IP地址(example.com：93.184.216.34)。 然后將其返回給設(shè)備，用于將請(qǐng)求發(fā)送到正確的Web服務(wù)器以檢索請(qǐng)求的網(wǎng)頁(yè)或資源。

使用“挖” (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服務(wù)器的命令行工具。 該命令通常用于故障排除，或者如現(xiàn)在一樣，以了解有關(guān)系統(tǒng)設(shè)置的更多信息。

$ 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導(dǎo)致打印到終端的響應(yīng)很長(zhǎng)，這是此處詳細(xì)介紹的默認(rèn)輸出 ，我們對(duì)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 。 如果多個(gè)Web服務(wù)器可以提供所需的信息，則有時(shí)域?qū)⒕哂卸鄠€(gè)A記錄。

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

還有更多！ 如果我們嘗試其他一些示例，我們很快就會(huì)看到另一個(gè)通用記錄出現(xiàn)了： 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.192www.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標(biāo)志可以使我們清楚地看到形成的路徑：

$ 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記錄允許將域名用作另一個(gè)規(guī)范(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服務(wù)器返回CNAME記錄時(shí)，不會(huì)將其返回給客戶端。 而是它將再次查找返回的域名，然后返回A記錄的IP地址。 該鏈可以深入許多CNAME級(jí)別，但是在進(jìn)行緩存之前，多次查找會(huì)對(duì)性能造成輕微影響。

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.

一個(gè)簡(jiǎn)單的例子就是如果您有一臺(tái)服務(wù)器來保存所有照片。 您通常可以通過photos.example.com訪問它。 但是，您可能還希望它允許通過photographs.example.com進(jìn)行訪問。 使之成為可能的一種方式是添加CNAME記錄是點(diǎn)photographs到photos 。 這意味著，當(dāng)有人訪問photographs.example.com他們將被給予相同的內(nèi)容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.

請(qǐng)務(wù)必注意， CNAME在右側(cè)。 左側(cè)是別名或標(biāo)簽。

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.

另一個(gè)常見用途是www子域。 購(gòu)買了example.com您可能還希望輸入www.example.com用戶看到相同的內(nèi)容。

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

在這里值得注意的是example.com可以稱為頂點(diǎn)，根或裸域名。

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.

一種選擇是設(shè)置另一個(gè)A記錄，指向與example.com相同的IP地址。 這是完全有效的，并且是真正的example.com所做的，但是擴(kuò)展性不好。 如果您需要更新example.com指向的IP地址，該怎么辦？ 您還需要針對(duì)www子域以及您可能使用的其他任何域進(jìn)行更新。

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則只需更新根域，其他所有節(jié)點(diǎn)都指向該域。

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標(biāo)準(zhǔn)時(shí)，制定了一些規(guī)則來管理其使用。 RFC 1912和RFC 2181規(guī)定：

• 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記錄只能作為單個(gè)記錄存在，不能與任何其他資源記錄(DNSSEC SIG ， NXT和KEY RR記錄除外)結(jié)合使用

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

這不包括在根域上使用的CNAME ，因?yàn)檫@兩個(gè)規(guī)則會(huì)相互矛盾。

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.

這里重要的是，這是合同限制，而不是技術(shù)限制。 可以在根目錄使用CNAME ，但由于它破壞了預(yù)期的行為約定，因此可能導(dǎo)致意外錯(cuò)誤。

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講述了一個(gè)這樣的示例，描述了他們?cè)诟蛏鲜褂肅NAME之后在Microsoft Exchange郵件服務(wù)器上遇到的問題：

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記錄來處理其電子郵件的服務(wù)器。 問題是Exchange服務(wù)器…可能會(huì)在根記錄中選擇CNAME，然后不能正確遵守MX記錄中設(shè)置的CNAME。 您不能真正責(zé)怪Exchange。 它們是在DNS規(guī)范提出的假設(shè)下運(yùn)行的。

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.

在這里，您會(huì)看到可能出現(xiàn)在幾種服務(wù)器軟件或庫(kù)中的缺點(diǎn)。 由于已經(jīng)建立了將CNAME作為節(jié)點(diǎn)上唯一記錄的標(biāo)準(zhǔn)，因此不會(huì)尋找其他記錄。 所有其他記錄將被靜默忽略，而不會(huì)發(fā)出警告或錯(cuò)誤消息。 即使將MX記錄設(shè)置為接收電子郵件，該MX也將被忽略，因?yàn)樗淮嬖?#xff0c;因?yàn)闀?huì)首先評(píng)估CNAME 。 如果有一條A記錄，也是這樣： CNAME優(yōu)先，并且A記錄不會(huì)被讀取。

現(xiàn)代互聯(lián)網(wǎng) (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?

那么為什么這是一個(gè)問題呢？ 您為何仍要為根域使用CNAME ？ 當(dāng)尋找托管您內(nèi)容的Web服務(wù)器的IP地址時(shí)，路徑肯定結(jié)束了嗎？

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

在現(xiàn)代互聯(lián)網(wǎng)環(huán)境中，情況已不再如此。 與編寫DNS標(biāo)準(zhǔn)時(shí)的世界大不相同。

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這樣的平臺(tái)即服務(wù)(PaaS)提供程序，并將內(nèi)容存儲(chǔ)在其Web服務(wù)器上。 您可以控制內(nèi)容，但不能控制基礎(chǔ)結(jié)構(gòu)，而PaaS提供程序可以極大地減輕網(wǎng)絡(luò)維護(hù)的負(fù)擔(dān)。 他們通常為您提供URL( my-app.herokuapp.com )，該URL是其根域的子域，并且您可以查看內(nèi)容所在的Web服務(wù)器的IP地址。 但是這些完全在PaaS提供商的控制之下，并且會(huì)隨時(shí)更改而不會(huì)發(fā)出警告。

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提供商進(jìn)行的后端更改的規(guī)模和頻率可能使維護(hù)指向單個(gè)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(或您選擇的托管服務(wù)提供商)管理CNAME指向的A記錄的更新，而無需您做任何更改。 但是，正如我們現(xiàn)在所知，這違反了DNS規(guī)范，所以這是一個(gè)非常糟糕的主意。

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).

可以簡(jiǎn)單地實(shí)現(xiàn)從example.com到www.example.com.的301/302重定向www.example.com. 但是，該指令發(fā)生在Web服務(wù)器上(因此仍然存在需要在DNS中使用固定的A記錄指向該Web服務(wù)器的問題)或自定義DNS提供程序重定向( 使用HTTPS會(huì)帶來麻煩 )。

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欄中看到的域的副作用。 此方法適用于您的網(wǎng)站永久移動(dòng)或試圖保留SEO排名的情況 ，而不是解決我們的問題，即以可伸縮的方式指向復(fù)雜的不斷變化的后端。

解決方案 (The solution)

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

現(xiàn)在，一些DNS提供商已經(jīng)開發(fā)了解決此問題的自定義解決方案，包括：

• ALIAS at DNSimple

  DNSimple的ALIAS

• ANAME at DNS Made Easy

  DNS輕松實(shí)現(xiàn)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行為的虛擬記錄類型，沒有缺點(diǎn)。 確切的實(shí)現(xiàn)可能有所不同，但是在較高級(jí)別上，當(dāng)DNS服務(wù)器看到這些虛擬記錄類型之一時(shí)，它將充當(dāng)DNS解析器。 它遵循別名創(chuàng)建的鏈，直到解析為一個(gè)A記錄(或多個(gè)記錄)并將這些A記錄返回到DNS服務(wù)器。 這會(huì)將CNAME鏈“拉平”到返回的A記錄中，與發(fā)送的查詢沒有區(qū)別。 該查詢僅看到純A記錄，該記錄沒有違反DNS規(guī)范，并且沒有CNAME任何缺點(diǎn)。

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.

這些虛擬記錄可以與其他記錄一起位于根目錄，而無需擔(dān)心意外行為。 根據(jù)遵循CNAME鏈時(shí)提供商的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.

對(duì)于DNSimple設(shè)置，我們將進(jìn)行如下配置。 此解決方案具有域名別名的所有優(yōu)點(diǎn)，并且沒有在根級(jí)別使用它的風(fēng)險(xiǎn)。

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.

與往常一樣，可以進(jìn)行任何更正或其他要點(diǎn)。

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

微軟dns能做cname嗎

總結(jié)

以上是生活随笔為你收集整理的微软dns能做cname吗_为什么域的根不能是CNAME以及有关DNS的其他花絮的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。