Re: [v6ops] NAT64/DNS64 and DNSSEC

Hello,

but isn't there a gap that when performing the RFC7050 64pref detection by querying ipv6only.arpa, an attacker can spoof this answer (DNSSEC won't work here, for example, the attacker - when between the client and the DNS - can return for example 2001:db8::192.0.0.170 (where 2001:db8:: is a prefix owned by the attacker)) and then attract all IPv4 traffic from the victim?

Nevertheless, an answer to the proliferation of DNSSEC and at the same time increasing usage of DNS64/NAT has to be found, not to stop the success of one or the other.

-- 
Holger Metschulat 
Deutsche Telekom Technik GmbH 
Heinrich-Hertz-Strasse 3-7, 64295 Darmstadt 
+49 6151 58 - 18671 (Tel.) 
+49 160 901 35443 (Mobil) 
E-Mail: holger.metschulat@telekom.de 
http://www.telekom.de 
Erleben, was verbindet.  
Die gesetzlichen Pflichtangaben finden Sie unter: www.telekom.de/pflichtangaben-dttechnik
Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken. 

-----Ursprüngliche Nachricht-----
Von: v6ops [mailto:v6ops-bounces@ietf.org] Im Auftrag von Erik Kline
Gesendet: Freitag, 24. Juli 2015 12:37
An: Philip Homburg
Cc: v6ops@ietf.org
Betreff: Re: [v6ops] NAT64/DNS64 and DNSSEC

> I guess this is easy enough to add to for example getdns 
> (https://getdnsapi.net/). One question is how an application would 
> find out that it is running in a DNS64 environment. Another option is 
> for getdns to do the probing and enable this option automatically.

One approach comes to ming: when a client resolver starts up, it checks ipv4only.arpa (https://tools.ietf.org/html/rfc7050#section-8.2), and after that can synthesize AAAAs as needed (DNS64 in done in the client) while getting validated answers for other things as desired.

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops