Subject: Re: [BEHAVE] using IPv4-mapped DNS/DNS64 resolvers for dual-stack/IPv6-only hosts

From: [email-masked]
Date: Thu, 11 Mar 2010 11:40:34 +0800

Hi, Dan,

IMO, DNS64 enhancement can solve your problem. Since dual stack application generates A and AAAA DNS query, and IPv6 only application only generates AAAA query, DNS64 can recognize the type of the application easily. DNS64 should not synthesize the answer of A query it forwards, only synthesize the answer of A query it generates for AAAA query.

Best Regards,
Zhenqiang Li

---

From: Mark Andrews <[email-masked]>
Date: Thu, 11 Mar 2010 14:42:44 +1100

In message <[email-masked]
ile>, [email-masked] writes:
> Hi, Dan,
> 
> IMO, DNS64 enhancement can solve your problem. Since dual stack application g
> enerates A and AAAA DNS query, and IPv6 only application only generates AAAA 
> query, DNS64 can recognize the type of the application easily. DNS64 should n
> ot synthesize the answer of A query it forwards, only synthesize the answer o
> f A query it generates for AAAA query.

Rubbish.  A DNS64 server cannot tell what type of client is generating
the queries.   Remember a good stub resolver will send each query
on a different random port and the query id will not be guessable.
There is just no way for a DNS64 server to work whether a AAAA query
is from a IPv6 only client, a IPv4 only client or a dual stack client.

Mark

> Best Regards,
> Zhenqiang Li
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 11 Mar 2010 10:43:47 -0800

> IMO, DNS64 enhancement can solve your problem. Since dual 
> stack application generates A and AAAA DNS query, and IPv6 
> only application only generates AAAA query, DNS64 can 
> recognize the type of the application easily. DNS64 should 
> not synthesize the answer of A query it forwards, only 
> synthesize the answer of A query it generates for AAAA query.

Interesting idea.  The DNS64 server would need to heuristically 
accomplish that function by noticing if an IPv6 client sent an 
A query and AAAA query (for the same QNAME) within NNNN 
milliseconds.  That seems fragile.  

No matter the heuristic chosen, a requirement is the host send all
its DNS queries over the same IPv6 interface so the DNS64 server 
would know the same host is querying the same QNAME for A 
and for AAAA.  That requirement seems to conflict with existing 
behavior of some OSs which have per-interface DNS lists [1] 
and may conflict with emerging requirements in MIF [2].

[1]
http://tools.ietf.org/html/draft-ietf-mif-current-practices-00#section-2.3.1
[2] http://tools.ietf.org/html/draft-ietf-mif-problem-statement-02#section-4.1

However, I imagine you are considering doing this new function within
the host itself (host-based translation), to avoid giving a dual-stack
application a synthesized AAAA record.  Which means the dual-stack
application is effectively being forced to prefer IPv4 to reach the
IPv4-only server.  With host-based translation (HBT), that means the
application's data goes through HBT from IPv4->IPv6, across the network, 
and then through the in-network IPv6->IPv4 translator.  Versus (without
the idea proposed above) the dual-stack application using the
synthesized AAAA and using the in-network IPv6->IPv4.  In both cases
with there was an in-network IPv6->IPv4 translation for that dual-
stack application accessing an IPv4-only server.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Mar 2010 09:37:16 +1300

> is from a IPv6 only client, a IPv4 only client or a dual stack client.

This is why I've been working on the assumption that people would strongly
constrain the usage of DNS64 servers so that only hosts intended to
use them and their associated NAT64 would do so.

    Brian