DNS:關于 DNS 基本概念的一些筆記整理

簡單介紹
DNS(DNS-Domain Name System) ,中文名即域名系統(tǒng)，簡單理解，即將域名和 IP 地址相互映射的一個分布式數(shù)據(jù)庫，用于 域名解析IP地址，IP地址反向解析域名 ,能夠使人更方便地訪問互聯(lián)網(wǎng)。DNS 使用 TCP 和 UDP 端口 53,系統(tǒng)內存儲了 網(wǎng)絡主機地址和資源目錄 的一個分層命名系統(tǒng)。分層類似樹一樣。

這里的 資源目錄 指將 域名 映射到不同 資源記錄。并保存在稱為 資源記錄 的邏輯條目中。

DNS 層次結構從頂部的 根域(.) 開始，向下分支到多個下一級域。DNS 層次結構的每一層都由域名中的 . 描述，. 是最頂層。域名如.com、.Net和.org 占據(jù)層次結構的第二層，例如example.com,占據(jù)在第三層, liruilongs.github.io占據(jù)第四層。

在全球互聯(lián)網(wǎng)中，部署 DNS 服務中存放最高級別的域名的服務器，稱之為 根服務器。負責返回頂級域名的權威域名服務器的地址，按照解析 IP 來分，有 IPV4 和 IPV6 兩種，按照服務器類型分，分為 主根服務器 和 輔根服務器,或者可在加一個 鏡像服務器

IPV4
最早是 IPV4，全球只有 13 臺(這 13 臺 IPv4 根域名服務器名字分別為“A”至“M”)，1 個為主根服務器在美國，由美國互聯(lián)網(wǎng)機構 Network Solutions 運作。其余 12 個均為輔根服務器，其中 9 個在美國， 2 個在歐洲(位于英國和瑞典)， 1 個在亞洲(位于日本)。

實際上 DNS 根域名服務器并不真的只有 13 臺，而是 13 個 IP，對應了 A-M 13 個編號，借由任播(Anycast)技術，編號相同的根服務器使用同一個 IP(類似一個集群)。截至 2014 年 10 月，全球有 504 臺根服務器，被編號為 A 到 M 共 13 個標號。504 臺根服務器大部分借由任播(Anycast)技術，編號相同的根服務器使用同一個 IP，504 臺根服務器總共只使用 13 個 IP，因此可以抵抗針對其所進行的分布式拒絕服務攻擊(DDoS)。

中國的鏡像服務器：

中國大陸在北京有三臺編號為 L 的鏡像，編號為 F、I、J 的鏡像各一臺，共 6 臺
香港有編號為 D、J 的鏡像各 2 臺，編號為 A、F、I、L 的鏡像各一臺，共 8 臺
臺灣有編號為 F、I、J 各一臺，共 3 臺。
為什么根服務器只有 13 臺 ?

DNS 協(xié)議的最初定義要從 20 世紀 80 年代未期開始算起，它使用了 UDP 和 TCP 協(xié)議。UDP 通常用于 DNS 解析查詢和響應，TCP 用于 DNS 主服務器和從服務器之間的區(qū)域數(shù)據(jù)傳送。

遺憾的是，在所有 UDP 實現(xiàn)中能保證正常工作的最大包是 512 字節(jié)，對于在每個包中必須含有數(shù)字簽名的一些 DNS 新特性(例如，DNSSEC)來說實在是太小了。

512 字節(jié)的限制還影響了根服務器的數(shù)量和名字。

要讓所有的根服務器數(shù)據(jù)能包含在一個 512 字節(jié)的 UDP 包中，根服務器只能限制在 13 個，而每個服務器要使用字母表中的單個字母命名。

以太網(wǎng)數(shù)據(jù)的長度必須在 46-1500 字節(jié)之間，這是由以太網(wǎng)的物理特性決定的。事實上，這個 1500 字節(jié)就是網(wǎng)絡層 IP 數(shù)據(jù)包的長度限制，理論上，IP 數(shù)據(jù)包最大長度是 65535 字節(jié)。

在 Internet 數(shù)據(jù)傳輸中，UDP 數(shù)據(jù)長度控制在 576 字節(jié)(Internet 標準 MTU 值)，而在許多 UDP 應用程序設計中數(shù)據(jù)包被限制成 512 字節(jié)或更小。這樣可以防止數(shù)據(jù)包的丟失。

許多解析器首先發(fā)送一條 UDP 查詢，如果它們接收到一條被截斷的響應，則會用 TCP 重新發(fā)送該查詢。這個過程繞過了 512 字節(jié)的限制，但是效率不高。

您或許認為 DNS 應該避開 UDP，總是使用 TCP，但是 TCP 連接的開銷大得多。

