0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

DNS報(bào)文結(jié)構(gòu)與編碼解析

dyquk4xk2p3d ? 來源:taoshu.in ? 2023-06-26 10:54 ? 次閱讀

網(wǎng)上很多人都說 DNS 根服務(wù)器只有 13 臺(tái),中國一臺(tái)也沒有。在網(wǎng)絡(luò)世界,中國被美國卡住了脖子。那 DNS 根服務(wù)器真的只有 13 臺(tái)嗎?如果是,那原因又是什么?今天就給大家說道說道。

DNS 基本概念

在回答這個(gè)問題之前,我們需要先回顧一些基本概念。DNS 是一種分層結(jié)構(gòu),這種層級(jí)就體現(xiàn)在域名的『點(diǎn)』里。以我的域名為例,TAOSHU.IN它的完整域名其實(shí)是TAOSHU.IN.。注意最后有一個(gè)點(diǎn)。它分三個(gè)層級(jí),結(jié)結(jié)構(gòu)為.?IN?TAOSHU。

DNS 又是分布式系統(tǒng),每一層級(jí)都有自己的解析服務(wù)器。.是第一層級(jí),它的解析服務(wù)器就是根服務(wù)器。第二層級(jí)是對(duì)應(yīng)我們常說的COM/NET等頂級(jí)域名 TLD,而我用的IN是印度的國家域名,跟中國的CN一樣,它們都是 CCTLD,也就是所謂的國家頂級(jí)域名。TAOSHU就是普通的一級(jí)域名。每個(gè)域名都可以自行設(shè)置子域名,不受上級(jí)域名限制。

域名解析過程也是分布式的。還是以TAOSHU.IN為例??蛻舳讼日业礁?wù)器的地址,并其查詢IN的解析服務(wù)器。再向IN的服務(wù)器查詢TAOSHU.IN的服務(wù)器。最后向TAOSHU.IN的服務(wù)器查詢具體的解析記錄,比如 A 記錄等。

當(dāng)前根服務(wù)器

從上面的過程可知,所有的 DNS 查詢都從根服務(wù)器開始。所以根服務(wù)器是整個(gè) DNS 系統(tǒng)的核心。如果根服務(wù)器出現(xiàn)故障,那所有 DNS 查詢都會(huì)失??!為了避免出現(xiàn)這種問題,人們?cè)O(shè)置了多個(gè) DNS 根服務(wù)器。發(fā)展到現(xiàn)在,互聯(lián)網(wǎng)社區(qū)累計(jì)設(shè)置了 13 臺(tái),它們分別是:

主機(jī)名 IP 地址 運(yùn)營機(jī)構(gòu) 國家
a.root-servers.net 198.41.0.4, 2001ba3e:30 Verisign, Inc. 美國
b.root-servers.net 199.9.14.201, 2001200::b University of Southern California, Information Sciences Institute 美國
c.root-servers.net 192.33.4.12, 20012::c Cogent Communications 美國
d.root-servers.net 199.7.91.13, 20012d::d University of Maryland 美國
e.root-servers.net 192.203.230.10, 2001a8::e NASA (Ames Research Center) 美國
f.root-servers.net 192.5.5.241, 20012f::f Internet Systems Consortium, Inc. 美國
g.root-servers.net 192.112.36.4, 200112::d0d US Department of Defense (NIC) 美國
h.root-servers.net 198.97.190.53, 20011::53 US Army (Research Lab) 美國
i.root-servers.net 192.36.148.17, 2001:53 Netnod 瑞典
j.root-servers.net 192.58.128.30, 2001c27:30 Verisign, Inc. 美國
k.root-servers.net 193.0.14.129, 2001:1 RIPE NCC 荷蘭
l.root-servers.net 199.7.83.42, 20019f::42 ICANN 國際
m.root-servers.net 202.12.27.33, 2001:35 WIDE Project 日本

資料來源:IANA1 資料截止時(shí)間:2023年06月06日

在 1984 年,Jon Postel 和 Paul Mockapetris 在南加州大學(xué)設(shè)立了世界上第一臺(tái)根服務(wù)器2。到了 1990 年,根服務(wù)器的數(shù)量擴(kuò)展到了 7 臺(tái),分屬不同的組織給護(hù),但全都在美國。到了 1991 年,KTH 在瑞典設(shè)立一臺(tái)根服務(wù)器。這是首次在美國之外部署根服務(wù)器。此后一直有舊的根服務(wù)器退役,新的服務(wù)器入役。到了 1995 年,根服務(wù)器已經(jīng)擴(kuò)展到 9 臺(tái)。這個(gè)時(shí)候就遇到了技術(shù)瓶頸,無法添加新的根服務(wù)器了。

到底是什么技術(shù)瓶頸呢?這就得說說 DNS 的底層實(shí)現(xiàn)細(xì)節(jié)了。

Priming 查詢

前面說所有的 DNS 查詢都從根服務(wù)器開始。那客戶端怎么知道當(dāng)前有哪些根服務(wù)器呢?沒什么好辦法,就是在各自的代碼中寫死!對(duì),是硬編碼。但我們前面也說了,在役的根服務(wù)器并非一成不變,寫死的話新添加的服務(wù)怎么生效呢?

這就用到了所謂的 Priming Queries3。簡單來說,所有 DNS 解析客戶端都隨軟件附帶一個(gè)列表文件,里面有當(dāng)前所有根服務(wù)器的信息,包括域名、IP地址等信息。這個(gè)文件叫 Root Hints,可以從 IANA 官網(wǎng)4下載。但考慮到根服務(wù)器的列表可能會(huì)變,所以客戶端需要定期從已知的根服務(wù)器查詢當(dāng)前最新的服務(wù)器列表,用的也是 DNS 協(xié)議,這類請(qǐng)求叫作 Priming 查詢。

對(duì)于客戶端來說,它先從 Root Hints 中根據(jù)某種規(guī)則5選出一臺(tái)根服務(wù)器,然后向它查詢最新的根服務(wù)器列表,并本機(jī)緩存一段時(shí)間,過期之前都以該列表為準(zhǔn)。

因?yàn)?Priming 查詢也是用 DNS 協(xié)議,自然也走 UDP 傳輸?;ヂ?lián)網(wǎng)早期 IP 網(wǎng)絡(luò)的最大傳輸單元長度(MTU)也就五百多字節(jié),所以 DNS 回復(fù)信息的最大長度同樣不能太長。所以 DNS 協(xié)議規(guī)定回復(fù)信息不能超過 512 字節(jié)。這就是添加根服務(wù)器遇到的技術(shù)瓶頸。

其實(shí)解決這個(gè)問題很容易,完全可以要求客戶端使用 TCP 連接傳輸 Priming 查詢結(jié)果嘛??上М?dāng)時(shí)沒有采用這種方案。不過,如果是我,也不會(huì)選 TCP 方案。因?yàn)樗?DNS 查詢都走 UDP 協(xié)議,簡單而統(tǒng)一。雖然 DNS 也支持使用 TCP,但讓 Priming 查詢單獨(dú)走 TCP 明顯會(huì)讓系統(tǒng)變得很復(fù)雜。

社區(qū)最終決定想辦法壓縮查詢結(jié)果長度。

報(bào)文結(jié)構(gòu)與編碼

DNS 報(bào)文結(jié)構(gòu)如下,分為五個(gè)部分6。

+---------------------+
|Header|
+---------------------+
|Question|thequestionforthenameserver
+---------------------+
|Answer|RRsansweringthequestion
+---------------------+
|Authority|RRspointingtowardanauthority
+---------------------+
|Additional|RRsholdingadditionalinformation
+---------------------+

Header

Header 為報(bào)文頭信息,長度固定為 12 字節(jié),結(jié)構(gòu)如下:

0123456789012345
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|ID|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|Opcode|AA|TC|RD|RA|Z|RCODE|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QDCOUNT|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|ANCOUNT|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|NSCOUNT|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|ARCOUNT|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Header 中跟本文內(nèi)內(nèi)直接相關(guān)的就是 QDCOUNT/ANCOUNT/NSCOUNT/ARCOUNT 這四個(gè)字段,分別表示后續(xù) Question/Answer/Authority/Additional 段的數(shù)量。

Question

Question 段保存查詢請(qǐng)求信息,通長只有一個(gè)。它分成三個(gè)部分。后兩個(gè)部分表示查詢類型和網(wǎng)絡(luò)類型。含義不重要,重要的是長度固定為 4 字節(jié)。

0123456789012345
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
||
/QNAME/
//
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QTYPE|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QCLASS|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

