IPv6 and App Review。app上线IPV6审核不通过

六月以后陆续有一些软件提交市场的时候被拒了，症状基本就是无法登陆啥的。我们公司的应用也未能幸免。

很多同学也想了不少办法，申诉、拍视频啥的都有，有人成功有人失败。但是如果苹果不能再自己的测试环境下测试成功，基本就还是要被拒的。

先分析一下情况，很多开发者抱怨自己按照苹果给出的方法，在自己电脑上搭了 IPv6 的环境测试了，没有问题，为啥一提交审核就不行了呢？这里就要看一下本机搭的这个 IPv6 环境到底是怎么回事，它到底能验证什么。

苹果提供的方法是帮我们创建一个 NAT64 的网络，这里先要搞清楚啥是 NAT64. 

Mac 创建的 IPv6 网络

所以，手机和 Mac 之间是 IPv6 没错，但 Mac 和你的服务器之间还是 IPv4 连接。如果这项测试通过，可以说明：你的客户端应用在 IPv6 网络下，是(基本)没有问题的，但是无法验证你的服务器能够对 IPv6 网络做出正确的响应。

然而，苹果审核的时候，却是要去 DNS 服务器询问你的服务器的 IPv6 地址，然后进行访问。如果查询不到 IPv6 地址，可能会进而询问 IPv4 地址，然后进行转换使用。苹果明确表示服务器不需要支持 IPv6，但是有一点苹果没有指出来，那就是，虽然你的服务器不用支持 IPv6，但是必须正确响应 IPv6 的 DNS 查询。

如何验证呢？？使用以下命令即可：

$ dig +nocmd +nostats example.com AAAA

如果返回的 status 为 NOERROR， 那基本就没什么问题，但是一定要在多个网络环境下测试都通过才行。如果返回的是其他的响应，尤其是 SERVFAIL 的情况，那就基本杯具了。由于你已经验证了客户端没有问题，现在要做的，就是催着你的运维、后台啥的，赶紧去改 DNS 配置，直到稳定返回 NOERROR 为止。

详情参见：https://forums.developer.apple.com/thread/49979。

或者建下边：


eskimoJul 22, 2016 3:29 AM

This post discusses some of the more common reasons for why your app might encounter networking problems during App Review.

Not All Rejections Are IPv6 Related

The App Review rejection you’ve received indicates that:

• your app failed

• it was tested on an IPv6-only network

This does not mean that the failure was specifically caused by that network.  There are many other reasons why an app can work in your office but fail during App Review.  QA1764 How to reproduce bugs reported against App Store submissionsoutlines our standard steps for isolating problems like this.

App Review’s IPv6-only Network

App Review tests your app on an IPv6-only network that supports DNS64/NAT64.  You can test your app in a similar way using an Internet Sharing-based DNS64/NAT64 test network.  FAQ #1 of the Supporting IPv6-only Networks pinned post has links to the instructions for setting this up.  You should make sure your app works on this test network before going any further.

This test network is not exactly the same as the network used by App Review.  Later sections of this document discuss some of the potential pitfalls here.

Check All the Servers

When evaluating the IPv6 readiness of your app, it’s important to consider all of the servers it’s accessing.  This may not be easy to determine.  Some apps access many different servers for many different reasons (core functionality, secondary functionality, advertising, analytics, and so on).  Moreover, it may not be easy for you to uncover all of these servers.  For example:

• server names may be hidden within library code

• server names may be returned to your app as the result of other network requests

• for HTTP and HTTPS servers, your app may start off talking to one server and be redirected to a different server

• DNS CNAME records mean that a server can have many aliases

One easy way to uncover all of the servers used by your app is to look at a CFNetwork diagnostic log:

1. enable CFNetwork diagnostic logging for your app

2. exercise your app in the usual way

3. grab the log and filter it to build a list of servers

IMPORTANT This approach works well if your app uses high-level networking APIs (anything based on CFSocketStream, including NSURLSession and NSURLConnection).  It will not show any networking done using low-level networking APIs, like BSD Sockets.  You will have to investigate such code manually.

The rest of this document assumes your app is talking to one server.  If your app is talking to multiple servers, you’ll have to repeat the following steps for each one.

IPv6 Connectivity

