北京dns服務器ip地址

介紹 (Introduction)

By the end of this article, you should have a better understanding of:

在本文末尾，您應該對以下內容有更好的了解：

What DNS is and what it does
什么是DNS及其作用
What DNS servers do
DNS服務器做什么
How Internet Protocol (IP) Addresses work in the context of DNS
Internet協議(IP)地址如何在DNS上下文中工作

重要概念 (Important concepts)

There are some essential mental models to be familiar with when learning about DNS, DNS servers, and IP addresses. Going over these concepts now, before starting to learn about DNS, will

在學習DNS，DNS服務器和IP地址時，有一些基本的思維模型需要熟悉。在開始了解DNS之前，現在仔細研究這些概念，將會

help make sense of all the different terms used to describe behavior that fits into these models, and
幫助弄清用于描述適合這些模型的行為的所有不同術語，并且
aid in memory retention.
幫助保持記憶。

Mental models give you a frame of reference when things get a little weird and unfamiliar.

當事情變得有些奇怪和陌生時，心理模型會為您提供參考。

So let’s lay the groundwork.

因此，讓我們奠定基礎。

Query and response. This is when Thing 1 asks Thing 2 for something, and Thing 2 responds to that request. Like this:
查詢和響應。這是Thing 1向Thing 2提出要求時，Thing 2響應該請求的時間。像這樣：

Parent-child node relationships and graphs that look like this (only more complicated).
看起來像這樣的父子節點關系和圖(只是更復雜)。

Messages. It’s not a query and response because there is no response. In the world of DNS, the formatting and content of messages vary according to usage.
訊息。這不是查詢和響應，因為沒有響應。在DNS的世界中，消息的格式和內容根據使用情況而有所不同。

Client-server relationship. In simplest terms, a server is a software or hardware device that provides functionality for other software or hardware devices, called “clients.”
客戶-服務器關系。用最簡單的術語來說，服務器是指為其他軟件或硬件設備(稱為“客戶端”)提供功能的軟件或硬件設備。

Client-server relationship. In simplest terms, a server is a software or hardware device that provides functionality for other software or hardware devices, called “clients.”
客戶-服務器關系。用最簡單的術語來說，服務器是指為其他軟件或硬件設備(稱為“客戶端”)提供功能的軟件或硬件設備。

Prepare for a lot of talk about servers. As it turns out, there’s a whole lot of servers that go into this thing we call DNS, and how we, as humans, use it when we connect to the Internet.
準備大量有關服務器的討論。事實證明，有很多服務器都在使用我們稱之為DNS的服務器，以及當我們連接到Internet時，我們作為人類如何使用它。

什么是DNS？ (What is DNS?)

The Domain Name System (DNS) maps human-readable domain names (in URLs or in email address) to IP addresses. For example, DNS translates and maps the domain freecodecamp.org to the IP address 104.26.2.33.

域名系統(DNS)將人類可讀的域名(在URL或電子郵件地址中)映射到IP地址。例如，DNS會將域名freecodecamp.org轉換并映射到IP地址104.26.2.33。

To help you fully understand this description, this section details:

為了幫助您完全理解此描述，本節詳細介紹：

Historical context for the development of DNS - what problems were it and IP addresses solving?
DNS發展的歷史背景-它和IP地址解決了哪些問題？
Domain names
網站域名
IP addresses
IP地址

歷史背景 (Historical Context)

In 1966, the Advanced Research Projects Agency (ARPA), a US government agency, founded a computer network called ARPAnet. In simple terms, think of ARPAnet as the first iteration of what we now know today as the Internet.

1966年，美國政府機構高級研究計劃局(ARPA)建立了一個名為ARPAnet的計算機網絡。簡而言之，可以將ARPAnet視為我們如今所知的Internet的第一版。

The main goals of ARPAnet included

ARPAnet的主要目標包括