一次 UDP DNS 交換可以短到兩個包：一個查詢包、一個響應包。
一次 TCP 交換則至少包含 7 個包：三次握手初始化 TCP 會話、一個查詢包、一個響應包以及最后一次握手來關閉連接。
IPV6
IPV4 受長度的限制，擔憂多年的 IPv4 地址耗盡時刻還是到了。負責英國、歐洲、中東和部分中亞地區(qū)互聯(lián)網(wǎng)資源分配的歐洲網(wǎng)絡協(xié)調中心通過郵件確認，其最后的 IPv4 地址儲備池已于 2019 年 11 月 25 日完全耗盡。

IPv6 是 IP 協(xié)議 的最新版本，用它來取代 IPv4 ，主要是為了解決 IPv4 地址枯竭問題，同時它也在其他方面對于 IPv4 有許多改進。

然而長期以來 IPv4 在互聯(lián)網(wǎng)流量中仍占據(jù)主要地位，同時 NAT 的出現(xiàn) ，使得 IPv6 的使用增長緩慢。在 2022 年 4 月，通過 IPv6 使用 Google 服務的用戶百分率首次超過 40%。

在與現(xiàn)有 IPv4 根服務器體系架構充分兼容基礎上，雪人計劃 于 2016 年在全球 16 個國家完成 25 臺 IPv6 根服務器架設，事實上形成了 13 臺原有根加 25 臺 IPv6 根的新格局.

為建立多邊、民主、透明的國際互聯(lián)網(wǎng)治理體系打下堅實基礎。中國部署了其中的 4 臺，由 1 臺主根服務器和 3 臺輔根服務器組成，打破了中國過去沒有根服務器的困境。

DNS 解析順序
粗粒度的看，當我們在瀏覽器中輸入域名的時候，或者應用程序處理域名解析時，一般首先會基于編程語言調用系統(tǒng)的 Socket 庫來進行 DNS 解析，獲取到對應的 IP，然后封裝 網(wǎng)絡層的相關數(shù)據(jù)包，添加首部，依次到鏈路層發(fā)出請求。

如果細粒度看，實際發(fā)生了好多細節(jié)，以 Linux 為例，首先會通過名稱解析服務 etc/nsswitch.conf 讀取 DNS 解析規(guī)則,通過文件中定義的 解析順序發(fā)生解析。

$ cat /etc/nsswitch.conf  | grep host
#     hosts: files dns
#     hosts: files dns  # from user file
hosts:      files dns myhostname
$
當解析發(fā)生時，首先通過 files 本地文件 /etc/hosts 發(fā)生解析，在 /etc/hosts 文件配置中，我們可以配置一些當前環(huán)境的自定義映射

$ cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

172.25.254.254  classroom.example.com classroom
172.25.254.254  content.example.com content
172.25.254.254  materials.example.com materials
### rht-vm-hosts file listing the entries to be appended to /etc/hosts

172.25.250.254  bastion.lab.example.com bastion
172.25.250.9    workstation.lab.example.com workstation
172.25.250.10   servera.lab.example.com servera
172.25.250.11   serverb.lab.example.com serverb
172.25.250.12   serverc.lab.example.com serverc
172.25.250.13   serverd.lab.example.com serverd
$
如果沒有則通過 dns 解析，當需要從 DNS 獲取信息時，如果對應的集群存在 DNS 緩存，可能會重緩存中獲取，如果緩存中沒有，會由存根解析器(stub resolver)向 /etc/resolv.conf 文件中第一個 nameserver記錄查詢 DNS 信息。如果該服務器沒有響應，它將依次嘗試其他服務器，直到獲得答案或服務器用完為止。

$ cat /etc/resolv.conf
# Generated by NetworkManager
search lab.example.com example.com
nameserver 172.25.250.254
如果還是沒有，則通過 myhostname 即當前主機名對應的DNS進行解析。

調用 DNS 服務器發(fā)送解析過程
客戶端聯(lián)系的 DNS 服務器通常是遞歸或者緩存 DNS服務器。通過會通過下面的方式檢索客戶端的答案：

如果客戶端聯(lián)系的 DNS 服務器恰好是 查詢記錄的權威際服務器則權威 DNS 服務器立即回答查詢，因為權威服務器已經在本地存儲了查詢區(qū)域的信息。
如果客戶端聯(lián)系的 DNS 服務器是 緩存 DNS 服務器，而且之前已經查詢過對應記錄并且數(shù)據(jù)緩存在本地且尚未過期，緩存 DNS 服務器也會立即向客戶端提供答案。這減少了獲取常用信息的延遲。每個查詢都有一個關聯(lián)的生存時間(TTL)值，該值由權威服務器設置。
如果客戶端聯(lián)系的 緩存 DNS 服務器本地未執(zhí)行過對應記錄查詢，或者緩存的數(shù)據(jù)已經過期，那么存 DNS 服務器繼續(xù)對其他 DNS 服務器執(zhí)行迭代查找，以獲取客戶端的信息。一旦獲得了客戶查詢的答案，它就會將該信息提供給客戶。
DNS 的一些基本概念
關于 DNS 的一些基本概念：域、子域和區(qū)域。