第一部分 QNAME 長度可變,保存查詢的域名。但存儲(chǔ)的方式有點(diǎn)特別。以域名A.ROOT-SERVERS.NET.為例,它會(huì)分成三部分A、ROOT-SERVERS和NET。每一部分稱作一個(gè)標(biāo)簽(Label), QNAME 字段只保存標(biāo)簽,不保存.。每個(gè)標(biāo)簽用第一個(gè)字節(jié)記錄當(dāng)前標(biāo)簽長度,后面跟著標(biāo)簽內(nèi)容。最后用一個(gè)長度為零的標(biāo)簽表示結(jié)尾。所以完整的 QNAME 字段編碼為:

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20|1|A|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22|12|R|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24|O|O|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26|T|-|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
28|S|E|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
30|R|V|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
32|E|R|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
34|S|3|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
36|N|E|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
38|T|0|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

長度為 20 字節(jié)。特別的,對(duì)于根域名.,它的 QNAME 編碼是:

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20|0||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

長度為 1 字節(jié)。

Answer

Answer 段是服務(wù)器返回的響應(yīng)結(jié)果。數(shù)量為一條到多條不等。每一條稱為一個(gè) RR,全稱是 Resource Record。其結(jié)構(gòu)如下:

0123456789012345
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
||
//
/NAME/
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|TYPE|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|CLASS|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|TTL|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|RDLENGTH|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/RDATA/
//
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

RR 跟前面的 Question 相比多了 TTL/RDLENGTH/RDATA 三個(gè)字段。TTL 表示有效時(shí)長, RDLENGTH 表示后續(xù) RDATA 的長度,RDATA 保存實(shí)際的響應(yīng)數(shù)據(jù)。根據(jù) TYPE 和 CLASS 的不同,RDATA 內(nèi)容也各不相同。在 Priming 查詢中,RDATA 保存各根服務(wù)器的域名,編碼跟前 Question 中的 QNAME 一樣。

如果服務(wù)器返回如下一條 RR 數(shù)據(jù):

.518400INNSa.root-servers.net.

那么 RR 的總長度是 1+2+2+4+2+20=31 字節(jié)。

Authority

Authority 段用來返回待查詢域名的權(quán)威服務(wù)器信息。比如我們嘗試向根服務(wù)器直接查詢TAOSHU.IN的A記錄,根服務(wù)器就會(huì)在 Authority 段返回IN域名的解析服器。因?yàn)楦?wù)器并不保存TAOSHU.IN的域名信息。不過在本文中,Priming 查詢的權(quán)威服務(wù)器就是根服務(wù)器,所以此段長度為零。

最后的 Additional 段用來返回一些附加信息。Answer 中只有域名信息。我們希望直接返回 IP 地址,所以需要用到 Additional 段。Additional 中也是一條一條的 PR,計(jì)算方式跟 Answer 的一模一樣。

因?yàn)?Priming 查詢會(huì)返回所有的根服務(wù)器域名及其對(duì)應(yīng)的 IP 地址7,所以根服務(wù)器數(shù)量越多,返回的數(shù)據(jù)就越長。但 DNS 協(xié)議規(guī)定最長只能是 512 字節(jié),這就產(chǎn)生了瓶頸。

到了 1995 年,已經(jīng)開通了 9 臺(tái)根服務(wù)器,Priming 查詢結(jié)果快要超過 512 字節(jié)了。社區(qū)開始著手解決這個(gè)問題。方案是標(biāo)簽壓縮。

標(biāo)簽壓縮

壓縮辦法也很簡單,就是在 NAME 中引入指針結(jié)構(gòu)

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|11|OFFSET|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

DNS 還有一個(gè)規(guī)定,域名的長度不能超過 63 字節(jié)。NAME 中第一個(gè)字節(jié)表示長度,最大值就是 63,二進(jìn)制表示為00111111,可見高兩位是零。于是大家約定高兩位設(shè)為11的時(shí)候,后面的 14 位就表示從報(bào)文 Header 開始的偏移量。這樣一來,如果多個(gè) RR 的域名中有相同的部分,就不需要重復(fù)傳輸,減少響應(yīng)長度。

舉個(gè)例子,比如要同時(shí)返回A.ROOT-SERVERS.NET和B.ROOT-SERVERS.NET兩個(gè)域名,顯然它們有共同的后綴ROOT-SERVERS.NET。假設(shè)A.ROOT-SERVERS.NET的偏移量為 20,那么可以表示為:

