Subject: [BEHAVE] In some cases Java does not work with DNS64

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 24 Jun 2012 12:21:15 -0700

I discovered a problem with DNS64 when working on an implementation of
draft-ietf-behave-nat64-discovery-heuristic for a review.

In most cases, Java delegates the DNS resolution to getaddrinfo(3), and in
this case, everything works just fine.  But in some cases a different resolver
needs to be used, mostly when the Java developer wants to be able to provision
the nameserver(s) to use for the resolution.  Switching the resolver is simple
and can be done on *any* Java application by adding the following option on
the java command line:

- -Dsun.net.spi.nameservice.provider.1=dns,sun

The problem with this resolver is that it will send an ANY request instead of
two separate A and AAAA requests, and as RFC 6147 does not say anything about
ANY requests, the AAAA RR are not synthesized.  This problem has been tested
with Java 1.6 (Sun and OpenJDK), 1.7 and the current 1.8 (I did not check
Android yet).

I am a Java developer, so obviously I consider this to be a huge problem,
especially because many existing Java applications will not work as expected
as soon the command line options are modified.  What is the correct way to fix
RFC 6147 and the DNS64 implementations out there?

Thanks.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 24 Jun 2012 18:57:02 -0400

On Sun, Jun 24, 2012 at 12:21:15PM -0700, Marc Petit-Huguenin wrote:

> ANY requests, the AAAA RR are not synthesized.

What Java is doing in that case has a broken assumption.

Suppose you have two end nodes on the network sharing a single
caching, full-service resolver.  Suppose also that example.com exists,
and contains at least an A and AAAA record at that owner name.

The first end node ("1") sends only A queries.

The second end node ("2") is using this Java strategy of sending
queries for ANY.

If 1 queries first for example.com A?, then the cache gets a copy of
the A record for example.com.

Now, when 2 queries for example.com ANY?, what do you suppose happens?
Many people seem to think that an ANY query is relayed upstream.  But
that's not what is required by the RFCs.  In fact, at least usualy,
the intermediate cache answers _with the records it has_, which means
that 2 gets an answer with only A records in it.  The response from a
cache when the TYPE is 255 is dependent on what is in the cache when
the query is received (even more than usual with caches).

> RFC 6147 and the DNS64 implementations out there?

Fix Java.  It's what's broken.  I agree, however, that a revision of
DNS64 (I have apparently committed to working one up; I suppose I'm
running out of calendar in which to do it) needs to point out this
sharp, pointy issue, but it can't fix it.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Mon, 25 Jun 2012 09:31:08 +1000

