Subject: [BEHAVE] DNS64 server using its own synthesized records

From: Simon Perreault <[email-masked]>
Date: Fri, 31 Jul 2009 15:25:19 +0200

Hello,

This is an implementation issue that I hadn't fully grasped before my
talk. Now I have, and I propose a fix.

Imagine you have a DNS64 server with IPv4 and IPv6 addresses. In the
process of recursing, it may synthesize AAAA records for upstream
servers that it wants to contact. It will then end up sending DNS
requests to the NAT64 device whereas they should have gone directly over
IPv4. This is the first problem.

The second problem is that it is not even certain that the NAT64 device
is accessible from the DNS64 server. I can imagine useful and common
real-life deployments where it will not be the case.

This last problem could be fixed by ignoring it. The IPv6 request will
time out quickly (assuming we receive an ICMP error) and IPv4 will
become preferred for future requests (or so I understood from chatting
with a DNS server implementor).

But the first problem remains even if the NAT64 device is accessible.
Therefore, I suggest that we add something along the line of the
following to the draft:

   A DNS64 implementation MUST provide a configuration directive
   specifying whether it is allowed to send requests to synthetic IPv6
   addresses while it is recursing.

      Note: If the DNS64 has a usable IPv4 connection, it is expected
      that the directive will be set to false. Otherwise, and if the
      DNS64 can reach the IPv4/IPv6 translator, it is expected that the
      directive will be set to true.

Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: liu dapeng <[email-masked]>
Date: Thu, 13 Aug 2009 01:19:03 +0800

> IPv4. This is the first problem.
==>
Why the DNS64 synthesize AAAA records for upstream DNS servers?

Since DNS64 has both IPv4 and IPv6 address, why not use its IPv4
interface to send the recurse query to the upstream DNS if the
upstream DNS has an IPv4 address?

BR,
Dapeng Liu

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Aug 2009 07:31:04 -0400

This case is explained here:

>>        that the directive will be set to false.

Note that "IPv4 address" does not equate "usable IPv4 connection". You 
need static configuration to differentiate between the two. It is the 
network administrator's job to decide.

Simon

---

From: liu dapeng <[email-masked]>
Date: Thu, 27 Aug 2009 03:29:18 +0800

> network administrator's job to decide.

DNS64  should has an IPv4 connection in my opinion, since RFC 3901
recommends that it should be avoid to deploy IPv6 only DNS since this
approach may cost many issues.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 26 Aug 2009 15:37:03 -0400

> approach may cost many issues.

The relevant passage from RFC 3901 is the following:

      - every recursive name server SHOULD be either IPv4-only or dual
        stack,

         This rules out IPv6-only recursive servers.  However, one might
         design configurations where a chain of IPv6-only name server
         forward queries to a set of dual stack recursive name server
         actually performing those recursive queries.

I can imagine useful and potentially common cases where a DNS64 would not have 
an IPv4 connection and would "forward queries to a set of dual stack recursive 
name server actually performing those recursive queries" through the NAT64. 
For example, when the RTT between the dual stack recursive name server and the 
IPv6 hosts is long, you might want to provide a local cache.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 26 Aug 2009 15:45:38 -0400

On Wednesday 26 August 2009 15:37:03 Simon Perreault wrote:
> I can imagine useful and potentially common cases where a DNS64 would not
> have an IPv4 connection and would "forward queries to a set of dual stack
> recursive name server actually performing those recursive queries" through
> the NAT64.

Actually, here's an even more potentially common case: you have only one IPv4 
address, and it's assigned to the NAT64. I wouldn't want to be running NAT44 
in parallel with NAT64 on the same IPv4 address just for the DNS64. Better to 
use NAT64 for everything.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 26 Aug 2009 16:23:08 -0400

On Wednesday 26 August 2009 15:37:03 Simon Perreault wrote:
> For example, when the RTT between the dual stack recursive name
> server and the IPv6 hosts is long, you might want to provide a local cache.

This doesn't make any sense in this context. Please ignore.

Simon

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Aug 2009 14:09:49 +1000

>          actually performing those recursive queries.

Note RFC 3901 was written when there were NO root servers that were
running IPv6 on address that were associated with the names of the
root servers.

The intent of RFC 3901 was to ensure that all zones have authoritative
nameservers reachable over IPv4 and that all recursive servers had
a path to reach those IPv4 authoritative servers.  As long as those
conditions are met a recursive server doesn't have to speak IPv4
or IPv6.

Using DNS64 internally is fine as is forwarding via IPv6 to a another
server that is "dual" stacked.  Using a DS-lite connection is fine.
There are lots of ways to do this.

At some point RFC 3901 will need to be updated to says all zones
must be served by both IPv4 and IPv6 servers and all resursive servers
must have IPv4 and IPv6 paths.

At a later point it will be that all zones MUST be reachable over
IPv6 and that all recursive server MUST have a IPv6 path to those
servers.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 27 Aug 2009 13:13:41 +0800

