dns域名怎么解密 dns域名解析的兩種方式

DNS加密傳輸

參考:

十載的宣威網(wǎng)站建設(shè)經(jīng)驗，針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時及時工作處理。成都全網(wǎng)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整宣威建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)從事“宣威網(wǎng)站設(shè)計”,“宣威網(wǎng)站推廣”以來，每個客戶項目都認(rèn)真落實執(zhí)行。

DNS 欺騙 即域名信息欺騙是最常見的DNS 安全問題。當(dāng)一個DNS 服務(wù)器掉入陷阱，使用了來自一個惡意DNS服務(wù)器的錯誤信 息，那么該DNS 服務(wù)器就被欺騙了。DNS 欺騙會使那些易受攻擊的DNS 服務(wù)器產(chǎn)生許多安全問題，例如：將用戶引導(dǎo)到錯誤的互聯(lián)網(wǎng)站點，或者發(fā)送一個電子 郵件到一個未經(jīng)授權(quán)的郵件服務(wù)器。

拒絕服務(wù)攻擊（DOS）

黑客主要利用一些DNS 軟件的 漏洞，如在BIND 9 版本（版本9.2.0 以前的 9 系列）如果有人向運行BIND的設(shè)備發(fā)送特定的DNS 數(shù)據(jù)包請求，BIND 就會自動關(guān)閉。攻擊者只能使BIND 關(guān)閉，而無法在服務(wù)器上執(zhí)行任意命令。如 果得不到DNS 服務(wù)，那么就會產(chǎn)生一場災(zāi)難：由于網(wǎng)址不能解析為IP 地址，用戶將無方訪問互聯(lián)網(wǎng)。這樣，DNS 產(chǎn)生的問題就好像是互聯(lián)網(wǎng)本身所產(chǎn)生的問 題，這將導(dǎo)致大量的混亂。

分布式拒絕服務(wù)攻擊（DDOS）

DDOS 攻擊通過使用攻擊者控制的幾十臺或幾百臺計算機攻擊一臺主機，使得服務(wù)拒絕攻擊更難以防范：使服務(wù)拒絕攻擊更難以通過阻塞單一攻擊源主機的數(shù)據(jù)流，來防范服務(wù)拒絕攻擊。Syn Flood 是針對DNS 服務(wù)器最常見的分布式拒絕服務(wù)攻擊。

緩沖區(qū)漏洞

Bind 軟件的 缺省設(shè)置是允許主機間進(jìn)行區(qū)域傳輸（zone transfer）。區(qū)域傳輸主要用于主域名服務(wù)器與輔域名服務(wù)器之間的數(shù)據(jù)同步，使輔域名服務(wù)器可以從主域名服務(wù)器獲得新的數(shù)據(jù)信息。一旦起用區(qū)域傳輸 而不做任何限制，很可能會造成信息泄漏，黑客將可以獲得整個授權(quán)區(qū)域內(nèi)的所有主機的信息，判斷主機功能及安全性，從中發(fā)現(xiàn)目標(biāo)進(jìn)行攻擊。

TSIG SIG0

DNS 的事務(wù)簽名分為 TSIG (Transaction Signatures) 與 SIG0 (SIGnature)兩種。該如何選擇呢? 首先，要先判斷客戶端與服務(wù)器間的信任關(guān)系為何，若是可信任者，可選擇對稱式的 TSIG。TSIG 只有一組密碼，并無公開/私密金鑰之分；若是非完全信任者，可選擇非對稱式金鑰的 SIG0，雖有公開/私密金鑰之分，相對的，設(shè)定上也較復(fù)雜。至于要選用哪種較適合，就由自己來判斷。通常區(qū)帶傳輸是主域名服務(wù)器到輔助域名服務(wù)器。通常 在主域名服務(wù)器配置文件/etc/named.conf 的dns-ip-list 的訪問控制列表（ACL，access control list）會列出一些IP 地址，它們只能為主域進(jìn)行傳輸區(qū)帶信息。

