大家好!今年早些時候,我在寫《DNS 是如何工作的 wizardzines.com》 時,有人問我——為什么人們有時在域名的末尾加一個點?例如,如果你通過運行 dig example.com 查詢example.com的 IP,你會看到一下內(nèi)容:
$ dig example.com
example.com. 5678 IN A 93.184.216.34
執(zhí)行完dig命令后,example.com有一個.——變成了example.com.!發(fā)生了什么?
有些 DNS 工具也要求傳給它的域名后加一個.:如果你在使用miekg/dns github.com時傳給它example.com,它會報錯:
// trying to send this message will return an error
m := new(dns.Msg)
m.SetQuestion("example.com", dns.TypeA)
最初我以為我知道這個問題的答案(“呃,末尾的點意味著域名是完全限定的?”)。這是對的 —— 一個完全限定域名(fully qualified domain name)(FQDN)是一個末尾有.的域名!
但是為什么末尾的點是有用且重要的呢?
在 DNS 的請求/響應(yīng)中,域名的末尾并沒有 “.”
我曾經(jīng)(錯誤地)認(rèn)為 “為什么末尾有一個點?”的答案可能是 “在 DNS 請求/響應(yīng)中,域名末尾有一個.,所以我們把它放進去,以匹配你的計算機實際發(fā)送/接收的內(nèi)容”。但事實并不是這樣!
當(dāng)計算機發(fā)送 DNS 請求/響應(yīng)時,域名的末尾并沒有點。實際上,域名中沒有點。
域名會被編碼成一系列的長度/字符串對。例如,域名example.com被編碼為這 13 個字節(jié)。
7example3com0
編碼后的內(nèi)容一個點也沒有。一個 ASCII 域名(如example.com)被轉(zhuǎn)成了各種 DNS 軟件的 DNS 請求/響應(yīng)中使用的格式。
今天我們來討論域名被轉(zhuǎn)成 DNS 響應(yīng)的一個地方:區(qū)域文件。
區(qū)域文件中域名末尾的 “.”
一些人管理域名的 DNS 記錄的方法是創(chuàng)建一個被稱為 “區(qū)域文件” 的文本文件,然后配置一些 DNS 服務(wù)器軟件(如nsd或bind)來為該區(qū)域文件中指定的 DNS 記錄提供服務(wù)。
下面是一個對應(yīng)example.com的示例區(qū)域文件:
orange 300 IN A 1.2.3.4
fruit 300 IN CNAME orange
grape 3000 IN CNAME example.com.
在這個文件中,任何不以.結(jié)尾的域名(比如orange)后都會自動加上.example.com。所以orange成了orange.example.com的簡稱。DNS 服務(wù)器從它的配置中得知這是一個example.com的區(qū)域文件,所以它知道在所有不以點結(jié)尾的名字后面自動添加example.com。
我想這里的想法只是為了少打幾個字符——如果要打出全稱,區(qū)域文件會是這樣:
orange.example.com. 300 IN A 1.2.3.4
fruit.example.com. 300 IN CNAME orange.example.com.
grape.example.com. 3000 IN CNAME example.com.
確實多了很多字符。
你也可以不通過區(qū)域文件來使用 DNS
盡管官方的 DNS RFC(RFC 1035 www.rfc-editor.org)中定義了區(qū)域文件格式,但你也可以不通過區(qū)域文件來使用 DNS。例如,AWS Route 53 就不用區(qū)域文件來存儲 DNS 記錄!你可以通過 Web 界面或 API 來創(chuàng)建記錄,我猜他們是用某種數(shù)據(jù)庫而不是一堆文本文件來存儲記錄。
不過,Route 53(像許多其他 DNS 工具一樣)確實支持導(dǎo)入和導(dǎo)出區(qū)域文件,這個功能或許在你更換 DNS 提供商時很有用。
dig 命令輸出中末尾的 “.”
現(xiàn)在我們來討論下 dig 命令的輸出:
$ dig example.com
; <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> +all example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10712
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 81239 IN A 93.184.216.34
有一件奇怪的事是,幾乎每一行都以;;開頭,這是怎么回事?;是區(qū)域文件中的注釋字符!
我想 dig 以這種奇怪的方式輸出的原因可能是為了方便你粘貼這些內(nèi)容到區(qū)域文件時,不用修改就可以直接用。
這也是example.com末尾有個.的原因 —— 區(qū)域文件要求域名末尾必須有點(否則它們會被解釋為是相對于該區(qū)域的)。因此 dig 也這么處理了。
我真的希望 dig 有一個+human選項,以更人性化的方式打印出這些信息,但現(xiàn)在我太懶了,懶得花工夫去實際貢獻代碼來做這件事(而且我并不擅長 C),所以我只能在我的博客上抱怨一下
curl 命令輸出中末尾的 “.”
我們來看下另一個末尾有.的例子:curl!
我家里有臺計算機名為grapefruit,其上運行著 Web 服務(wù)器。當(dāng)我執(zhí)行 curl grapefruit 時,會輸出:
$ curl grapefruit
......
這樣運行沒問題!但是如果我在域名后加一個.會怎樣呢?它報錯了:
$ curl grapefruit.
curl: (6) Could not resolve host: grapefruit.
發(fā)生了什么?為了搞清楚,我們需要先來學(xué)習(xí)下搜索域:
初識搜索域
當(dāng)我執(zhí)行 curl grapefrult 時,它是怎么被轉(zhuǎn)成一個 DNS 請求的?你可能會認(rèn)為我的計算機會向域名grapefruit發(fā)送一個請求,對嗎?但事實并不是這樣。
讓我們用 tcpdump 來看看到底是什么域名在被查詢。
$ sudo tcpdump -i any port 53
[...] A? grapefruit.lan. (32)
實際上是向grapefruit.lan.發(fā)送的請求。為什么呢?
解釋一下:
1.curl調(diào)用函數(shù)getaddrinfo來查詢grapefruit 2.getaddrinfo查詢了我計算機上的文件/etc/resolv.conf 3./etc/resolv.conf包含兩行內(nèi)容:
nameserver 127.0.0.53
search lan
4.因為有search lan這行內(nèi)容,所以getaddrinfo在grapefruit的末尾添加了一個lan,去查詢grapefruit.lan
什么時候搜索域被使用?
現(xiàn)在我們知道了一些奇怪的事情:當(dāng)我們查詢一個域名時,有時會有一個額外的東西(如lan)被加到最后。但是什么時候會發(fā)生這種情況呢?
1.如果我們在域名末尾添加一個.,那么這時不會用到搜索域 2.如果域名中間包含一個.(如example.com),那么默認(rèn)也不會用到搜索域。但是可以通過修改配置來改變處理邏輯(在ndots pracucci.com里有更詳細的說明)
我們現(xiàn)在知道了curl grapefruit.與curl grapefruit結(jié)果不一樣的原因——因為一個查詢的是grapefruit.,而另一個查詢的是grapefruit.lan.。
我的計算機怎么知道使用哪個搜索域呢?
當(dāng)我連接路由時,它會通過 DHCP 告訴我它的搜索域是lan—— 它也是通過這個方式給我的計算機分配 IP。
所以為什么要在域名末尾加一個點呢?
現(xiàn)在我們已經(jīng)了解了區(qū)域文件和搜索域,下面是我認(rèn)為的人們要在域名末尾加點的原因:
有兩種情況下,域名會被修改,并在末尾添加其他東西。
?在example.com的區(qū)域文件中,grapefruit會被轉(zhuǎn)為grapefruit.example.com ?在我的本地網(wǎng)絡(luò)(我的計算機已經(jīng)配置了使用搜索域lan),grapefruit被轉(zhuǎn)為grapefruit.lan
因此,由于域名在某些情況下實際上可能被轉(zhuǎn)成其他名字,人們就在結(jié)尾處加一個.,以此來表示 “這是域名,末尾不需要添加任何東西,這就是全部內(nèi)容”。否則會引起混亂。
“這就是全部內(nèi)容”的技術(shù)術(shù)語是**“完全限定域名”,簡稱為“FQDN”**。所以google.com.是一個完全限定域名,而google.com不是。
我總是要提醒自己這樣做的原因,因為我很少使用區(qū)域文件和搜索域,所以我經(jīng)常覺得——“我當(dāng)然是指google.com而不是google.com.something.else! 我為什么要指其他東西?那太傻了!”
但是有些人確實在使用區(qū)域文件和搜索域(例如 Kubernetes 中使用了搜索域?。?,所以結(jié)尾的.很有用,可以讓人確切的知道,不應(yīng)該再添加其他東西。
什么時候在末尾添加 “.”?
以下是關(guān)于何時在域名末尾加 ". " 的幾個簡單說明:
需要添加:配置 DNS 時
在配置 DNS 時,使用完全限定域名從來都不是壞事。你不一定要這樣做:非完全限定域名通常也能正常工作,但我從來沒有遇到過不接受完全限定域名的 DNS 軟件。
有些 DNS 軟件需要這樣做:現(xiàn)在我為jvns.ca使用的 DNS 服務(wù)器讓我在域名的末尾加上.(例如在 CNAME 記錄中),并提示如果我不添加,它將在我輸入的內(nèi)容末尾加上.jvns.ca。我不同意這個設(shè)計決定,但這不是什么大問題,我只是在最后加一個.。
不需要加:在瀏覽器中
令人困惑的是,在瀏覽器中,在域名結(jié)尾處加一個.不能正常運行。例如,如果我在瀏覽器中輸入https://twitter.com.,它就會報錯。它會返回 404。
我認(rèn)為這里發(fā)生的事情是,它將 HTTPHost標(biāo)頭設(shè)置為Host:twitter.com.,而對端的 Web 服務(wù)器則期望Host:twitter.com。
同樣地,https://jvns.ca.由于某種原因,返回了一個 SSL 錯誤。
我認(rèn)為相對域名在過去是比較常見的
最后一件事:我認(rèn)為“相對”域名(比如我用grapefruit來指代我家的另一臺計算機grapefruit.lan)在過去更常用,因為 DNS 是在大學(xué)或其他有大型內(nèi)部網(wǎng)絡(luò)的大機構(gòu)中開發(fā)的。
在今天的互聯(lián)網(wǎng)上,使用“絕對”域名(如example.com)似乎更為普遍。
審核編輯:劉清
-
Web服務(wù)器
+關(guān)注
關(guān)注
0文章
138瀏覽量
24703 -
ASCII
+關(guān)注
關(guān)注
5文章
172瀏覽量
35569 -
DNS
+關(guān)注
關(guān)注
0文章
221瀏覽量
20189
原文標(biāo)題:為什么有時候域名的末尾有個點?
文章出處:【微信號:良許Linux,微信公眾號:良許Linux】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論