本發(fā)明屬于網絡通信技術領域，尤其涉及一種域名解析方法及裝置。

背景技術：

域名解析系統(tǒng)(英文：Domain Name System，縮寫：DNS)是互聯(lián)網架構中的最基礎、最核心的一項服務，它的作用是實現域名和IP地址相互映射，使上網者能方便的訪問互聯(lián)網，而不用去記憶枯燥繁瑣的IP數串，為眾多網絡應用提供根本性支撐。

別名指向(英文：Canonical Name，縮寫：CNAME)是DNS里常用資源記錄類型之一，也被稱為規(guī)范名字，就是將域名解析到另外一個域名。

CNAME解析主要應用在兩方面，第一是為了方便域名的解析變更，例如，有一臺計算機名為“host”(A記錄)，A記錄是用來指定主機名(或域名)對應的IP地址記錄。用戶可以將該域名下的網站服務器指向到自己的網站服務器上。同時也可以設置域名的二級域名。它同時提供WWW和MAIL服務，為了便于用戶訪問服務。可以為該計算機設置兩個CNAME：WWW和MAIL，實際上他們都指向“host”。同樣的方法可以將多個域名指向同一服務器IP，如先將一個域名A做A記錄指向服務器IP，然后將其他的域名(如域名B、域名C等)做別名指向域名A上，那么當服務器IP地址變更時，就可以不必麻煩的一個一個域名更改指向。只需要把域名A的A記錄指向新的服務器IP，其他做過CNAME的域名也將自動更改到新的IP地址上。

CNAME記錄第二個作用是內容分發(fā)網絡(英文：Content Delivery Network，縮寫CDN)加速，例如域名www.apple.com通過層層CNAME指向，將返回的資源IP地址指向給了離訪問者最近的CDN網絡邊緣分發(fā)節(jié)點。

技術實現要素：

本發(fā)明的實施例提供一種域名解析方法及裝置。

一方面，本發(fā)明實施例提供一種域名解析方法，包括：接收來自用戶端的域名解析查詢請求；判斷是否已經存在針對域名解析查詢請求的應答信息；在尚未存在針對域名解析查詢請求的應答信息時，將域名解析查詢請求轉發(fā)給域名解析服務器；接收針對域名解析查詢請求的一個或多個域名解析應答消息，一個或多個域名解析應答消息包括域名解析查詢請求的解析地址和域名解析類型；對所述一個或多個域名解析應答消息進行解析以已建立所述域名解析查詢請求的解析地址和域名解析類型的對應關系，從而生成全量響應報文；根據過濾策略過濾應答報文以移除包含指定域名解析類型的應答信息，從而生成第一格式應答信息；將第一格式應答信息轉發(fā)給所述用戶端。

另一方面，本發(fā)明實施例提供一種域名解析裝置，包括：接收單元、判斷單元、處理單元和發(fā)送單元，該接收單元配置為接收來自用戶端的域名解析查詢請求和/或接收針對域名解析查詢請求的一個或多個域名解析應答消息，一個或多個域名解析應答消息包括域名解析查詢請求的解析地址和域名解析類型；該判斷單元被配置為判斷是否已經存在針對域名解析查詢請求的應答信息；該處理單元，被配置為在尚未存在針對域名解析查詢請求的應答信息時，將域名解析查詢請求轉發(fā)給域名解析服務器；對一個或多個域名解析應答消息進行解析以已建立域名解析查詢請求的解析地址和域名解析類型的對應關系，從而生成全量響應報文；根據過濾策略過濾應答報文以移除包含指定域名解析類型的應答信息，從而生成第一格式應答信息；發(fā)送單元，被配置為將第一格式應答信息轉發(fā)給用戶端。

