1. D" />

国产成人精品无码青草_亚洲国产美女精品久久久久∴_欧美人与鲁交大毛片免费_国产果冻豆传媒麻婆精东

18143453325 或 在線咨詢 在線咨詢
18143453325 或 在線咨詢
所在位置： 首頁 > 營銷資訊 > 建站知識 > DNS協(xié)議深度解析

DNS協(xié)議深度解析

時間：2023-02-02 15:28:01 | 來源：建站知識

時間：2023-02-02 15:28:01 來源：建站知識

DNS（Domain Name System）是互聯(lián)網(wǎng)的基礎(chǔ)核心協(xié)議之一，我們在日常工作不知不覺中經(jīng)常使用到該協(xié)議，我們需要對其有很好的了解。那么他的主要用途是什么呢？都應(yīng)用在哪些方面呢？下面我們先來了解一下 DNS 協(xié)議及其原理。

1. DNS原理

在現(xiàn)實(shí)世界中，我們?nèi)绻枰业揭粋€餐廳。我們大多數(shù)情況會在大眾點(diǎn)評中搜索這個餐廳，大眾點(diǎn)評的“地址薄”會返回給你一個非常詳細(xì)的地址，比如：廣東省深圳市南山區(qū) XX 路 XX 號。那么在網(wǎng)絡(luò)世界中，我們?nèi)绻涀∫粋€網(wǎng)站，不大可能記住他的 IP 地址，況且如果他的 IP 變動了，我們又需要記住新的 IP 地址。

所以 DNS 是整個互聯(lián)網(wǎng)的地址簿，它能夠?qū)⒖杀蝗死斫獾挠蛎g成可被機(jī)器理解 IP 地址，使得大家不再需要記住 IP 地址，另外當(dāng) IP 地址發(fā)生改變時，我們可以在其發(fā)生變動時修改地址薄中“地址”和 IP 地址的關(guān)系，那么我們就可以保證對外提供的服務(wù)能夠相對穩(wěn)定地被其他客戶訪問。

從這里我們也可以看出來 DNS 在日常生活中多么重要。每個人上網(wǎng)，都需要訪問它，但是同時，這對它來講也是非常大的挑戰(zhàn)。一旦它出了故障，整個互聯(lián)網(wǎng)都將癱瘓。所以 DNS 服務(wù)器一定要設(shè)計(jì)成一個 高可用，高并發(fā)，分布式的架構(gòu)。

于是就有了下面這個樹狀層次結(jié)構(gòu)：

如圖樹的最頂層是根域名，一般使用 . 來表示，所以當(dāng)我們在請求的域名時一般寫為 http://node1.cluster.example.com，但是這里的寫法其實(shí)省略了最后的 .，也就是全稱域名（FQDN）node1.cluster.example.com.

根域名下面的就是 com、net、cn 等頂級域名以及次級域名 http://example.com，我們一般在各個域名網(wǎng)站中購買和使用的都是次級域名、子域名和主機(jī)名了。

既然 DNS 是樹形的層次結(jié)構(gòu)，所以 DNS 服務(wù)也是樹形的并且每一層職責(zé)是不通的。DNS 解析器從根域名服務(wù)器查找到頂級域名服務(wù)器的 IP 地址，又從頂級域名服務(wù)器查找到權(quán)威域名服務(wù)器的 IP 地址，最終從權(quán)威域名服務(wù)器查出了對應(yīng)服務(wù)的 IP 地址。比如 Google 中國主頁所使用的域名是：http://www.google.cn，那么當(dāng)我們請求 DNS 服務(wù)器的時候，他是如何一步步的獲得IP地址的呢？

我們可以在 Linux/MacOS 中使用 dig 命令追蹤一下：