Domain 域，是 resource records 的集合，以通用名結尾，表示 DNS 命名空間的整個子樹，如 example.com.。

Subdomain 子域：是另一個域的完整子樹的域。在討論兩個域之間的關系時使用此術語。例如，lab.example.com 是 example.com 的子域，而 example.com 是 .com 的子域。您也可以將 example.com 稱為第二級域，并將 lab.example.com 稱為第三級域。

Zone 區(qū)域：是特定 DNS 服務器直接負責的域。它可能是整個域，也可能只是域的一部分。Zone 可以將部分或全部子域都委派給另一個 DNS 服務器或多個 DNS 服務器。

例如，root DNS 服務器對 root zone 具有權威性，但它們將 .com 域的職責委派給其他 DNS 服務器，這些 DNS 服務器為 .com 區(qū)域提供權威性應答。這些服務器還可以繼續(xù)將責任委派給其他 DNS 服務器。

再例如，redhat.fun DNS 服務器對redhat.tun zone 具有權威性，但他將 lab.redhat.fun zone 委派給lab.redhat.fun DNS 服務器。






DNS 資源記錄表
DNS 區(qū)域中的DNS resource record(RR-DNS資源記錄)條目指定有關區(qū)域中特定名稱或對象的信息。資源記錄格式如下：

DNS 記錄，不管任何類型的資源目錄都使用下面的格式

owner-name        TTL     class type data
www.example.com.  300     IN    A    192.168.1.10
owner-name：查詢條目，DNS 名稱
TTL：生命周期/s
class：類別，IN interent，因特網(wǎng)
type：資源類型
data: 名稱對應的值
資源類型
A
A 資源記錄將主機名映射到 IPv4 地址。

host.example.com. 86400 IN A 172.25.254.254
AAAA
AAAA 資源記錄(4A 記錄)將主機名映射到 IPv6 地址。

a.root-servers.net. 604800 IN AAAA 2001:503:ba3e::2:30
CNAME：別名
CNAME 資源記錄將一個名稱映射為規(guī)范名稱，規(guī)范名稱具有 A 或 AAAA 記錄。CNAME 記錄的數(shù)據(jù)字段可以指向任意名稱，無論該區(qū)域是內部的還是外部的：

www-dev.example.com.    30 IN CNAME lab.example.com.
www.example.com.           30 IN CNAME www.redhat.com.

CNAME 記錄可能指向具有 CNAME 的名稱，但 CNAME 記錄鏈最終必須解析為 A 或 AAAA 記錄的名稱。

通常，避免將 CNAME 記錄指向其他 CNAME 記錄。CNAME 會使查找效率降低，并且您可能會意外地創(chuàng)建一個指向彼此的 CNAME 記錄循環(huán)。

CNAME 記錄鏈有合法用途。例如，它們與 Content Delivery Network(CDN)結合使用。NS 和 MX 記錄不得指向帶有 CNAME 記錄的名稱，而是使用帶有 A 和/或 AAAA 資源記錄的名稱。

PTR：IP 到域名反向解析
PTR 或 pointer 資源記錄將 lPv4 或 IPv6 地址映射到主機名。它們用于反向 DNS 解析。PTR 記錄以一種類似于主機名的特殊格式對 IP 地址進行編碼。

對于 IPv4 地址，該地址被顛倒，以最具體的部分開始，然后視為 in-addr.arpa 域的子域中的主機。
對于 IPV6 地址，該地址在半字節(jié)邊界(每個十六進制數(shù)字)上劃分為子域，并設置為 ip6.arpa 域的子域。
4.0.41.198.in-addr.arpa.                          785 IN PTR a.root-servers.net.
0.3.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.e.3.a.b.3.0.5.0.1.0.0.2.ip6.arpa.  86400 IN PTR a.root-servers.net.
該語法可能看起來很奇怪，但是它簡化了將地址范圍的責任委托給其他 DNS 管理員的情況。

NS：指定區(qū)域的權威服務器
NS 或 DNS 服務器資源記錄,將 域名映射到對其 DNS區(qū)域 具有 權威性的DNS 服務器,該區(qū)域的每個權威 DNS 服務器都必須其有 NS 記錄。

example.com.                              86400 IN NS classroom.example.com.
168.192.ip-addr.arpa.                  86400 IN NS classroom.example.com.
9.0.e.1.4.8.4.6.2.e.d.f.ip6.arpa.      86400 IN NS classroom.example.com.
說明：