DNSSEC 主要依靠公鑰技術(shù)對于包含在DNS 中的信息創(chuàng)建密碼簽名。密碼簽名通過計算出一個密碼hash數(shù)來提供DNS 中數(shù)據(jù)的完整性，并將該hash 數(shù)封裝進(jìn)行保護(hù)。私/公鑰對中的私鑰用來封裝hash 數(shù)，然后可以用公鑰把hash 數(shù)譯出來。如果這個譯出的hash 值匹配接收者剛剛計算出來的hash 樹，那么表明數(shù)據(jù)是完整的。不管譯出來的hash 數(shù)和計算出來的hash 數(shù)是否匹配，對于密碼簽名這種認(rèn)證方式都是絕對正確的，因為公鑰僅僅用于解密合法 的hash 數(shù)，所以只有擁有私鑰的擁有者可以加密這些信息。

在Windows下使用加密DNS(DoH)

本文在我博客 ?王權(quán)之首の秘密基地 中同步發(fā)布

為什么要使用加密DNS（DoH）

由于部分運營商網(wǎng)絡(luò)的問題，很多寬帶自帶的DNS存在劫持問題，甚至某些寬帶存在劫持53端口，直接強制使用運營商DNS。這就有可能會造成DNS解析結(jié)果的異?；蛘呶廴荆灿锌赡芫哂袀€人隱私泄露的風(fēng)險。所以，要防止DNS污染，就需要使用加密DNS，對DNS請求的過程全程加密，這樣運營商即使獲取到了你的數(shù)據(jù)包，也無法對其解密，更無法對其進(jìn)行修改。這篇文章將會教你如何將你的Windows設(shè)備接入DNS服務(wù)商提供的公共加密DNS服務(wù)

前置條件

1.系統(tǒng)要求：Windows 10 build19628及以上，建議Windows11

設(shè)置步驟

本文以Windows11為例(因為我已升級至Windows11,目前身邊沒有Windows10設(shè)備)

大概方法 :

設(shè)置--網(wǎng)絡(luò)Internet--WLAN/以太網(wǎng)

WLAN--硬件屬性--編輯DNS設(shè)置--手動--開啟IPv4和IPv6--填寫dns地址

以太網(wǎng)--DNS服務(wù)器分配--手動--開啟IPv4和IP v6--填寫dns地址

詳細(xì)步驟

1.在開始菜單中打開設(shè)置

2.進(jìn)入網(wǎng)絡(luò)和Internet 然后選擇你所連接的網(wǎng)絡(luò)(WLAN or 以太網(wǎng))

3.點擊硬件屬性（以太網(wǎng)不需要走這一步）

4.找到DNS服務(wù)器分配，然后點擊編輯

5.將DNS獲取方式從DHCP改為手動

6.輸入你想用的DNS服務(wù)器(這里推薦cloudflare的1.1.1.1和Google的8.8.8.8,文章末尾還有其他推薦的)

7.添加你所選的DNS服務(wù)器到WindowsDNS列表(8.8.8.8和1.1.1.1等權(quán)威DNS提供商不需要這一步)

因為Windows默認(rèn)認(rèn)證的DNS少的可憐，所以需要手動將DNS服務(wù)器加入Windows服務(wù)器列表

同時按下Windows 徽標(biāo)鍵?+ X打開Windows終端(管理員)

然后輸入（這里以O(shè)pen DNS為例）

netsh dns add encryption 208.67.222.222 "" no no netsh dns add encryption 208.67.220.220 “” no no

輸入完成后按Enter鍵

8.將DNS加密設(shè)為僅加密

由于國內(nèi)互聯(lián)網(wǎng)環(huán)境比較特殊，建議先測試所選DNS在大陸加密后能否正常試用，比如說四川電信就無法使用加密了的cloudflare1.1.1.1和Google8.8.8.8，我的解決方法是使用open DNS(服務(wù)器地址在下文“其他”中)