The Networking Overview says:

Note that, unlike DNS64/NAT64 workflows deployed by service providers, [the Internet Sharing-based test network] always generates synthesized IPv6 addresses. Therefore, it does not provide access to IPv6-only servers outside of your local network.

The App Review network, like the networks deployed by service providers, does support IPv6-to-IPv6 connectivity.  Thus, if your server supports IPv6, your app will talk to it directly, without going through the NAT64 translator.

This is, in general, a good thing, but it can trip you up if your server claims to support IPv6 but that IPv6 support is broken.  For example, if:

• the DNS name is incorrect

• the DNS is correct but the server is not listening on IPv6

• the server is listening on IPv6 but fails when a request comes in over IPv6

The following sections discuss each of these points in turn.

IPv6 DNS Problems

Your first step in debugging IPv6 connectivity should be to check that the DNS is returning reasonable results for your server’s name.  You can do this using the dig command line tool.  The following is an example of the results you’d expect if your server supports IPv6.

1. $ dig +nocmd +nostats example.com AAAA  
2. ;; Got answer:  
3. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24342  
4. ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0  
5.   
6. ;; QUESTION SECTION:  
7. ;example.com. IN AAAA  
8.   
9. ;; ANSWER SECTION:  
10. example.com. 66159 IN AAAA 2606:2800:220:1:248:1893:25c8:1946  

Note dig is a flexible tool for interrogating DNS name servers.  dig does not use this system’s DNS resolver, but rather talks to the DNS server directly.  In these examples I’m supplying the +nocmd and +nostats arguments to minimise the noise in the output and AAAA to query for an IPv6 address record.

As you can see, the server responds with a status of NOERROR (line 3) and an Answer Section that contains the IPv6 address of the server.  This indicates that the server claims to support IPv6.

In contrast, the following command shows the result to expect when the AAAA record is not present.

1. $ dig +nocmd +nostats ipv4only.arpa AAAA  
2. ;; Got answer:  
3. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49883  
4. ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0  
5.   
6. ;; QUESTION SECTION:  
7. ;ipv4only.arpa. IN AAAA  
8.   
9. ;; AUTHORITY SECTION:  
10. ipv4only.arpa. 489 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2015072218 7200 3600 604800 3600  

Note that the status is still NOERROR but there’s no Answer Section.  This indicates that the server only supports IPv4.  If that’s the case, you can skip the next few sections (move on to General DNS Problems) because your connections will always go through the NAT64 translator.

One thing to watch out for is a result like this:

1. $ dig +nocmd +nostats broken.example.com AAAA  
2. ;; Got answer:  
3. ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27593  
4. ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0  
5.   
6. ;; QUESTION SECTION:  
7. ;broken.example.com. IN AAAA  

In this case the status (still on line 3) is SERVFAIL.  A status like this indicates a failure on the server rather than the absence of an AAAA record.  If your DNS server incorrectly returns this status, it can cause problems for DNS64/NAT64 networks.

IMPORTANT Section 5.1.2 of RFC 6147 DNS64 requires that a DNS64/NAT64 gateway treat a status of SERVFAIL when requesting an AAAA record as equivalent to NOERROR.  The App Review DNS64/NAT64 gateway does not currently comply with this requirement.

Another thing to watch out for is a result like this:

1. $ dig +nocmd +nostats broken.example.com AAAA  
2. ;; Got answer:  
3. ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52961  
4. ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0  
5.   
6. ;; QUESTION SECTION:  
7. ;broken.example.com.        IN  AAAA  

Again, the key thing to note here is the status (line 3).  A status of NXDOMAIN means that there are no records of any type for this name.  You shouldn’t see this for your server’s name because that server should have an A record containing its IPv4 address.  Some DNS servers incorrectly return NXDOMAIN when asked for an AAAA record, even though there’s a valid Arecord.  A bug like this in your DNS server will cause problems for IPv6-only clients because the DNS64/NAT64 gateway takes the DNS server at its word: an NXDOMAIN result for the AAAA query means there is also no A record, and thus the name is invalid.

IPv6 Listening

If your server claims to support IPv6, you should make sure it’s listening on the IPv6 address returned by the DNS.  If it’s a web server (HTTP or HTTPS), there are a variety of web-based tools to check this (for example, ipv6-test.com).  If it’s some other sort of server, you will have to test this from a native IPv6 network.