“(1) providing reliable communication even in the event of a partial equipment or network failure, (2) being able to connect to different types of computers and operating systems and (3) being a cooperative effort rather than a monopoly controlled by a single corporation. In order to provide reliable communication in the face of equipment failure, ARPANET was designed so that no one point or link was more critical than any other. This was accompanied by the building of redundant routes and the use of on-the-fly rerouting of data if any part of the network failed.”
“(1)即使在部分設備或網絡出現故障的情況下也能提供可靠的通信；(2)能夠連接到不同類型的計算機和操作系統，并且(3)是一種合作而不是由一個人控制的壟斷公司。為了在設備出現故障時提供可靠的通信，ARPANET的設計使任何一個點或鏈接都比其他任何一個都更為關鍵。如果網絡的任何部分發生故障，則需要建立冗余路由并使用實時數據重新路由。 ”

問題所在 (The Problems)

DNS and TCP/IP were critical in solving two issues with ARPAnet:

DNS和TCP / IP對于解決ARPAnet的兩個問題至關重要：

For ARPAnet, there was a single location (a file called HOSTS.TXT) that contained all name-to-address mapping for every host on the network.

對于ARPAnet，只有一個位置(名為HOSTS.TXT的文件)包含網絡上每個主機的所有名稱到地址的映射。

“HOSTS.TXT was maintained by SRI’s Network Information Center (dubbed “the NIC”) and distributed from a single host, SRI-NIC.[*] ARPAnet administrators typically emailed their changes to the NIC, and periodically FTP’ed to SRI-NIC and grabbed the current HOSTS.TXT file. Their changes were compiled into a new HOSTS.TXT file once or twice a week.”
“ HOSTS.TXT由SRI的網絡信息中心 (稱為“ NIC”)維護，并從單個主機SRI-NIC分發。[ * ] ARPAnet管理員通常將其更改通過電子郵件發送到NIC，并定期通過FTP發送到SRI- NIC并獲取了當前的HOSTS.TXT文件。他們的更改每周一次或兩次被編譯到一個新的HOSTS.TXT文件中。 ”

There were three challenges with this set-up:

此設置面臨三個挑戰：

Traffic and load - distributing the file was becoming too much for the responsible host to handle.
流量和負載-分發文件變得過多，負責主機無法處理。
Name collisions - each host had to have a unique name, and there was no centralized authority that prevented network users from adding a host with a conflicting (non-unique) name, thereby “breaking the whole scheme.”
名稱沖突-每個主機都必須有一個唯一的名稱，并且沒有集中的權限來阻止網絡用戶添加具有沖突(非唯一)名稱的主機，從而“破壞了整個方案”。
Consistency - the act of updating the file and ensuring all hosts had the most updated version became impossible or at least very difficult.
一致性-更新文件并確保所有主機具有最新版本的行為變得不可能或至少非常困難。

In essence, HOSTS.TX was a single point of failure, so the entire process here didn’t scale well past a certain number of hosts. ARPAnet needed a decentralized and scalable solution. DNS was it. Source

本質上，HOSTS.TX是一個單點故障，因此此處的整個過程無法很好地擴展到超過一定數量的主機。 ARPAnet需要一個分散和可擴展的解決方案。 DNS就是這樣。資源

Host-to-host communication within the same network wasn’t reliable enough. TCP/IP helped solve this issue.

同一網絡內的主機到主機通信不夠可靠。 TCP / IP幫助解決了這個問題。

Transmission Control Protocol (TCP) provides quality assurance measures for the process of turning messages (between hosts) into packets. The TCP protocol is connection-oriented, which means a connection between source host and destination host must be established.
傳輸控制協議(TCP)為將消息(主機之間)轉換為數據包的過程提供了質量保證措施。 TCP協議是面向連接的，這意味著必須在源主機和目標主機之間建立連接。
Internet Protocol (IP) defines how messages (packets) are carried between source host and destination host. An IP address is a unique identifier for a specific path that leads to a host on a network.
Internet協議(IP)定義了源主機和目標主機之間如何傳送消息(數據包)。 IP地址是通向網絡主機的特定路徑的唯一標識符。
TCP and IP work closely together, which is why they’re usually referenced like “TCP/IP.”
TCP和IP緊密協作，這就是為什么它們通常被稱為“ TCP / IP”的原因。
While I won’t dive into it in this article, both TCP and User Datagram Protocol (UDP) are used in the data transport layer of DNS. UDP is faster, much less reliable, and doesn’t require connections; TCP is slower, much more reliable, but needs connections. They are used as needed and appropriate in DNS; needless to say, the inclusion of TCP in APRAnet was a valuable addition to the data transport layer.
雖然我不會在本文中深入探討，但DNS的數據傳輸層同時使用了TCP和用戶數據報協議(UDP)。 UDP更快，更不可靠，并且不需要連接。 TCP較慢，更可靠，但需要連接。在DNS中根據需要和適當的方式使用它們；不用說，將TCP包含在APRAnet中是對數據傳輸層的寶貴補充。