A.ROOT-SERVERS.NET
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20|1|A|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22|12|R|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24|O|O|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26|T|-|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
28|S|E|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
30|R|V|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
32|E|R|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
34|S|3|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
36|N|E|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
38|T|0|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
B.ROOT-SERVERS.NET
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
40|1|B|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
44|11|20|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
46|0||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

利用標(biāo)簽壓縮技術(shù),域名B.ROOT-SERVERS.NET只需要占用 5 個(gè)字節(jié),比A.ROOT-SERVERS.NET節(jié)省了 15 個(gè)字節(jié)。

根服務(wù)器更名

要想使用壓縮,前提是所有域名有重復(fù)的部分。但之前的根服務(wù)器域名不相同,這就得改名。到了 1995 年,社區(qū)統(tǒng)一的域名為根服務(wù)器重新編組并部署標(biāo)簽壓縮功能。

舊域名 新域名 運(yùn)營機(jī)構(gòu)
NS.INTERNIC.NET A.ROOT-SERVERS.NET InterNIC (operated by NSI)
NS1.ISI.EDU B.ROOT-SERVERS.NET Information Sciences Institute, USC
C.PSI.NET C.ROOT-SERVERS.NET PSINet
TERP.UMD.EDU D.ROOT-SERVERS.NET University of Maryland
NS.NASA.GOV E.ROOT-SERVERS.NET NASA Ames Research Center
NS.ISC.ORG F.ROOT-SERVERS.NET Internet Software Consortium
NS.NIC.DDN.MIL G.ROOT-SERVERS.NET GSI (operated by NSI)
AOS.ARL.ARMY .MIL H.ROOT-SERVERS.NET U.S. Army Research Lab
NIC.NORDU.NET I.ROOT-SERVERS.NET NORDUnet

上線之后,為新的根服務(wù)器留出了空間。于是在 1997 年,又上線了 J/K/L/M 四臺(tái)根服務(wù)器。

這時(shí)候 Priming 查詢響應(yīng)的返回值有多大呢?我們可以算一下:

Header 固定 12 字節(jié)

第一個(gè) PR 保存完整域名,31 字節(jié)

另外 12 PR 保存壓縮后的域名,12*15 = 180 字節(jié)

13 個(gè) PR 保存 A 記錄,13 * 16 = 208 字節(jié)8

Question 段中 QTYPE 和 QCLASS 字段, 4 字節(jié)

Question 段中 QNAME 字段,1 字節(jié)

總共為 12+31+180+208+4+1=436 字節(jié)。剩余可用 512?436=76 字節(jié)。一組臺(tái)服務(wù)器需要額外占用 15+16=31 字節(jié)。理論上還可以再添加兩臺(tái)根服務(wù)器,也就是最多15臺(tái)。

如果只管根服務(wù)器功能,確實(shí)還可以添加。但是早期的根服務(wù)器同時(shí)也是COM/NET/ORG的解析服務(wù)器。客戶端可以向根服器發(fā)起針對(duì)特定COM域名的 Priming 查詢。因?yàn)轫憫?yīng)結(jié)果需要包含查詢域名 QNAME,所以上面說的 76 字節(jié)中至少要保留 64 字節(jié)給 QNAME。這樣就只剩下 12 字節(jié)。所以就不能再添加新的根服務(wù)器了。

IPv6 與 Anycast

雖然理論上是不能再加新的根服務(wù)器了,但后來網(wǎng)絡(luò)不斷發(fā)展,UDP 報(bào)文早已不需要把長度限制到 512 字節(jié)。而且引入 IPv6 網(wǎng)絡(luò)后,Priming 查詢結(jié)果中還需要返回 AAAA 記錄, 512 個(gè)字節(jié)肯定不夠用。所以社區(qū)又設(shè)計(jì)了 EDNS09 來支持返回超過 512 字節(jié)的 DNS 響應(yīng)。

理論上還是可以繼續(xù)添加新的根服務(wù)器。但為什么不加了呢?那是因?yàn)橛辛烁冗M(jìn)的技術(shù) Anycast,中文譯作任播。任播,可以簡單理解為允許不同網(wǎng)絡(luò)中的計(jì)算機(jī)共用一個(gè) IP 地址,同時(shí)對(duì)外提供 DNS 查詢服務(wù)。互聯(lián)網(wǎng)會(huì)根據(jù)客戶端的位置將請(qǐng)求路由到就近的計(jì)算機(jī)。

