成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

為什么有時候域名的末尾有個點?

系統(tǒng) Linux
今天我們來討論域名被轉成 DNS 響應的一個地方:區(qū)域文件。

大家好!今年早些時候,我在寫《??DNS 是如何工作的???》 時,有人問我——為什么人們有時在域名的末尾加一個點?例如,如果你通過運行 ??dig example.com??? 查詢 ??example.com?? 的 IP,你會看到一下內容:

$ dig example.comexample.com.        5678    IN  A   93.184.216.34

執(zhí)行完 ??dig?? 命令后,??example.com?? 有一個 ??.?? ——變成了 ??example.com.??!發(fā)生了什么?

有些 DNS 工具也要求傳給它的域名后加一個 ??.??:如果你在使用 ??miekg/dns?? 時傳給它 ??example.com??,它會報錯:

// trying to send this message will return an errorm := new(dns.Msg)m.SetQuestion("example.com", dns.TypeA)

最初我以為我知道這個問題的答案(“呃,末尾的點意味著域名是完全限定的?”)。這是對的 —— 一個完全限定域名fully qualified domain name(FQDN)是一個末尾有 ??.?? 的域名!

但是為什么末尾的點是有用且重要的呢?

在 DNS 的請求/響應中,域名的末尾并沒有 “.”

我曾經(jīng)(錯誤地)認為 “為什么末尾有一個點?”的答案可能是 “在 DNS 請求/響應中,域名末尾有一個 ??.??,所以我們把它放進去,以匹配你的計算機實際發(fā)送/接收的內容”。但事實并不是這樣!

當計算機發(fā)送 DNS 請求/響應時,域名的末尾并沒有點。實際上,域名中沒有點。

域名會被編碼成一系列的長度/字符串對。例如,域名 ??example.com?? 被編碼為這 13 個字節(jié)。

7example3com0

編碼后的內容一個點也沒有。一個 ASCII 域名(如 ??example.com??)被轉成了各種 DNS 軟件的 DNS 請求/響應中使用的格式。

今天我們來討論域名被轉成 DNS 響應的一個地方:區(qū)域文件。

區(qū)域文件中域名末尾的 “.”

一些人管理域名的 DNS 記錄的方法是創(chuàng)建一個被稱為 “區(qū)域文件” 的文本文件,然后配置一些 DNS 服務器軟件(如 ??nsd?? 或 ??bind??)來為該區(qū)域文件中指定的 DNS 記錄提供服務。

下面是一個對應 ??example.com?? 的示例區(qū)域文件:

orange  300   IN    A     1.2.3.4fruit   300   IN    CNAME orangegrape   3000  IN    CNAME example.com.

在這個文件中,任何不以 ??.?? 結尾的域名(比如 ??orange??)后都會自動加上 ??.example.com??。所以 ??orange?? 成了 ??orange.example.com?? 的簡稱。DNS 服務器從它的配置中得知這是一個 ??example.com?? 的區(qū)域文件,所以它知道在所有不以點結尾的名字后面自動添加 ??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??)中定義了區(qū)域文件格式,但你也可以不通過區(qū)域文件來使用 DNS。例如,AWS Route 53 就不用區(qū)域文件來存儲 DNS 記錄!你可以通過 Web 界面或 API 來創(chuàng)建記錄,我猜他們是用某種數(shù)據(jù)庫而不是一堆文本文件來存儲記錄。

