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

[Andrew Sullivan <[e-mail]>]

Hi,

On Mon, Aug 23, 2010 at 04:43:32PM +0200, Patrik Fältström wrote:
> 
> I of course do understand that we at this late stage rather want to
> have the document released than pushing it back to the WG. I have
> tried to explain below what things I do though absolutely would like
> to have clarified and not. And yes, you and I seems to be on the
> same wavelength here.
> 

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've removed in what follows places where it's clear to me what to do.

> > On Thu, Aug 19, 2010 at 11:28:22AM +0200, Patrik Fältström wrote:

> 
> I.e. the whole document could be so extremely more simple of the DNS64 server case was indeed a special case explained just in a separate section where it is explained that "if the DNS64 recursive resolver is indeed authoritative for some zone(s) it is getting queries for, it should ...".
> 
> And then have the document ONLY talk about the two resolver cases.
> 
> But I do see your issue with restructuring "too much".
> 
> 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?
 
> 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.

> 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 ;-)

> > 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?

> >>>  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?

> 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?

> >>> 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?

> 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.

> >>>  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.  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.  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?

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

A

-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.