其他:

DNS的Wiki:

DoT的Wiki:

我推薦的公共dns:

1.cloudflare的1.1.1.1

For IPv4 : 1.1.1.1 and? 1.0.0.1

For IPv6 : 2606:4700:4700::1111 and 2606:4700:4700::1001

官網(wǎng): 1.1.1.1 — the Internet’s Fastest, Privacy-First DNS Resolver

2.Google DNS:

The Google Public DNS IP addresses (IPv4) are as follows:

8.8.8.8

8.8.4.4

The Google Public DNS IPv6 addresses are as follows:

2001:4860:4860::8888

2001:4860:4860::8844

官網(wǎng):

3.Open DNS:

For IPv4 :208.67.222.222? and ?208.67.220.220

For IPv6 :2620:119:35::35? and ?2620:119:53::53

4.騰訊

119.29.29.29

182.254.118.118

Public DNS+——DNSPod推出的域名遞歸解析服務(wù)

5.阿里 （不確定能否加密）

223.5.5.5

223.6.6.6

阿里DNS

6.百度 （不確定能否加密）

180.76.76.76

百度DNS - 幫助中心 - 公共DNS

7.CNNIC （不確定能否加密）

1.2.4.8

210.2.4.8

sDNS

網(wǎng)絡(luò)相關(guān)

HTTP是超文本傳輸協(xié)議

get、post、 head、put、delete、options

如下圖：

在發(fā)起一個http請求之前，需要通過tcp的三次握手建立鏈接（就是客戶端和服務(wù)端的三次交互）。

HTTP建立鏈接步驟：

1.客戶端 發(fā)送syn的同步報文到 server端

2.sever端 返回叫ACK的syn同步報文到 客戶端

3.客戶端會 回應(yīng)一個確認(rèn)報文到 server端

1.客戶端 發(fā)送http請求到 server端

2.server 回應(yīng)http響應(yīng)報文

TCP的響應(yīng)完成后，進(jìn)行TCP 的四次揮手。比如客戶端主動 發(fā)起鏈接斷開：

1.客戶端 發(fā)起FIN終止報文到 server端

2.server端收到終止報文之后，返回確認(rèn)報文ACK給 客戶端

3.某一時機， server端 發(fā)送FIN,ACK報文 給客戶端

4.客戶端發(fā)送 ACK確認(rèn)報文到服務(wù)端

http特點：無連接、無狀態(tài)

可節(jié)省tcp建立鏈接、釋放鏈接的數(shù)量。

利用http的 中間人攻擊 漏斗進(jìn)行的。

1.客戶端 向server端發(fā)送一個報文，報文包含（TLS版本號、客戶端支持的加密算法、隨機數(shù)C）

3.客戶端收到server端的報文后：

4.server端：

6.server端也發(fā)送加密的握手消息給客戶端，驗證安全通道是否正確的完成。

（中間生成的隨機數(shù)C、S，非對稱加密傳遞的預(yù)主私鑰都是為了后面得到會話秘鑰做準(zhǔn)備。

客戶端、server端根據(jù)C、S、預(yù)主秘鑰生成會話秘鑰。進(jìn)行傳輸）

會話秘鑰 = 隨機數(shù)S+隨機數(shù)C+預(yù)主秘鑰

對稱加密、非對稱加密

1.連接建立過程中使用 非對稱加密 ，非對稱加密是很 耗時 的。

(因為加密和解密的方法不一樣)

2.后續(xù)通信過程使用對稱加密

有發(fā)送方、接收方。

1.發(fā)送方發(fā)送“hello”字符串，發(fā)送方通過 公鑰 對“hello”進(jìn)行加密。

2.經(jīng)過TCP的連接傳輸?shù)浇邮辗健?/p>

3.接收方通過 私鑰 進(jìn)行解密。