Anycast 技術(shù)將原來的單臺(tái)服務(wù)器變成了一組多臺(tái)服務(wù)器。到了2002年,J根服務(wù)器首次部署 Anycast 功能。到現(xiàn)在為止,前面說的13臺(tái)根服務(wù)器嚴(yán)格來說是 13 個(gè)域名并且對(duì)應(yīng) 13 對(duì) IPv4 和 IPv6 地址。每對(duì)地址之后都通過 Anycast 部署了很多臺(tái)實(shí)例,總計(jì)有超過 1500 臺(tái)根服務(wù)器實(shí)例。這些實(shí)例又稱為根鏡像服務(wù)器。

中國根服務(wù)器鏡像

雖說中國沒有自己的根服務(wù)器,但境內(nèi)還是有不少根鏡像服務(wù)器:

編號(hào) 城市
A 廣州
D 香港 臺(tái)北
E 臺(tái)北
F 北京 重慶 杭州 高雄 南寧 臺(tái)北
I 北京 香港 沈陽 臺(tái)北
J 北京 香港 湖州 上海
K 北京 廣州 貴陽 臺(tái)北
L 北京 長沙 ???上海 武漢 西寧 新北 鄭州
M 高雄

大家不妨通過 Ping 命令測(cè)一下,上面的幾個(gè)根服務(wù)器的延遲都在 50ms 左右,一看就是在國內(nèi),不然不會(huì)這么快。

審核編輯:湯梓紅

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • 編碼
    +關(guān)注

    關(guān)注

    6

    文章

    932

    瀏覽量

    54731
  • DNS
    DNS
    +關(guān)注

    關(guān)注

    0

    文章

    215

    瀏覽量

    19771
  • 報(bào)文
    +關(guān)注

    關(guān)注

    0

    文章

    38

    瀏覽量

    4012
  • 根服務(wù)器
    +關(guān)注

    關(guān)注

    1

    文章

    7

    瀏覽量

    3205

原文標(biāo)題:為什么 DNS 全球只有 13 臺(tái)根服務(wù)器,中國卻沒有自己的?

文章出處:【微信號(hào):良許Linux,微信公眾號(hào):良許Linux】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