AlandeMacBook-Pro:~ alan$ dig -t A www.google.cn +trace; <<>> DiG 9.10.6 <<>> -t A www.google.cn +trace;; global options: +cmd. 57 IN NS a.root-servers.net.. 57 IN NS d.root-servers.net.. 57 IN NS i.root-servers.net.. 57 IN NS j.root-servers.net.. 57 IN NS c.root-servers.net.. 57 IN NS g.root-servers.net.. 57 IN NS k.root-servers.net.. 57 IN NS l.root-servers.net.. 57 IN NS h.root-servers.net.. 57 IN NS b.root-servers.net.. 57 IN NS f.root-servers.net.. 57 IN NS e.root-servers.net.. 57 IN NS m.root-servers.net.;; Received 228 bytes from 223.5.5.5#53(223.5.5.5) in 57 mscn. 172800 IN NS a.dns.cn.cn. 172800 IN NS b.dns.cn.cn. 172800 IN NS c.dns.cn.cn. 172800 IN NS d.dns.cn.cn. 172800 IN NS e.dns.cn.cn. 172800 IN NS f.dns.cn.cn. 172800 IN NS g.dns.cn.cn. 172800 IN NS ns.cernet.net.cn. 86400 IN DS 57724 8 2 5D0423633EB24A499BE78AA22D1C0C9BA36218FF49FD95A4CDF1A4AD 97C67044cn. 86400 IN RRSIG DS 8 1 86400 20211120050000 20211107040000 14748 . RsJoclM7GXR5uwuTeTwmDt09HTxQXG+dIKA3aCI9E7YPIFqCCuoW3iwA HA9FeNDUoznV+YvAZsMQA+mgwtBdrUWiABuVT69Zv3ye9KBQaLpUV3fQ iNikwG1KAFke2SJ0sH8+7OTTIFoHsWhbmfGWOJiYlaO27FGKjwRDQBgL /GNAYx8Mw7yKvt1qXWHBa8G8d1Xa9GLDYTv3m3zoEPn5rNwYo/I/QTNm J5dFmngsLDS+gPVz5L2u2EGnBPorbipmZrG2xnC9DXLX9Oafk+Ex/RaL /qErKsq6DfJrPruiAbCCbhzPEPBRiq4y/8rjT1sJEmzmnMz/MFX2CmgV wtLYCw==;; Received 704 bytes from 192.58.128.30#53(j.root-servers.net) in 393 msgoogle.cn. 86400 IN NS ns1.google.com.google.cn. 86400 IN NS ns3.google.com.google.cn. 86400 IN NS ns2.google.com.google.cn. 86400 IN NS ns4.google.com.3QDAQA092EE5BELP64A74EBNB8J53D7E.cn. 21600 IN NSEC3 1 1 10 AEF123AB 3QM14FQ32F1CJFTP8D3J5BCTNP5BIELO NS SOA RRSIG DNSKEY NSEC3PARAM3QDAQA092EE5BELP64A74EBNB8J53D7E.cn. 21600 IN RRSIG NSEC3 8 2 21600 20211203071642 20211103061642 38388 cn. qyrAppcU/gK8pzkFh+SkyX+rkvFSyeBK3c9r4XKAzO7QFkh5Hw/aVydP 2nEApdBhFvG2DbH/YVS81XOtiFQkhBmIL6vyByLUGGFcAgn3a7mgIx0n +8Ae2FWLogR0gRRNisU1obpVEvEG9G47fpEZ9iVifc2pLT+ekz3EOJnj N+k=8TKMCNJ923RR3GI4UAK4FF8RHB788CNF.cn. 21600 IN NSEC3 1 1 10 AEF123AB 8UHOOPIE1URLUSVICNFBIDOLA9HMRV82 CNAME RRSIG8TKMCNJ923RR3GI4UAK4FF8RHB788CNF.cn. 21600 IN RRSIG NSEC3 8 2 21600 20211203071642 20211103061642 38388 cn. Jy9qk55fGKqi/iuJuefBQXGKw0GJkmRDxguQDGmWLBwrdUj7hJjWJiP9 5hvYe96UNgnSm5cPdYXUe/yL2X8jPyYxXJW/bf/uHKK65jwnnEGghkS4 yDVkSCWOsDU2gmGdmm5ytga4xcl1ZNx8+98fhTir49m/uo93DqB7CRin oHQ=;; Received 615 bytes from 66.198.183.65#53(g.dns.cn) in 294 mswww.google.cn. 300 IN A 180.163.150.162;; Received 58 bytes from 216.239.32.10#53(ns1.google.com) in 54 ms我們可以看出，首先會向預(yù)置的 13 組根域名服務(wù)器發(fā)出請求獲取頂級域名的地址：