還一方面，本發(fā)明實施例提供一種域名解析裝置，包括：存儲器、處理器、輸入設備、輸出設備、I/O接口和總線。該存儲器用于存儲計算機可執(zhí)行指令；該處理器用于執(zhí)行存儲器存儲的程序，該程序使得處理器執(zhí)行上述域名解析方法；總線，用于在所述處理器、存儲器、輸入設備、輸出設備和I/O接口之間傳遞信息。

本發(fā)明實施例提供的域名解析方法及裝置，通過用戶端發(fā)出的域名解析查詢請求在需要向其他域名解析服務器進行查詢時，在接收上述域名解析服務器對于上述域名解析查詢請求的應答時根據域名解析類型將域名解析類型對應的域名解析信息進行解析和拆分，并過濾掉域名解析類型為別名指向解析地址也就是CNAME的地址信息，只包含主機指向解析地址即A記錄的應答信息發(fā)送給用戶端，徹底解決CNAME導致域名轉發(fā)查詢不穩(wěn)定的問題，并可選擇性地過濾用戶響應報文中的CNAME記錄，實現域名解析裝置對于用戶查詢請求的響應報文壓縮優(yōu)化，有效降低域名解析裝置對于用戶查詢請求的響應報文對帶寬資源的消耗，提升域名解析裝置處理性能，提高域名解析裝置抗攻擊能力，且該域名解析裝置及方法簡單實用，部署成本低廉，便于推廣。

附圖說明

通過參考附圖會更加清楚地理解本發(fā)明的特征和優(yōu)點，附圖是示意性的而不應理解為對本發(fā)明進行任何限制，在附圖中：

圖1示出了經由傳統(tǒng)的域名解析裝置實現的用戶端域名解析的示例性過程；

圖2示出根據一種實施例的域名解析方法的方法流程圖；

圖3示出根據一種實施例的域名解析裝置的結構框圖；

圖4示出根據另一種實施例的域名解析裝置的結構框圖。

具體實施方式

為使本發(fā)明實施例的目的、技術方案和優(yōu)點更加清楚，下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行描述。

下面將詳細描述本發(fā)明的各個方面的特征和示例性實施例。在下面的詳細描述中，提出了許多具體細節(jié)，以便提供對本發(fā)明的全面理解。但是，對于本領域技術人員來說很明顯的是，本發(fā)明可以在不需要這些具體細節(jié)中的一些細節(jié)的情況下實施。下面對實施例的描述僅僅是為了通過示出本發(fā)明的示例來提供對本發(fā)明的更好的理解。本發(fā)明決不限于下面所提出的任何具體配置和算法，而是在不脫離本發(fā)明的精神的前提下覆蓋了元素、部件和算法的任何修改、替換和改進。在附圖和下面的描述中，沒有示出公知的結構和技術，以便避免對本發(fā)明造成不必要的模糊。

現在將參考附圖更全面地描述示例實施方式。然而，示例實施方式能夠以多種形式實施，且不應被理解為限于在此闡述的實施方式；相反，提供這些實施方式使得本發(fā)明更全面和完整，并將示例實施方式的構思全面地傳達給本領域的技術人員。在圖中，為了清晰，可能夸大了區(qū)域和層的厚度。在圖中相同的附圖標記表示相同或類似的結構，因而將省略它們的詳細描述。

此外，所描述的特征、結構或特性可以以任何合適的方式結合在一個或更多實施例中。在下面的描述中，提供許多具體細節(jié)從而給出對本發(fā)明的實施例的充分理解。然而，本領域技術人員將意識到，可以實踐本發(fā)明的技術方案而沒有所述特定細節(jié)中的一個或更多，或者可以采用其它的方法、組元、材料等。在其它情況下，不詳細示出或描述公知結構、材料或者操作以避免模糊本發(fā)明的主要技術創(chuàng)意需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互組合。