不過,Route 53(像許多其他 DNS 工具一樣)確實支持導入和導出區(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?? 以這種奇怪的方式輸出的原因可能是為了方便你粘貼這些內容到區(qū)域文件時,不用修改就可以直接用。

這也是 ??example.com?? 末尾有個 ??.?? 的原因 —— 區(qū)域文件要求域名末尾必須有點(否則它們會被解釋為是相對于該區(qū)域的)。因此 ??dig?? 也這么處理了。

我真的希望 dig 有一個 ??+human?? 選項,以更人性化的方式打印出這些信息,但現(xiàn)在我太懶了,懶得花工夫去實際貢獻代碼來做這件事(而且我并不擅長 C),所以我只能在我的博客上抱怨一下 :smiley:

curl 命令輸出中末尾的 “.”

我們來看下另一個末尾有 ??.?? 的例子:??curl??!

我家里有臺計算機名為 ??grapefruit??,其上運行著 Web 服務器。當我執(zhí)行 ??curl grapefruit?? 時,會輸出:

$ curl grapefruit<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html><head>......

這樣運行沒問題!但是如果我在域名后加一個 ??.?? 會怎樣呢?它報錯了:

$ curl grapefruit.curl: (6) Could not resolve host: grapefruit.

發(fā)生了什么?為了搞清楚,我們需要先來學習下搜索域:

初識搜索域

當我執(zhí)行 ??curl grapefrult?? 時,它是怎么被轉成一個 DNS 請求的?你可能會認為我的計算機會向域名 ??grapefruit?? 發(fā)送一個請求,對嗎?但事實并不是這樣。

讓我們用 ??tcpdump?? 來看看到底是什么域名在被查詢。

$ sudo tcpdump -i any port 53[...] A? grapefruit.lan. (32)

實際上是向 ??grapefruit.lan.?? 發(fā)送的請求。為什么呢?

解釋一下:

  1. ??curl?? 調用函數(shù)??getaddrinfo?? 來查詢??grapefruit??
  2. ??getaddrinfo?? 查詢了我計算機上的文件??/etc/resolv.conf??
  3. ?/etc/resolv.conf?? 包含兩行內容:
nameserver 127.0.0.53search lan
  1. 因為有??search lan?? 這行內容,所以??getaddrinfo?? 在??grapefruit?? 的末尾添加了一個??lan??,去查詢??grapefruit.lan??

什么時候搜索域被使用?

現(xiàn)在我們知道了一些奇怪的事情:當我們查詢一個域名時,有時會有一個額外的東西(如 ??lan??)被加到最后。但是什么時候會發(fā)生這種情況呢?

  1. 如果我們在域名末尾添加一個??.??,那么這時不會用到搜索域
  2. 如果域名中間包含一個??.??(如??example.com??),那么默認也不會用到搜索域。但是可以通過修改配置來改變處理邏輯(在??ndots?? 里有更詳細的說明)

我們現(xiàn)在知道了 ??curl grapefruit.?? 與 ??curl grapefruit?? 結果不一樣的原因——因為一個查詢的是 ??grapefruit.??,而另一個查詢的是 ??grapefruit.lan.??。

我的計算機怎么知道使用哪個搜索域呢?

當我連接路由時,它會通過 DHCP 告訴我它的搜索域是 ??lan?? —— 它也是通過這個方式給我的計算機分配 IP。

所以為什么要在域名末尾加一個點呢?

現(xiàn)在我們已經(jīng)了解了區(qū)域文件和搜索域,下面是我認為的人們要在域名末尾加點的原因:

有兩種情況下,域名會被修改,并在末尾添加其他東西。

  • 在??example.com?? 的區(qū)域文件中,??grapefruit?? 會被轉為??grapefruit.example.com??
  • 在我的本地網(wǎng)絡(我的計算機已經(jīng)配置了使用搜索域??lan??),??grapefruit?? 被轉為??grapefruit.lan??

因此,由于域名在某些情況下實際上可能被轉成其他名字,人們就在結尾處加一個 ??.??,以此來表示 “這是域名,末尾不需要添加任何東西,這就是全部內容”。否則會引起混亂。

“這就是全部內容”的技術術語是**“完全限定域名”,簡稱為“FQDN”**。所以 ??google.com.?? 是一個完全限定域名,而 ??google.com?? 不是。

我總是要提醒自己這樣做的原因,因為我很少使用區(qū)域文件和搜索域,所以我經(jīng)常覺得——“我當然是指 ??google.com?? 而不是 ??google.com.something.else??! 我為什么要指其他東西?那太傻了!”

但是有些人確實在使用區(qū)域文件和搜索域(例如 Kubernetes 中使用了搜索域!),所以結尾的 ??.?? 很有用,可以讓人確切的知道,不應該再添加其他東西。

什么時候在末尾添加 “.”?

以下是關于何時在域名末尾加 ". " 的幾個簡單說明:

需要添加:配置 DNS 時

在配置 DNS 時,使用完全限定域名從來都不是壞事。你不一定要這樣做:非完全限定域名通常也能正常工作,但我從來沒有遇到過不接受完全限定域名的 DNS 軟件。

有些 DNS 軟件需要這樣做:現(xiàn)在我為 ??jvns.ca?? 使用的 DNS 服務器讓我在域名的末尾加上 ??.??(例如在 CNAME 記錄中),并提示如果我不添加,它將在我輸入的內容末尾加上 ??.jvns.ca??。我不同意這個設計決定,但這不是什么大問題,我只是在最后加一個 ??.??。

不需要加:在瀏覽器中

令人困惑的是,在瀏覽器中,在域名結尾處加一個 ??.?不能正常運行。例如,如果我在瀏覽器中輸入 ??https://twitter.com.??,它就會報錯。它會返回 404。

我認為這里發(fā)生的事情是,它將 HTTP ??Host?? 標頭設置為 ??Host:twitter.com.??,而對端的 Web 服務器則期望 ??Host:twitter.com??。

同樣地,??https://jvns.ca.?? 由于某種原因,返回了一個 SSL 錯誤。

我認為相對域名在過去是比較常見的

最后一件事:我認為“相對”域名(比如我用 ??grapefruit?? 來指代我家的另一臺計算機 ??grapefruit.lan??)在過去更常用,因為 DNS 是在大學或其他有大型內部網(wǎng)絡的大機構中開發(fā)的。

在今天的互聯(lián)網(wǎng)上,使用“絕對”域名(如 ??example.com??)似乎更為普遍。

責任編輯:龐桂玉 來源: Linux中國
相關推薦

2025-05-28 01:10:00

SQL索引MySQL

2019-11-04 16:08:33

Wi-Fi4G路由器

2009-09-28 11:20:30

面試

2022-11-02 08:55:43

Gofor 循環(huán)存儲

2025-05-28 00:00:00

CSS前端Flexbox

2023-05-22 07:10:38

GPTpromptPerplexity

2022-12-12 08:17:29

2019-12-17 16:04:25

微軟

2024-01-11 08:19:14

react打點上報功能Modal組件

2019-12-26 09:50:14

HTTP緩存代理服務器

2019-12-06 17:31:30

程序員人生第一份工作設計

2024-04-08 13:08:16

Python去除水印

2014-07-21 13:04:34

代碼

2015-02-10 11:07:02

360域名

2023-08-02 08:40:38

C++代碼宏定義

2024-04-07 08:19:19

Oracle數(shù)據(jù)庫故障

2020-07-10 15:18:12

微服務設計模型

2020-02-04 14:41:37

微服務設計DDD

2024-11-12 09:58:42

2022-11-08 17:39:27

MySQLkilled
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 国产精品国产成人国产三级 | 日韩中文字幕在线视频观看 | 四虎影| 久久美女视频 | 久久国产一区二区 | www视频在线观看 | 亚洲精品免费视频 | 免费视频一区二区三区在线观看 | 一区二区三区高清不卡 | 亚洲精品成人 | 国产精品亚洲一区 | 国产三级国产精品 | 国产精品日韩在线 | 国产精品一区二区av | 天天综合网天天综合 | 五月香婷婷 | 欧美精品一区二区三区四区 在线 | 亚洲日本一区二区 | 黄色一级视频免费 | 国产激情免费视频 | 欧美色综合天天久久综合精品 | 久草网站| 在线播放一区二区三区 | 国产欧美一区二区三区另类精品 | 欧美一区二区免费视频 | 男女羞羞视频在线免费观看 | 欧美日产国产成人免费图片 | av在线一区二区 | 中文字字幕一区二区三区四区五区 | 91看片视频| 亚洲夜射 | www成人啪啪18| 七七婷婷婷婷精品国产 | 祝你幸福电影在线观看 | 性网站免费 | 亚洲精品永久免费 | 美女131mm久久爽爽免费 | 99成人精品 | 国外成人在线视频网站 | 91精品入口蜜桃 | 国产69精品久久99不卡免费版 |