引言:單位用戶反饋某網站打開時顯示不完整,與用戶溝通了解情況后了解到這是一個電子資源一站式檢索平臺,因為加載不完整,導致搜索框、CSS樣式表、圖片等都無法顯示。筆者使用域名轉發功能解決的用戶的故障。
域名解析服務是每一張網絡的重要基石,然而伴隨著互聯網發展,網絡的互聯互通遠比我們了解的要更為復雜。
近日收到用戶反饋,描述某網站打開時顯示不完整,與用戶溝通了解情況后,確認待訪問的網站url形如http://web.b.ebscohost.com/start?key=10.6_8_586&site=ehost&IsAdminMobile=N&return=y,是一個電子資源一站式檢索平臺,因為加載不完整,導致搜索框、CSS樣式表、圖片等都無法顯示,極大地影響了用戶使用,希望盡快解決。
按照一般問題處理步驟,首先在自己的電腦上測試訪問打開正常,詢問其他同事訪問的情況,有的能打開,有的打開顯示不完整。接著使用nslookup檢查該域名的解析,測試本地DNS可以解析到IPv4和IPv6雙棧IP,阿里云DNS解析的IPv4結果和本地解析一致。既然能夠解析,并且也能加載部分頁面,說明解析無誤且目標可達,不能訪問的原因會是雙棧么?
在自己的電腦上取消IPv6的協議支持,無法完整顯示的情況立即出現,可是驗證了這一點并不能解決用戶的問題,畢竟用戶主要以IPv4訪問,會是多出口選路的問題么?在邊界網絡上查詢解析的IP,該IP未在運營商地址庫中,因此默認路由有三條,每次請求時由設備自動選擇一條出口,假設訪問過程產生多個會話,則每個會話可能走不同出口導致訪問異常,因此調整目的IP純走一條出口,通常就能解決問題。
然而,將目的IP分別設置成純走任一條運營商出口,依然是無法完整顯示網站,說明并未找到真正原因。仔細回憶一遍各個細節,目標網站IP可解析,頁面可顯示部分,問題實質在不可顯示的那一部分,首要問題應該是找出無法訪問的目標。
在瀏覽器中按F12打開Web開發者工具,選擇網絡標簽,刷新目標域名訪問,觀察到除了目標域名,還有if.ebsco-content.com這樣一個域名提供stylesheet、img、js等頁面元素,同時所有該域名的訪問都是超時的。憑經驗感覺,這才是真正的原因所在。
在本地DNS上解析該域名,無法解析。用aliyun等公共DNS解析,都能解析到,因此,這就能解釋同樣在IPv4網絡中,為什么有的同事能打開,有的不能打開的疑問。能打開的同事則是設置了互聯網上公共DNS。臨時解決該問題可以建議用戶設置互聯網公共DNS,但是這會影響園區網內業務系統的解析,只有讓本地DNS能解析該域名才是長效解決辦法。
本 地DNS搭 建 在rhel5+bind9環境,承載園區網權威域名解析和園區網內用戶的遞歸解析服務,對所有非權威解析請求,通過標準的迭代解析從根域開始做逐層迭代解析,該機制確保了DNS服務與用戶請求在通過園區網邊界三條出口智能選路時能保持一致,一般極少出現無法解析現象。針對此問題,先分析迭代解析的過程,使用 命 令”dig @localdnsip+trace if.ebsco-content.com”跟蹤獲得如下信息:


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


可見,迭代解析過程中本地DNS對sigmacdn的權威域名服務器都無法解析,從而導致解析失敗。面對一個陌生的cdn服務,通過互聯網公共DNS服務確定其權威域名服務器IP不難,確定后將其調整到更快的運營商出口也并不復雜,但是cdn服務可能不定期調整和優化造成解析的IP變化,這會導致本地DNS解析再次失效,DNS管理則面臨被動,因此,若能對這類少數無法解析的域名交給互聯網上公共DNS來解析就能一勞永逸。
所幸在BIND 9.1開始具有了轉發區(forward zone)這一特性,該特性允許查找指定域名時才使用轉發進行解析,對指定域名之外的解析仍遵循原有的迭代。編輯bind配置文件添加轉發域ebsco-content.com


原本以為問題處理到這里就結束了,然而通過nslookup測試本地DNS卻依然無法解析,更換轉發的DNS也沒有任何效果。難道是轉發域名配置錯誤?轉發域名功能無效?功能開關未開啟?
為了不耽誤用戶使用,臨時采取措施,將if.ebscocontent.com配置為一個權威解析,由本地DNS直接解析其IP,這相當于“欺騙”了來自用戶的DNS請求,讓客戶端以為本地DNS就是ebsco-content.com的權威解析服務,從而不再去互聯網中進行逐層迭代解析,問題的解決減少用戶的抱怨和等待。
暫時穩住了用戶,重新回顧dig迭代的過程,CNAME這個細節引起了注意,迭代解析的過程已經把原域名正常解析到別名了,前一個解析過程其實已經結束了。下一個解析過程是對別名的解析,也需要做一次迭代查詢。當前問題的本質應該是該別名無法迭代解析導致的訪問失敗,假設轉發解析不設置為ebsco-content.com,而是設置wac.sigmacdn.net這個cdn服務的域名呢?答案很快有了分曉,轉發解析成功了,通過nslookup查詢if.ebsco-content.com已經能夠解析到IP。
將非權威域名配置成本地權威解析來影響目標訪問的選路和可達性是一個簡便易行的手段,最大的缺點在于外部目標解析發生改變是隨時發生的,如果待解析的域名數量少且名稱固定,采用腳本的方法來自動維護解析的變更也是可行的,但當待解析的域名數量多,或通過cdn服務優化后存在域名名稱經常變化,則難以用這一辦法解決。針對指定域名進行轉發解析則能夠最大滿足在既有環境中解析的靈活性,同時與原環境中涉及的多出口負載均衡、內部訪問策略、由外到內的智能解析都不會產生影響和干擾。