圖1示出了經由傳統(tǒng)的域名解析裝置實現的用戶端域名解析的示例性過程。如圖1所示，本地運營商域名解析系統(tǒng)Local DNS通常具備兩項最基本的功能模塊：DNS緩存查詢模塊和DNS遞歸解析模塊：DNS緩存查詢模塊，接收用戶的DNS查詢請求，如果存在緩存記錄，則直接返回用戶查詢結果；如果不存在緩存記錄，交由DNS遞歸解析模塊處理；并接收遞歸模塊返回的查詢結果，將查詢結果返回用戶，并將查詢結果記錄到緩存記錄中。由于DNS緩存查詢模塊最接近用戶，常常會整合安全功能，并執(zhí)行轉發(fā)策略，本地強制解析等定制化策略。事實上，除了用戶查詢的恰好是CNAME記錄情況，DNS緩存查詢模塊產生的DNS用戶響應報文里的多層級CNAME記錄對普通用戶并沒有實際意義，例如對發(fā)起A記錄查詢請求的用戶而言只需要獲得最后一層A記錄的IP地址即可實現業(yè)務通信。DNS遞歸解析模塊，處理DNS緩存查詢模塊發(fā)送過來的遞歸請求，執(zhí)行完遞歸查詢后將結果返回給DNS緩存查詢模塊。CNAME記錄在DNS遞歸解析模塊一般不可或缺，CNAME記錄為追蹤域名解析過程、排查域名故障提供了必要手段。

網絡運營商為了實現網站緩存加速，會把待解析域名在LOCAL DNS(后簡寫為LDNS)上轉發(fā)給web緩存服務器的DNS，由web緩存服務器的DNS解析出的本地緩存服務器IP地址返回給運營商LDNS，再由運營商LDNS返回給用戶，這是基于轉發(fā)方式實現web緩存應用的技術原理。這里的web緩存服務器是為了網站緩存提速相對于源站服務器搭建的資源鏡像服務器。應理解，這里的web緩存服務器可以與源站服務器設置在相同的網絡，也可以是分離地設置在不同的網絡中。以中國移動運營商提供的CMNET網絡為例，以上DNS均部署在CMNET網絡內，為了節(jié)省跨網資源及緩存加速，web緩存DNS會將外網源站的權威DNS資源鏡像到網內，部署在CMNET網絡內web緩存服務器會為從對外網源站的權威DNS抓取的域名解析資源中的A記錄重新分配內網地址。以www.sina.com.cn為例，源站的權威DNS中的地址為189.189.189.189，鏡像到內網后的地址為139.139.139.139。由于傳統(tǒng)的DNS裝置及方法是以域為單位進行域名遞歸解析、解析結果儲存、用戶查詢應答和域名轉發(fā)，該機制會導致當某個域名存在CNAME時，如果僅對該域名自身做轉發(fā)查詢，其轉發(fā)查詢解析結果常常不穩(wěn)定，LDNS會將除139.139.139.139外的CNAME指向的源站地址一并轉發(fā)和存儲，從而使得基于轉發(fā)查詢方式的網絡應用效果大打折扣。而在傳統(tǒng)的DNS裝置上為實現轉發(fā)查詢解析穩(wěn)定，需要將CNAME串涉及的所有CNAME一起進行轉發(fā)對用戶端域名解析查詢請求的應答，上線操作和后期維護難度大幅增加。

另外CNAME記錄使得運營商LDNS響應報文的長度變大，消耗了DNS系統(tǒng)的帶寬資源，削弱了對抗網絡攻擊的能力，例如如果能將緩存DNS產生的用戶響應報文壓縮至512字節(jié)以內，就可以關閉緩存DNS的tcp 53端口，只開放udp53端，而tcp 53端口相對薄弱，極易受到網絡攻擊。

再次以www.sina.com.cn為例，www.sina.com.cn.的權威DNS配置了CNAME指向jupiter.sina.com.cn，CNAME記錄的生存時間值(英文：Time To Live，縮寫：TTL)為3600秒。當LDNS把www.sina.com.cn待加速域名轉發(fā)給web緩存服務器的DNS后，理論上LDNS得到的解析A記錄應該是web緩存服務器IP，但事實上常常得到的卻仍然是源站的IP。