> I can imagine useful and potentially common cases where a DNS64 would not
have
> IPv6 hosts is long, you might want to provide a local cache.

I agree with your opinion. Even though we have some other approaches (e.g.,
CGN) to offer an IPv4 path between the DNS64 and the recursive name servers,
I still think it's also worthwhile for the DNS64 server to synthesize IPv6
addresses of the IPv4 recursive servers in absence of the IPv4 path between
them. 

Xiaohu

---

From: Hui Deng <[email-masked]>
Date: Thu, 27 Aug 2009 20:38:10 +0800

but here NAT64 is assuming an IPv6 only network
I would like to see how RFC 3901 work here.

-Hui

---

From: Hui Deng <[email-masked]>
Date: Thu, 27 Aug 2009 20:41:21 +0800

how consequently this could happen, DNS64 have to send AAAA  resolver
to DNS6 side, and
send a A resolver through NAT64 meantime? is this your assumpation and
described in the draft?

-Hui

---

From: Hui Deng <[email-masked]>
Date: Thu, 27 Aug 2009 20:42:05 +0800

if you propose like this, then I would like to see the text and comment it later
thanks

-Hui

---

From: Simon Perreault <[email-masked]>
Date: Thu, 27 Aug 2009 08:46:57 -0400

On Thursday 27 August 2009 08:42:05 Hui Deng wrote:
> if you propose like this, then I would like to see the text and comment it
> later thanks

I don't understand what you want. I have proposed some text and based on the 
feedback I have received it still stands.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 27 Aug 2009 08:48:53 -0400

> send a A resolver through NAT64 meantime? is this your assumpation and

When a DNS64 has only an IPv6 connection, it can only contact authoritative 
name servers over IPv6. However, if it has access to the NAT64, it can also 
talk to IPv4-only authoritative name servers through it. To do so it only has 
to use the synthetic AAAA records it generates.

Simon

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Aug 2009 15:27:36 +0200

> to use the synthetic AAAA records it generates.

Being able to perform DNS64 synthesis and being able to do recursive  
queries through a NAT64 are two different things. One doesn't imply  
the other, although once you have one the other is easier because you  
already have the NAT64 prefix that you need.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Aug 2009 11:20:15 +1000

In message <[email-masked]>, Iljitsch van Beijn
> already have the NAT64 prefix that you need.

Here is a example of how it would be done, sorry for the line width.

  client                      DNS64                            NAT64                     V4 server
(IPv6 only)                (IPv6 only)                     (dual stack)                 (IPv4 only)
2000:yyyy                   2001:xxxx                        4.0.0.1                     3.0.0.1
          example.com/AAAA 
           ->2001:xxxx
                                        example.com/AAAA
                                        -><prefix>:3.0.0.1
                                                                         example.com/AAAA
                                                                           ->3.0.0.1
                                                                     example.com/AAAA/NXRRSET
                                                                           <-4.0.0.1
                                     example.com/AAAA/NXRRSET
                                         <-2001:xxxx
                                        example.com/A
                                        -><prefix>:3.0.0.1
                                                                         example.com/A
                                                                           ->3.0.0.1
                                                                     example.com/A/1.2.3.4
                                                                           <-4.0.0.1
                                     example.com/A/1.2.3.4
                                         <-2001:xxxx
     example.com/AAA/<prefix>:1.2.3.4
          <-2001:yyyy

NXRRSET (no such RRset) indicates that the name exists but the
requested type doesn't.  It's another way of expressing NOERROR
with zero answers and no referral.

Mark

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 28 Aug 2009 10:17:35 +0800

Hi Mark,

>      example.com/AAA/<prefix>:1.2.3.4

I think the illustration would become more clearly once you could introduce
one more layer of recursive server in your example. For example, the DNS64
firstly sends a DNS query for the AAAA RR of www.example.com to the DNS
server (e.g. S1, prefix+3.0.0.1) which is the authoritative DNS server for .
com zone, and S1 told the DNS64 that the authoritative DNS server for
example.com zone is S2 (i.e., 5.1.1.1 which is expressed in a NS record).
Upon receiving the above reply, the DNS64 will then send a recursive query
to S2 by using the synthesized address of S2 (i.e., prefix64+5.1.1.1). This
synthesis action is exactly implemented by the DNS64 itself. However, in
your example, the synthesized address for DNS server 3.0.0.1 could be
configured directly on the DNS64, which is transparent to the DNS64.

Xiaohu

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Aug 2009 14:25:46 +1000

In message <[email-masked]>, Xu Xiaohu writes:
> one more layer of recursive server in your example.

	I think you actually mean one more level of iteration.  The
	recurive requests happen between client and DNS64.  Iterative
	requests happen between DNS64 and the authoritative servers.

> For example, the DNS64

	One can add too much.

	Mark

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 28 Aug 2009 16:12:06 +0800

> > I think the illustration would become more clearly once you could 
> > introduce one more layer of recursive server in your example.
> 

Oh, yes, I meant "iterative query". 

Xiaohu