Re: [dns-dir] [[e-mail]: DISCUSS: <draft-ietf-behave-dns64-10.txt>]

[Patrik Fältström <[e-mail]>]

On 24 aug 2010, at 03.40, Andrew Sullivan wrote:

> Well, there are two views:
> 
>    1.  We should not publish until the spec is totally ready.
> 
>    2.  We should publish a reasonably complete spec at the minimal
>    standards-track level and then do revisions to advance it.
> 
> Given the standards track rules as they are, I'm in favour of (2).  It
> would appear that the IETF Chair and a number of supporters are not,
> so maybe we should think twice.  Anyway, I'll commit now to starting a
> dns64-bis document as soon as practical if people think that would be
> desirable.

I agree with you. If we try to make a document "better", then what is happening is that it takes time. People "fall asleep", and we do not get good review. So the quality of the document do not always increase...

>> Unfortunately as the document now talk about DNS64 server it just has to. Otherwise it must go back to the wg.
> 
> I think what you're saying here (and in some other remarks about "next
> version" is what to do when dns64-bis is being prepared, and _not_
> what to do with the next version of this draft.  Right?

Absolutely!

DNS64-bis

>> I have, honestly, not really been thinking of what happens with DNS64 and dynamic updates and other non-queries.
> 
> Do you think an explicit treatment of what happens with dynamic update
> is needed?  I think I understand it, but I'll bet a pretty good lunch
> it hasn't been pressed very hard.

DNS64-bis

I just want someone to think about _all_ DNS requests that we have. Not only normal queries.

Thinking of how to handle dynamic updates and DNS64 makes my head hurt though.

>> Mumble...we need a DNS terminology document. Although, we would never agree on anything in that document...
> 
> I merely note without comment the tremendous success the DNSEXT WG met
> with when hoping to do that job ;-)

Like in the UN, everything is an outstanding success! ;-)

>>> Ok.  To do this, I think, we'd need to take it back to the WG and
>>> through LC again, no?  That's a pretty significant change.
>> 
>> Do not do the change.
>> 
>> But you do understand my view?
>> 
>> I.e. have the sections like a flowchart.
> 
> Yep, I get it.  But you want to leave this for dns64-bis, correct?

Yes.

>>>>> o  The RDATA field is set to the IPv6 representation of the IPv4
>>>>>    address from the RDATA field of the A record.  The DNS64 SHOULD
>>>>>    check each A RR against configured IPv4 address ranges and select
>>>>>    the corresponding IPv6 prefix to use in synthesizing the AAAA RR.
>>>> 
>>>> Why only a SHOULD? And, is this not an implementation issue?
>>> 
>>> Someone wanted to be able to short-circuit this check if there's only
>>> one address range configured.
>> 
>> Well, then it is really checking every IPv4 A still, right? The check always returns the one same IPv6 prefix.
>> 
>> Mumble. I am really nervous there will not be a test here in some implementations. I.e. that someone will screw up. Ok, I do know the meaning of SHOULD, but still...
> 
> I'm willing to ask on the list why this isn't MUST, and to recommend
> that it be.  Ok?

If you do not think that is "too much" for the wg, please do.

I do not want to reopen the document. But I really would like to have this change.

>> I am just *personally* very tired of long RFC with lots of text (that you give to programmers and they do not get it).
> 
> Yes.  I think what might help is to add a DISCUSSION heading for these
> bits of explanatory fluff, and then call out in the introduction
> (explicitly) that the bits under DISCUSSION are never normative, but
> are intended to explain the motivation.  Thoughts?

Hmm....I think to some degree this document is already much better than lots of others, simply because it does mark what is normative and not. Just because we happen to have those markings, do I ask for even more detailed markings? Maybe. Possibly.

Just skip these things.

We need this document. And fix the few things that are needed to be changed.

