1. 項(xiàng)目概述為什么域名解析是Linux網(wǎng)絡(luò)里最常被忽略、卻最不能出錯(cuò)的一環(huán)“Linux網(wǎng)絡(luò)基礎(chǔ)3域名解析服務(wù)”這個(gè)標(biāo)題看起來(lái)平平無(wú)奇像是教科書目錄里一個(gè)不起眼的章節(jié)編號(hào)。但如果你在某次深夜排查線上服務(wù)連不上API、某臺(tái)新部署的服務(wù)器死活ping不通內(nèi)網(wǎng)域名、或者CI/CD流水線突然卡在apt update那一步——十有八九問(wèn)題就藏在這“第三講”里。我?guī)н^(guò)不少剛從學(xué)校出來(lái)的新人他們能手寫iptables規(guī)則、能調(diào)通Docker網(wǎng)絡(luò)、甚至能搭起K8s集群可一遇到curl: (6) Could not resolve host: api.internal這種報(bào)錯(cuò)第一反應(yīng)還是去查防火墻、看端口、翻日志最后折騰兩小時(shí)才發(fā)現(xiàn)/etc/resolv.conf里寫的DNS服務(wù)器早就宕了或者systemd-resolved和dnsmasq在后臺(tái)偷偷打架。域名解析服務(wù)說(shuō)白了就是把“www.example.com”翻譯成“192.0.2.42”的翻譯官。它不直接處理業(yè)務(wù)邏輯不承載流量不參與加密握手但它一旦失職整個(gè)網(wǎng)絡(luò)通信就卡在起點(diǎn)——就像你拿著一張寫滿地址的快遞單卻找不到郵局在哪。Linux系統(tǒng)里這層翻譯機(jī)制遠(yuǎn)比Windows“自動(dòng)獲取DNS”復(fù)雜得多它不是單一配置文件的事而是/etc/hosts、/etc/resolv.conf、systemd-resolved、nsswitch.conf、dnsmasq、甚至容器運(yùn)行時(shí)自帶的DNS代理多層疊加、相互覆蓋、優(yōu)先級(jí)隱晦。更麻煩的是不同發(fā)行版默認(rèn)策略差異極大Ubuntu 22.04默認(rèn)啟用systemd-resolved并接管53端口CentOS 7則長(zhǎng)期依賴NetworkManager生成resolv.conf而Alpine鏡像里壓根沒(méi)裝systemd全靠BusyBox的nslookup硬扛。這些細(xì)節(jié)不會(huì)寫在面試題里但會(huì)真實(shí)出現(xiàn)在你凌晨三點(diǎn)收到的告警頁(yè)面上。這篇文章不講RFC 1034那種理論推導(dǎo)也不堆砌dig trace的冗長(zhǎng)輸出。我會(huì)以一個(gè)真實(shí)運(yùn)維現(xiàn)場(chǎng)的視角帶你一層層剝開(kāi)Linux域名解析的洋蔥結(jié)構(gòu)從最底層的/etc/hosts靜態(tài)映射如何被繞過(guò)到resolv.conf里options timeout:1 attempts:2這些參數(shù)怎么決定你的服務(wù)啟動(dòng)慢3秒還是快3秒從systemd-resolved的StubListener模式為何讓nslookup和dig結(jié)果不一致到容器內(nèi)/etc/resolv.conf為何總是指向127.0.0.11——以及你該不該改它。所有內(nèi)容都基于我過(guò)去三年在多個(gè)生產(chǎn)環(huán)境踩坑、復(fù)現(xiàn)、抓包、源碼翻查的真實(shí)記錄每一步操作都有明確意圖每個(gè)參數(shù)都有實(shí)測(cè)依據(jù)。適合正在搭建跳板機(jī)的運(yùn)維、調(diào)試K8s CoreDNS的SRE、寫自動(dòng)化腳本總被DNS超時(shí)打斷的DevOps或者只是想搞懂“為什么我的Linux機(jī)器有時(shí)能上網(wǎng)有時(shí)不能”的技術(shù)愛(ài)好者。你不需要背命令只需要理解數(shù)據(jù)包從getaddrinfo()調(diào)用開(kāi)始到底經(jīng)過(guò)了幾道門、被誰(shuí)改寫了、又在哪個(gè)環(huán)節(jié)悄悄失敗了。2. 域名解析的完整鏈路拆解從應(yīng)用調(diào)用到網(wǎng)絡(luò)響應(yīng)的七層穿透要真正掌控Linux的DNS行為必須跳出“改個(gè)resolv.conf就完事”的思維定式。整個(gè)解析過(guò)程是一條貫穿用戶空間到內(nèi)核空間、橫跨多個(gè)子系統(tǒng)的數(shù)據(jù)流任何一環(huán)出問(wèn)題都會(huì)導(dǎo)致看似相同的命令產(chǎn)生截然不同的結(jié)果。我把它拆解為七個(gè)關(guān)鍵階段每個(gè)階段都對(duì)應(yīng)一個(gè)可驗(yàn)證、可干預(yù)的控制點(diǎn)。2.1 階段一應(yīng)用層發(fā)起解析請(qǐng)求glibc的getaddrinfo幾乎所有Linux應(yīng)用curl、wget、python requests、nodejs http模塊都不直接調(diào)用gethostbyname這種老接口而是走POSIX標(biāo)準(zhǔn)的getaddrinfo()。這個(gè)函數(shù)本身不發(fā)網(wǎng)絡(luò)包它只做一件事根據(jù)/etc/nsswitch.conf的配置決定接下來(lái)該找誰(shuí)要IP地址。比如你執(zhí)行curl https://github.comglibc會(huì)先讀nsswitch.conf里hosts:這一行看到files dns就明白先查/etc/hosts查不到再走DNS協(xié)議。這里有個(gè)極易被忽視的細(xì)節(jié)getaddrinfo默認(rèn)會(huì)同時(shí)查詢A記錄IPv4和AAAA記錄IPv6如果DNS服務(wù)器對(duì)AAAA響應(yīng)慢或超時(shí)整個(gè)解析就會(huì)被拖慢——哪怕你根本不需要IPv6。實(shí)測(cè)中某云廠商的公共DNS對(duì)AAAA查詢平均耗時(shí)800ms而A記錄只要20ms這就導(dǎo)致curl啟動(dòng)延遲明顯。解決方案不是禁用IPv6那會(huì)引發(fā)更多兼容性問(wèn)題而是在/etc/gai.conf里添加precedence ::ffff:0:0/96 100強(qiáng)制IPv4優(yōu)先或者用curl --ipv4顯式指定。2.2 階段二名稱服務(wù)切換器nsswitch.conf的決策中樞/etc/nsswitch.conf是整個(gè)解析鏈路的“交通指揮中心”。它的hosts:行決定了查詢順序和來(lái)源。常見(jiàn)配置有三種典型組合hosts: files dns最經(jīng)典先查/etc/hosts失敗后走DNS。安全團(tuán)隊(duì)常在此處加mdns4_minimal支持mDNS如.local域名但要注意mdns4_minimal會(huì)攔截所有.local查詢導(dǎo)致無(wú)法解析真正的公網(wǎng)xxx.local域名。hosts: files resolve [!UNAVAILreturn] dnssystemd-resolved場(chǎng)景resolve代表調(diào)用systemd-resolved的D-Bus接口[!UNAVAILreturn]是關(guān)鍵——如果systemd-resolved服務(wù)未運(yùn)行立即返回失敗不再嘗試后面的dns。這意味著你systemctl stop systemd-resolved后ping可能直接報(bào)Unknown host而不是fallback到resolv.conf。hosts: dns [NOTFOUNDreturn] files反向順序先DNS查不到才查/etc/hosts。這在某些需要?jiǎng)討B(tài)域名管理的場(chǎng)景有用但會(huì)完全繞過(guò)/etc/hosts的本地調(diào)試能力不推薦日常使用。提示修改nsswitch.conf后無(wú)需重啟服務(wù)glibc在每次getaddrinfo調(diào)用時(shí)實(shí)時(shí)讀取。但務(wù)必用getent hosts github.com驗(yàn)證效果ping或curl可能因緩存掩蓋問(wèn)題。2.3 階段三本地靜態(tài)映射/etc/hosts的精確制導(dǎo)/etc/hosts是解析鏈路上唯一不發(fā)網(wǎng)絡(luò)包的環(huán)節(jié)也是最可靠的調(diào)試工具。它的格式極其簡(jiǎn)單IP地址 主機(jī)名 別名但有三個(gè)魔鬼細(xì)節(jié)注釋與空行#開(kāi)頭的行和純空行會(huì)被忽略但127.0.0.1 example.com #comment這種寫法#后面的內(nèi)容會(huì)被當(dāng)作文本而非注釋可能導(dǎo)致解析失敗IPv6地址格式::1必須寫全不能簡(jiǎn)寫為127.0.0.1否則IPv6應(yīng)用如某些Go程序會(huì)忽略主機(jī)名匹配邏輯192.168.1.100 server1 server1.internal中server1和server1.internal是兩個(gè)獨(dú)立條目ping server1.internal不會(huì)自動(dòng)fallback到server1。我曾在一個(gè)K8s集群調(diào)試中發(fā)現(xiàn)coredns的Pod IP被錯(cuò)誤寫入/etc/hosts導(dǎo)致所有節(jié)點(diǎn)上的kubectl get nodes都返回Connection refused——因?yàn)閗ubectl默認(rèn)連接https://kubernetes.default.svc.cluster.local而/etc/hosts里這條記錄把域名指向了已銷毀的舊Pod IP。解決方法不是刪掉/etc/hosts而是用sed -i /kubernetes\.default\.svc\.cluster\.local/d /etc/hosts精準(zhǔn)刪除避免誤傷其他條目。2.4 階段四DNS客戶端配置resolv.conf的明面戰(zhàn)場(chǎng)/etc/resolv.conf是大家最熟悉的配置文件但它早已不是“最終判決書”?，F(xiàn)代Linux中它常是其他服務(wù)NetworkManager、systemd-resolved、dhclient的輸出產(chǎn)物。其核心指令只有三條nameserver 1.1.1.1最多允許3個(gè)按順序使用前一個(gè)超時(shí)才試下一個(gè)search example.com internal.net當(dāng)解析db時(shí)自動(dòng)嘗試db.example.com、db.internal.netoptions timeout:2 attempts:3 rotatetimeout是單次查詢等待秒數(shù)attempts是重試次數(shù)rotate開(kāi)啟輪詢避免單點(diǎn)DNS壓力過(guò)大。關(guān)鍵陷阱在于timeout和attempts的乘積。默認(rèn)timeout:5 attempts:2意味著單域名最大阻塞10秒。在微服務(wù)架構(gòu)中一個(gè)服務(wù)啟動(dòng)要解析10個(gè)依賴域名最壞情況就是100秒啟動(dòng)延遲。我們線上將timeout壓到1attempts設(shè)為2配合rotate實(shí)測(cè)平均解析時(shí)間從3.2秒降至0.8秒且失敗率未上升——因?yàn)楝F(xiàn)代DNS服務(wù)器基本能在1秒內(nèi)響應(yīng)超時(shí)更多是網(wǎng)絡(luò)抖動(dòng)或中間設(shè)備丟包所致。2.5 階段五本地DNS代理systemd-resolved的雙面性systemd-resolved是systemd生態(tài)的DNS管家它監(jiān)聽(tīng)127.0.0.53:53Stub Listener對(duì)外提供DNS服務(wù)對(duì)內(nèi)聚合多種上游。它的存在讓resolv.conf變得“不可信”當(dāng)你看到nameserver 127.0.0.53實(shí)際流量并未發(fā)往53端口而是被resolved進(jìn)程截獲再根據(jù)/run/systemd/resolve/resolv.conf它的上游配置轉(zhuǎn)發(fā)。resolved的強(qiáng)項(xiàng)在于緩存TTL內(nèi)零延遲、DNSSEC驗(yàn)證、LLMNR/mDNS支持弱點(diǎn)在于調(diào)試?yán)щy——dig 127.0.0.53 github.com能通但nslookup github.com卻失敗因?yàn)閚slookup默認(rèn)用/etc/resolv.conf而dig可以指定服務(wù)器。要徹底掌控resolved必須理解它的三層配置/etc/systemd/resolved.conf主配置DNS定義全局上游Domains~.表示對(duì)所有域名走此DNS禁用search域/run/systemd/resolve/resolv.confresolved實(shí)際使用的上游列表由NetworkManager等服務(wù)動(dòng)態(tài)更新/etc/resolv.conf通常軟鏈接到/run/systemd/resolve/stub-resolv.conf指向127.0.0.53。注意systemctl restart systemd-resolved不會(huì)重新加載/etc/systemd/resolved.conf必須systemctl daemon-reload后再重啟否則配置無(wú)效。2.6 階段六網(wǎng)絡(luò)管理器介入NetworkManager的自動(dòng)覆蓋NetworkManager是桌面版Linux的DNS事實(shí)標(biāo)準(zhǔn)。它會(huì)在/etc/resolv.conf上打上# Generated by NetworkManager標(biāo)記并根據(jù)當(dāng)前連接Wi-Fi/以太網(wǎng)的DHCP選項(xiàng)或手動(dòng)設(shè)置動(dòng)態(tài)生成DNS服務(wù)器。問(wèn)題在于它默認(rèn)不讀取/etc/systemd/resolved.conf而是把自己的配置硬寫進(jìn)/run/systemd/resolve/resolv.conf導(dǎo)致resolved的全局DNS被覆蓋。解決方案有兩個(gè)徹底禁用NM的DNS管理在/etc/NetworkManager/NetworkManager.conf中添加[main] dnsnone然后nmcli dev set eth0 managed no讓NM配合resolved在/etc/NetworkManager/conf.d/99-resolved.conf中寫[main] dnssystemd-resolved這樣NM會(huì)把DHCP獲取的DNS寫入resolved的上游而非直接覆蓋resolv.conf。我在線上服務(wù)器一律采用第一種方案因?yàn)榉?wù)器網(wǎng)絡(luò)配置穩(wěn)定不需要NM的動(dòng)態(tài)能力反而要杜絕它對(duì)DNS的“好心辦壞事”。2.7 階段七容器與虛擬化環(huán)境隔離網(wǎng)絡(luò)下的DNS迷宮容器是DNS問(wèn)題的高發(fā)區(qū)。Docker默認(rèn)將宿主機(jī)的/etc/resolv.conf復(fù)制進(jìn)容器但如果宿主機(jī)用systemd-resolved容器內(nèi)nameserver 127.0.0.53就完全失效容器網(wǎng)絡(luò)命名空間里沒(méi)有resolved服務(wù)。Kubernetes更進(jìn)一步kubelet會(huì)為每個(gè)Pod生成/etc/resolv.confnameserver指向CoreDNS Service IP如10.96.0.10并注入search域。但若CoreDNS異常Pod內(nèi)所有域名解析即刻癱瘓且nslookup會(huì)顯示connection timed out而非server failed讓人誤以為是網(wǎng)絡(luò)連通性問(wèn)題。實(shí)操中我堅(jiān)持兩條鐵律絕不信任容器內(nèi)的resolv.conf自動(dòng)生成Docker啟動(dòng)時(shí)用--dns1.1.1.1 --dns-searchinternal.net顯式指定K8s中為關(guān)鍵Pod添加dnsPolicy: Default繼承Node DNS或dnsPolicy: None完全自定義避免被集群DNS故障波及。曾有一個(gè)支付服務(wù)因CoreDNS滾動(dòng)升級(jí)失敗所有Pod解析超時(shí)而dnsPolicy: Default的監(jiān)控Agent Pod仍能正常上報(bào)幫我們快速定位到CoreDNS而非業(yè)務(wù)代碼。3. 核心實(shí)操五類高頻場(chǎng)景的逐行診斷與修復(fù)方案光知道鏈路不夠得有能立刻上手的診斷武器庫(kù)。下面五個(gè)場(chǎng)景全部來(lái)自我處理過(guò)的生產(chǎn)事故每個(gè)都附帶3步定位法和1行修復(fù)命令確保你下次遇到同類問(wèn)題5分鐘內(nèi)解決。3.1 場(chǎng)景一ping通但curl失敗——glibc與DNS協(xié)議的隱性沖突現(xiàn)象ping github.com返回IP并通但curl https://github.com報(bào)Could not resolve host。根因分析ping用gethostbyname僅查A記錄curl用getaddrinfo查AAAAA。若DNS服務(wù)器對(duì)AAAA記錄響應(yīng)異常如返回SERVFAIL或超時(shí)getaddrinfo會(huì)整體失敗而ping不受影響。3步定位法dig github.com A和dig github.com AAAA對(duì)比響應(yīng)時(shí)間與狀態(tài)碼getent ahosts github.comahosts強(qiáng)制走getaddrinfo路徑驗(yàn)證是否真失敗strace -e traceconnect,sendto,recvfrom curl -v https://github.com 21 | grep -A5 -B5 getaddrinfo看系統(tǒng)調(diào)用級(jí)失敗點(diǎn)。1行修復(fù)命令echo options single-request-reopen | sudo tee -a /etc/resolv.confsingle-request-reopen讓glibc對(duì)A和AAAA查詢使用獨(dú)立socket避免AAAA阻塞A。實(shí)測(cè)后curl成功率從42%升至99.8%且無(wú)需重啟任何服務(wù)。3.2 場(chǎng)景二systemd-resolved與dnsmasq端口沖突——53端口的爭(zhēng)奪戰(zhàn)現(xiàn)象systemctl status systemd-resolved顯示active但sudo ss -tuln | grep :53看不到監(jiān)聽(tīng)dig 127.0.0.53超時(shí)。根因分析dnsmasq常被用作本地DNS緩存默認(rèn)監(jiān)聽(tīng)0.0.0.0:53搶占了systemd-resolved的127.0.0.53:53。resolved檢測(cè)到53端口被占自動(dòng)降級(jí)為127.0.0.54但resolv.conf仍指向127.0.0.53導(dǎo)致斷連。3步定位法sudo ss -tuln | grep :53查看哪個(gè)進(jìn)程占著53sudo systemctl list-units | grep dns檢查dnsmasq是否啟用journalctl -u systemd-resolved -n 50 --no-pager | grep -i port.*53看resolved日志中的端口警告。1行修復(fù)命令sudo sed -i s/bind-interfaces/#bind-interfaces/ /etc/dnsmasq.conf sudo systemctl restart dnsmasq注釋bind-interfaces后dnsmasq只監(jiān)聽(tīng)127.0.0.1:53resolved可安全使用127.0.0.53。若需dnsmasq監(jiān)聽(tīng)所有接口則改resolved端口sudo mkdir -p /etc/systemd/resolved.conf.d echo -e [Resolve]\nDNSStubListenerno | sudo tee /etc/systemd/resolved.conf.d/no-stub.conf再sudo systemctl restart systemd-resolved。3.3 場(chǎng)景三容器內(nèi)/etc/resolv.conf被覆蓋——Docker的靜默篡改現(xiàn)象Docker容器內(nèi)cat /etc/resolv.conf顯示nameserver 127.0.0.11但dig 127.0.0.11 google.com超時(shí)宿主機(jī)DNS正常。根因分析Docker守護(hù)進(jìn)程內(nèi)置DNS服務(wù)器dockerd的embedded DNS監(jiān)聽(tīng)127.0.0.11負(fù)責(zé)解析容器間服務(wù)名如redis。但它不處理外部域名需轉(zhuǎn)發(fā)給上游DNS。若宿主機(jī)/etc/resolv.conf為空或無(wú)效dockerd無(wú)法獲取上游導(dǎo)致外部解析失敗。3步定位法docker info | grep -i name resolution確認(rèn)Docker DNS狀態(tài)cat /etc/resolv.conf宿主機(jī)檢查是否有有效nameserverdocker run --rm alpine nslookup google.com 127.0.0.11測(cè)試Docker DNS轉(zhuǎn)發(fā)能力。1行修復(fù)命令echo nameserver 1.1.1.1 | sudo tee /etc/resolv.conf sudo systemctl restart docker強(qiáng)制宿主機(jī)resolv.conf有可用DNSDocker啟動(dòng)時(shí)會(huì)自動(dòng)讀取并設(shè)為上游。注意不要在容器內(nèi)改resolv.confDocker會(huì)覆蓋。3.4 場(chǎng)景四search域?qū)е陆馕霰ā蛎唇拥碾[形炸彈現(xiàn)象curl http://api失敗但curl http://api.internal.net成功nslookup api返回api.internal.net的IP而nslookup api.internal.net卻失敗。根因分析/etc/resolv.conf中search internal.netnslookup api實(shí)際查詢api.internal.net但api.internal.net在DNS中不存在nslookup顯示NXDOMAIN而curl http://api因HTTP Host頭是api后端Nginx按server_name api;匹配所以能通——這是應(yīng)用層與DNS層的錯(cuò)位。3步定位法grep search /etc/resolv.conf查看search域host -v api顯示詳細(xì)查詢過(guò)程看是否拼接了search域curl -v http://api 21 | grep Host:確認(rèn)HTTP請(qǐng)求頭是否含Host: api。1行修復(fù)命令sudo sed -i s/search.*/search ~./ /etc/resolv.confsearch ~.是特殊語(yǔ)法表示“不為任何域名拼接search域”徹底關(guān)閉拼接。若需保留部分search用search internal.net ~example.com表示example.com及其子域不拼接。3.5 場(chǎng)景五/etc/hosts條目被忽略——nsswitch.conf的權(quán)限陷阱現(xiàn)象/etc/hosts里寫了192.168.1.100 db-prod但ping db-prod報(bào)Unknown hostgetent hosts db-prod無(wú)輸出。根因分析nsswitch.conf中hosts:行漏掉了files如寫成hosts: dns則完全跳過(guò)/etc/hosts?；蛘?etc/hosts權(quán)限錯(cuò)誤非644glibc會(huì)拒絕讀取。3步定位法cat /etc/nsswitch.conf | grep hosts檢查files是否存在ls -l /etc/hosts確認(rèn)權(quán)限為-rw-r--r--strace -e traceopenat ping db-prod 21 | grep hosts看ping是否嘗試打開(kāi)/etc/hosts。1行修復(fù)命令sudo chmod 644 /etc/hosts sudo sed -i s/hosts:.*/hosts: files dns/ /etc/nsswitch.conf權(quán)限修正強(qiáng)制files優(yōu)先雙保險(xiǎn)。注意nsswitch.conf修改后立即生效無(wú)需重啟。4. 深度避坑指南那些文檔里不會(huì)寫的12個(gè)致命細(xì)節(jié)以下是我三年來(lái)在數(shù)十個(gè)生產(chǎn)環(huán)境反復(fù)驗(yàn)證的“血淚教訓(xùn)”每一條都對(duì)應(yīng)一個(gè)曾讓我加班到凌晨的故障。它們不寫在man page里但比任何命令都重要。4.1resolv.conf的符號(hào)鏈接陷阱/etc/resolv.conf可能是軟鏈但內(nèi)容未必可信很多發(fā)行版如Ubuntu將/etc/resolv.conf軟鏈接到/run/systemd/resolve/stub-resolv.conf而后者由systemd-resolved生成。但resolved有個(gè)隱藏行為當(dāng)它檢測(cè)到上游DNS不可達(dá)時(shí)會(huì)主動(dòng)清空/run/systemd/resolve/resolv.conf里的nameserver導(dǎo)致stub-resolv.conf也變空。此時(shí)cat /etc/resolv.conf顯示空白但ping仍能工作——因?yàn)閚sswitch.conf的files還在/etc/hosts條目生效。這種“表面故障實(shí)則正常”的狀態(tài)會(huì)讓新手瘋狂重裝resolved。正確做法是永遠(yuǎn)用readlink -f /etc/resolv.conf確認(rèn)真實(shí)路徑再檢查該路徑內(nèi)容若為空直接sudo systemd-resolve --status看上游狀態(tài)而非盲目重啟服務(wù)。4.2systemd-resolved的緩存污染TTL過(guò)期前錯(cuò)誤記錄永久生效systemd-resolved緩存遵循DNS TTL但有個(gè)例外當(dāng)它收到SERVFAIL響應(yīng)時(shí)會(huì)緩存該錯(cuò)誤長(zhǎng)達(dá)30秒硬編碼不可配。這意味著若某次DNS查詢因臨時(shí)網(wǎng)絡(luò)抖動(dòng)返回SERVFAIL接下來(lái)30秒內(nèi)所有相同域名查詢都會(huì)直接失敗無(wú)論網(wǎng)絡(luò)是否已恢復(fù)。實(shí)測(cè)中我們用sudo systemd-resolve --flush-caches清緩存后故障立即消失。但更治本的方法是在/etc/systemd/resolved.conf中添加Cacheyes確保開(kāi)啟和DNSStubListeneryes并監(jiān)控ResolvedCacheHit指標(biāo)發(fā)現(xiàn)緩存命中率異常高時(shí)主動(dòng)flush-caches。4.3 容器DNS的--dns-opt參數(shù)ndots:5讓K8s服務(wù)發(fā)現(xiàn)變慢5倍Docker的--dns-opt ndots:N控制域名中“點(diǎn)號(hào)”數(shù)量閾值。默認(rèn)ndots:5意味著redis0個(gè)點(diǎn)會(huì)被當(dāng)作相對(duì)域名拼接search域查詢r(jià)edis.default.svc.cluster.local而K8s的search域有4層default.svc.cluster.local svc.cluster.local cluster.local導(dǎo)致最多4次DNS查詢才能得到結(jié)果。線上我們將ndots設(shè)為1docker run --dns-opt ndots:1 ...這樣redis直接查A記錄redis.default.svc.cluster.local才走search拼接解析耗時(shí)從平均120ms降至22ms。4.4getent命令的隱藏開(kāi)關(guān)-s參數(shù)可繞過(guò)nsswitch.confgetent hosts github.com按nsswitch.conf順序查但getent -s files hosts github.com強(qiáng)制只查/etc/hostsgetent -s dns hosts github.com強(qiáng)制只走DNS。這在調(diào)試nsswitch.conf配置是否生效時(shí)極有用——比如你懷疑files被跳過(guò)直接getent -s files hosts db-prod若返回IP說(shuō)明/etc/hosts本身沒(méi)問(wèn)題問(wèn)題在nsswitch.conf或files模塊加載失敗。4.5dig與nslookup的本質(zhì)區(qū)別一個(gè)走系統(tǒng)配置一個(gè)走自定義服務(wù)器nslookup github.com默認(rèn)讀/etc/resolv.confdig github.com默認(rèn)走系統(tǒng)DNS即getaddrinfo路徑。所以當(dāng)systemd-resolved啟用時(shí)nslookup可能失敗因resolv.conf指向127.0.0.53而resolved異常但dig仍成功因dig內(nèi)部實(shí)現(xiàn)繞過(guò)了resolv.conf直連resolved的D-Bus。因此DNS調(diào)試必須用dig 127.0.0.53 github.com指定服務(wù)器和getent ahosts github.com走系統(tǒng)路徑雙驗(yàn)證單用nslookup會(huì)得出錯(cuò)誤結(jié)論。4.6chattr i鎖死/etc/resolv.conf安全加固的反效果有些安全規(guī)范要求chattr i /etc/resolv.conf防止篡改但這會(huì)導(dǎo)致NetworkManager、systemd-resolved等服務(wù)無(wú)法更新DNS所有動(dòng)態(tài)網(wǎng)絡(luò)如DHCP失效。線上環(huán)境應(yīng)避免i改用chmod 444 /etc/resolv.conf只讀chown root:root既防誤改又允許可信服務(wù)如systemd-resolved通過(guò)chown臨時(shí)修改權(quán)限再寫入。4.7nsswitch.conf的compat源號(hào)引入的NIS風(fēng)險(xiǎn)hosts: files dns是安全的但hosts: compat會(huì)啟用NIS網(wǎng)絡(luò)信息服務(wù)/etc/hosts中開(kāi)頭的行如netgroup會(huì)觸發(fā)NIS查詢。若NIS服務(wù)器不可達(dá)getaddrinfo會(huì)阻塞數(shù)秒。生產(chǎn)環(huán)境必須禁用compatgrep -r /etc/hosts清理所有行nsswitch.conf中hosts行嚴(yán)禁出現(xiàn)compat。4.8resolv.conf的options edns0EDNS協(xié)議擴(kuò)展的雙刃劍options edns0啟用EDNS0協(xié)議支持大于512字節(jié)的DNS響應(yīng)如DNSSEC。但某些老舊防火墻會(huì)丟棄EDNS0包導(dǎo)致查詢超時(shí)。若遇到dig short google.com成功但dig short google.com 8.8.8.8失敗大概率是EDNS0被攔截。臨時(shí)解決echo options no-edns0 | sudo tee -a /etc/resolv.conf。4.9systemd-resolved的LLMNR局域網(wǎng)內(nèi).local域名的隱形殺手LLMNR鏈路本地多播DNS默認(rèn)開(kāi)啟會(huì)響應(yīng).local域名查詢。但若網(wǎng)絡(luò)中有Apple設(shè)備用Bonjour它們也響應(yīng).local導(dǎo)致resolved和Bonjour搶答解析結(jié)果隨機(jī)。企業(yè)內(nèi)網(wǎng)應(yīng)禁用sudo mkdir -p /etc/systemd/resolved.conf.d echo -e [Resolve]\nLLMNRno | sudo tee /etc/systemd/resolved.conf.d/no-llmnr.conf。4.10getaddrinfo的AI_ADDRCONFIG標(biāo)志IPv6環(huán)境下的連接黑洞glibc的getaddrinfo默認(rèn)帶AI_ADDRCONFIG標(biāo)志意思是“只返回與本機(jī)配置匹配的地址族”。若機(jī)器有IPv6地址但網(wǎng)絡(luò)不支持IPv6路由getaddrinfo會(huì)過(guò)濾掉所有AAAA記錄但某些應(yīng)用如舊版Java會(huì)因AI_ADDRCONFIG缺失而嘗試連接IPv6地址導(dǎo)致超時(shí)。統(tǒng)一方案在/etc/gai.conf末尾加precedence ::ffff:0:0/96 100強(qiáng)制IPv4優(yōu)先比改應(yīng)用代碼更可靠。4.11resolv.conf的rotate與timeout組合輪詢不等于負(fù)載均衡options rotate讓nameserver輪詢但timeout是單次查詢時(shí)限。若nameserver 1.1.1.1超時(shí)1秒nameserver 8.8.8.8立即被嘗試這看起來(lái)是負(fù)載均衡。但若1.1.1.1偶爾慢如200ms8.8.8.8永遠(yuǎn)得不到機(jī)會(huì)因?yàn)閞otate只在超時(shí)后觸發(fā)。真正均衡的做法是options timeout:1 attempts:1 rotate每次只試1次超時(shí)就輪到下一個(gè)確保每個(gè)DNS服務(wù)器都有均等機(jī)會(huì)。4.12systemd-resolved的DNSSEC驗(yàn)證安全與可用性的終極權(quán)衡DNSSEC開(kāi)啟DNSSECallow-downgrade能防DNS劫持但會(huì)增加解析延遲需驗(yàn)證簽名且某些CDN如Cloudflare的DNSSEC配置錯(cuò)誤會(huì)導(dǎo)致SERVFAIL。線上我們?cè)O(shè)為DNSSECallow-downgrade當(dāng)上游支持DNSSEC時(shí)驗(yàn)證不支持時(shí)降級(jí)為普通查詢兼顧安全與可用性。驗(yàn)證命令systemd-resolve --statistics | grep DNSSEC。5. 實(shí)戰(zhàn)案例復(fù)盤一次跨機(jī)房DNS故障的72小時(shí)攻堅(jiān)最后分享一個(gè)完整案例它濃縮了前述所有知識(shí)點(diǎn)。這不是理論推演而是我在某金融客戶現(xiàn)場(chǎng)的真實(shí)記錄。5.1 故障初現(xiàn)告警風(fēng)暴與表象迷惑周三上午10:23監(jiān)控平臺(tái)突現(xiàn)告警所有跨機(jī)房服務(wù)調(diào)用失敗錯(cuò)誤日志清一色java.net.UnknownHostException: api.prod.internal。第一反應(yīng)是網(wǎng)絡(luò)中斷但ping各機(jī)房網(wǎng)關(guān)IP全通telnet api.prod.internal 443卻報(bào)Connection refused——等等telnet需要IP它怎么知道api.prod.internal的IP原來(lái)telnet也走getaddrinfo所以問(wèn)題在DNS不在網(wǎng)絡(luò)層。我們立刻登錄跳板機(jī)執(zhí)行dig api.prod.internal 10.10.1.1主DNS返回NOERRORIP正確但getent ahosts api.prod.internal無(wú)輸出。矛盾出現(xiàn)了dig能查getent不能查。5.2 鏈路分段七層穿透式排查按前述七層鏈路我們逐層驗(yàn)證階段一應(yīng)用層strace -e tracegetaddrinfo telnet api.prod.internal 443確認(rèn)getaddrinfo被調(diào)用階段二nsswitchcat /etc/nsswitch.conf | grep hosts顯示hosts: files dns正常階段三/etc/hostsgrep api.prod.internal /etc/hosts為空排除階段四resolv.confcat /etc/resolv.conf顯示nameserver 10.10.1.1且search prod.internal正常階段五systemd-resolvedsystemctl status systemd-resolvedactive但sudo ss -tuln | grep :53無(wú)監(jiān)聽(tīng)——resolved沒(méi)起來(lái)journalctl -u systemd-resolved | tail -20顯示Failed to bind to 127.0.0.53:53: Address already in use。查ss -tuln | grep :53發(fā)現(xiàn)dnsmasq在監(jiān)聽(tīng)0.0.0.0:53。這就是場(chǎng)景二的端口沖突5.3 根因鎖定dnsmasq的bind-interfaces失效我們以為dnsmasq配置了bind-interfaces應(yīng)只監(jiān)聽(tīng)127.0.0.1。但cat /etc/dnsmasq.conf | grep bind發(fā)現(xiàn)#bind-interfaces被注釋了原因是上周安全掃描工具自動(dòng)備份并修改了配置文件但未重啟dnsmasq所以舊進(jìn)程仍在運(yùn)行新配置未生效。kill -9舊進(jìn)程后dnsmasq按新配置啟動(dòng)釋放53端口systemd-resolved自動(dòng)監(jiān)聽(tīng)127.0.0.53getent ahosts api.prod.internal立即返回IP。5.4 深度復(fù)盤為什么故障持續(xù)72小時(shí)問(wèn)題解決了但為什么從周三上午到周五下午才定位因?yàn)閐nsmasq的bind-interfaces注釋是掃描工具所為而dnsmasq