;; global options: +cmd. 57 IN NS a.root-servers.net.. 57 IN NS d.root-servers.net.. 57 IN NS i.root-servers.net.. 57 IN NS j.root-servers.net.. 57 IN NS c.root-servers.net.. 57 IN NS g.root-servers.net.. 57 IN NS k.root-servers.net.. 57 IN NS l.root-servers.net.. 57 IN NS h.root-servers.net.. 57 IN NS b.root-servers.net.. 57 IN NS f.root-servers.net.. 57 IN NS e.root-servers.net.. 57 IN NS m.root-servers.net.;; Received 228 bytes from 223.5.5.5#53(223.5.5.5) in 57 ms根域名服務(wù)器（root name server）是互聯(lián)網(wǎng)域名解析系統(tǒng)（DNS）中最高級別的域名服務(wù)器，負(fù)責(zé)返回頂級域的權(quán)威域名服務(wù)器地址。它們是互聯(lián)網(wǎng)基礎(chǔ)設(shè)施中的重要部分，因?yàn)樗杏蛎馕霾僮骶x不開它們。由于 DNS 和某些協(xié)議（未分片的用戶數(shù)據(jù)報協(xié)議（UDP）數(shù)據(jù)包在 IPv4 內(nèi)的最大有效大小為512字節(jié)）的共同限制，根域名服務(wù)器地址的數(shù)量被限制為 13 個。幸運(yùn)的是，采用任播技術(shù)架設(shè)鏡像服務(wù)器可解決該問題，并使得實(shí)際運(yùn)行的根域名服務(wù)器數(shù)量大大增加。截至2019 年 8 月，全球共有 1008 臺根域名服務(wù)器在運(yùn)行。（具體這13個服務(wù)器的IP地址以及運(yùn)營商請參考這里：https://www.iana.org/domains/root/servers ）

由于中國互聯(lián)網(wǎng)發(fā)展的較晚，國內(nèi)沒有根服務(wù)器，為了防止其他國家因?yàn)檎卧虼驌糁袊?，從而對中國互?lián)網(wǎng)產(chǎn)生重大打擊。截至 2021 年 7 月，中國共有F、I、J、K、L這5個根域的 21 臺 DNS 鏡像在提供服務(wù)。
而通過根服務(wù)器（http://j.root-servers.net），我們獲得了 13 個cn.定義的頂級 DNS 服務(wù)器：

cn. 172800 IN NS a.dns.cn.cn. 172800 IN NS b.dns.cn.cn. 172800 IN NS c.dns.cn.cn. 172800 IN NS d.dns.cn.cn. 172800 IN NS e.dns.cn.cn. 172800 IN NS f.dns.cn.cn. 172800 IN NS g.dns.cn.cn. 172800 IN NS ns.cernet.net.cn. 86400 IN DS 57724 8 2 5D0423633EB24A499BE78AA22D1C0C9BA36218FF49FD95A4CDF1A4AD 97C67044cn. 86400 IN RRSIG DS 8 1 86400 20211120050000 20211107040000 14748 . RsJoclM7GXR5uwuTeTwmDt09HTxQXG+dIKA3aCI9E7YPIFqCCuoW3iwA HA9FeNDUoznV+YvAZsMQA+mgwtBdrUWiABuVT69Zv3ye9KBQaLpUV3fQ iNikwG1KAFke2SJ0sH8+7OTTIFoHsWhbmfGWOJiYlaO27FGKjwRDQBgL /GNAYx8Mw7yKvt1qXWHBa8G8d1Xa9GLDYTv3m3zoEPn5rNwYo/I/QTNm J5dFmngsLDS+gPVz5L2u2EGnBPorbipmZrG2xnC9DXLX9Oafk+Ex/RaL /qErKsq6DfJrPruiAbCCbhzPEPBRiq4y/8rjT1sJEmzmnMz/MFX2CmgV wtLYCw==;; Received 704 bytes from 192.58.128.30#53(j.root-servers.net) in 393 ms再通過上述的頂級 DNS 服務(wù)器（http://g.dns.cn）一共獲得 4 個權(quán)威 DNS 服務(wù)器的地址：

