引言：單位用戶反饋某網(wǎng)站打開時顯示不完整，與用戶溝通了解情況后了解到這是一個電子資源一站式檢索平臺，因為加載不完整，導(dǎo)致搜索框、CSS樣式表、圖片等都無法顯示。筆者使用域名轉(zhuǎn)發(fā)功能解決的用戶的故障。

域名解析服務(wù)是每一張網(wǎng)絡(luò)的重要基石，然而伴隨著互聯(lián)網(wǎng)發(fā)展，網(wǎng)絡(luò)的互聯(lián)互通遠(yuǎn)比我們了解的要更為復(fù)雜。

故障現(xiàn)象

近日收到用戶反饋，描述某網(wǎng)站打開時顯示不完整，與用戶溝通了解情況后，確認(rèn)待訪問的網(wǎng)站url形如http://web.b.ebscohost.com/start?key=10.6_8_586&site=ehost&IsAdminMobile=N&return=y，是一個電子資源一站式檢索平臺，因為加載不完整，導(dǎo)致搜索框、CSS樣式表、圖片等都無法顯示，極大地影響了用戶使用，希望盡快解決。

常規(guī)“治療”并不對癥

按照一般問題處理步驟，首先在自己的電腦上測試訪問打開正常，詢問其他同事訪問的情況，有的能打開，有的打開顯示不完整。接著使用nslookup檢查該域名的解析，測試本地DNS可以解析到IPv4和IPv6雙棧IP，阿里云DNS解析的IPv4結(jié)果和本地解析一致。既然能夠解析，并且也能加載部分頁面，說明解析無誤且目標(biāo)可達(dá)，不能訪問的原因會是雙棧么？

在自己的電腦上取消IPv6的協(xié)議支持，無法完整顯示的情況立即出現(xiàn)，可是驗證了這一點并不能解決用戶的問題，畢竟用戶主要以IPv4訪問，會是多出口選路的問題么？在邊界網(wǎng)絡(luò)上查詢解析的IP，該IP未在運營商地址庫中，因此默認(rèn)路由有三條，每次請求時由設(shè)備自動選擇一條出口，假設(shè)訪問過程產(chǎn)生多個會話，則每個會話可能走不同出口導(dǎo)致訪問異常，因此調(diào)整目的IP純走一條出口，通常就能解決問題。

然而，將目的IP分別設(shè)置成純走任一條運營商出口，依然是無法完整顯示網(wǎng)站，說明并未找到真正原因。仔細(xì)回憶一遍各個細(xì)節(jié)，目標(biāo)網(wǎng)站IP可解析，頁面可顯示部分，問題實質(zhì)在不可顯示的那一部分，首要問題應(yīng)該是找出無法訪問的目標(biāo)。

對癥治療

在瀏覽器中按F12打開Web開發(fā)者工具，選擇網(wǎng)絡(luò)標(biāo)簽，刷新目標(biāo)域名訪問，觀察到除了目標(biāo)域名，還有if.ebsco-content.com這樣一個域名提供stylesheet、img、js等頁面元素，同時所有該域名的訪問都是超時的。憑經(jīng)驗感覺，這才是真正的原因所在。

在本地DNS上解析該域名，無法解析。用aliyun等公共DNS解析，都能解析到，因此，這就能解釋同樣在IPv4網(wǎng)絡(luò)中，為什么有的同事能打開，有的不能打開的疑問。能打開的同事則是設(shè)置了互聯(lián)網(wǎng)上公共DNS。臨時解決該問題可以建議用戶設(shè)置互聯(lián)網(wǎng)公共DNS，但是這會影響園區(qū)網(wǎng)內(nèi)業(yè)務(wù)系統(tǒng)的解析，只有讓本地DNS能解析該域名才是長效解決辦法。

本 地DNS搭 建 在rhel5+bind9環(huán)境，承載園區(qū)網(wǎng)權(quán)威域名解析和園區(qū)網(wǎng)內(nèi)用戶的遞歸解析服務(wù)，對所有非權(quán)威解析請求，通過標(biāo)準(zhǔn)的迭代解析從根域開始做逐層迭代解析，該機制確保了DNS服務(wù)與用戶請求在通過園區(qū)網(wǎng)邊界三條出口智能選路時能保持一致，一般極少出現(xiàn)無法解析現(xiàn)象。針對此問題，先分析迭代解析的過程，使用 命 令”dig @localdnsip+trace if.ebsco-content.com”跟蹤獲得如下信息：