（加密用公鑰、解密就用私鑰。加密用私鑰、解密就用公鑰）

1.發(fā)送方發(fā)送“hello”字符串，發(fā)送方通過 對稱秘鑰 對“hello”進(jìn)行加密。

2.經(jīng)過TCP的連接傳輸?shù)浇邮辗健?/p>

3.接收方通過 同一個秘鑰 進(jìn)行解密。

缺點：

秘鑰需要通過tcp連接進(jìn)行傳遞，server才能通過秘鑰進(jìn)行解密。在網(wǎng)絡(luò)傳輸中如果有中間人攻擊就會被捕獲到。

比如說在應(yīng)用層、傳輸層、IP層（網(wǎng)絡(luò)層）傳輸過程進(jìn)行解釋：

應(yīng)用層有個報文，可大可小。不管大小都不會進(jìn)行拆分傳給運輸層。

應(yīng)用層會把報文原封不動作為運輸層UDP用戶數(shù)據(jù)報的數(shù)據(jù)部分，拼接為UDP頭部。

UDP數(shù)據(jù)報作為IP數(shù)據(jù)報的數(shù)據(jù)部分拼接到IP首部

這個就是多端口復(fù)用。

從接收方來說，IP層接收IP數(shù)據(jù)報數(shù)據(jù)，拆分成UDP數(shù)據(jù)報。每個數(shù)據(jù)報都會有對應(yīng)的端口。就可以根據(jù)端口進(jìn)行分發(fā)。

什么是TCP?

tcp特點、tcp功能

數(shù)據(jù)傳輸開始之前，需要建立鏈接，即三次握手。

數(shù)據(jù)傳輸結(jié)束時，需要斷開鏈接，即四次揮手

為什么是三次握手？

假如是兩次握手：

1.客戶端發(fā)送syn同步報文給server端時，網(wǎng)絡(luò)發(fā)生了超時。

2.客戶端會啟用超時重傳策略，重新syn發(fā)送報文給server。server端就認(rèn)為又要建立一個連接。

假如是三次握手：

客戶端發(fā)送syn同步報文給server端，發(fā)生超時。

server端發(fā)送syn，ACK確認(rèn)請求給客戶端后，會等待客戶端發(fā)送ACK確認(rèn)信號。

此時超時了，客戶端重啟策略發(fā)送的是syn信號，不是ACK信號。等不到ACK信號，說明是鏈接超時了。

四次揮手為什么要客服端、服務(wù)端進(jìn)行兩方面的斷開呢？

客戶端發(fā)起終止報文FIN給給server端；

server發(fā)送ACK確認(rèn)報文給客戶端。

-- 此時客戶端向服務(wù)端的鏈接已經(jīng)斷開了。server端還可以向客戶端發(fā)送數(shù)據(jù)，客戶端不可以向server端發(fā)送數(shù)據(jù)了。就是半關(guān)閉狀態(tài)。

在一定時機內(nèi)，server端會發(fā)起終止確認(rèn)的報文，斷開server端到客戶端方向的鏈接。

客戶端給server端ACK確認(rèn)報文。

要進(jìn)行兩方面的斷開，是因為客戶端和server之間建立的TCP通道是全雙攻的（一條通道兩個端點都可以進(jìn)行發(fā)送和接收）。

TCP是怎么樣保證可靠傳輸?shù)?？（怎么保證報文： 無差錯、 不丟失、 不重復(fù)、 按序到達(dá)）

可靠傳輸在TCP層面是通過【停止等待協(xié)議】實現(xiàn)的：

無差錯情況下，客戶端會按順序的發(fā)送一個報文，得到server端響應(yīng)后發(fā)送下一個報文。

客戶端發(fā)送分組報文M1,server端給客戶端確認(rèn)。

客戶端發(fā)送分組報文M2,server端給客戶端確認(rèn)。

客戶端發(fā)送分組報文M3,server端給客戶端確認(rèn)。