> with Java 1.6 (Sun and OpenJDK), 1.7 and the current 1.8 (I did not check

So?  ANY requests are NOT guarenteed to return ALL records, just
all *available* records (RFC 1034).  This is why "ANY" is used to
describe "*" despite the official alternate name for "*" being
"ALL".  If there are no AAAA records in the ANY response the
application should make a seperate AAAA query.  If this is not
happening then the application is broken.  This is basic DNS.

Now there are AAAA records that are excluded and the ANY response
from a DNS64 server could filter AAAA RRsets that contain only these
records but I doubt that this is your concern.

> as soon the command line options are modified.  What is the correct way to fi
> x RFC 6147 and the DNS64 implementations out there?
> 
> Thanks.
> 
> - -- 
> Marc Petit-Huguenin
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> 
> iQIcBAEBCAAGBQJP52ilAAoJECnERZXWan7E6eQQAK7thiirVIbjh+ztQjsdHV4l
> 7x6McnqSPuA8O6KCFkdFCg6lixVE6iy+m9u8xKBHghvEZSqiCu3StPozFkhMf+i7
> G8rir2dAJFqsUf6NFsopl2aYWKX17R+3cuVI2mG933+I/dJyxnL2GY+vgKoSAHpH
> pWKmJk2h8EcttwfzlmgwmSzRh6Q7UJILzglQHtmQIuQcvxTcK9n3Ry7uMgDp9eZm
> QatAYg629HACgreaiHJQqRVeqlTdireqOLktuiWgxjne4OEKqkB3pOQ4wbBfaLNw
> Xx9LZt7km662YQJJgvNAP53vcIXi1DEV+3ehb02jg+1zb5j4+daxnrYDXjeWDI4v
> HjwRQk2O3oyawzH7l9MEnxGwgBCQKK42vwR7s9bVQi6ndqTKt0jh0yUK2YihUqg5
> FrpwuUVuSXM+tC/AIFY3qx0lP7ClnY6s4SL+MeXrzXB4e/y5bWzVf7FI8CeNDCOc
> OLMuGP4zgIF6fzbJnm3u64bRbLw/8intDgeDcto3VpUpXQaWOQCLmXaigLr5tSAn
> 5mDP6xfhro7CuDbnG7Z45Kkg9WbUn7tziYNdduh9QFJl0FJHl7jf4g8RAqT0GpuY
> vwjTk1UpX0iETaOkRwKGwG/C2d0GYxmThgSIHoWh+7KRalg/IDA1/4DPUaK/a+nn
> aU64jb6ruIInFZhcTTBL
> =yNiU
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 24 Jun 2012 16:34:19 -0700

On 06/24/2012 03:57 PM, Andrew Sullivan wrote:
>> The problem with this resolver is that it will send an ANY request
>> instead of two separate A and AAAA requests, and as RFC 6147 does not say
>> anything about ANY requests, the AAAA RR are not synthesized.
> 
> Suppose you have two end nodes on the network sharing a single caching,
> full-service resolver.  Suppose also that example.com exists, and contains
> at least an A and AAAA record at that owner name.
> 
> The second end node ("2") is using this Java strategy of sending queries
> for ANY.
> 
> If 1 queries first for example.com A?, then the cache gets a copy of the A
> record for example.com.
> 
> Now, when 2 queries for example.com ANY?, what do you suppose happens? Many
> people seem to think that an ANY query is relayed upstream.  But that's not
> what is required by the RFCs.  In fact, at least usualy, the intermediate
> cache answers _with the records it has_, which means that 2 gets an answer
> with only A records in it.  The response from a cache when the TYPE is 255
> is dependent on what is in the cache when the query is received (even more
> than usual with caches).
> 
>> I am a Java developer, so obviously I consider this to be a huge
>> problem, especially because many existing Java applications will not work
>> as expected as soon the command line options are modified.  What is the
>> correct way to fix RFC 6147 and the DNS64 implementations out there?
> 
> Fix Java.  It's what's broken.

OK, it make sense, the Java resolver implementers thought that ANY meant ALL.
 I will fill a bug, and we'll see what happen.

> I agree, however, that a revision of DNS64 (I have apparently committed to
> working one up; I suppose I'm running out of calendar in which to do it)
> needs to point out this sharp, pointy issue, but it can't fix it.

OTOH, what is the downside of synthesizing the AAAA when only the A RR are
returned from the cache for an ANY?  Sure it would have been better to use the
native AAAA than NAT64, but isn't that better than no connectivity at all for
a pure IPv6 client?

- -- 
Marc Petit-Huguenin

---

From: Mark Andrews <[email-masked]>
Date: Mon, 25 Jun 2012 09:49:52 +1000

I can't write a DNS64 + DNSSEC application / server that works
due to the overloading of CD.

	DNSSEC has CD=1 meaning don't validate.
	DNS64 has CD=1 meaning don't synthesis.

If I have a validating DNS64 recursive server with a bad clock /
out of date trust anchors.  I can't get a synthesised response from
this server.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Mon, 25 Jun 2012 10:34:45 +1000

> native AAAA than NAT64, but isn't that better than no connectivity at all for

If you are trying to match AAAA records to IP6.ARPA PTR records
then generating DNS64 records in the ANY response when there *are*
AAAA records will prevent the client making the subsequent AAAA
query it should causing the match to fail when it would otherwise
succeed.

Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 25 Jun 2012 02:18:25 -0400

> due to the overloading of CD.

Please expand the meaning of "works" there.

> 	DNS64 has CD=1 meaning don't synthesis.

I think we may agree, but I don't regard them as so different.  DNS64
uses the CD=1 bit to say, "Whatever is really in the DNS, regardless
of what you think, give it to me raw," which is not dissimilar to what
it means in DNSSEC.

> out of date trust anchors.  I can't get a synthesised response from

Correct.  DNS64 and DNSSEC are bound to be an awkward combination,
because DNSSEC is designed to detect modifications of data changes
along the resolution path, and DNS64 is designed to modify data along
the resolution path.  

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 25 Jun 2012 08:53:14 +0200

That is correct but is not due to the overloading fo the CD bit, but it 
is a fundamental limitation of the DNS64 and DNSSEC interaction.

You cannot validate dynthetice respeconses, well, because they are 
synthetic, so validation would fail.

This is documented in rfc6147

   3.  If the CD bit is set and DO is set, then vDNS64 MAY perform
        validation, but MUST NOT perform synthesis.  It MUST return the
        data to the query initiator, just like a regular recursive
        resolver, and depend on the client to do the validation and the
        synthesis itself.

        The disadvantage to this approach is that an end point that is
        translation-oblivious but security-aware and validating will not
        be able to use the DNS64 functionality.  In this case, the end
        point will not have the desired benefit of NAT64.  In effect,
        this strategy means that any end point that wishes to do
        validation in a NAT64 context must be upgraded to be
        translation-aware as well.

So, as you say, you cant make this work.

Regards, marcelo

---

From: Mark Andrews <[email-masked]>
Date: Mon, 25 Jun 2012 17:41:13 +1000

> Please expand the meaning of "works" there.

I have a application which knows to set CD=1 for particular names
because a upstream server (recursive or authoritative) is DNSSEC
broken and it is willing to live with non-validating data.

Now try it introduce DNS64.  It won't work because CD=1 says "don't
synthesis" and without CD=1 there is no data for DNS64 to work with.

> of what you think, give it to me raw," which is not dissimilar to what

What comes out looks the same but the purposes are orthogonal.

> along the resolution path, and DNS64 is designed to modify data along

And they can be made to work.  See my recent post to this list for how.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 25 Jun 2012 10:06:56 +0200

El 25/06/12 09:41, Mark Andrews escribió:
> In message<[email-masked]>, Andrew Sullivan writes:

i am missing something here. If the application is willing to live 
wihtout DNSSEc data, why would it set CD bit?
If that is the case, it shouldnot set any DNSSEC bit and live without 
DNSSEC and DNS64 would work just fine.

I guess this is not what you have in mind, so can you clarify?

> And they can be made to work.  See my recent post to this list for how.

Sorry, i must have missed this one, could you send me a pointer?

Regards, marcelo

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 25 Jun 2012 07:57:19 -0400

> synthesis" and without CD=1 there is no data for DNS64 to work with.

Correct.  If you want to use CD=1, then you need to be DNS64 aware
too.  DNS64 has failure modes that other resolution strategies don't
have, yes.

> And they can be made to work.  See my recent post to this list for how.

Is this the one from some weeks ago where you suggested using the DO
bit instead?  I don't see how that's going to work: many shipping
resolvers set DO, but very few set CD.  Please recall that the main
point of DNS64/NAT64 is that very few things in the network need to be
altered.  It's a hack to get around the lack of IPv6 deployment.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 Jun 2012 00:02:58 +1000

In message <[email-masked]>, marcelo bagnulo braun writes:
> El 25/06/12 09:41, Mark Andrews escribi=F3:
> > In message<[email-masked]>, Andrew Sullivan writ=
> es:
> i am missing something here. If the application is willing to live =

Because it wants a answer and there is a upstream validator stopping
the answer due to a DNSSEC validation failure.

> If that is the case, it shouldnot set any DNSSEC bit and live without =

It isn't just the end client that validates in DNSSEC.  Everything
except the authoritative sources should be validating as there are
error cases / attacks that can't be recovered from unless everyone
is validating.  Not everyone in the DNSSEC community will agree
with me on this but time and experience will tell that I'm right
on this.

You don't have to be setting bits for DNSSEC to impact responses.
You need to set bits to stop DNSSEC to impacting responses i.e. CD=1.

RFC 6147 Section 5.5 failed to even address CD=1, DO=0.  It also
failed to address that there are both signed and unsigned responses
to DO=1 queries.  It also failed to address daisy chained validators.

> Sorry, i must have missed this one, could you send me a pointer?

http://www.ietf.org/mail-archive/web/behave/current/msg10461.html

> >> -- =

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 25 Jun 2012 10:41:46 -0400

Mark,

> to DO=1 queries.  It also failed to address daisy chained validators.

Two things.  First, with respect, as far as I know you were
participating here when RFC 6147 was called; solicitations for review
also appeared on the DNSEXT mailing list.  It'd have been nice if you
sent text when it was asked for.

But more importantly, since we're talking about deficiencies, what
exactly would you like to have happen when CD=1 and DO=0?  Why do you
think that the signed and unsigned responses matter, given that the
only way the protocol allows you to do DNSSEC with DNS64 is to do the
DNS64 yourself?  And why do you think that it should have addressed
daisy chained validators (in particular)?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 Jun 2012 01:32:42 +1000

> altered.  It's a hack to get around the lack of IPv6 deployment.

At the moment we have every application that accepts raw IP addresses
needing to be upgraded.  Now we can push that down into getaddrinfo()
but that requires upgrading the system libraries.

You also need to upgrade recursive servers to be DNS64 aware as RFC
1034 recursive servers don't pass on CD=1 and DNSSEC recursive
servers return cached CD=0 answers to CD=1 queries.

Even if DNS64 aware recursive servers are installed there is no
sane DNS64 signalling to the DNS64 server.   Additionally if there
are DNSSEC errors there is no way to pass DNS64 information on the
the client when that occurs because DNS64 has stolen the one bit
that is used to turn off DNSSEC and re-purposed it for DNS64.

And while it is a hack I expect it to be around for many years and
I don't want it to slow down DNSSEC deployment.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 Jun 2012 02:36:36 +1000

> sent text when it was asked for.

If I had thought of it I would have mentioned it at the time.
Not synthesising on CD=1, DO=1 is fine. 

RFC 6147 was pushed through in behave.  Lots of things were left
for later.

draft-ietf-behave-nat64-discovery-heuristic has taken CD=1, DO=1
from RFC 6147 and made it just CD=1 which breaks DNSSEC error
handling.

> exactly would you like to have happen when CD=1 and DO=0?

That the unvalidated answers have DNS64 processing applied to them.

> Why do you
> DNS64 yourself?

This working group wanted DNS64 to work through existing servers
to the best of its ability.  You can synthesis responses to DO=1,CD=1
queries provided the responses from the authoritative sources are
not signed and not break validation.

> And why do you think that it should have addressed daisy chained
> validators (in particular)?

---

From: <[email-masked]>
Date: Mon, 25 Jun 2012 19:11:31 +0000

> draft-ietf-behave-nat64-discovery-heuristic has taken CD=1, DO=1 from RFC
> 6147 and made it just CD=1 which breaks DNSSEC error handling.

The draft is quite open for corrections and improvements.

So heuristic-drafti should say to set DO=0 and CD=0 ? (instead of just CD=0 as of now - the draft does not say set CD=1)

DO=1 is problem if the DNS64 is security-oblivious (RFC6147 section 3 step 2),

I mean with DO=0 and CD=0 for well-known name query the DNS64 will perform RFC6147 section 3 step 5, and validate the A record of well-known name but still will synthesize AAAA record for the querying node. Right?

Best regards,

Teemu