By the early 1980s, DNS and TCP/IP (and therefore, IP addresses) were standard operating procedures for the ARPAnet.

到1980年代初，DNS和TCP / IP(以及IP地址)已成為ARPAnet的標準操作程序。

This history is very abridged. If you’d like to learn more about these topics, please reference the Resources section at the end of this article.

這段歷史非常簡短。如果您想了解有關這些主題的更多信息，請參考本文末尾的參考資料部分。

Now that we have some historical context, let’s move on to learning more about domain names and IP addresses.

現在我們有了一些歷史背景，讓我們繼續學習有關域名和IP地址的更多信息。

網站域名 (Domain Names)

In the context of DNS, a domain name provides a user-friendly way to point to non-local resources. This could be a website, a mail system, print server, or any other server that is available on the Internet. A domain name can be more than just a website!

在DNS的上下文中，域名提供了一種用戶友好的方式來指向非本地資源。這可以是網站，郵件系統，打印服務器或Internet上可用的任何其他服務器。域名不僅可以是網站！

“The goal of domain names is to provide a mechanism for naming resources in such a way that the names are usable in different hosts, networks, protocol families, internets, and administrative organizations.”
“域名的目標是提供一種資源命名機制，以使名稱可以在不同的主機，網絡，協議族，互聯網和管理組織中使用。 ”

A domain name is much easier to remember and enter into a terminal or Internet browser, than an IP address.

域名比IP地址更容易記住和輸入終端或Internet瀏覽器。

A domain name is part of a Uniform Resource Locator (URL), but the terms are not synonymous. A URL is the complete web address of a resource, while the domain name is the name of a website and is a sub-component of every URL.

域名是統一資源定位器(URL)的一部分，但這些術語不是同義詞 。 URL是資源的完整網址，而域名是網站的名稱，并且是每個URL的子組件。

While there are technical distinctions between URLs and domain names, web browsers usually treat them the same way, so you’ll get to the website if you type in the complete web address, or just the domain name.

雖然URL和域名之間在技術上有所區別，但是Web瀏覽器通常以相同的方式對待它們，因此，如果您輸入完整的Web地址或僅輸入域名，您將進入網站。

頂級域和二級域 (Top Level Domains and Second Level Domains)

There are two parts to any given domain: top-level domain (TLD) and second-level domain (SLD). The parts of a domain name become more specific when moving from the right (end) to the left (beginning).

任何給定域都有兩個部分：頂級域(TLD)和二級域(SLD)。從右(結束)到左(開始)時，域名的各個部分變得更加具體。

This can be confusing at first. For example, let’s look at “freecodecamp.org”

起初這可能會造成混淆。例如，讓我們看一下“ freecodecamp.org”

URL: https://www.freecodecamp.org
網址：https：//www.freecodecamp.org
Domain name: freecodecamp.com
域名：freecodecamp.com
TLD: org
TLD：org
SLD: freecodecamp
SLD：freecodecamp

In the early days of ARPAnet, there were a limited number of TLDs available, including com, edu, gov, org, arpa, mil, and 2-letter country code domains. These TLDs were initially reserved for institutions participating in the ARPAnet, but some later became available on commercial markets.

在ARPAnet成立之初，可用的TLD數量有限，包括com，edu，gov，org，arpa，mil和2個字母的國家/地區代碼域。這些TLD最初是為參加ARPAnet的機構保留的，但后來在商業市場上可用。

Today, there is a comparative wealth of available TLDs, including net, aero, biz, coop, info, museum, name, and others.

如今，有相當數量的可用TLD，包括網絡，航空，商務，合作社，信息，博物館，名稱等。

Second-level domains are the domains that are available for individual purchase through domain registrars (for example, Namecheap).

二級域名是可以通過域名注冊商(例如Namecheap)個人購買的域名。

IP地址 (IP Addresses)

