Subject: Re: [BEHAVE] draft-ietf-behave-dns64-00 Additional section processing

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Jul 2009 17:35:18 +1000

There is no need to perform AAAA synthesis for the additional
	section of a response.  All IPV6 aware dns clients (including
	other nameservers) will preform AAAA lookups for data missing
	from the additional section.

	Performing AAAA synthesis without checking that there is
	no AAAA address will lead to sub optimal commections and
	additional breakage due to unnecessarially sending connetions
	through the NAT64.

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 28 Jul 2009 09:54:02 +0200

At Tue, 28 Jul 2009 17:35:18 +1000,

> 	from the additional section.

Is it true for an SMTP server?  I can imagine a case like this:

- an SMTP server tries to resolve MX for mx.examle.com.
- it gets a response with an A RR (untouched by the dns64 server) in
  the additional section
- the SMTP server tries to make an SMTP connection over IPv4
  corresponding to the A RR in the additional section.  It fails
  (because the server doesn't have IPv4 connectivity).  The SMTP
  server treats it as a fatal error and gives up at that point.

---
JINMEI, Tatuya

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Jul 2009 18:25:10 +1000

In message <[email-masked]>, JINMEI Tatuya / =?ISO-2022-JP?B?GyRC
>   server treats it as a fatal error and gives up at that point.

	Such a SMTP is strongly discouraged by RFC5321 Section 5.1
	and 5.2.  In practic such a MTA is broken as it will never
	work reliably.  You can never assume global IPv4 or IPv6
	reachability based on the presence of local IPv4 or IPv6
	addresses.

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Jul 2009 05:18:05 -0400

> 	additional breakage due to unnecessarially sending connetions

Let's assume we have a modern recursive caching resolver (R) sitting in
front of the client (C) that's actually trying to connect to something.
C is a v6-only host and it wants to talk to a v4-only system,
example.com.  There's a DNS64 and NAT64 being used to make the
connections work.

C asks R for an AAAA record for example.com.  R knows to ask the
DNS64 for everything, so it does.  

The DNS64 asks for AAAA, and does not get an answer.  So it asks for
an A, and does get an answer.  Now it knows that it should synthesize.

Now let's suppose that the additional section includes glue for
ns.example.com.  If there is no AAAA for ns.example.com, and you don't
synthesize and add the AAAA (not replace, note, but add), then an
additional lookup ends up being needed (every time).

If there _is_ (real) AAAA glue for ns.example.com, then it will just
stay there in the additional section, unless it is bumped out by some
protocol limit.  There is text in the current draft intended to
suggest that the AAAAs should sort to the top, so that it's more
likely that the A gets silently truncated (and the AAAA ends up
sticking in R's cache), but perhaps it isn't clear enough.

The only case of the problem you identify is where there's real AAAA
glue in the additional, but it gets silently truncated at the outset
(on its way from example.com's authority server to DNS64) .  In that
case, yes, R will end up using a NATted connection _for the DNS lookup_
where a real v6 address was available for performing additional DNS
lookups. And since that truncated data will stick in R's cache, it
will stay with that that NATted connection even if a subsequent lookup
would cause the (real) AAAA data in the additional section become
available.

But this all sounds to me like it's optimizing for the wrong thing.
By synthesizing new AAAA records for the additional section, we avoid
the next lookup which is otherwise required.  It seems to me that this
is a good thing, and it also seems to me that it will be quite unusual
if the answer that comes back will be large enough that the additional
section has to be truncated silently.

So I would claim that for the use case we're tackling, there's not
much benefit in refusing to synthesize the AAAAs and a significant
disadvantage to not synthesizing AAAA in the additional section.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Jul 2009 19:47:51 +1000

> DNS64 for everything, so it does.  

	If R is asking DNS64 for everything it will NEVER attempt
	to go directly to the authoritative servers.

	You can't both ask the DNS64 and talk to the authoritative
	servers directly and get sane responses out of R.  Such a
	configuration is broken and will never work reliably.

	R needs to choose which view of the world it sees.  The
	authoritative view or the modified view.

	All the servers a client talks to need to provide a
	*consistant* view of the world for a given name.  Attempts
	to do otherwise will lead to angst.  I've seen it occur
	many times.

	Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Jul 2009 06:50:38 -0400

> 	to go directly to the authoritative servers.

Yes.
 
> 	configuration is broken and will never work reliably.

Of course.  Where did you get the idea that R was supposed to talk to
anything other than the DNS64?

> 	to do otherwise will lead to angst.  I've seen it occur

Right.  If you're going to lie, lie consistently and do it only to
consenting adults.  It is that "consistency" criterion that leads me
to say you should perform synthesis (but not pruning -- a nice term
for this introduced in the BEHAVE session today) in the Additional
section.

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Jul 2009 20:59:11 +1000

> anything other than the DNS64?  

You were worried about there being A but not AAAA records for the
nameservers.  The only possible reason for such a concern is to
talk directly to the nameservers.

> for this introduced in the BEHAVE session today) in the Additional

But you are telling the DNS64 to be inconsistent by translating A's
in the additional section without checking for a lack of AAAA records
first.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Jul 2009 11:47:55 -0400

> talk directly to the nameservers.

Aha.  This is indeed the scenario I was worried about.  I think you're
convincing me that this is a scenario that will break.  I'm slow on
the uptake.

In the scenario I was supposing, there is a synthesis-oblivious
recursing (caching) resolver _behind_ the DNS64.  It knows that it's
only ever supposed to talk to its upstream resolver (which happens to
be the DNS64 box).  This is a plausible scenario, since I happen to
own a mass-market home gateway that works exactly this way.  That
resolver is the one I called R.

Now, suppose the DNS64 synthesises AAAAs for the A records in the
additional section.  In this case, R ends up with a synthetic AAAA
that subsequently sends it off to the name server.  But that name
server is synthesis-obvlivious, of course, and simply hands back an A
record.  If R doesn't know about synethesis, then there's nowhere for
the original querying agent to go, and so now we're hosed.

This means actually that we need to strengthen the language about what
sorts of DNS clients may live behind the DNS64 boundary.  In
particular, no DNS system that caches any record, or that can use glue
to perform additional resolution independently, may live behind the
DNS64 boundary.  Right?

If that's right, it is also sort of bad news for our deployment cases,
because it means that some classes existing hardware won't work no
matter what we do.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Jul 2009 06:29:51 +1000

> convincing me that this is a scenario that will break.  I'm slow on

	If R is so misconfigured and thing break because of that then
	that is good.  R needs to be correctly configured not to talk
	to the authoritative servers directly if it is using a DNS64
	box.
 
> the original querying agent to go, and so now we're hosed.

	No.  Forwarding nameservers don't behave like that.  If you
	are talking to a forwarder and not to the authoritative
	servers you don't need to return any glue.  Glue is ONLY
	needed when you are iterating.  Nameservers that are
	forwarding are not iterating.

> because it means that some classes existing hardware won't work no

	No.  You iterate or you forward.  You don't mix modes.

	Mixed mode configuration is for performance not to change
	namespace or to synthesis AAAA records.

	Mark
> A
> 
> -- 
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Jul 2009 20:03:27 -0400

> 	No.  You iterate or you forward.  You don't mix modes.

You don't need to preach to me: I am in the choir, my book is open,
and I am singing.  But we have an existing world that unfortunately
does not really comply with our ideas of the right thing to do.  There
are in fact boxes that mix these modes (which modes, I hesitate to
note, are not exactly called out completely plainly in the giant pile
of DNS-specifying RFCs).  If you are a naive implementer being paid by
the hour (and harassed by the picosecond) to "implement DNS" in some
commodity box, let me suggest that it would not be entirely surprising
if you maybe overlooked one of the side comments in some RFC that made
all of this clear.
 
> 	namespace or to synthesis AAAA records.

I must not have made my point clear.  Our goal is to deploy all of
this stuff into existing, otherwise-oblivious networks.  What we seem
to be converging on is that you _cannot_ deploy DNS64 before a network
where there is even one recursive, caching resolver (i.e. an Iterative
Mode Resolver or IMR).  The draft was intending to solve the case
where there's an IMR in the path, but I think you have convinced me
that such a case is totally broken in principle.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 31 Jul 2009 16:10:44 -0400

> 	forwarding are not iterating.

Right.  But some nameservers that are deployed in, for instance, CPE
boxes actually have iterative mode resolvers in them.  Usually, this
is because they want to have a cache.

So, for those who haven't been following this little incursion into
the vagaries of the DNS protocols, what follows is a description of
and proposed answer to the problem (which I have in my muddle-headed
way finally understood from what Mark was saying).  The DNS community
has jargon for all this, but I have just realised that I can't give
you a nice pointer to where these things are defined, so I'm going to
skip the jargon and try to express things explicitly.  Sorry for the
tedium if you know the jargon.

Suppose one has a DNS server that offers recursion and performs
caching, and that it is behind a DNS64.  I'll call this system "B" for
the sake of brevity.  B can happen on a CPE box, for instance, which
usually gets its own list of nameservers from DHCP.  What B does
_not_ have is a root.hints file: it relies on an upstream server for
some work, in order to make use of the existing cache at the ISP.  The
critical ingedient here is that the nameserver is not merely
forwarding.  I have no idea how common these are compared to simple
forwarders, but since I have one I'm inclined to think they're at
least not really strange.

Now, suppose a client "A" wants to look up www.example.com.  It asks
B. When B does its first query for www.example.com, depending on some
details of what's deployed and whether the name servers are "in
baliwick", the answer may come back with an additional section
including the nameservers for example.com.  If the DNS64 is in the
way, then (under the text of the current draft) this is no problem:
the A records in the answer will be pruned and corresponding AAAAs are
removed, and the additional just gets additional AAAAs at the
beginning (to reduce the chance that they're what gets chopped off if
the additional section makes the response too big.  I know, I know,
you're thinking that TC should be set in that case, but it often
isn't).

So far, so good.  B has the answer A needs, so hands it back, and A
goes off to the site.  But now, suppose that A wants to look up
www4.example.com.  The nameservers for example.com are in B's cache.
So B will happily go and talk to those nameservers and ask about
www4.example.com.

Now everything is completely broken.  Neither the target nameservers
nor B knows anything about the synthesis for DNS or the translation in
the NAT64.  B, which is inside the IPv6-only network, will not get any
AAAA records, and will be unable to resolve www4.example.com in a way
useful to A.  

There are two possible answers to this problem:

    1.  "We don't care.  Don't run a DNS server that offers recursion
    and performs caching behind a DNS64, period."  I think this won't
    really work, because we have no way of knowing how many such
    resolvers there are out there, and the whole point of this effort
    is to reduce the need to upgrade all the deployed systems
    (particularly, all the customer equipment) or to know exactly what
    equipment lies where in the network.

    2.  Always prune the glue in the DNS64 server.  This should solve
    the problem where B gets the glue and later uses it (because it's
    not there).  I _think_ there might be a case where B gets an
    answer without glue that is necessary, however, and in that case
    B fails.  Since we have demonstrated, however, that B
    will eventually fail anyway, it's just as well to fail right away,
    I'd say.  This scenario also has the potential to work all the
    time, depending on details of the underlying software used to make
    B.  

Thoughts?  My own inclination is to revise the draft along the lines
of #2.

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Timothy Baldwin <[email-masked]>
Date: Fri, 31 Jul 2009 22:33:52 +0100

>     equipment lies where in the network.
But one can be reasonably certain many of them are IPv4 only, along with 
many IPv4 hosts. Such a network must therefore be dual-stack or IPv4 
only and one may as well use IPv4 NAT (which could be Softwires NAT) 
rather than NAT64; which is what would happen with this behaviour.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 31 Jul 2009 17:45:58 -0400

On Fri, Jul 31, 2009 at 10:33:52PM +0100, Timothy Baldwin wrote:

> But one can be reasonably certain many of them are IPv4 only, 

I think I don't understand this part of your comment, which is why the
rest of it is opaque to me.  Many of _what_ are IPv4 only?  Do you
mean that the target hosts are v4 only?  If so, then yes, that's
exactly the scenario we're trying to help, where one host is on a v6
only network and another is on a v4 only network.

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.