可見，目標(biāo)if.ebscocontent.com域名其實已經(jīng)解析成功，只是被解析到了另一個cs751.wac.sigmacdn.net域名，從名字上猜想這個別名是一個cdn服務(wù)，本地DNS因無法解析該別名而不能打開相關(guān)網(wǎng)頁對象。繼續(xù)用命令“dig @localdnsip +trace cs751.wac.sigmacdn.net”跟蹤獲得如下信息：

可見，迭代解析過程中本地DNS對sigmacdn的權(quán)威域名服務(wù)器都無法解析，從而導(dǎo)致解析失敗。面對一個陌生的cdn服務(wù)，通過互聯(lián)網(wǎng)公共DNS服務(wù)確定其權(quán)威域名服務(wù)器IP不難，確定后將其調(diào)整到更快的運營商出口也并不復(fù)雜，但是cdn服務(wù)可能不定期調(diào)整和優(yōu)化造成解析的IP變化，這會導(dǎo)致本地DNS解析再次失效，DNS管理則面臨被動，因此，若能對這類少數(shù)無法解析的域名交給互聯(lián)網(wǎng)上公共DNS來解析就能一勞永逸。

所幸在BIND 9.1開始具有了轉(zhuǎn)發(fā)區(qū)（forward zone）這一特性，該特性允許查找指定域名時才使用轉(zhuǎn)發(fā)進(jìn)行解析，對指定域名之外的解析仍遵循原有的迭代。編輯bind配置文件添加轉(zhuǎn)發(fā)域ebsco-content.com

原本以為問題處理到這里就結(jié)束了，然而通過nslookup測試本地DNS卻依然無法解析，更換轉(zhuǎn)發(fā)的DNS也沒有任何效果。難道是轉(zhuǎn)發(fā)域名配置錯誤？轉(zhuǎn)發(fā)域名功能無效？功能開關(guān)未開啟？

為了不耽誤用戶使用，臨時采取措施，將if.ebscocontent.com配置為一個權(quán)威解析，由本地DNS直接解析其IP，這相當(dāng)于“欺騙”了來自用戶的DNS請求，讓客戶端以為本地DNS就是ebsco-content.com的權(quán)威解析服務(wù)，從而不再去互聯(lián)網(wǎng)中進(jìn)行逐層迭代解析，問題的解決減少用戶的抱怨和等待。

暫時穩(wěn)住了用戶，重新回顧dig迭代的過程，CNAME這個細(xì)節(jié)引起了注意，迭代解析的過程已經(jīng)把原域名正常解析到別名了，前一個解析過程其實已經(jīng)結(jié)束了。下一個解析過程是對別名的解析，也需要做一次迭代查詢。當(dāng)前問題的本質(zhì)應(yīng)該是該別名無法迭代解析導(dǎo)致的訪問失敗，假設(shè)轉(zhuǎn)發(fā)解析不設(shè)置為ebsco-content.com，而是設(shè)置wac.sigmacdn.net這個cdn服務(wù)的域名呢？答案很快有了分曉，轉(zhuǎn)發(fā)解析成功了，通過nslookup查詢if.ebsco-content.com已經(jīng)能夠解析到IP。

經(jīng)驗總結(jié)

將非權(quán)威域名配置成本地權(quán)威解析來影響目標(biāo)訪問的選路和可達(dá)性是一個簡便易行的手段，最大的缺點在于外部目標(biāo)解析發(fā)生改變是隨時發(fā)生的，如果待解析的域名數(shù)量少且名稱固定，采用腳本的方法來自動維護(hù)解析的變更也是可行的，但當(dāng)待解析的域名數(shù)量多，或通過cdn服務(wù)優(yōu)化后存在域名名稱經(jīng)常變化，則難以用這一辦法解決。針對指定域名進(jìn)行轉(zhuǎn)發(fā)解析則能夠最大滿足在既有環(huán)境中解析的靈活性，同時與原環(huán)境中涉及的多出口負(fù)載均衡、內(nèi)部訪問策略、由外到內(nèi)的智能解析都不會產(chǎn)生影響和干擾。