IMPORTANT When testing a web server, make sure you know whether the server is being accessed by HTTP or HTTPS, and test the appropriate protocol.

IPv6 Server Failures

It’s possible that your server is correctly set up to use IPv6 but fails when it gets a request over IPv6.  If you have access to the server’s log, you might be able to use it to debug failures like this.  If not, you will have to test your server from a native IPv6 network.

General DNS Problems

For DNS64/NAT64 to work properly, it’s important that your DNS servers are set up correctly.  It’s easy for subtle DNS configuration errors to cause problems to show up in some circumstances, like on the App Review network, and not in others, like your Internet Sharing-based DNS64/NAT64 test network.

There are a variety of Internet-based tools you can use to check your DNS setup.  Many of them are based on theDNSCheck code from The Internet Foundation In Sweden.  While it’s possible to download and run this code yourself, it’s generally easier to use their online tool.

When checking DNS, be wary of the following:

• DNS aliases (CNAME records)

• domain names versus zones

The following sections explain these points in detail.

DNS Aliases

As mentioned earlier, DNS allows a server to have multiple aliases via CNAME records.  If the name you’re connecting to is a DNS alias, and the source and destination names are in different zones, you have to check each zone independently.

You can uncover these DNS aliases using dig.  For example, the following shows that ftp.microsoft.com is actually a CNAME for ftp.microsoft.akadns.net., which in turn resolves to the IP address 134.170.188.232.  On the other hand, www.example.com directly points to 93.184.216.34.

1. $ dig +short ftp.microsoft.com  
2. ftp.microsoft.akadns.net.  
3. 134.170.188.232  
4. $ dig +short www.example.com  
5. 93.184.216.34  

In the case of ftp.microsoft.com, the DNS alias means you have to be concerned with both the microsoft.com.domain and the akadns.net. domain.

Domain Names versus Zones

Some DNS checking tools will not let you enter an arbitrary domain name.  Instead, you have to enter the domain name of the top of the zone.  For example, you can’t check www.example.com, but instead have to check example.com.

You can find the top of the zone by searching for an SOA (Start of Authority) record.  If you don’t get an SOA record for the name, walk ‘up’ the DNS hierarchy, removing a label from the front of the name, until you do.  The following example shows how to do this using dig.

1. $ dig +short www.example.com SOA  
2. $ dig +short example.com SOA  
3. sns.dns.icann.org. noc.dns.icann.org. 2015082599 7200 3600 1209600 3600  

Once you have the top of the zone you can check the domain using whatever DNS checking tool you choose.  The following is an example of running a check with the dnscheck command line tool, which I built from the DNSCheck open source on my Mac.

1. $ /usr/local/bin/dnscheck example.com  
2.   0.000: example.com INFO Begin testing zone example.com with version 1.6.6.  
3.   0.001: example.com INFO Begin testing delegation for example.com.  
4. 17.579: example.com INFO Name servers listed at parent: a.iana-servers.net,b.iana-servers.net  
5. 22.148: example.com INFO Name servers listed at child: a.iana-servers.net,b.iana-servers.net  
6. …  

Note Installing dnscheck is not without its challenges. If you only have a few domains to check, it’s much easier to useIIS’s online tool.

Well-Known Prefix

Some developers have attempted to synthesise an IPv6 address by combining an IPv4 address with the Well-Known Prefix (64:ff9b::/96).  This will not work in the general case.  For reliable results you must use getaddrinfo (or some higher-level API) to synthesise IPv6 addresses, as described in Use System APIs to Synthesize IPv6 Addresses.

For more advice on this front, see FAQ #4 in the Supporting IPv6-only Networks pinned post.

Share and Enjoy 
— 
Quinn “The Eskimo!” 
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 
let myEmail = "eskimo" + "1" + "@apple.com"

---

Change History

• 23 Jun 2016 — First posted.

• 22 Jul 2016 — Removed an incorrect mention of NXDOMAIN and added a more in-depth discussion of that status.  Expanded the discussion of SERVFAIL, adding a reference to Section 5.1.2 of RFC 6147.  Made minor editoral changes.

•