While IP addresses are related to DNS in their function, the Internet Protocol itself is technically separate from DNS. I’ve already provided historical context for this distinction, so now I’ll explain how IP addresses function.

盡管IP地址在功能上與DNS相關，但是Internet協議本身在技術上與DNS是分開的。我已經為這種區別提供了歷史背景，因此現在我將解釋IP地址的功能。

An IP address, as previously mentioned, is a unique identifier for a specific path that leads to a host on a network. I’d like to reference the analogy of a phone number and a phone: a phone number doesn’t represent the phone itself, it’s just a way to reach the person with the phone.

如前所述，IP地址是指向網絡上主機的特定路徑的唯一標識符。我想引用一個電話號碼和一個電話的類比：電話號碼并不代表電話本身，它只是一種聯系電話對象的方式。

This analogy is reasonably appropriate (at least, on a surface level), with IP addresses. An IP address represents an endpoint, but it isn’t the endpoint itself. IP assignments can be fixed (permanent) or dynamic (flexible and may be reassigned).

用IP地址這種類比是合理的(至少在表面上)。 IP地址代表一個端點，但不是端點本身。 IP分配可以是固定的(永久的)，也可以是動態的(靈活的，可以重新分配)。

Like a domain name, the organization of IP addresses follows a hierarchical structure. Unlike domain names, IP addresses get more specific going left-to-right. This is an IPv4 example below:

像域名一樣，IP地址的組織遵循分層結構。與域名不同，IP地址的具體含義從左到右。這是下面的IPv4示例：

Network: the unique number assigned to your network
網絡：分配給您的網絡的唯一編號
Host: identifies the host (machine) on the network
主機：標識網絡上的主機(機器)

If greater specificity is needed, network administrators can subnet the address space and delegate additional numbers.

如果需要更高的特異性，網絡管理員可以將地址空間劃分為子網，并委派其他號碼。

有多少個IP地址？ (How many IP addresses are there?)

IPv4 was the very first iteration of IP that ARPAnet used in production. Deployed in the early 80s, it’s still the most prevalent IP version. It’s a 32-bit scheme, and can therefore support slightly over 4 billion addresses.

IPv4是ARPAnet在生產中使用的IP的第一個迭代。部署于80年代初期，它仍然是最流行的IP版本。這是一種32位方案，因此可以支持略超過40億個地址。

But wait, is that enough? Nope.

但是等等，夠了嗎？不。

IPv6 has a 128-bit scheme, which allows it to support 340 undecillion addresses. It also offers performance improvements on IPv4.

IPv6具有128位方案，從而可以支持340個十億地址。它還可以改善IPv4的性能。

Example IPv4 address:

示例IPv4地址：

104.26.2.33 (freeCodeCamp)
104.26.2.33(freeCodeCamp)

Example IPv6 address:

IPv6地址示例：

2001:db8:a0b:12f0::1 (the compressed format and not pointing to freeCodeCamp)
2001：db8：a0b：12f0 :: 1(壓縮格式，不指向freeCodeCamp)

域名系統如何工作？ (How does the Domain Name System work?)

So, we’ve learned about domain names! We’ve learned about IP addresses! Now how do they relate to the Domain Name System?

因此，我們已經了解了域名！我們已經了解了IP地址！現在它們與域名系統有什么關系？

First of all, they fit into the namespace.

首先，它們適合命名空間。

域名空間 (The Domain Namespace)

As implied by the language “top” level domain and “second” level domain, the namespace is based on a hierarchy

正如“頂級”域和“第二”級域所暗示的那樣，名稱空間基于層次結構

“...with the hierarchy roughly corresponding to organizational structure, and names using "." as the character to mark the boundary between hierarchy levels.” Source.
“ ...的層次結構大致對應于組織結構，并使用“。”命名。作為標記層次結構之間邊界的字符。” 來源。

This tree graph, with the root at the top, best illustrates the structure:

該樹形圖的根在頂部，最能說明該結構：

Let’s break this down, starting at the top.

讓我們從頂部開始進行分解。

The top of this graph, noted with a “.” is called the “root.”

該圖的頂部用“。”標記被稱為“根”。

“The authoritative name servers that serve the DNS root zone, commonly known as the “root servers”, are a network of hundreds of servers in many countries around the world. They are configured in the DNS root zone as 13 named authorities.”
“為DNS根目錄區域提供服務的權威名稱服務器，通常稱為“根服務器”，是由世界許多國家的數百個服務器組成的網絡。它們在DNS根區域中配置為13個命名機構。 ”

The root domain has a zero-length label.

根域的長度為零。

From here-on down, each node (dot) in the graph has a unique label up to 63 characters long.

從現在開始，圖形中的每個節點(點)都有一個唯一的標簽，最長為63個字符。

The first level down from the root are the TLDs: the com, org, edu, and gov. Please note that this graph does not contain a full list of TLDs.

從根目錄開始的第一層是TLD：com，org，edu和gov。請注意，此圖不包含TLD的完整列表。

Below TLDs are the SLDs, the second-level domains. The children of each node are called “subdomains,” which are still considered part of the parent domain. For example, in freecodecamp.org, freecodecamp (the SLD) is a subdomain of org (the TLD).

TLD下方是SLD，即二級域。每個節點的子節點稱為“子域”，仍被視為父域的一部分。例如，在freecodecamp.org中，freecodecamp(SLD)是org(TLD)的子域。

Depending on the hierarchy of the website, there may be third-, fourth, fifth- level domains. For example, in hypothetical-subdomain.freecodecamp.org, hypothetical-subdomain is the third-level domain, and the subdomain of freecodecamp. So on and so forth, at least up to 127 levels, which is the maximum allowed by DNS.

根據網站的層次結構，可能會有第三，第四，第五級域。例如，在hypothetical-subdomain.freecodecamp.org中，hypothetical-subdomain是第三級域，也是freecodecamp的子域。依此類推，至少達到127個級別，這是DNS所允許的最大值。

誰管理名稱空間？ (Who manages the namespace?)

Wouldn’t it be nuts to try to have one person or organization administer everything? Yes, it would. Especially because one of the chief design goals of DNS was to promote distributed, decentralized management of the system at large.

嘗試讓一個人或組織來管理所有事情不是很瘋狂嗎？是的，會的。特別是因為DNS的主要設計目標之一是促進整個系統的分布式，分散式管理。

I wish I could tell you the folks in charge are called the “Namespace Kings,” but alas.

我希望我能告訴您負責的人被稱為“命名空間之王”，但是a。

Each domain (or subdomain) in the domain namespace is or is part of a zone, “an autonomously administered piece of the namespace.” So, the namespace is broken into zones.

域名稱空間中的每個域(或子域)都屬于區域 “ 區域名稱 ”的一部分，或者是該區域的一部分。因此，名稱空間分為多個區域。

Responsibility for those zones is managed through delegation and administration.

這些區域的責任通過授權和管理來管理。

The process of assigning the responsibility of subdomains to other entities is called delegation.

將子域的職責分配給其他實體的過程稱為委托。

For example, the Public Interest Registry administers the domain name org, and has since 2003. Public Interest Registry may delegate responsibility to other parties to manage subdomains of org, say freecodecamp. And then whoever administers freecodecamp may assign responsibility for the subdomains of freecodecamp (for example, hypothethical-subdomain.freecodecamp.com) to another party.

例如，公共利益注冊機構管理著域名org，并且自2003年以來一直運營。公共利益注冊機構可以將責任委托給其他方來管理組織的子域，例如freecodecamp。然后，負責管理freecodecamp的人可以將對freecodecamp的子域(例如，hypothethical-subdomain.freecodecamp.com)的責任分配給另一方。

If someone (an organization, team, or individual) administers a zone, what they’re doing is administering the nameserver that is responsible for the zone.

如果某人(組織，團隊或個人)管理區域，那么他們正在做的事情就是管理負責該區域的名稱服務器。

This brings us into one of the most foundational concepts in the Domain Name System.

這使我們進入了域名系統中最基礎的概念之一。

域名服務器 (Domain Name Servers)

“The programs that store information about the domain namespace are called nameservers.”
“存儲有關域名稱空間信息的程序稱為名稱服務器。 ”

At this point is where thinking about a client-server relationship, at least initially, is useful. Domain nameservers are the “server” side of the client-server relationship. Nameservers may load one, hundreds, or even thousands of zones, but they never load the entire namespace. Once a nameserver has loaded the totality of a zone, it is said to be authoritative for that zone.