經過抓包定位發(fā)現LDNS上首次轉發(fā)策略執(zhí)行成功，LDNS會從web緩存服務器的DNS獲取到本地緩存服務器IP地址，A記錄TTL時間為適應緩存業(yè)務而定制的60秒。當60秒A紀錄的TTL逐漸遞減到0秒超時后，再次解析www.sina.com.cn，通過抓包發(fā)現DNS實際發(fā)出的域名解析請求是CNAME對應的norma.sina.com.cn，而不是待解析域名，www.sina.com.cn，原因是A記錄的TTL老化為0時，CNAME記錄TTL 3600秒還沒有老化為0仍然有效，這個原因導致了針對www.sina.com.cn域名的轉發(fā)查詢策略失效。

由以上示例可知，經由傳統(tǒng)的域名解析裝置實現的用戶端域名解析的過程中，對于通過轉發(fā)查詢方式進行網站加速的域名，為了提升網絡緩存的命中率，需要核實該域名是否存在CNAME，如果存在CNAME，不僅域名自身要進行轉發(fā)查詢，相應的CNAME也要同時進行轉發(fā)查詢，否則解析結果就會出現不穩(wěn)定的情況。但額外配置CNAME forward即地址別名轉發(fā)查詢耗時耗力，不僅增加LDNS處理的轉發(fā)查詢域名數量，還增加了后期維護和排查故障的難度。同樣網絡運營商為了實現網站緩存加速，把需要域名解析的域名在LDNS上轉發(fā)給web緩存服務器的DNS進行查詢，由web緩存服務器的DNS解析出的本地緩存服務器IP地址返回給運營商LDNS，再由運營商LDNS返回給用戶。如果需要域名解析的域名存在CNAME，那么被加速域名首次獲得的本地緩存服務器IP信息TTL超時后，待加速域名將可能不再會執(zhí)行轉發(fā)查詢策略，而以CNAME域名對應的源站解析IP做為結果，從而導致了網絡緩存的失效。

并且，經由傳統(tǒng)的域名解析裝置實現的用戶端域名解析過程中，由于CNAME記錄使得LDNS對用戶響應報文的長度變大，消耗了LDNS系統(tǒng)的帶寬資源，削弱了對抗網絡攻擊的能力。在某些情況的超大DNS報文下還會導致故障發(fā)生。例如，目前DNS的流量模型都是DNS響應報文遠大于DNS請求報文的，這會導致DNS響應方向的帶寬先出現擁塞。通常采用DNS流量放大比參數來衡量DNS響應流量/請求流量的比例關系。當使用傳統(tǒng)方法配置為標準響應模式時，LDNS流量放大比約為3.3。當使用傳統(tǒng)方法啟用最小響應模式后，此時響應報文將只返回answer字段，刪除authority和additional字段，縮減響應報文長度，DNS放大比降為2.1。因此如果能將DNS放大比降為2以內，將更大程度挖掘出DNS的帶寬應答潛力，因為帶寬一定的情況下，DNS響應報文越小，可應答的DNS查詢并發(fā)數越多，提高了DNS的應答性能。

更且，經由傳統(tǒng)的域名解析裝置實現的用戶端域名解析過程中，由于DNS報文一般使用UDP協(xié)議，單個報文字節(jié)大小限制在512字節(jié)，當DNS響應報文超過512字節(jié)，則需要客戶端重新使用TCP發(fā)送查詢請求。域名CNAME層級過多，可能導致響應報文大小超過UDP 512字節(jié)的限制。TCP相對UDP雖然可靠性高，但效率低下，所以有些LOCAL DNS基于性能的考慮，可能會關閉TCP DNS報文查詢與響應，進而會導致響應報文超過512字節(jié)的域名查詢失敗，影響終端用戶的業(yè)務使用。