如果因為網(wǎng)絡(luò)等情況，在一定時間內(nèi)，客戶端沒有收到server端的反饋：

客戶端再次發(fā)送報文；

如果因為網(wǎng)絡(luò)等情況，在一定時間內(nèi)，客戶端沒有收到server端的反饋：

客戶端再次發(fā)送報文；

如果因為網(wǎng)絡(luò)等情況，在一定時間內(nèi)，客戶端沒有收到server端的反饋：

客戶端再次發(fā)送報文；

對于TCP，發(fā)送方和接收方各有一個緩沖區(qū)。發(fā)送方會把要發(fā)送的內(nèi)容放在緩沖區(qū)，接收方接收到數(shù)據(jù)后也會放到緩沖區(qū)。

對于每次發(fā)送多少字節(jié)，由TCP連接根據(jù)情況決定。有可能把發(fā)送方的10個字節(jié)會拆分成6個字節(jié)、4個字節(jié)兩次發(fā)送，有可能把發(fā)送方的5個字節(jié)、3個字節(jié)合并成8個字節(jié)一起發(fā)送。

通過【滑動窗口協(xié)議】實現(xiàn)的。

怎么理解滑動窗口協(xié)議？（第三輪面試）

總結(jié)：

【滑動窗口協(xié)議】

發(fā)送方定義為客戶端

接收方定義為server端

簡單描述TCP慢啟動的特點：

考察的是TCP擁塞控制中：慢開始、擁塞避免。

橫軸：交互次數(shù)

縱軸：窗口值的大小、擁塞窗口的多少

1.剛開始發(fā)送1個報文，如果沒有發(fā)生擁塞就發(fā)送2個報文，仍舊沒有擁塞就翻倍，發(fā)送4個報文、8個報文、一直到16個報文。這個過程以 指數(shù)規(guī)律增長 ，叫做 慢開始算法 。

2.當(dāng)增加 到門限值16 的時候，會采用 擁塞避免的策略 進(jìn)行發(fā)送報文數(shù)量的增長。比如17個、18個，是一種 線性 的增長。當(dāng)發(fā)送的報文數(shù)為24的時候，可能就會發(fā)生 網(wǎng)絡(luò)擁塞 。

（網(wǎng)絡(luò)擁塞的界定是很復(fù)雜的，簡單理解為連續(xù)發(fā)送的三個報文的ACK確認(rèn)都沒有收到，就產(chǎn)生網(wǎng)絡(luò)擁塞了）

3.網(wǎng)絡(luò)擁塞產(chǎn)生后，就要采用 乘法減小 的策略，把發(fā)送的報文數(shù)量恢復(fù)到1,減小給網(wǎng)絡(luò)層帶來的壓力。然后重新慢開始.... 同時把擁塞窗口值降低到之前的一半 ，例如之前是24，現(xiàn)在減小為12。

在達(dá)到 窗口門限值 之前使用慢開始，到達(dá)之后進(jìn)行擁塞避免加法增大。

是基于慢恢復(fù)、擁塞避免實現(xiàn)的。

達(dá)到擁塞窗口的上限值之后，回到新的門限值位置開始新的擁塞避免。

你是否了解DNS解析？DNS解析是怎樣的過程呢？

DNS解析是：域名到IP地址的映射，DNS解析采用UDP數(shù)據(jù)報，且明文。

客戶端向server端發(fā)送請求的時候，需要經(jīng)歷一個域名到IP地址的映射過程：

1.客戶端通過DNS協(xié)議向DNS服務(wù)器請求，進(jìn)行相應(yīng)域名的解析。

2.DNS服務(wù)器把解析的IP結(jié)果返回給客戶端。

3.客戶端向?qū)?yīng)的IP Server發(fā)送網(wǎng)絡(luò)請求。

1.客戶端向DNS發(fā)起域名請求的時候，先訪問本地DNS是否知道我要的IP地址，本地DNS知道就進(jìn)行返回，不知道就去問根域名DNS。

2.根域名DNS知道就返回給本地DNS,本地DNS返回給客戶端。根域名DNS不知道的話就去問頂級DNS.....依次類推。。

1.客戶端向DNS發(fā)起域名請求的時候，先訪問本地DNS是否知道我要的IP地址，本地DNS知道就進(jìn)行返回，不知道就去問根域名DNS。

2.根域DNS不知道，說頂級DNS可能知道，你去問頂級DNS吧，然后本地DNS又去問頂級DNS。

DNS解析存在哪些常見的問題？****

DNS劫持問題

DNS解析轉(zhuǎn)發(fā)問題

因為DNS解析是UDP數(shù)據(jù)報的，并且是明文的。

所以客戶端在給DNS服務(wù)器發(fā)送請求的時候，會被釣魚DNS劫持，返回一個錯誤的IP地址給客戶端。導(dǎo)致請求的IP Server也是錯誤的。

1.客戶端詢問本地DNS服務(wù)器某一個域名的IP地址時，我們用的是中國移動，中國移動的DNS服務(wù)器就會進(jìn)行域名解析。

某些域名服務(wù)商為了節(jié)省資源，轉(zhuǎn)發(fā)給電信的DNS服務(wù)器，讓電信DNS服務(wù)器解析。

2.電信DNS服務(wù)器會去權(quán)威的DNS服務(wù)器進(jìn)行解析。權(quán)威DNS根據(jù)不同的服務(wù)商返回不同的IP。返回的就會是電信的IP。

這個就會導(dǎo)致用的移動網(wǎng)絡(luò)，訪問的服務(wù)器是電信網(wǎng)絡(luò)的服務(wù)器處理請求。涉及到了跨網(wǎng)訪問，有請求效率等問題。

DNS解析，其實是使用DNS協(xié)議向DNS服務(wù)器的53端口進(jìn)行請求。

采用httpDNS請求，其實是： 使用HTTP協(xié)議向DNS服務(wù)器的80端口進(jìn)行請求。 就不產(chǎn)生正常的DNS解析，就不會有DNS劫持了。

客戶端向httpDNS server發(fā)送http get請求獲取IP地址。

1.有客戶端、客戶端要請求的API server。客戶端和API server中間建立一個長連server(可以理解為一個代理服務(wù)器)。

2.客戶端和長連server中間建立一個長連通道。客戶端直接通過長連通道把http請求發(fā)給長連server。

3.長連server通過內(nèi)網(wǎng)專線進(jìn)行請求。規(guī)避了公網(wǎng)DNS劫持的問題。

HTTP特點有:

無連接：需要有連接和斷開的一個過程。比如三次握手、四次揮手。

無狀態(tài)：同一個用戶多次訪問server端，server端并不知道是同一個用戶。

session/cookie就是HTTP協(xié)議無狀態(tài)特點的補償。

客戶端向server端發(fā)送請求，server端生成cookie返回給客戶端。

客戶端把cookie進(jìn)行保存，每次請求的時候發(fā)送給server端。讓server端區(qū)分用戶。

客戶端發(fā)送的cookie在http請求報文的cookie首部字段中；

服務(wù)端設(shè)置http響應(yīng)報文的Set-Cookie首部字段；

cookie 主要用來記錄用戶狀態(tài)，區(qū)分用戶； 狀態(tài)保存在服務(wù)端

session 狀態(tài)保存在服務(wù)端

cookie 狀態(tài)保存在客戶端

session依賴于set-Cookie、Cookie這兩個方法。

新聞名稱：dns域名怎么解密 dns域名解析的兩種方式
分享鏈接：http://muchs.cn/article20/ddcepco.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供靜態(tài)網(wǎng)站、微信小程序、網(wǎng)站營銷、網(wǎng)站改版、ChatGPT、面包屑導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)