google.cn. 86400 IN NS ns1.google.com.google.cn. 86400 IN NS ns3.google.com.google.cn. 86400 IN NS ns2.google.com.google.cn. 86400 IN NS ns4.google.com.3QDAQA092EE5BELP64A74EBNB8J53D7E.cn. 21600 IN NSEC3 1 1 10 AEF123AB 3QM14FQ32F1CJFTP8D3J5BCTNP5BIELO NS SOA RRSIG DNSKEY NSEC3PARAM3QDAQA092EE5BELP64A74EBNB8J53D7E.cn. 21600 IN RRSIG NSEC3 8 2 21600 20211203071642 20211103061642 38388 cn. qyrAppcU/gK8pzkFh+SkyX+rkvFSyeBK3c9r4XKAzO7QFkh5Hw/aVydP 2nEApdBhFvG2DbH/YVS81XOtiFQkhBmIL6vyByLUGGFcAgn3a7mgIx0n +8Ae2FWLogR0gRRNisU1obpVEvEG9G47fpEZ9iVifc2pLT+ekz3EOJnj N+k=8TKMCNJ923RR3GI4UAK4FF8RHB788CNF.cn. 21600 IN NSEC3 1 1 10 AEF123AB 8UHOOPIE1URLUSVICNFBIDOLA9HMRV82 CNAME RRSIG8TKMCNJ923RR3GI4UAK4FF8RHB788CNF.cn. 21600 IN RRSIG NSEC3 8 2 21600 20211203071642 20211103061642 38388 cn. Jy9qk55fGKqi/iuJuefBQXGKw0GJkmRDxguQDGmWLBwrdUj7hJjWJiP9 5hvYe96UNgnSm5cPdYXUe/yL2X8jPyYxXJW/bf/uHKK65jwnnEGghkS4 yDVkSCWOsDU2gmGdmm5ytga4xcl1ZNx8+98fhTir49m/uo93DqB7CRin oHQ=;; Received 615 bytes from 66.198.183.65#53(g.dns.cn) in 294 ms最后通過 Google 的 DNS 服務(wù)器（http://ns1.google.com）返回他的 IP 地址：

www.google.cn. 300 IN A 180.163.150.162;; Received 58 bytes from 216.239.32.10#53(ns1.google.com) in 54 ms從整個解析過程，我們可以看出 DNS 域名服務(wù)器大體分成三類，根域名服務(wù)、頂級域名服務(wù)以及權(quán)威域名服務(wù)三種，獲取域名對應(yīng)的 IP 地址時，也會像遍歷一棵樹一樣按照從頂層到底層的順序依次請求不同的服務(wù)器。

所以整個過程如過用一副圖表述的話，整體過程如下圖：

上圖中第一步本地 DNS 解析器先查看看本地的緩存是否有這個記錄。如果有則直接使用，因?yàn)樯厦娴倪^程太復(fù)雜了，如果每次都要遞歸解析，那么速度就太慢了。如果本地?zé)o緩存，則需要請求本地的 DNS 服務(wù)器。

第三步本地的 DNS 服務(wù)器一般是你所在的運(yùn)營商（中國電信/聯(lián)通/移動等）提供的，當(dāng)然現(xiàn)在也有很多公共 DNS（比如國內(nèi)很出名的：114.114.114.114，阿里云223.5.5.5；國外很出名的：Google 8.8.8.8。），本地 DNS 服務(wù)器也需要看本地是否有緩存，如果有則返回，因?yàn)樗膊幌氚焉厦娴倪f歸過程再走一遍。




2. HTTPDNS

