Configure server for IPv6 compatibility (for API used by rejected iOS app)

Question

I realise that there's already many questions on Stack Overflow from users that have had their iOS apps rejected by Apple because they don't work on an IPv6 only network.

I've already checked through my code to ensure there's no hardcoded IP addresses (definitely none) and no use of old reachability (none at all) or other low-level networking frameworks (we're using NSURLSession only). I've been through the NAT64 test network on my machine, and the app (appeared to) worked fine.

This is a Xamarin app that communicates with an API over HTTPS (and no other network connections).

Some of the answers I've found have indicated that the solution to this problem requires configuration changes to the server.

So my question is broadly, what configuration changes are required? More specifically, do you need an AAAA record on the domain? If so, how should it be configured?

I'm coming at this problem more as a software developer, so without the detailed understanding of how IPv6 works and what server changes are required.

Answer 1

Your server shouldn't need to change. The NAT64 should take care of the translation for IPv4-only servers and the DNS64 should make sure that you get the right address for a hostname. So when using hostnames and not hardcoded addresses and you use IP-version-neutral APIs then it should usually just work.

One case where it can fail is when people try to be more compliant with Apple's policy and put some dummy/fake/wrong AAAA records in their DNS zone. Those will actually prevent the DNS64 to generate the right records because it thinks the server has real IPv6 and doesn't need the translation service.

The DNS64 built into MacOS doesn't have a "real" IPv6 connection to the internet and will ignore such bad AAAA records, but a real DNS64 will not. So in this case your local test will seem to work but Apple will see it fail.

I built a test tool that you can use to check a website with a real DNS64 and NAT64 service at https://nat64check.org/. Feel free to use it.

While it's not mandatory, if you want the best reachability for your web service then ity is recommended to actually make your server accessible over IPv6 and to provide AAAA records. That will make your service independent of NAT64 and DNS64 translation services, which will improve reliability and performance. It will also improve things for other users that have IPv6, because it allows them to bypass the tricks that ISPs need to deploy these days to compensate for the lack of IPv4 addresses (like CGN, DS-Lite etc).

It will also prevent problems with DNSSEC: NAT64 needs to generate "fake" AAAA needs to make the service work over IPv6, and DNSSEC is designed to prevent anyone from lying about DNS records. If you provide real AAAA records then NAT64 doesn't need to lie and DNSSEC isn't affected.

To summarise: the best thing to do is to make your server reachable over IPv6 and publish its address in DNS with AAAA records. That will benefit everybody. But don't publish fake AAAA records (for example those starting with ::ffff:, 2001:db8:, 64:ff9b:, fc or fd). Those will hurt everybody that has IPv6, which is quite a large number of people these days. When you make your service available over IPv6 treat it as a production service and do it right.