app store 稽核 IPv6-Olny

背景

從今年六月起IOS平臺應用程式上線app store需要其支援IPV6-only網路的訪問。這無疑給IOS開發人員和應用程式伺服器後臺的支援維護工作設了一道巨大的關卡，之前就一直傳來業內的小夥伴頻頻被拒的訊息，雖然網上的各種解決方案層出不窮，直接原因總結起來就是APP客戶端在美國的IPv6-Only網路環境下不能正確訪問後臺的app server。說起來僅僅是很小的一個訪問測試，但是這個隱藏的系統內部的經絡是十分錯綜複雜，要保障各個環節任何步驟不出問題更是難上加難。前日某銀行應用程式伺服器DNS解析失常，直接導致其後臺伺服器在internet上”失聯”，某公司在DNS GSLB解析時不穩定，經排查存在timeout現象，導致app sever解析不正常…….app server處在如此不穩定的網路中，再加上國際間網路路由複雜，保障客戶端正確請求app server 這一條件比app store在程式碼層面上的稽核要求顯得更加苛刻，這也成了一個主要的難題。

由於IPv6和IPv4的不相容性，IPv6網路在我國的發展過程呈現的特點就是客戶接入端響應很高，各大高校，政府紛紛試點部署，但是在內容上業務端的部署開展卻是屢屢受挫，就連國內偌大的阿里雲都不支援IPv6，為了響應現在IPv6的客戶端去訪問ipv4的伺服器這一需求，且原先的NAT-PT在實際網路應用中面臨各種缺陷，NAT64+DNS64的技術在這種情況下便應育而生，所以在app store稽核才會新增此項。而DNS64+NAT64轉換的環境也是官方給出的測試環境。

DNS64+NAT64

現實中我們用的DNS64和NAT64：

app store測試環境

在apple官網上給了一種測試環境是用MAC配置DNS64和NAT64環境，如下：

DNS64+NAT64技術原理

讓我們來看一個完整的IPv6-Only客戶端與IPv4-Only app server通訊的過程。

• 基於DNS64域名解析：客戶端向指定的本地DNS伺服器發起example.apple.com的AAAA解析請求，本地DNS伺服器（帶有DNS64功能）收到此請求後會幫其遞迴，從根域開始查詢，一直找到apple.com這個域的授權域名伺服器(如在com域名伺服器查詢到的apple域權威域名伺服器為ns.apple.com和其A或AAAA記錄)，並開始向其解析example.apple.com的主機記錄。本地DNS伺服器會先發一條AAAA記錄的request請求，此時如果ns.apple.com在記錄檔案或資料庫有example.apple.com且為AAAA記錄，則直接回復給本地DNS伺服器，本地DNS伺服器直接將解析到的AAAA記錄回覆給客戶端，根據這條AAAA記錄客戶端直接通過IPv6網路向app server後臺發起連線請求，若ns.apple.com的記錄檔案或資料庫中example.apple.com的解析記錄為A記錄，則會回覆empty，代表沒有IPv6記錄，在本地DNS收到其回覆後依據DNS64模組向ns.example.com發起一條A記錄請求，ns.example.com返回解析檔案或資料庫中的A記錄給DNS64伺服器，之後DNS64會將這條A記錄合併為一條AAAA記錄返回給IPv6-Only的客戶端。這樣就保證了對客戶端透明，即無論收到的遞迴解析回覆的主機記錄型別是A或是AAAA，返回客戶端的都是IPv6-Only 客戶端可以直接請求的AAAA記錄。流程如圖：

問題是DNS64如何對A記錄進行合併成為AAAA記錄呢？其中常用的一種方法為：DNS64將NAT64路由器的前128bits的IPV6字首前96位提取出來再將解析到的32位A記錄地址放入IPv6地址的後32位，即合成了一個IPv6的AAAA記錄。如：解析到的A記錄為8.8.8.8，NAT64的IPv6字首為64ff:ff9b::/96，則DNS64返回客戶端的AAAA記錄為64ff:ff9b::8.8.8.8。（詳見RFC6052）

• 基於NAT64轉法：客戶端在解析到主機記錄後會發起連線資料包，資料包根據IPv6網路路由到NAT64的IPV6介面，當有狀態的NAT64裝置收到資料包，會使用一個未使用的埠與其源地址進行對映，如將源IP和源埠 2001:c68:101:1::111 ,150轉換為其ipv4介面地址8.8.7.8,2000 ，再根據SIIT演算法將IPv6的報頭轉換為IPv4的報頭，將目的地址的字首去掉，還原為app server的ipv4地址並保持埠不變，將之前的對映後的源地址和源埠填入新的報頭中。重新封裝完成之後，即可將就該後的資料包通過IPv4網路路由到app server。在app server回包的時候根據轉換後的請求資料包的源IP路由到NAT64的IPv4網路介面，NAT64裝置根據對映表對其進行還原。最後通過IPv6網路將IPV6資料包路由回客戶端。

需要注意的是：在真實的使用環境中，客戶端通過非DNS查詢獲取得到的IPv6記錄，在NAT64上v6到v4的轉換任然會進行，DNS64和NAT64是分離的，並且IPV6資料包和IPV4資料包轉換除了地址需要轉換之外，資料包的格式也需要進行轉換，這個過程按照SIIT(RFC2765)無狀態IP/ICMP翻譯演算法進行。
除此之外，和NAT一樣，任何對IP報頭進行加密的協議都不能與NAT64進行相容，如AH或是ESP的傳輸模式的時候，不能進行端到端的IPSEC驗證。

如何保障可用性

滿足測試環境中IPv6-only客戶端順利訪問IPv4-only的應用伺服器，在應用可用性上應該至少保證滿足兩點