然后傳統(tǒng)的 DNS 協(xié)議存在一些已知的問題：

1.本地緩存問題

根據(jù)上面的介紹我們知道他并不是每個請求都會訪問根、頂級、權(quán)威 DNS 服務(wù)器，他會訪問過一次后就把結(jié)果緩存到自己本地。當(dāng)其他人再次來訪問的時候，他就會立即返回緩存的數(shù)據(jù)。這就相當(dāng)于你問一個人某餐廳在哪里？他憑借自己的記憶給你說了一個地方，但是可能這個餐廳已經(jīng)換地址了。

還有一種情況，用長城寬帶，移動寬帶的朋友經(jīng)常遇到的一個問題。這些運(yùn)營商通常會把一些靜態(tài)頁面，視頻緩存到他們的服務(wù)器內(nèi)，這樣用戶請求的時候，就不用跨運(yùn)營商進(jìn)行訪問，這樣既加快了速度，也減少了運(yùn)營商之間流量計(jì)算的成本。在域名解析的時候，不會將用戶導(dǎo)向真正的網(wǎng)站，而是指向這個緩存的服務(wù)器。很多情況下是看不出問題的，但是當(dāng)視頻或者頁面更新了，我們就會訪問到老的頁面。

還有就是會導(dǎo)致最短路徑失效，上次緩存的IP地址可能不是離客戶最近的，這樣客戶的訪問速度就會受到影響，從而影響用戶的體驗(yàn)。

2.域名劫持

當(dāng)我們向外部發(fā)出請求解析 DNS 的時候，首先會先連接到本地運(yùn)營商的 DNS 服務(wù)器（如電信/聯(lián)通/移動），由他們的 DNS 服務(wù)器幫我們?nèi)ジ晚敿?DNS 服務(wù)器解析，然后將解析的結(jié)果返回給客戶端。但如果這些本地運(yùn)營商在其 DNS 服務(wù)器上有一些自己的想法，比如想推送個廣告呢？這樣他就可以輕易的劫持你的 DNS請求，達(dá)到自己的一些“小需求”，這就是我們常說的運(yùn)營商劫持。

3.DNS解析更新

本地運(yùn)營商 DNS 服務(wù)器對域名解析緩存的處理上，實(shí)現(xiàn)策略是有所區(qū)別的，有的會忽略域名解析結(jié)果的 TTL 時間限制，在權(quán)威 DNS 服務(wù)器解析變更的時候，因而導(dǎo)致解析結(jié)果在全網(wǎng)生效的周期非常漫長。但是在 DNS 的切換中，某些情況對生效時間要求又比較高。例如異地災(zāi)備業(yè)務(wù)部署的時候，跨地區(qū)數(shù)據(jù)庫，負(fù)載均衡的切換一般通過 DNS 解析來實(shí)現(xiàn)。當(dāng)一個區(qū)域出問題后，需要修改 DNS 解析，將數(shù)據(jù)庫，負(fù)載均衡等域名指向新的 IP 地址，但是如果更新太慢，那很多用戶都會出現(xiàn)訪問異常。




針對以上的情況，就催生了 HTTPDNS。HTTPDNS 一般是基于 Http 協(xié)議向自己搭建或者公有云服務(wù)商提供的基于 HTTP 協(xié)議的 DNS 服務(wù)器集群，分布在多個地點(diǎn)和多個運(yùn)營商的 DNS 服務(wù)器發(fā)送域名解析請求，替代了基于 DNS 協(xié)議向本地運(yùn)營商 Local DNS 發(fā)起解析請求的傳統(tǒng)方式，可以避免了本地運(yùn)營商 Local DNS 造成的域名劫持和跨網(wǎng)訪問問題，解決移動互聯(lián)網(wǎng)服務(wù)中域名解析異常帶來的困擾，同時還可以實(shí)現(xiàn)域名解析快速生效，以及智能調(diào)度實(shí)現(xiàn)用戶獲取離他最近的IP地址。

