DNSSEC would only matter to the end client (the iPhone in this case) if it actually verified DNSSEC responses on the client, but it doesn't.
So unless your application contains a full DNS resolver that can walk the roots itself, you are relying on the DNS server from your provider to provide you with DNSSEC validated results. In this case the provider can simply return results without any of the DNSSEC results and things will be more than happy to continue on.
XLAT464 is not some sort of panacea, and requires a bunch of extra software running on the device to properly function. NAT64 with DNS64 means you ignore all of that, and only the provider has to know that translation is happening, from a device perspective it looks like it is running on top of a IPv6 only network with all endpoints only being IPv6. It's simpler, and maybe just the push providers need to roll out IPv6 more aggressively.
> DNSSEC would only matter to the end client (the iPhone in this case) if it actually verified DNSSEC responses on the client, but it doesn't.
If you tunnel the DNS resposes over a TLS connection, then it would be secure. This has been specified in an RFC recently.
And about XLAT464: Apple could've just added that to iOS, instead of this. Google did the same a few years ago. If all the vendors would apply the same transition mechanism, that would make it a lot more easier for carries to deploy IPv6.
>If all the vendors would apply the same transition mechanism, that would make it a lot more easier for carries to deploy IPv6.
The nice thing about NAT64/DNS64 is that there is no support for anything beyond IPv6 required on the client - it's entirely handled by the network, and is completely transparent / invisible to the endpoints.
464XLAT (https://tools.ietf.org/html/rfc6877), is a stateless NAT46 on the phone, coupled with a stateful NAT64 on the headend, and sometimes with DNS64.
This (edit: 'this' being the presence of stateless translation on the device) means the device has to do extra translation work on a per-packet basis, which would not help the battery life, and also the apps remains IPv4-only. I.e.: it is technical debt.
Apple has a stronger influence on the developers + a lot of address-family independent APIs, so they could exercise this option of allowing operation on IPv6-only access networks while also progressing towards all applications being future-proof.
So unless your application contains a full DNS resolver that can walk the roots itself, you are relying on the DNS server from your provider to provide you with DNSSEC validated results. In this case the provider can simply return results without any of the DNSSEC results and things will be more than happy to continue on.
XLAT464 is not some sort of panacea, and requires a bunch of extra software running on the device to properly function. NAT64 with DNS64 means you ignore all of that, and only the provider has to know that translation is happening, from a device perspective it looks like it is running on top of a IPv6 only network with all endpoints only being IPv6. It's simpler, and maybe just the push providers need to roll out IPv6 more aggressively.