其中兩個 NS 記錄用于 192.168.0.0/16 網(wǎng)絡和 fde2:6484:1e09:/48 網(wǎng)絡的反向查找。
NS 記錄映射的名稱必須有 A 或 4A 記錄。
可以正向或者反向解析
SOA:指定 DNS 運行信息
SOA 資源記錄，也叫做起始授權機構記錄，提供有關 DNS 區(qū)域如何運行的信息。每個區(qū)域必須有一個 SOA 記錄。

example.com.  86400 IN SOA classroom.example.com. root.classroom.example.com.  2015071700  3600  300  604800  60
MNAME | classroom.example.com. : 該 DNS 服務器是這個區(qū)域的主要 DNS 服務器負責維護區(qū)域資源記錄。
RNAME | root.classroom.example.co ：該區(qū)域中負責人郵件地址，(@用.代替，例如root@classroom.example.com.
SERIAL | 2015071700 ：該區(qū)域版本號，隨著區(qū)域中記錄更改而增加。
REFRESH | 3600 : 從 DNS 服務器向主 DNS 服務器更新數(shù)據(jù)頻.單位秒。
RETRY | 300 : 在重試失敗的刷新前，應當?shù)却臅r間間隔。單位秒。
EXPIRE | 604800 ：如果刷新失敗，從服務器在停止其舊的區(qū)域副本響應查詢之前等待的時間。單位秒。
MINIMUM：| 60 ：如果解析器查找某個名稱，并且該名稱不存在，解析器應將“記錄不存在”這一信息緩存的時間。單位秒。
MX
MX 資源記錄將域名映射到接受該域的電子郵件的郵件交換(mail exchange)。該記錄類型的數(shù)據(jù)是用于確定在多個 MX 記錄之間選擇郵件服務器(值越小，優(yōu)先級越高)，提供負載平衡和冗余的郵件服務器。

example.com.86400 IN MX 10  classroom.example.com.
example.com.86400 IN MX 10  mail.example.com.
example.com.86400 IN MX 100 mailbackup.example.com.
TXT
TXT 資源記錄將名稱映射到編碼為可打印 ASCl 字符的任意文本。它們通常用于提供用于各種電子郵件身份驗證方案(例如 SPF，DKIM 和 DMARC)的數(shù)據(jù)，以驗證域所有權(例如，用于 Google 和 Facebook)，以及用于其他目的。

lwn.net. 27272 IN TXT  "google-site-verification:sVlx-S z1es5DfNSUNXrqr3n9Y4F7tOr7HNVMKUGs"
lwn.net. 27272 IN TXT  "v=spf1 a:mail.lwn.net a:prod.lwn.net a:git.lwn.neta:ms.lwn.net-all"
SRV 特定服務主機
SRV 資源記錄可幫助客戶端找到域中支特定服務的主機。

ldap.tcp.example.com.86400 IN SRV 0 100 389 server0.example.com.
有特定的格式要求

含義：表明存在一個可以使用 TCP 傳輸協(xié)議(tcp)與 LDAP 連接的 LDAP 服務器(ldap)，該主機屬于域 example.com。LDAP 服務器是 server0.example.com，正在偵聽端口 389，優(yōu)先級為 0，權重為 100(如果客戶端接收到多個 SRV 記錄，則控制選擇哪個服務器)。

主機和資源記錄：
無論是客戶端還是服務器，都具有以下 DNS 資源記錄：

一個或多個 A 或 AAAA 記錄
用于將其 IP 地址反向映射到名稱的 PTR 記錄
一個或多個 CNAME 記錄(可選)
DNS zone 還具有以下資源記錄：

唯一的 SOA 記錄
每個權威 DNS 服務器的 NS 記錄
一個或多個 MX 記錄(可選)
用于在域中查找服務的一個或多個 SRV 記錄(可選)
DNS 安全
DNS 對于 Internet 的運行至關重要，基本的 DNS 協(xié)議非常容易受到欺騙和篡改攻擊。

DNS 的原始設計沒有提供用于緩存 DNS 服務器以驗證來自權威服務器的響應的真實性的方法。攻擊者可能偽造對 DNS 查找的響應，偽裝成權威服務器，然后將流量重定向到惡意主機。緩存 DNS 服務器將壞數(shù)據(jù)存儲在其緩存中，并在看起來有效的情況下將其提供給其他客戶端，該技術通常稱為緩存中毒。

為了解決這個問題，許多區(qū)域使用域名系統(tǒng)安全擴展(DNSSEC-Domain Name System Security Extensions)。每個使用 DNSSEC 的區(qū)域都經過數(shù)字簽名，并向解析器提供包含這些簽名的特殊資源記錄。





作者：山河已無恙


歡迎關注微信公眾號 ：山河已無恙