考慮到結合圖1描述的上述情況，本發(fā)明提出了一種域名解析裝置、及域名解析方法。

圖2示出根據一種實施例的域名解析方法的方法流程圖。一種域名解析方法，在S210中，接收來自用戶端的域名解析查詢請求；應理解，為了減少跨網流量，該域名解析查詢請求可以理解為是在請求由圖1中的web緩存服務器在源站權威服務器抓取的資源生產的鏡像的解析地址，可以稱上述的解析地址為主站地址也可以用A記錄來進行表示。在S220中，判斷是否已經存在針對域名解析查詢請求的應答信息；在S230中，在尚未存在針對域名解析查詢請求的應答信息時，將該域名解析查詢請求轉發(fā)給域名解析服務器；應理解，這里的將該域名解析查詢請求轉發(fā)給域名解析服務器的步驟可以分為兩個方面，在一個示例中，可以向相同網絡中的域名解析服務器轉發(fā)該域名解析查詢請求進行查詢，這里的相同網絡指的是圖1中為了對域名解析進行提速而搭建作為外網資源鏡像服務器的web緩存服務器所在的網絡，可以是相同網絡運營商的通信網絡，例如中國移動運營商提供的CMNET網絡。在一個示例中，發(fā)起迭代查詢，直至從權威域名解析服務器中獲得解析地址，這里從權威域名解析服務器獲得的解析地址即為包含源站解析地址的CNAME記錄，這里的權威域名解析服務器可以與上述資源鏡像服務器部署在同一網絡，也可分別部署在不同網絡，例如不同網絡運營商的通信網絡，例如電信運營商通信網絡或聯(lián)通運營商通信網絡。在S240中，接收針對所述域名解析查詢請求的一個或多個域名解析應答消息，所述一個或多個域名解析應答消息包括所述域名解析查詢請求的解析地址和域名解析類型；在一個示例中，這里的一個或多個域名解析應答消息包括用戶端需要查詢的A記錄，也就是web緩存服務器在源站權威服務器抓取的資源生產的鏡像的解析地址，同時也包括CNAME記錄。在一個示例中，可以建立上述域名解析類型字段與域名解析查詢請求的解析地址字段的指向關系。在S250中，對所述一個或多個域名解析應答消息進行解析以已建立所述域名解析查詢請求的解析地址和域名解析類型的對應關系，從而生成全量響應報文。在S260中，根據過濾策略過濾所述應答報文以移除包含指定域名解析類型的應答信息，從而生成第一格式應答信息。也就是說可以直接對該全量響應報文執(zhí)行過濾策略而不進行存儲。由于過濾策略可以預先設置，可以設置過濾策略為過濾應答報文以移除包含別名指向域名解析類型的應答信息。例如可以通過該全量響應報文中的別名指向域名解析類型對別名指向域名解析類型對應的別名指向解析地址字段進行過濾。在一個示例中，如果建立了域名解析類型字段與域名解析查詢請求的解析地址字段的指向關系，那么可以選擇執(zhí)行過濾策略為通過所述全量響應報文中的別名指向域名解析類型對別名指向域名解析類型對應的別名指向解析地址字段進行過濾。在S270中，將所述第一格式應答信息轉發(fā)給所述用戶端。在一個示例中，該方法還可以包括對全量響應報文進行存儲。在一個示例中，該方法中在判斷為存在有包含域名解析查詢請求的應答信息時，對包含域名解析查詢請求的應答信息的全量響應報文進行過濾以移除包含的別名指向地址類型的應答信息，從而生成第一格式應答信息。在過濾策略為過濾應答報文以移除包含別名指向域名解析類型的應答信息時，第一格式應答信息可以理解為只包含A記錄的應答信息。