收藏 人收藏

    評(píng)論

    相關(guān)推薦

    FPGA可以做報(bào)文解析嗎?有沒有相關(guān)資料?

    我想在fpga上做一個(gè)報(bào)文解析的功能,就是將一串01數(shù)據(jù)發(fā)送給FPGA,然后fpga對(duì)數(shù)據(jù)進(jìn)行報(bào)文解析,然后再將解析后的數(shù)據(jù)發(fā)送給電腦,想問
    發(fā)表于 11-13 16:04

    如何解決DNS解析錯(cuò)誤故障

    DNS解析出現(xiàn)錯(cuò)誤,就是把一個(gè)域名解析成一個(gè)錯(cuò)誤的IP地址,或者根本不知道某個(gè)域名對(duì)應(yīng)的IP地址是什么時(shí),我們就無法通過域名訪問相應(yīng)的站點(diǎn)了,這就是DNS
    發(fā)表于 09-29 15:14

    為什么我的DNS解析為0.0.0.0?

    為什么我的DNS解析為0.0.0.0?它被稱為SuxChar*URL=“www. GooGl.com”;IPNS4ADDR ADDR;DNSRES= TCPIPSY-DNSUBION解析(URL
    發(fā)表于 01-17 13:36

    使用JavaScript代碼在Rapid板子上實(shí)現(xiàn)DNS解析域名得到IP地址操作分享!

    ,最終得到該主機(jī)名對(duì)應(yīng)的IP地址的過程叫做域名解析(或主機(jī)名解析)。在這里,您將了解到如何使用JavaScript代碼在Rapid板子上來實(shí)現(xiàn)DNS解析域名得到IP地址。Javascr
    發(fā)表于 08-15 04:17

    榮小菜補(bǔ)鈣記第43期:報(bào)文合成與解析之字的合成與分解

    榮小菜補(bǔ)鈣記第43期:報(bào)文合成與解析之字的合成與分解 同步更新于 WeChat:榮小菜在補(bǔ)鈣歡迎關(guān)注 內(nèi)容更豐富大家好,我是榮小菜,本期將分享一個(gè)能夠快速合成和分解報(bào)文字(字節(jié))的Vi,同時(shí)結(jié)合
    發(fā)表于 08-26 20:33

    CAN報(bào)文解析需要知道DBC的哪些信息排序方式

    CAN總線中報(bào)文數(shù)據(jù)讀取方法motorola編碼格式的CAN報(bào)文解析需要知道DBC的哪些信息排序方式讀取方式發(fā)送方式注motorola編碼
    發(fā)表于 01-12 07:28

    Win 2000中DNS服務(wù)器的設(shè)置

    Win 2000中DNS服務(wù)器的設(shè)置  DNS Domain Name Service是域名解析服務(wù),是一種組織成域?qū)哟?b class='flag-5'>結(jié)構(gòu)的計(jì)算機(jī)和網(wǎng)絡(luò)服務(wù)命名系統(tǒng)。
    發(fā)表于 02-01 11:51 ?896次閱讀

    什么是DNS

    什么是DNS  英文原義:Domain Name Server 中文釋義:域名解析系統(tǒng) 注  解:簡單地說,
    發(fā)表于 02-23 11:08 ?718次閱讀

    電力101規(guī)約(2002版)報(bào)文解析

    電力101規(guī)約(2002版)報(bào)文解析~~~~
    發(fā)表于 01-08 14:39 ?0次下載

    淺談兩種加密DNS協(xié)議

    DNS over TLS的標(biāo)準(zhǔn)文檔是RFC7858。文檔很短,也比較易懂??蛻舳讼群瓦f歸服務(wù)器進(jìn)行TLS握手,使用的TCP端口號(hào)是853。握手之后,把DNS數(shù)據(jù)包作為TLS的payload發(fā)給DNS遞歸服務(wù)器即可。請(qǐng)求和回答的
    發(fā)表于 05-02 15:44 ?7269次閱讀

    教你動(dòng)手寫UDP協(xié)議?!?b class='flag-5'>DNS報(bào)文解析

    教你動(dòng)手寫UDP協(xié)議棧系列文章序號(hào)內(nèi)容1《教你動(dòng)手寫UDP協(xié)議棧-UDP協(xié)議棧格式》2《教你動(dòng)手寫UDP協(xié)議棧-DHCP報(bào)文解析》3《教你動(dòng)手寫UDP協(xié)議棧-OTA上位機(jī)》4《教你動(dòng)手寫UDP協(xié)議棧-
    的頭像 發(fā)表于 12-24 16:16 ?1361次閱讀

    網(wǎng)絡(luò)協(xié)議棧:MQTT的報(bào)文格式解析

    在上一篇文章,直接在本地搭建了服務(wù)器和客戶端,簡單的實(shí)踐了MQTT的用法。而這一篇來解析MQTT的報(bào)文格式。MQTT的報(bào)文字段很精簡。但是解析起來還是有些復(fù)雜的。
    的頭像 發(fā)表于 05-13 14:06 ?5291次閱讀
    網(wǎng)絡(luò)協(xié)議棧:MQTT的<b class='flag-5'>報(bào)文</b>格式<b class='flag-5'>解析</b>

    DNS基本概述

    與 HTTP、FTP 和 SMTP 一樣,DNS 協(xié)議也是一種應(yīng)用層的協(xié)議,DNS 使用客戶-服務(wù)器模式運(yùn)行在通信的端系統(tǒng)之間,在通信的端系統(tǒng)之間通過 UDP 運(yùn)輸層協(xié)議來傳送 DNS 報(bào)文
    的頭像 發(fā)表于 05-25 10:49 ?2897次閱讀

    DNS結(jié)構(gòu)和工作原理

    DNS 代表域名系統(tǒng)或域名服務(wù)器。DNS 將IP 地址解析為主機(jī)名,反之亦然。
    的頭像 發(fā)表于 08-05 15:23 ?351次閱讀
    <b class='flag-5'>DNS</b>的<b class='flag-5'>結(jié)構(gòu)</b>和工作原理

    解析的高防DNS是什么?高防DNS有什么作用?

    DNS解析手段在應(yīng)對(duì)攻擊時(shí)只能采取被動(dòng)防守的策略,導(dǎo)致線路擁堵、服務(wù)器宕機(jī)、域名劫持等情況的時(shí)有發(fā)生。云解析作為一種更智能、更安全的解析技術(shù),其高防
    的頭像 發(fā)表于 09-26 17:31 ?224次閱讀