在這一點上，至少在最初考慮客戶端-服務器關系是有用的。域名服務器是客戶端-服務器關系的“服務器”端。名稱服務器可以加載一個，數百甚至數千個區域，但是它們從不加載整個名稱空間。一旦名稱服務器加載了整個區域，就可以說該服務器是該區域的權威。

To understand why nameservers function the way they do, it’s useful to understand the “client” part of the relationship.

要了解名稱服務器為何以這種方式發揮作用，了解關系的“客戶端”部分很有用。

解析器 (Resolvers)

In DNS, the client (the requester of information) is called the “resolver,” which may seem backward at first. Wouldn’t the server that is resolving the request be called the “resolver?” I thought so, too, but it’s not. Best to just memorize that and move on.

在DNS中，客戶端(信息的請求者)被稱為“解析器”，乍一看似乎是倒退的。解析請求的服務器不會被稱為“解析器”嗎？我也這樣認為，但事實并非如此。最好只是記住并繼續前進。

Resolvers are typically included, de facto, in most operating systems, so the applications installed on the OS don’t have to figure out how to make low-level DNS queries.

實際上，大多數操作系統通常都包含解析器，因此，操作系統上安裝的應用程序不必弄清楚如何進行低級DNS查詢。

DNS queries and their responses are types of DNS messages, and have their own data transport protocol (usually UDP). Resolvers are responsible for helping applications installed on the OS translate requests for DNS-related data into DNS queries.

DNS查詢及其響應是DNS消息的類型，并且具有自己的數據傳輸協議(通常為UDP)。解析程序負責幫助操作系統上安裝的應用程序將對DNS相關數據的請求轉換為DNS查詢。

In sum, resolvers are responsible for packaging and sending off requests for data. Once the resolver receives the response (if at all), it passes that back to the original requesting application in a format consumable to the requesting application.

總之，解析器負責打包和發送數據請求。解析器一旦收到響應(如果有的話)，便會將其以消耗給請求應用程序的格式傳遞回原始請求應用程序。

返回名稱服務器 (Back to Nameservers)

Now that we are a bit more familiar with the client-side of the relationship, we need to understand how domain nameservers respond to resolver queries.

現在，我們對這種關系的客戶端有了更多的了解，我們需要了解域名服務器如何響應解析器查詢。

Nameservers respond to DNS queries through resolution. Resolution is the process by which nameservers find datafiles in the namespace. Depending on the type of query, nameservers respond differently to different queries, but the end goal is resolution.

域名服務器通過解析來響應DNS查詢。解析是名稱服務器在名稱空間中查找數據文件的過程。根據查詢的類型，名稱服務器對不同查詢的響應方式不同，但是最終目標是解析。

查詢類型 (Query Types)

Type of query? Yes, there are multiple types of DNS queries. But first, what’s usually in a DNS query? It’s a request for information, specifically for the IP address associated with a domain name.

查詢類型？是的，有多種類型的DNS查詢。但是首先，DNS查詢通常是什么？這是對信息的請求，特別是對于與域名關聯的IP地址的信息。

Recursive: recursive queries allow the query to be referred on to multiple nameservers to be resolved. If the first queried nameserver doesn’t have the desired data, then that nameserver sends the query along to the most appropriate next nameserver, until the nameserver with the desired datafiles is found and sends a response to the resolver.
遞歸：遞歸查詢允許將查詢引用到多個要解析的名稱服務器上。如果第一個查詢的名稱服務器沒有所需的數據，則該名稱服務器會將查詢發送到最合適的下一個名稱服務器，直到找到具有所需數據文件的名稱服務器，并將響應發送到解析器。
Iterative: iterative queries require the queried nameserver to respond either with the desired data or with an error. The response may contain the IP address of the most appropriate nameserver to send the request to next; the resolver may then send another request to that, more appropriate, nameserver.
迭代：迭代查詢需要查詢的名稱服務器以所需的數據或錯誤進行響應。響應中可能包含最合適的名稱服務器的IP地址，以將請求發送到下一個；解析器然后可以向該更合適的名稱服務器發送另一個請求。