而 HTTPDNS 特別是適合移動 APP 端復(fù)雜的網(wǎng)絡(luò)條件，既能做到加速解析和加速更新，還能做到精準(zhǔn)調(diào)度，以及避免運(yùn)營商劫持。一般可以為 iOS 和 Android 的應(yīng)用APP 提供 SDK 接入，而服務(wù)端以及非主流客戶端接入一共通過 HTTPS API的方式接入。SDK 的接入非常的方便，這樣就可以通過 SDK 來做到如何更新、何時更新，APP 客戶端可以和服務(wù)器協(xié)調(diào)來做這件事情，而不受制于電信運(yùn)營商。

下面我們通過 API 接入 HTTPDNS 的最佳實(shí)踐簡單了解一下 HTTPDNS 的請求過程：

通過上圖，我們可以看到整個解析過程非常的簡單，不需要向根、頂級、權(quán)威 DNS 服務(wù)器發(fā)送請求。只想要向 HTTPDNS 接口發(fā)送請求即可，大幅縮短了請求路徑，提高了性能。

以上便是目前解決 DNS 協(xié)議使用后遇到的一些問題的一種有效的解決方法--HTTPDNS。

3. Kubernest中的DNS

而 DNS 作為一種常見的服務(wù)發(fā)現(xiàn)手段，很多開源項(xiàng)目都會使用 DNS 為集群提供服務(wù)發(fā)現(xiàn)的功能，Kubernetes 就在集群中使用 DNS 解決服務(wù)發(fā)現(xiàn)的問題。如果使用常規(guī)的 DNS 服務(wù)，就會存在上面說的延遲問題，所以目前 Kubernetes 啟動一個單獨(dú)的 DNS 服務(wù)--CoreDNS。




CoreDNS 在 Kubernetes 1.12版本之后成為默認(rèn) DNS 服務(wù)。他是使用 Golang 編寫的基于 Caddy 服務(wù)器框架實(shí)現(xiàn)的一個插件鏈的架構(gòu)的應(yīng)用，就像其官方文檔上寫的一樣：CoreDNS is powered by plugins. 其主要有3個特點(diǎn)：

1.插件化，開發(fā)者只要按照 CoreDNS Plugin API編寫自定義插件，就可以很方便地集成到 CoreDNS 中。

2.完整的解決方案，其內(nèi)置了緩存、后端存儲管理和健康檢查等功能，無需第三方插件實(shí)現(xiàn)。

3.配置簡單

作為集群部署完成后第一個容器化的應(yīng)用，其為整個集群提供了穩(wěn)定，可靠的 DNS 服務(wù)。

下面我們來一起看一下 CoreDNS 的工作流程：

.:53 { errors health kubernetes cluster.local. in-addr.arpa ip6.arpa { pods insecure upstream fallthrough in-addr.arpa ip6.arpa } prometheus :9153 forward . /etc/resolv.conf cache 30 reload loadbalance}example.io:53 { errors log file /etc/coredns/zones/example.io.db}coredns.io:5300 { file /etc/coredns/zones/coredns.io.db}通過上面的 Corefile，我們可以看出一共定義了 2 個 DNS Server，但有3個配置塊，分別監(jiān)聽的是 53 和 5300 端口，那么 CoreDNS 又是怎么解析這個配置的呢？

可以看出 Coredns 會根據(jù)不同的域名選擇不同區(qū)中的插件進(jìn)行處理。這充分體現(xiàn)了其插件化的架構(gòu)設(shè)計(jì)。




Kubernets 中 DNS 策略可以在每個 Pod 基礎(chǔ)上進(jìn)行設(shè)置，目前，Kubernetes支持Default、ClusterFirst、ClusterFirstWithHostNet和None四種DNS策略，具體請參見https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/。這些策略在 pod-specific 的 dnsPolicy 字段中指定。

Tips：“Default”不是默認(rèn)的DNS策略。如果dnsPolicy的Flag沒有特別指明，則默認(rèn)使用“ClusterFirst”。




所以他的請求流程是：

