Subject: [dnsext] DNS64 and SRV records

From: Andrew Sullivan <[email-masked]>
Date: Wed, 10 Feb 2010 15:33:14 -0500

Dear colleagues,

I'm writing not in my capacity as Chair, but as one of the editors of
the BEHAVE DNS64 draft.  We have received an interesting observation
from Rick van Rein about the draft.  This message is similar to a
question I posted on the behave list, so if you saw it there feel free
to respond there instead.

The current draft says that DNS64 MUST NOT alter the Additional
section when assembling the answer.

Obviously, for some records we habitually include A and AAAA records
in the Additional section in order to allow a querying client to
proceed without querying again for the answer.  The particular case
that troubles Rick van Rein is the case of SRV records (but MX records
and similar might have this problem as well).

RFC 2782 (which specifies the SRV RR) encourages servers to include
records in the additional section in order that targets of SRV records
can be resolved without additional queries.  It notes, however, that
clients cannot depend on there being data in the Additional section,
because the TTLs on (say) an SRV record and an A record to match the
target could be different; so an SRV might be satisfied from cache
without a corresponding A for the additional.

Now, suppose a client gets an SRV record with data in the additional
containing only A records.  Suppose also that the client has only IPv6
connectivity, so the A records do the client no good.

My reading is that the client _should_ go and query for the AAAA of
the target in the SRV record, because there's no data in the
additional section that will be useful to the client.  If the client
does this, it should end up with a synthetic AAAA as usual, and
everything will work.

The question is whether we know that there are clients that just won't
query for the AAAA.  If we do know of such clients, then the approach
currently in the draft won't work.  In that case, I propose changing
the draft to require the additional section to be truncated whenever
it does not contain at least one AAAA record.

Thoughts?

A

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

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 10 Feb 2010 22:34:11 +0100

> it does not contain at least one AAAA record.

My view is that the only reasonable thing is to allow implementations to also either remove the additional information, or synthesize also A records in the Additional Section using the same algorithm used for the Answer section.

Sorry for not mentioning this earlier, but I dived into DNS64 just some time ago...

I.e. I would support the ability for altering the data in the Additional section and still be compliant.

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 10 Feb 2010 17:47:48 -0500

On Wed, Feb 10, 2010 at 10:34:11PM +0100, Patrik Fältström wrote:
> 
> My view is that the only reasonable thing is to allow
> implementations to also either remove the additional information, or
> synthesize also A records in the Additional Section using the same
> algorithm used for the Answer section.

Well, we used to have the option of synthesizing AAAA records for the
additional section, and it became obvious that that wouldn't work.
For if you have a synthetic AAAA that corresponds to the address of an
NS record, then you will get the AAAA back and traverse the NAT64 to
reach that NS, which you will then query.  Your DNS64-oblivious
query source asks a DNS64-oblivious name server for an answer, and you
don't get one, because there are no real AAAA records in the zone for
the resource you want.

This is why we changed the draft to say "leave the additional alone".
Mark Andrews made this point very firmly (and, in my estimation,
correctly).  

Therefore, I think the only options are "leave the data alone" and
"truncate the Additional".  I think that synthesizing in the
Additional is dangerous.

A

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

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 11 Feb 2010 07:53:04 +0100

> additional section, and it became obvious that that wouldn't work.

Hmm...

> don't get one, because there are no real AAAA records in the zone for

Can you be more specific. Are you talking about the following:

A query is sent with RD=0 and then for www.example.com, IN, AAAA, and the result that comes back to the DNS64 box is the following:

Query: www.example.com, IN, AAAA
Answer: <empty>
Authority: example.com. IN NS ns.example.com.
Additional: ns.example.com. IN A 1.2.3.4

The DNS64 box then have three alternatives:

1. Remove the additional section

Query: www.example.com, IN, AAAA
Answer: <empty>
Authority: example.com. IN NS ns.example.com.
Additional: <empty>

2. Keep the additional data as it is:

Query: www.example.com, IN, AAAA
Answer: <empty>
Authority: example.com. IN NS ns.example.com.
Additional: ns.example.com. IN A 1.2.3.4

3. Synthesize an AAAA in the additional section:

Query: www.example.com, IN, AAAA
Answer: <empty>
Authority: example.com. IN NS ns.example.com.
Additional: ns.example.com. IN AAAA dead:beef::1234

If we look at version 3, the next thing the client might do is to send a DNS packet directly to that IPv6 address that is synthesized. It will be possible to send the query as the NAT64 box will detect the synthesized address in the destination, and NAT it to the corresponding IPv4 address.

But, I think you talk about the problem with the client sending the query www.example.com. IN AAAA to that authoritative server as there might not be an AAAA record in the zone for www.example.com?