In case you need it, you can also query for the domain name, if all you have is the IP address. This is called a reverse DNS lookup.

如果您需要的話，如果您只有IP地址，也可以查詢域名。這稱為反向DNS查找。

Once the query reaches a nameserver that contains the desired datafiles, then the query can be resolved. Nameservers have a number of datafiles associated with them, all or some of which may be used to resolve the query.

一旦查詢到達包含所需數據文件的名稱服務器，就可以解決該查詢。名稱服務器具有許多與之關聯的數據文件，所有或部分數據文件可用于解析查詢。

資源記錄(RR) (Resource Records (RRs))

These are the datafiles in the domain namespace. These datafiles have specific formats and contents.

這些是域名稱空間中的數據文件。這些數據文件具有特定的格式和內容。

The most common RRs:

最常見的RR：

A Record: if you haven’t heard of any other RRs except for this one, that would make sense. It’s likely the best-known RR and contains the IP address of the given domain.
記錄：如果您除了此以外沒有其他RR，那將是有道理的。它可能是最著名的RR，并且包含給定域的IP地址。
CNAME Record: if you haven’t heard of any other RRs except for this one and the A record, that would also make sense. The “C” stands for “canonical”, and is used instead of an A record, to assign an alias to a domain.
CNAME記錄：如果除了此記錄和A記錄之外，您還沒有聽說過其他任何RR，那也很有意義。 “ C”代表“規范”，并且代替A記錄用于為域分配別名。
SOA Record: this record contains administrative information about the one, including the email address of the administrator. Hint: if you administer a zone, make sure there’s a valid email address here, so folks can get in touch with you if needed.
SOA記錄：此記錄包含有關該記錄的管理信息，包括管理員的電子郵件地址。提示：如果您管理區域，請確保此處有一個有效的電子郵件地址，以便人們在需要時可以與您聯系。
Other important Resource Record (RR) types are PR, NS, SRV, and MX. Read about them here.
其他重要的資源記錄(RR)類型是PR，NS，SRV和MX。在這里閱讀有關它們的信息。

緩存和生存時間(TTL) (Caching and Time to Live (TTL))

When the local nameserver receives a response from a query, it caches that data (stores it in memory), so next time it receives the same query, it can just answer the query directly rather than go through the original, longer resolution process.

當本地名稱服務器收到查詢的響應時，它會緩存該數據(將其存儲在內存中)，因此，下次它收到相同的查詢時，它可以直接回答查詢，而無需經過原始的較長解析過程。

But once this information is cached, it is both static and isolated, and is therefore at risk of becoming out of date. Therefore, resource records all have what is called a time to live (TTL) value, which dictates how long that data can be cached. When that time runs out (reaches zero), the nameserver deletes the record.

但是，一旦此信息被緩存，它既是靜態的又是孤立的，因此有過時的風險。因此，所有資源記錄都具有所謂的生存時間 (TTL)值，該值指示可以將數據緩存多長時間。當時間用完(達到零)時，名稱服務器將刪除記錄。

Important note: TTL doesn’t apply to the name servers that are authoritative for the zone that contains the resource record. It just applies to the nameserver that cached that resource record.

重要說明：TTL不適用于對包含資源記錄的區域具有權威性的名稱服務器。它僅適用于緩存該資源記錄的名稱服務器。

查詢生命中的一天 (A Day in the Life of a Query)

We’ve covered a lot of ground in this article, and it’s been heavy on the concepts. To tie this all together and make it real, here’s a day (figurative day) in the life of a query.

我們在本文中介紹了很多基礎知識，并且對概念進行了大量的介紹。為了將所有這些聯系在一起并使其成為現實，這是查詢生命中的一天(象征性的一天)。

那么，為什么我需要了解所有這些？ (So why do I need to know all of this?)

There are so many reasons to be familiar with DNS and IP address related concepts.

熟悉DNS和IP地址相關概念的原因有很多。

First, it’s a backbone of the Internet, the thing many of us use, develop feelings for (love/hate/you-name-it), and take for granted every day. It’s important to be familiar with the structures that enable us to accomplish great things today with technology and the Internet today.
首先，它是互聯網的中堅力量，是我們許多人使用的東西，對(愛/恨/你的名字)產生感情，并且每天都在理所當然。重要的是要熟悉使我們能夠利用當今的技術和Internet成就偉大成就的結構。
Incredibly smart people spent decades of their lives building this stuff! Let’s acknowledge and appreciate their contributions.
令人難以置信的聰明人花了數十年的時間來建造這種東西！讓我們感謝并感謝他們的貢獻。
Now that I got the gushy stuff out of the way, it’s important to be familiar with DNS concepts in case you’re responsible for anything relating to infrastructure in your company or team or your own business. Having a frame of reference when significant issues crop up allows you to act that much faster and find solutions that much sooner.
現在，我已經擺脫了麻煩的東西，重要的是要熟悉DNS概念，以防您負責與公司，團隊或您自己的企業中的基礎結構有關的任何事情。當重大問題浮出水面時，有了參考框架可以使您更快地采取行動，并更快地找到解決方案。

結論 (Conclusion)

At this point, you should understand what DNS is and what a nameserver is, as well as be familiar with technical concepts relating to IP addresses.

在這一點上，您應該了解什么是DNS，什么是名稱服務器，以及熟悉與IP地址有關的技術概念。

Many books have been written about and dive deeper into the fascinating world of DNS, and there is so much more to learn. The topics that were not included in this article but are either part of DNS or very related include:

已經寫了許多書籍，并且深入探討了迷人的DNS世界，還有很多東西要學習。本文未包含但與DNS無關或相關性很強的主題包括：

Nameserver implementations
名稱服務器的實現
Forwarding
轉寄
(More about) node labels
(更多關于)節點標簽
Primary and secondary nameserver relationships
主要和輔助名稱服務器關系
Retransmission algorithms
重傳算法
Load balancing
負載均衡
Plus, other more general topics about the how the Internet functions, like:
另外，還有其他有關Internet工作原理的更一般的主題，例如：
World Wide Web
全球資訊網
HTTP
HTTP
FTP
的FTP
Communication protocol layers: link layer, IP layer, transport layer, Internet layer, etc.
通信協議層：鏈路層，IP層，傳輸層，Internet層等

For those of you who are still reading and want to learn more about DNS, I first and foremost recommend “DNS and BIND, 5th Ed.”, written by Cricket Liu and published by O’Reilly Media. It’s invaluable.

對于那些仍在閱讀和要想了解有關DNS的更多信息，我首先推薦由Cricket Liu撰寫并由O'Reilly Media出版的“ DNS和BIND，第5版”。這是無價的。

I also encourage everyone to poke around in the original Request for Comments (RFCs) linked below. Not only are there points for reading primary sources, but they’re also exceptionally well-organized and comprehensible documents, which is why I quoted them in this article.

我還鼓勵大家在下面鏈接的原始“征求意見”(RFC)中四處摸索。不僅有閱讀原始資料的要點，而且它們是組織得很好且易于理解的文檔，這就是我在本文中引用它們的原因。

資源資源 (Resources)

RFC 1034: DOMAIN NAMES - CONCEPTS AND FACILITIES
RFC 1034：域名-概念和功能
RFC 1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
RFC 1035：域名-實施和規范
RFC 1122: Requirements for Internet Hosts -- Communication Layers
RFC 1122：Internet主機的要求-通信層
More about DNS Design Goals, from Connected: An Internet Encyclopedia
有關“互聯網絡：DNS百科全書”的DNS設計目標的更多信息
How the Internet was Born from the ARPAnet to the Interpret, from The Conversation
互聯網是如何從ARPAnet誕生到口譯的，來自The Conversation
Learning DNS Video Course, by Cricket Liu, from O'Reilly Media
O'Reilly Media的Cricket Liu撰寫的學習DNS視頻課程

關于我的一點 (A bit about me)

I'm Chloe Tucker, an artist and developer in Portland, Oregon. As a former educator, I'm continuously searching for the intersection of learning and teaching, or technology and art. Reach out to me on Twitter @_chloetucker and check out my website at chloe.dev.

我是俄勒岡州波特蘭市的藝術家兼開發商Chloe Tucker。作為前教育工作者，我一直在尋找學與教，技術與藝術的交集。伸手到我的Twitter上@_chloetucker ，并在檢查了我的網站chloe.dev 。