• 客戶端通過DNS64正確解析到app server的AAAA記錄地址
• 通過NAT64將客戶端的請求資料包正確並快速路由到app server上

最近遇到的case

事件描述

某銀行的應用程式稽核持續被拒。經過測試我們發現在app store所屬權威DNS server上沒有其IPV6的AAAA記錄。但是IPV4的A記錄解析正常，在本地設定Local DNS為一臺網上公開的DNS64的server，其IPV6地址為2001:778:0:ffff:64:0:de1c:9b19 (有能力的讀者可自行設定測試，需要IPV6網路能到此DNS64 server)。經過nslookup除錯並抓包發現回覆其DNS 標準查詢的response報文中的reply code為server failure，表示IPV6解析地址失常，具體原因見後面的分析。

情景模擬

一臺阿里雲伺服器模擬應用程式伺服器，一臺citrix NetScaler做DNS解析，公司域名模擬客戶在萬網託管的域名。
dylan.phdata.cn.為後臺app server FQDN，dylantestns.phdata.cn.為負載均衡裝置的FQDN

原先客戶域名在萬網的設定：

在citrix上設定DNS解析：（A記錄）

在客戶端nslookup抓包：
set q=A後請求dylan.phdata.cn :

Set q=AAAA 後再請求dylan.phdata.cn:

如上dylan.phdata.cn的A記錄解析正常，回覆的reply code為no error，但是dylan.phdata.cn的AAAA記錄解析失敗，回覆的reply code為server failure，表示查詢失敗。

故障原因

首先萬網上設定dylan這個子域的NS為父域內的主機設定的方法是不合常理的（由於父域phdata.cn解析權已交由萬網）按照DNS查詢流程，穩定的子域的授權域名伺服器應該保證由子域內的某臺name server解析。且完整的子域授權應當保證父域內有子域的ns記錄和對應的主機記錄，子域內的權威域名伺服器上應當配置完整的DNS相關配置。
回覆reply code為server failure(等同於dig響應中的status：SERVFAIL)，其代表的是LDNS無法和正在查詢的權威name server進行通訊，可能由於網路層路由不可達，還有可能就是name server不能回覆請求報文，如權威域名伺服器故障不可用或直接將LDNS的查詢drop掉。當LDNS直接請求IPv6的AAAA記錄，若被請求的name server不回覆其request報文，則LDNS認為其無法與授權域名伺服器進行通訊，便不會再對主機的A記錄再次進行請求。為了讓LDNS的DNS64模組可以在查詢IPv6 AAAA記錄得知其為空後，發出IPv4的A記錄請求，需要保證LDNS查詢AAAA記錄結果狀態為no error。但是若LDNS在AAAA記錄查詢沒有收到no error回覆，則LDNS（DNS64模組）便不會繼續查詢A記錄。

解決方案（GSLB+CNAME子域模式）

為了達到上述需求並規避server failed查詢狀態，我們可以設定CNAME子域的方式實現。設定CNAME的好處是權威域名伺服器總會將這個CNAME記錄返回給LDNS讓其對CNAME的記錄值進行重新解析，即LDNS在AAAA記錄查詢收到no error。
同時為了防止地理位置的阻礙，保障和加速client對app server的記錄查詢和業務訪問。專業的智慧DNS解析應用交付裝置F5 GTM，citrix NetScaler等，其可以根據最精準的GSLB排程演算法，（通過對DNS64的位置和跳數進行RTT測量，根據採集到的RTT值，GSLB Controller會選擇RTT值最小的站點的VIP返回給LDNS）加速app client的DNS64解析和NAT64訪問。
如我們利用NetScaler做GSLB並採用子域CNAME的方式：

• 萬網配置：

以上的配置相當於構建了一個子域nslb，其子域中的主機：ns.nslb.phdata.cn即負載均衡裝置負責子域名的解析，對於的A記錄就是其對外介面地址。再將業務主機CNAME到子域下的某臺主機名，當客戶端的LDNS解析到CNAME記錄時會以CNAME記錄值去重新發起查詢，只要在負載均衡上面完成穩定的子域配置和業務主機的CNAME後的記錄即可。
如，在citrix上配置：

• 先後配置GSLB 解析的site和services，virtual server:

• site配置：
  

• services配置：
  

• virtual server配置：
  

• SOA記錄：

• NS記錄：

用IPV6的客戶端驗證（nslookup並抓set query=AAAA的記錄報文）：

使用IPV6的客戶端去訪問阿里雲上的IPV4的httpd伺服器，訪問正常。

注意，往往出現的錯誤reply code就是server failure(等同於dig響應中的status：SERVFAIL)。其代表的是LDNS無法和正在查詢的權威name server進行通訊，可能由於網路層路由不可達，還有可能就是name server不能回覆請求報文，如權威域名伺服器故障不可用，甚至不知道自己就是權威域名伺服器。在這種情況下，可以使用dig +trace 選項來對域名解析進行除錯，觀察其輸出資訊，來幫助我們來排錯。在此處如果缺少SOA和NS記錄，負載均衡器就不知道自身就是授權的name server，便就不會回應自身沒有的AAAA記錄了。

正常的情況

由圖可見，LDNS即前面給出的公開DNS64地址。由DNS64原理可驗證，通過DNS64合併得出的IPV6地址的後32位即ipv4-only網路的後臺app server地址，如3ad3.xxxx的十六進位制進行十進位制轉換後即為58.211.x.x
當IPV6-only客戶端去解析app server時，便可根據此AAAA記錄路由到NAT的IPV6介面，再通過後32位的DIP路由到app server所在的內網入口，資料包的傳送的過程便是如此，同理，回包時到達NAT64裝置命中其轉換會話表項即可。