通過用戶端發(fā)出的域名解析查詢請求在需要向其他域名解析服務器進行查詢時，在接收上述域名解析服務器對于上述域名解析查詢請求的應答時根據域名解析類型將域名解析類型對應的域名解析信息進行解析和拆分，將拆分后的應答信息進行存儲，并過濾掉域名解析類型為別名指向解析地址也就是CNAME的地址信息，只包含主機指向解析地址即A記錄的應答信息發(fā)送給用戶端，徹底解決CNAME導致域名轉發(fā)查詢不穩(wěn)定的問題，并可選擇性地過濾用戶響應報文中的CNAME記錄，實現域名解析裝置對于用戶查詢請求的響應報文壓縮優(yōu)化，有效降低域名解析裝置對于用戶查詢請求的響應報文對帶寬資源的消耗，提升域名解析裝置處理性能，提高域名解析裝置抗攻擊能力，且該域名解析方法簡單實用，部署成本低廉，便于推廣

圖3示出根據一種實施例的域名解析裝置的結構框圖。如圖3所示，該域名解析裝置，包括：接收單元310、判斷單元320、處理單元330和發(fā)送單元340，該接收單元310配置為接收來自用戶端的域名解析查詢請求和/或接收針對域名解析查詢請求的一個或多個域名解析應答消息，一個或多個域名解析應答消息包括域名解析查詢請求的解析地址和域名解析類型；該判斷單元320被配置為判斷是否已經存在針對域名解析查詢請求的應答信息；該處理單元330被配置為在尚未存在針對域名解析查詢請求的應答信息時，將域名解析查詢請求轉發(fā)給域名解析服務器；對一個或多個域名解析應答消息進行解析以已建立所述域名解析查詢請求的解析地址和域名解析類型的對應關系，從而生成全量響應報文；根據過濾策略過濾應答報文以移除包含指定域名解析類型的應答信息，從而生成第一格式應答信息；該發(fā)送單元340被配置為將第一格式應答信息轉發(fā)給用戶端。需要說明的是，該裝置與該方法相對應，二者具有類似的功能，可以解決類似的技術問題，因此，二者相同或者相似的地方不再贅述。

在一個實施例中，該裝置中，過濾策略包括過濾應答報文以移除包含別名指向域名解析類型的應答信息。在一個示例中，該過濾策略還包括通過全量響應報文中的別名指向域名解析類型對別名指向域名解析類型對應的別名指向解析地址字段進行過濾。

在一個實施例中，該裝置還可以包括存儲單元，被配置為對全量響應報文進行存儲。

在一個實施例中，該裝置的處理單元330還可以被在存在有包含域名解析查詢請求的應答信息時，對包含域名解析查詢請求的應答信息的全量響應報文進行過濾以移除包含的別名指向地址類型的應答信息，從而生成第一格式應答信息。

在一個實施例中，該裝置的處理單元330還可以被配置為對第一格式應答信息進行過濾，以移除應答信息中多余的主機名指域名解析類型的應答信息，使應答信息中至少包含一條主機名指向信息。在一個示例中，該裝置的處理單元330還可以被配置為向相同網絡中的域名解析服務器轉發(fā)域名解析查詢請求進行查詢。在一個示例中，該裝置的處理單元330還可以包括遞歸查詢模塊，被配置為發(fā)起迭代查詢，直至從權威域名解析服務器中獲得解析地址。在一個示例中，該裝置的處理單元330還可以被配置為建立域名解析類型字段與域名解析查詢請求的解析地址字段的指向關系。

結合圖2和圖3描述的域名解析方法和域名解析裝置的至少一部分可以由計算設備實現。圖4示出根據另一種實施例的域名解析裝置的結構框圖。如圖4所示，計算設備400包括輸入設備401、輸入端口402、處理器403、存儲器404、輸出端口405、以及輸出設備406。其中，輸入端口402、處理器403、存儲器404、以及輸出端口405通過總線410相互連接，輸入設備401和輸出設備406分別通過輸入端口402和輸出端口405與總線410連接，進而與計算設備400的其他組件連接。需要說明的是，這里的輸出接口和輸入接口也可以用I/O接口表示。具體地，輸入設備401接收來自外部的輸入信息，并通過輸入端口402將輸入信息傳送到處理器403；處理器403基于存儲器404中存儲的計算機可執(zhí)行指令對輸入信息進行處理以生成輸出信息，將輸出信息臨時或者永久地存儲在存儲器404中，然后通過輸出端口405將輸出信息傳送到輸出設備406；輸出設備406將輸出信息輸出到計算設備400的外部。