未配置存根域：沒有匹配上配置的集群域名后綴的任何請求，例如 “www.google.cn”，將會被轉(zhuǎn)發(fā)到繼承自節(jié)點(diǎn)的上游域名服務(wù)器。

已配置存根域：如果配置了存根域和上游 DNS 服務(wù)器，DNS 查詢將基于下面的流程對請求進(jìn)行路由：

首先被發(fā)送到 CoreDNS 中的 DNS 緩存層。

從緩存層，檢查請求的后綴，并根據(jù)下面的情況轉(zhuǎn)發(fā)到對應(yīng)的 DNS 上：

其整體過程如下圖：

以上便是 Kubernetes 中 DNS 解析的策略，那么其具體的 DNS 解析是如何進(jìn)行的呢？由于 Pod 默認(rèn)會根據(jù) /etc/resolve.conf 來進(jìn)行解析過程，我們先看一個 Pod的 /etc/resolve.conf 的文件內(nèi)容：

nameserver 10.6.98.183search default.svc.cluster.local svc.cluster.local cluster.localoptions ndots:5第一行 nameserver 就是CoreDns的Service的ClusterIP，而第二行便是搜索域。

Kubernetes 中，域名的全稱，必須是 service-name.namespace.svc.cluster.local 這種模式，服務(wù)名，就是Kubernetes中 Service 的名稱。所以我們執(zhí)行

curl nginx-democurl nginx-demo.default他們的流程分別是：

首先會通過 10.6.98.183 這個 nameserver 進(jìn)行解析，然后將nginx-demo帶入search的搜索域進(jìn)行dns解析。過程分別是：

nginx-demo.default.svc.cluster.local

nginx-demo.svc.cluster.local

nginx-demo.cluster.local

所以通過這個過程，我們在請求 nginx-demo 和 nginx-demo.default 時，明顯直接請求服務(wù)名稱會更快，效率更高。因?yàn)?nginx-demo.default 第一次請求是 nginx-demo.default.default.svc.cluster.local，到第二次才是正確的：nginx-demo.default.svc.cluster.local，所以這點(diǎn)我們在平時使用中需要特別注意。

上面說的是Kubernetes 內(nèi)部服務(wù)的DNS解析請求，那么如果訪問外部的域名呢？比如請求http://www.google.cn呢？他有時如何工作的呢？


其實(shí)他的請求路徑是：

www.google.cn.default.svc.cluster.local

www.google.cn.svc.cluster.local

www.google.cn.cluster.local

www.google.cn.

可以看出來，有3次請求是無意義的請求。那么為什么會出現(xiàn)這種情況呢？就要回頭去看 /etc/resolve.conf 中的最后一行。

options ndots:5這一行的含義是：如果查詢的域名包含的點(diǎn)“.”，不到5個，那么進(jìn)行DNS查找，將使用非完全限定名稱（或者叫絕對域名），如果你查詢的域名包含點(diǎn)數(shù)大于等于5，那么 DNS 查詢，默認(rèn)會使用絕對域名進(jìn)行查詢。

那么我們?nèi)绾伪苊膺@種查詢浪費(fèi)呢？其實(shí)很簡單，只需要在請求的域名后面加上"."，如：www.google.cn. 這樣子就能避免走 search 域進(jìn)行匹配，從而提升效率。所以我們需要在編寫應(yīng)用代碼時，應(yīng)該硬編碼為包含"."。




4.總結(jié)


本文詳細(xì)介紹了 DNS 的解析原理以及目前 DNS 存在一些缺陷，并通過介紹HTTPDNS 這種新的方式來有效的解決這些缺陷。同時介紹了 Kubernets 中 DNS 的路由策略和解析過程。

歡迎繼續(xù)關(guān)注我的微信公眾號 矢量SRE



關(guān)鍵詞：深度,協(xié)議

74
73
25
news

版權(quán)所有? 億企邦 1997-2025 保留一切法律許可權(quán)利。

為了最佳展示效果，本站不支持IE9及以下版本的瀏覽器，建議您使用谷歌Chrome瀏覽器。 點(diǎn)擊下載Chrome瀏覽器
關(guān)閉