> Mark Andrews made this point very firmly (and, in my estimation,

Hmm...ok...I think I start to get this now. :-)

   Patrik

---

From: [email-masked]
Date: Thu, 11 Feb 2010 09:41:36 +0000

> without a corresponding A for the additional.

	this presumes (correctly) that the DNS has no information
	about the available transports at the target.

> connectivity, so the A records do the client no good.

	or ... contains only AAAA records and the client only has
	IPv4 connectivity...

> does this, it should end up with a synthetic AAAA as usual, and

	well - if there is no data in the answer or additional section
	that is useful to the client, then the client has two choices:
	a) use what data they have
	b) get more data

	the DNS has no way to determine IP transport availablity, regardless
	off family.

> it does not contain at least one AAAA record.

	I suspect your proposed changes are worse than doing requeries.
	and yes - there are some client code that won't re-query.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Feb 2010 08:53:20 -0500

> Authority: example.com. IN NS ns.example.com.

Not quite: the DNS64 box when assembling this answer would already
have synthesized the AAAA for the answer section and put that in
place.  So there's a AAAA answer that includes the Pref::64/n and the
corresponding IPv4 address.  Other than that, yes.

> Additional: ns.example.com. IN A 1.2.3.4

See above, but yes.

> Additional: ns.example.com. IN AAAA dead:beef::1234

Modulo the answer thing above, yes.  This is the one we currently forbid.

> If we look at version 3, the next thing the client might do is to
> send a DNS packet directly to that IPv6 address that is
> synthesized. It will be possible to send the query as the NAT64 box
> will detect the synthesized address in the destination, and NAT it
> to the corresponding IPv4 address.

Right, that will work, assuming the only route out is the NAT64 box
(or assuming it takes that route.  There's the other problem about
dual-homed v6-only hosts, but we already say "don't do that".  As I've
said before, anyone who thinks this DNS64/NAT64 approach is anything
other than a mostly-works kludge is kidding themselves).  But …

> But, I think you talk about the problem with the client sending the
> query www.example.com. IN AAAA to that authoritative server as there
> might not be an AAAA record in the zone for www.example.com?

…exactly.  And since _ex hypothesi_ the querying host doesn't know
about NAT64 and the DNS authority server doesn't know about the NAT64,
this will break anyway.  So we might as well have it break as early as possible.

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

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Feb 2010 08:57:26 -0500

> 	and yes - there are some client code that won't re-query.

If we just truncate the Additional section, what additional harm can
come?  A client that knows to look up when it has no additional, but
falls over when it has additional it can't use, will look up.  A
client that just doesn't know what to when it doesn't have useful
additional is no worse off.  And everyone else is no worse off,
because under the scenario we're imagining, there's no additional
that's useful (so this collapses to the previous case).  Therefore, we
should just not return any additional to the client if and only if we
have done synthesis.  (If there's available AAAA in the first place,
no synthesis is supposed to happen, although for some reason some
people insist on including the "always synthesise" policy as allowed.
I am betting that will be broken in practice and that nobody will be
able really to use it.)

A

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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 12 Feb 2010 08:03:29 +1100

One doesn't synthesis the additional section as you don't know if
there are real AAAA records or not and we don't do extra work to
find out.

In a non DNS64 case you wouldn't go and make AAAA queries so you
shouldn't in the DNS64 case.  If the client wants AAAA records it
will ask for them and you can do the AAAA and A queries then as
required.  Additional processing is "fill in with what you have".

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

---

From: Doug Barton <[email-masked]>
Date: Thu, 11 Feb 2010 17:31:11 -0800

On 02/11/10 05:57, Andrew Sullivan wrote:
> come?

...

> that's useful

Assuming a situation where there is no IPv4 connectivity on the network 
that is served by the DNS64 resolver stripping A records from ADDITIONAL 
seems reasonable. Otherwise I agree with Mark, ADDITIONAL should not be 
tampered with.

As for the concern regarding clients that won't re-query for AAAAs, my 
feeling is that people who deploy IPv6-only networks will be doing so 
with the knowledge that there will be tradeoffs, and that problems like 
this don't have solutions in the DNS space.

Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Feb 2010 11:08:59 -0500

On Thu, Feb 11, 2010 at 05:31:11PM -0800, Doug Barton wrote:
> seems reasonable. 

You can't assume that.  There is no way to be sure that the
NAT64-using client does not also have a native v4 connection.  That
said, the plain fact is that the NAT64 is likely to get used anyway
under that condiiton, and anyone who sets things up this way is just
mistaken (and the A in the additional probably wouldn't help).  Most
resolvers query for AAAA first, so that's what they'll get.

> this don't have solutions in the DNS space.

If only.  If they knew that, we wouldn't be attempting to fix NAT-PT.

A

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