上述存儲器404包括用于數據或指令的大容量存儲器。舉例來說而非限制，存儲器404可包括HDD、軟盤驅動器、閃存、光盤、磁光盤、磁帶或通用串行總線(USB)驅動器或者兩個或更多個以上這些的組合。在合適的情況下，存儲器404可包括可移除或不可移除(或固定)的介質。在合適的情況下，存儲器404可在計算設備400的內部或外部。在特定實施例中，存儲器404是非易失性固態(tài)存儲器。在特定實施例中，存儲器404包括只讀存儲器(ROM)。在合適的情況下，該ROM可以是掩模編程的ROM、可編程ROM(PROM)、可擦除PROM(EPROM)、電可擦除PROM(EEPROM)、電可改寫ROM(EAROM)或閃存或者兩個或更多個以上這些的組合。

總線410包括硬件、軟件或兩者，將計算設備400的部件彼此耦接在一起。舉例來說而非限制，總線410可包括加速圖形端口(AGP)或其他圖形總線、增強工業(yè)標準架構(EISA)總線、前端總線(FSB)、超傳輸(HT)互連、工業(yè)標準架構(ISA)總線、無限帶寬互連、低引腳數(LPC)總線、存儲器總線、微信道架構(MCA)總線、外圍組件互連(PCI)總線、PCI-Express(PCI-X)總線、串行高級技術附件(SATA)總線、視頻電子標準協(xié)會局部(VLB)總線或其他合適的總線或者兩個或更多個以上這些的組合。在合適的情況下，總線410可包括一個或多個總線410。盡管本發(fā)明實施例描述和示出了特定的總線，但本發(fā)明考慮任何合適的總線或互連。

當通過圖4所示的計算設備400實現結合圖2和圖3描述的域名解析裝置時，輸入設備401接收來自用戶端的域名解析查詢請求和/或接收針對域名解析查詢請求的一個或多個域名解析應答消息，在特定實施例中，與輸出設備相連的I/O接口可以包括硬件、軟件或兩者，提供用于在計算設備400與一個或多個I/O設備之間的通信的一個或多個接口。在合適的情況下，計算設備400可包括一個或多個這些I/O設備。一個或多個這些I/O設備可允許人和計算機系統(tǒng)400之間的通信。舉例來說而非限制，I/O設備可包括鍵盤、小鍵盤、麥克風、監(jiān)視器、鼠標、打印機、掃描儀、揚聲器、靜態(tài)照相機、觸針、手寫板、觸摸屏、軌跡球、視頻攝像機、另一合適的I/O設備或者兩個或更多個以上這些的組合。I/O設備可包括一個或多個傳感器。本發(fā)明實施例考慮用于它們的任何合適的I/O設備和任何合適的I/O接口。在合適的情況下，I/O接口可包括一個或多個裝置或能夠允許處理器703驅動一個或多個這些I/O設備的軟件驅動器。在合適的情況下，I/O接口可包括一個或多個I/O接口。盡管本發(fā)明實施例描述和示出了特定的I/O接口，但本發(fā)明實施例考慮任何合適的I/O接口。該處理器403基于存儲器404中存儲的計算機可執(zhí)行指令，在尚未存在針對域名解析查詢請求的應答信息時，將域名解析查詢請求轉發(fā)給域名解析服務器；對一個或多個域名解析應答消息進行解析以已建立域名解析查詢請求的解析地址和域名解析類型的對應關系，從而生成全量響應報文；根據過濾策略過濾應答報文以移除包含指定域名解析類型的應答信息，從而生成第一格式應答信息。隨后在需要經由輸出端口405和輸出設備406將域名解析結果發(fā)送給用戶端。

