> On Dec 9, 2016, at 1:43 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > > Yoav Nir <ynir.i...@gmail.com> wrote: >> To get this working, the DNS64 should be on the remote tunnel endpoint >> or behind it. And this will require that it has an IPv6 address and >> knows to do the NAT64 translation in cooperation with the tunnel >> endpoint. I guess this vendor’s IPsec implementation doesn’t do all >> that. Neither does my employer’s. > > So, I think that you are saying that if the client does DNS through the > tunnel, then the HQ's DNS servers have to do DNS64 synthesis? I guess people > need to do DNS through the tunnel because of needing to resolv internal > addresses. It's the whole MIF/split-horizon DNS problem, and I think it's > all a bad IPv4-specific idea, and we should be trying to kill it.
The VPN's DNS should never have to know about DNS64 or support it. The client can solve the issue independently—don't add it at the server end! If I have a IPv4-only split-tunnel VPN over a NAT64 network, with DNS configured such that some hostnames that need to get routed outside the VPN are resolved only inside the VPN (and thus only get A records), the client can take the IPv4 literal result and synthesize the correct IPv6 address using the prefix of the NAT64 network. Thanks, Tommy > > In an IPv6 world, we have better ways to build walled gardens. > > > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