>>>>> 5.2.  Generation of the IPv6 representations of IPv4 addresses
>>>> 
>>>> Should not queries for other RR Types be in 5.2, and this be part of the "synthesizing responses" above, or some other section?
>>> 
>>> Why?
>> 
>> Because that is the only case when this does happen?
> 
> But there's a logical difference between the generation of the v6
> representation and the synthesis, since one is just a step in the
> other, I think?

I understand that view now. I have not really separated the synthesis (creation of the records) and building of the actual response (that might include some synthesized records).

So my comments on these things just went *poof*.

>> But this is wrong as the PTR might not have a corresponding IN-ADDR.ARPA name. In that case you absolutely must say "....to the corresponding name". Or "...to the corresponding name in IN-ADDR.ARPA if it exists".
>> 
>> Lets say we have:
>> 
>> www.example.com. IN PTR foo.bar.example.
>> 
>> Now we query for that....I think the text must absolutely be so that the PTR in question is not invalid.
> 
> Ok, I propose that this be altered so that the synthetic CNAME is
> returned only if there is existing RDATA at the PTR (i.e. what you
> said).  I'll check on the behave list to make sure there's no
> objection, but if there is I can't understand what it'd be.

What is needed to check for is whether the PTR is in IN-ADDR.ARPA. Not only if there is any RDATA at the PTR. Or? If so, some magic has to happen. If the PTR is not in IN-ADDR.ARPA, the stuff can be managed like "every other RR Type", right?

Well, you seem to get my point.

>>>>> 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.
> 
>>> But you agree with this approach?  This point is in fact exactly
>>> what the DISCUSS on this draft was about: the document assumes that a
>>> validating resolver knows how to do DNS64 or else DNS64 just doesn't
>>> work for that host.  You don't think that's impractical?  (That was
>>> the question.)
>> 
>> Let me think...you talk about the case when a resolver that has only IPv6 transport want to use a DNS64 service somewhere where the DNS64 is NOT doing the validation? But, there will be RR synthesized by the DNS64 box, so that must do the validation, right?
>> 
>> This actually do work if you have a validating resolver on the inside of a DNS64 box and that resolver is doing DNS64 by itself. Which I think should be possible.
>> 
>> So you can have one DNS64 be validating and use another DNS64 as a forwarder.
>> 
>> Which I think makes sense.
> 
> Well, something like that, yes.  But the main thing is this: an
> existing, shipping-today, validating resolver that is DNS64 oblivious
> and that goes into  a DNS64-dependent network (i.e. one with a NAT64)
> will simply break.

Oh boy. Yes, I get the point now.

> I think that is better than the alternative (i.e. "screw with DNSSEC so
> that the NAT64 works anyway"), and anyway I have no idea how to make
> that alternative work.

Ok.

> But the DISCUSS on this document was
> originally that it is unrealistic to accept that.  I think it's early
> enough days in end-point validation that the only people we'll
> inconvenience are the early-upgrading DNSSEC nerds, but I could be
> wrong.  What do you (or any of the rest of the DNS directorate, or
> even anyone else who's listening!) think?

I would say the best solution is:

When a validating full service resolver is moved behind a Nat64/DNS64 box, and only get IPv6 transport, then that box to be able to do validation MUST be configured to do the DNS64 functionality itself. The DNS64 spec MUST work accordingly, i.e. one should NOT have a hierarchy of DNS64 boxes, but only one.

The existing DNS64 box, that might be set as a forwarder for the newly placed box on the "inside" of the NAT64/DNS64, should not have to be reconfigured, but instead be transparent regarding DNS64 if a validating resolver is sending queries to it.

If a validating resolver is set on the inside of a DNS64 box and the validating resolver is NOT supporting DNS64 with prefix etc according to the NAT64 in the network it exists, then it will not function properly.

> Again, thanks lots for the detailed review.  You know, however, that
> this means I'm going to hassle you about the -bis document, right?
> :-D

Yeah, I was nervous about that... ;-)

   Patrik