也就是說，根據本發(fā)明實施例的域名解析裝置也可以被實現為包括存儲有計算機可執(zhí)行指令的存儲器404；以及處理器403，該處理器403在執(zhí)行計算機可執(zhí)行指令時，可以實現結合圖2和圖3描述的域名解析方法和域名解析裝置。

在合適的情況下，計算機可執(zhí)行指令可包括一個或多個基于半導體的或其他集成電路(IC)(例如，諸如現場可編程門陣列(FPGA)或專用IC(ASIC))、硬盤驅動器(HDD)、混合硬盤驅動器(HHD)、光盤、光盤驅動器(ODD)、磁光盤、磁光盤驅動器、軟盤、軟盤驅動器(FDD)、磁帶、全息存儲介質、固態(tài)驅動器(SSD)、RAM驅動器、安全數字卡或驅動或其他合適的計算機可讀非臨時性存儲介質或者兩個或更多個以上這些的組合。

需要明確，本發(fā)明并不局限于上文所描述并在圖中示出的特定配置和處理。并且，為了簡明起見，這里省略對已知方法技術的詳細描述。在上述實施例中，描述和示出了若干具體的步驟作為示例。但是，本發(fā)明的方法過程并不限于所描述和示出的具體步驟，本領域的技術人員可以在領會本發(fā)明的精神后作出各種改變、修改和添加，或者改變步驟之間的順序。

本領域普通技術人員可以意識到，結合本文中所公開的實施例描述的各示例的單元及算法步驟，能夠以電子硬件、計算機軟件或者二者的結合來實現，為了清楚地說明硬件和軟件的可互換性，在上述說明中已經按照功能一般性地描述了各示例的組成及步驟。這些功能究竟以硬件還是軟件方式來執(zhí)行，取決于技術方案的特定應用和設計約束條件。專業(yè)技術人員可以對每個特定的應用來使用不同方法來實現所描述的功能，但是這種實現不應認為超出本發(fā)明的范圍。

所屬領域的技術人員可以清楚地了解到，為了描述的方便和簡潔，上述描述的系統(tǒng)、裝置和單元的具體工作過程，可以參考前述方法實施例中的對應過程，在此不再贅述。

在本申請所提供的幾個實施例中，應該理解到，所揭露的系統(tǒng)、裝置和方法，可以通過其它的方式實現。例如，以上所描述的裝置實施例僅僅是示意性的，例如，所述單元的劃分，僅僅為一種邏輯功能劃分，實際實現時可以有另外的劃分方式，例如多個單元或組件可以結合或者可以集成到另一個系統(tǒng)，或一些特征可以忽略，或不執(zhí)行。另外，所顯示或討論的相互之間的耦合或直接耦合或通信連接可以是通過一些端口、裝置或單元的間接耦合或通信連接，也可以是電的，機械的或其它的形式連接。

所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網絡單元上。可以根據實際的需要選擇其中的部分或者全部單元來實現本發(fā)明實施例方案的目的。

另外，在本發(fā)明各個實施例中的各功能單元可以集成在一個處理單元中，也可以是各個單元單獨物理存在，也可以是兩個或兩個以上單元集成在一個單元中。上述集成的單元既可以采用硬件的形式實現，也可以采用軟件功能單元的形式實現。

以上所述，僅為本發(fā)明的具體實施方式，但本發(fā)明的保護范圍并不局限于此，任何熟悉本技術領域的技術人員在本發(fā)明揭露的技術范圍內，可輕易想到各種等效的修改或替換，這些修改或替換都應涵蓋在本發(fā)明的保護范圍之內。因此，本發(fā)明的保護范圍應以權利要求的保護范圍為準。