我意识到已经有很多关于Stack Overflow的问题已经被苹果公司拒绝了他们的iOS应用程序，因为它们不适用于仅支持IPv6的网络。
我已经检查过我的代码，以确保没有硬编码的IP地址（绝对没有），也没有使用旧的可达性（根本没有）或其他低级网络框架（我们只使用NSURLSession）。我已经在我的机器上通过了NAT64测试网络，并且应用程序（似乎）工作正常。
这是一个Xamarin应用程序，它通过HTTPS（而不是其他网络连接）与API通信。
我发现的一些答案表明此问题的解决方案需要对服务器进行配置更改。
所以我的问题是广泛的，需要进行哪些配置更改？更具体地说，您是否需要域名上的AAAA记录？如果是这样，应该如何配置？
我作为软件开发人员更多地解决这个问题，所以没有详细了解IPv6如何工作以及需要更改服务器。
答案 0 :(得分：3)
您的服务器不需要更改。 NAT64应该处理仅限IPv4服务器的转换，DNS64应该确保为主机名获取正确的地址。因此，当使用主机名而不是硬编码地址并使用IP版本中立的API时，它通常应该可以工作。
可能失败的一个案例是当人们试图更加遵守Apple的政策并在他们的DNS区域中放置一些假/假/错误的AAAA记录时。这些实际上会阻止DNS64生成正确的记录，因为它认为服务器具有真正的IPv6并且不需要翻译服务。
MacOS内置的DNS64没有＆＃34;真正的＆＃34; IPv6连接到互联网并将忽略这些错误的AAAA记录，但真正的DNS64不会。因此，在这种情况下，您的本地测试似乎会起作用，但Apple会看到它失败。
我构建了一个测试工具，您可以使用https://nat64check.org/检查具有真实DNS64和NAT64服务的网站。随意使用它。
虽然它不是强制性的，但如果您希望Web服务具有最佳可访问性，则建议您实际通过IPv6访问服务器并提供AAAA记录。这将使您的服务独立于NAT64和DNS64翻译服务，这将提高可靠性和性能。它还将改善其他拥有IPv6的用户的工作，因为它允许他们绕过ISP现在需要部署的技巧来弥补IPv4地址的缺乏（如CGN，DS-Lite等）。
它还可以防止DNSSEC出现问题：NAT64需要生成＆＃34; fake＆＃34; AAAA需要使服务在IPv6上运行，而DNSSEC旨在防止任何人撒谎DNS记录。如果你提供真正的AAAA记录，那么NAT64不需要撒谎，DNSSEC也不会受到影响。
总结一下：最好的办法是让服务器通过IPv6访问，并使用AAAA记录在DNS中发布其地址。这将使每个人受益。但是，不要发布假的AAAA记录（例如以::ffff:，2001:db8:，64:ff9b:，fc或fd开头的记录。那些会伤害所有拥有IPv6的人，这些人现在已经相当多了。当您通过IPv6提供服务时，请将其视为生产服务并正确执行。