Subject: [dns-dir] [[email-masked]: DISCUSS: <draft-ietf-behave-dns64-10.txt>]

From: Andrew Sullivan <[email-masked]>
Date: Thu, 12 Aug 2010 10:44:52 -0400

Hi,

Will someone please review this?

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

Subject: DISCUSS: <draft-ietf-behave-dns64-10.txt>
From: Tim Polk <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Thu, 12 Aug 2010 07:02:47 -0700

Discuss:
I have some concerns regarding the impact on DNSSEC aware clients.  Is expecting these systems to be
translation-aware practical?  I noticed the writeup mentioned the need for the DNS directorate review, but my
review of the dns-dir archives did not turn up a review.  If the DNS directorate has reviewed  this document and
supports publication I will clear.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 18 Aug 2010 07:31:56 -0400

Andrew, Directorate - I've been asked again by the IESG for a Directorate review of this document.  I need a volunteer to read and comment as soon as possible.  Thanks.

- Ralph

On Aug 12, 2010, at 10:44 AM 8/12/10, Andrew Sullivan wrote:

> Date: August 12, 2010 10:02:47 AM EDT
> To: [email-masked]
> _______________________________________________
> dns-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-dir

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 19 Aug 2010 11:21:25 +0200

> Andrew, Directorate - I've been asked again by the IESG for a Directorate review of this document.  I need a volunteer to read and comment as soon as possible.  Thanks.

Here are my comments on the draft:

In the introduction:

>    These mechanisms are expected to play a critical role in the IPv4-
>    IPv6 transition and co-existence.  Due to IPv4 address depletion, it
>    is likely that in the future, many IPv6-only clients will want to
>    connect to IPv4-only servers.  In the typical case, the approach only
>    requires the deployment of IPv6/IPv4 translators that connect an
>    IPv6-only network to an IPv4-only network, along with the deployment
>    of one or more DNS64-enabled name servers.  However, some advanced
>    features require performing the DNS64 function directly in the end-
>    hosts themselves.

I do not like words like "advanced" in texts like these. Why is for example "validation of DNSSEC records in the end host resolver" to be "advanced"?

In the non-normative section, the following important information exists:

>    (NOTE: By IPv6-only hosts we mean hosts running IPv6-only
>    applications, hosts that can only use IPv6, as well as cases where
>    only IPv6 connectivity is available to the client.  By IPv4-only
>    servers we mean servers running IPv4-only applications, servers that
>    can only use IPv4, as well as cases where only IPv4 connectivity is
>    available to the server).

> 3.  Background to DNS64-DNSSEC interaction

As section 2 explicitly is non-normative, is section 3 normative as it is not say that it is not?

>    Here are the possible cases:

I think personally it would be better to, for each of the alternatives, compare the DNS64 impact on resolver and server than list (again) a more comprehensive DNSSEC behaviour list like this. But that is a personal opinion.

>    1.  A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query with
>        the DO bit clear.  In this case, DNSSEC is not a concern, because
>        the querying agent does not understand DNSSEC responses.

Should not it be mentioned that the DNS64, if being a DNS64 resolver, very well can do validation of the response, and act according to local policy? Similar to a case 5, but with local policy?

>    4.  A security-aware and non-validating DNS64 receives a query with
>        the DO bit set and the CD bit set.  In this case, the resolver is

What is "resolver" in this sentence? Looks to me that this is written only for the "DNS64 resolver" cases and not the DNS64 server case?

>        supposed to pass on all the data it gets to the query initiator
>        (see section 3.2.2 of [RFC4035]).  This case will not work with
>        DNS64, unless the validating resolver is prepared to do DNS64
>        itself.  If the DNS64 server modifies the record, the client will

Here one say "DNS64 server" and claim that it "modifies" the record. I do not understand what "modifies" implies at an authoritative server, as for me whatever comes from an authoritative server is the authoritative record. There is nothing that is modified. The records (the AAAA records) can in the case of a DNS64 server very well be signed AAAA records that are very stable and never changed. I.e. pre-populated in the zone and not at all something that is synthesized, and signed!

>        get the data back and try to validate it, and the data will be
>        invalid as far as the client is concerned.
> 
>    5.  A security-aware and validating DNS64 node receives a query with

Here is a new term, DNS64 node. Is that the same as "a DNS64" earlier, i.e. one of the three cases? I think in reality it is one of the "DNS64 resolver" cases one talk about here, and not "DNS64 server".

>        the DO bit clear and CD clear.  In this case, the resolver
>        validates the data.  If it fails, it returns RCODE 2 (Server
>        failure); otherwise, it returns the answer.  This is the ideal
>        case for vDNS64.  The resolver validates the data, and then
>        synthesizes the new record and passes that to the client.  The
>        client, which is presumably not validating (else it should have
>        set DO and CD), cannot tell that DNS64 is involved.
> 
>    6.  A security-aware and validating DNS64 node receives a query with

See comment above about "DNS64 node".

>        the DO bit set and CD clear.  This works like the previous case,
>        except that the resolver should also set the "Authentic Data"
>        (AD) bit on the response.
> 
>    7.  A security-aware and validating DNS64 node receives a query with

See comment above about "DNS64 node".

>        the DO bit set and CD set.  This is effectively the same as the
>        case where a security-aware and non-validating recursive resolver
>        receives a similar query, and the same thing will happen: the
>        downstream validator will mark the data as invalid if DNS64 has
>        performed synthesis.  The node needs to do DNS64 itself, or else
>        communication will fail.

> 4.  Terminology

I presume this is normative section. See comment above.

>    Authoritative server:  A DNS server that can answer authoritatively a
>       given DNS question.

Is "question" the correct term? I ask...

I try to say "Respond authoritatively to a DNS request" but I also know that some people do think it is a good thing to say query/answer when it explicitly is a query we talk about.

>    DNS64:  A logical function that synthesizes DNS resource records (e.g
>       AAAA records containing IPv6 addresses) from DNS resource records
>       actually contained in the DNS (e.g., A records containing IPv4
>       addresses).

Does it have to be synthesized? Also if it is a DNS64 server?

>    DNS64 recursor:  A recursive resolver that provides the DNS64
>       functionality as part of its operation.  This is the same thing as
>       "DNS64 in recursive resolver mode".

Above, in the non-normative section, this was called "DNS64 resolver" as well. Is "DNS64 recursor" a subset of "DNS resolver"? If it is, should not "DNS64 stub" also be defined?

>    DNS64 resolver:  Any resolver (stub resolver or recursive resolver)
>       that provides the DNS64 function.
> 
>    DNS64 server:  Any server providing the DNS64 function.

Authoritative server, or also resolvers?

>    Recursive resolver:  A DNS server that accepts requests from one
>       resolver, and asks another server (of some description) for the
>       answer on behalf of the first resolver.

Is this the same definition as in other documents?

>    Synthetic RR:  A DNS resource record (RR) that is not contained in
>       any zone data file, but has been synthesized from other RRs.  An
>       example is a synthetic AAAA record created from an A record.

Mumble, is "zone data file" a good wording? Should one not talk about "generated on request" instead? Maybe it is the best wording? Although some records might be in a database, and not at all in a file.

>    IPv6/IPv4 translator:  A device that translates IPv6 packets to IPv4
>       packets and vice-versa.  It is only required that the
>       communication initiated from the IPv6 side be supported.

> 5.  DNS64 Normative Specification

Here suddenly the normative part comes...

>    DNS64 is a logical function that synthesizes AAAA records from A
>    records.  The DNS64 function may be implemented in a stub resolver,
>    in a recursive resolver, or in an authoritative name server.

In an authoritative server they do not have to be synthesized.

>    DNS64 also responds to PTR queries involving addresses containing any
>    of the IPv6 prefixes it uses for synthesis of AAAA RRs.

> 5.1.2.  The answer when there is an error
> 
>    If the query results in a response with RCODE other than 0 (No error
>    condition), then there are two possibilities.  A result with RCODE=3
>    (Name Error) is handled according to normal DNS operation (which is
>    normally to return the error to the client).  This stage is still
>    prior to any synthesis having happened, so a response to be returned
>    to the client does not need any special assembly than would usually
>    happen in DNS operation.
> 
>    Any other RCODE is treated as though the RCODE were 0 and the answer
>    section were empty.

Maybe a reference to 5.1.6/5.1.7 (see below) here.

> 5.1.4.  Special exclusion set for AAAA records

This section is confusing, as other 5.1.* sections are alternatives. I.e. "issue an AAAA query, and do the following if this happens". Specifically as 5.1.4 is before 5.1.6 which is another alternative parallel to for example 5.1.2.

I.e. I think it would be better if the document was like this (not critical though):

5. Behaviour

5.1. Queries for AAAA

Issue a query for AAAA, and behave like the following:

5.1.1. A non-empty answer section, where the AAAA is not in the special range

5.1.2. A non-empty answer section, where the AAAA is in the special range

5.1.3. A non-empty answer section, with CNAME or DNAME

5.1.4. An answer with Errcode 3

5.1.5. Other errcodes

I.e. like a flowchart. One of the subsections matches. That makes it easier to know what to do and how to implement.

> 5.1.6.  Data for the answer when performing synthesis
:
> 5.1.7.  Performing the synthesis

5.1.6 and 5.1.7 should really be merged, and the section should be "errcode != 3 and an empty answer section"

>    o  The TTL field is set to the minimum of the TTL of the original A
>       RR and the SOA RR for the queried domain.  (Note that in order to
>       obtain the TTL of the SOA RR, the DNS64 does not need to perform a
>       new query, but it can remember the TTL from the SOA RR in the
>       negative response to the AAAA query.  If the SOA RR was not
>       delivered with the negative response to the AAAA query, then the
>       DNS64 SHOULD use a default value of 600 seconds.

Not really...it should be the smallest of 600 and the TTL for the A, right?

>       It is possible
>       instead to query explicitly for the SOA RR and use the result of
>       that query, but this will increase query load and time to
>       resolution for little additional benefit.)  This is in keeping
>       with the approach used in negative caching ([RFC2308]

Why not just stop after saying it should be the smallest of the TTL of the A and the SOA, and then let the rest be up to the implementor? I am nervous over more "fixed default values" for negative caching. If the SOA was not returned, then the DNS64 have to query for it.

>    o  The RDLENGTH field is set to 16
> 
>    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?

If you look at the specification of DNS64, the DNS64 MUST synthesize an AAAA record according to local policy.

And then reference 5.2 for discussion about policy/algorithms?

>       See Section 5.2 for discussion of the algorithms to be used in
>       effecting the transformation.

> 5.1.8.  Querying in parallel
> 
>    The DNS64 MAY perform the query for the AAAA RR and for the A RR in
>    parallel, in order to minimize the delay.  However, this would result
>    in performing unnecessary A RR queries in the case where no AAAA RR
>    synthesis is required.

Why is this "however" listed in a normative specification?

>    A possible trade-off would be to perform them
>    sequentially but with a very short interval between them, so if we
>    obtain a fast reply, we avoid doing the additional query.  (Note that
>    this discussion is relevant only if the DNS64 function needs to
>    perform external queries to fetch the RR.  If the needed RR
>    information is available locally, as in the case of an authoritative
>    server, the issue is no longer relevant.)

Everything from "However..." can be deleted.

There is nothing in 5.1 (what to do when querying for AAAA records) about the additional or authoritative section.

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

> 5.3.  Handling other Resource Records and the Additional Section
> 
> 5.3.1.  PTR Resource Record
> 
>    If a DNS64 server receives a PTR query for a record in the IP6.ARPA
>    domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the
>    address portion of the QNAME according to the encoding scheme
>    outlined in section 2.5 of [RFC3596], and examine the resulting
>    address to see whether its prefix matches any of the locally-
>    configured Pref64::/n.

...or the default well known prefix (that was not to be configured).

>    There are two alternatives for a DNS64 server

What about DNS64 resolvers that receive PTR queries?

>    2.  The second option is for the DNS64 nameserver to synthesize a
>        CNAME mapping the IP6.ARPA namespace to the corresponding IN-
>        ADDR.ARPA name.

Is this safe? I.e. it is clear no other RR Type than PTR exists with this owner?

See Apple Bonjour for example.

A query for a PTR record might not have owner in the IP6.ARPA, so 5.3.1 is really for PTR records in the IP6.ARPA domain. What about other PTR queries?

I guess the answer is here:

>    If the address prefix does not match any Pref64::/n, then the DNS64
>    server MUST process the query as though it were any other query; i.e.
>    a recursive nameserver MUST attempt to resolve the query as though it
>    were any other (non-A/AAAA) query, and an authoritative server MUST
>    respond authoritatively or with a referral, as appropriate.

No other RR Types need special treatment?

I.e. the flow is weird here as well in the document. Because other RR Types comes as 5.3.3.

> 5.3.2.  Handling the additional section
> 
>    DNS64 synthesis MUST NOT be performed on any records in the
>    additional section of synthesized answers.  The DNS64 MUST pass the
>    additional section unchanged.

The normative part of 5.3.2 should stop here. Remove the rest or move to non-normative section of this document.

> 5.4.  Assembling a synthesized response to a AAAA query

Here we have some text on how to do synthesis again?

Should not this be part of 5.1 that is about AAAA?

> 5.5.  DNSSEC processing: DNS64 in recursive resolver mode
> 
>    We consider the case where a recursive resolver that is performing
>    DNS64 also has a local policy to validate the answers according to
>    the procedures outlined in [RFC4035] Section 5.  We call this general
>    case vDNS64.

Then this is really:

5.5. DNSSEC processing: DNS64 in validating recursive resolver

>    The vDNS64 uses the presence of the DO and CD bits to make some
>    decisions about what the query originator needs, and can react
>    accordingly:
> 
>    1.  If CD is not set and DO is not set, vDNS64 SHOULD perform
>        validation and do synthesis as needed.  See the next item for
>        rules about how to do validation and synthesis.  In this case,
>        however, vDNS64 MUST NOT set the AD bit in any response.
> 
>    2.  If CD is not set and DO is set, then vDNS64 SHOULD perform
>        validation.  Whenever vDNS64 performs validation, it MUST
>        validate the negative answer for AAAA queries before proceeding
>        to query for A records for the same name, in order to be sure
>        that there is not a legitimate AAAA record on the Internet.
>        Failing to observe this step would allow an attacker to use DNS64
>        as a mechanism to circumvent DNSSEC.  If the negative response
>        validates, and the response to the A query validates, then the
>        vDNS64 MAY perform synthesis and SHOULD set the AD bit in the
>        answer to the client.  This is acceptable, because [RFC4035],
>        section 3.2.3 says that the AD bit is set by the name server side
>        of a security-aware recursive name server if and only if it
>        considers all the RRSets in the Answer and Authority sections to
>        be authentic.  In this case, the name server has reason to
>        believe the RRSets are all authentic, so it SHOULD set the AD
>        bit.  If the data does not validate, the vDNS64 MUST respond with
>        RCODE=2 (Server failure).
>        A security-aware end point might take the presence of the AD bit
>        as an indication that the data is valid, and may pass the DNS
>        (and DNSSEC) data to an application.  If the application attempts
>        to validate the synthesized data, of course, the validation will
>        fail.  One could argue therefore that this approach is not
>        desirable, but security aware stub resolvers must not place any
>        reliance on data received from resolvers and validated on their
>        behalf without certain criteria established by [RFC4035], section
>        4.9.3.  An application that wants to perform validation on its
>        own should use the CD bit.

Too much discussion. And (for example) last sentence have "should" in lower case. What does that imply?

Stay with what is normative. Move discussions and non-normative stuff to some other section.

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

(Re)move second paragraph.

> 6.  Deployment notes

Normative?

> 7.  Deployment scenarios and examples
> 

>    In this section, we walk through some sample scenarios that are
>    expected to be common deployment cases.  It should be noted that this
>    is provided for illustrative purposes and this section is not
>    normative.

Good.

> 8.  Security Considerations
> 
>    DNS64 operates in combination with the DNS, and is therefore subject
>    to whatever security considerations are appropriate to the DNS mode
>    in which the DNS64 is operating (i.e. authoritative, recursive, or
>    stub resolver mode).
> 
>    DNS64 has the potential to interfere with the functioning of DNSSEC,
>    because DNS64 modifies DNS answers, and DNSSEC is designed to detect
>    such modification and to treat modified answers as bogus.  See the
>    discussion above in Section 3, Section 5.5, and Section 6.2.

It should be noted what might happen if the translator between IPv4 and IPv6 is not in sync with this box.

Additionally:

There is no text on how to handle the query and additional section of the request/response.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 19 Aug 2010 11:28:22 +0200

5. Behaviour

5.1. Queries for AAAA

5.1.5. Other errcodes

Then this is really:

Normative?

Good.

Additionally:

  Patrik

---

From: Ralph Droms <[email-masked]>
Date: Thu, 19 Aug 2010 07:10:24 -0400

Thanks, Patrik.

- Ralph

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 20 Aug 2010 13:33:30 -0400

Hi Patrik,

Thanks for your detailed review.  The document is now under IESG
control, so I can make some suggestions but I can't actually make any
of these changes yet.  See below inline.

> I do not like words like "advanced" in texts like these. Why is for example "validation of DNSSEC records in the end host resolver" to be "advanced"?

So if we just remove it, that'd be ok?

> >   available to the server).

We could restate this in the definitions section.  Ok?

> As section 2 explicitly is non-normative, is section 3 normative as it is not say that it is not?

You raise this several times.  I think you're right.  I suggest that
we alter the Introduction and state there explicitly which sections
are normative and which not.  Ok?

> I think personally it would be better to, for each of the alternatives, compare the DNS64 impact on resolver and server than list (again) a more comprehensive DNSSEC behaviour list like this. But t…

Well, this was intended to be explanatory material for someone who was
implementing this but not familiar with DNSSEC.  Otherwise I was
nervous that the reasoning behind not synthesizing when CD=1 wouldn't
be clear.

> Should not it be mentioned that the DNS64, if being a DNS64 resolver, very well can do validation of the response, and act according to local policy? Similar to a case 5, but with local policy?

We can if you like, sure.

> What is "resolver" in this sentence? Looks to me that this is written only for the "DNS64 resolver" cases and not the DNS64 server case?

Ugh.  It does look like we have terminological issues here.  I thought
I'd weeded this out in a previous pass, but I think I did it only in
the normative sections, perhaps.  Yuck.

It is indeed supposed to include the DNS64 server case.  For reasons
that are not clear to me, some have insisted that a DNS authoritative
server that is doing DNS64 could do so automatically, without anyone
actually provisioning the AAAA records with the Pref::/64.  I don't
personally get this use case at all, but people have insisted on it so
it's possible.

> Here one say "DNS64 server" and claim that it "modifies" the record. I do not understand what "modifies" implies at an authoritative server, as for me whatever comes from an authoritative server is…

Remember that strictly speaking the DNS64 is a logical function.  So
the name server function in the DNS64 (which is technically speaking
never exposed to anyone) only provides the A record, and the DNS64
function "modifies" it.  I concede that it is a little uncomfortable
to talk like this, but it preserves the logical distinction between an
actual DNS64 server, and a plain DNS server that happens to have in it
AAAA records using the Pref::/64.  Does that make sense?

> Here is a new term, DNS64 node. Is that the same as "a DNS64" earlier, i.e. one of the three cases? I think in reality it is one of the "DNS64 resolver" cases one talk about here, and not "DNS64 se…

Yeah, it's a resolver.  (A DNS64 authority server never validates.)
We'll have to go through and fix up the terminology to be consistent
with the terminology section.
 
> I try to say "Respond authoritatively to a DNS request" but I also know that some people do think it is a good thing to say query/answer when it explicitly is a query we talk about.

If only the DNS geeks had a consistent set of terms, eh?  Oh, wait.
I'm also ok with request.

> Does it have to be synthesized? Also if it is a DNS64 server?

Yes.

> Above, in the non-normative section, this was called "DNS64 resolver" as well. Is "DNS64 recursor" a subset of "DNS resolver"? If it is, should not "DNS64 stub" also be defined?

I don't think we have anywhere in the document where we really needed
a DNS64 stub definition, so I removed it.  But I'm happy to add it
back if you think it helps.  Dave Thaler in particular was keen that
we not define additional terms we don't strictly need.

> Authoritative server, or also resolvers?

Any server.  So it could be a recursive resolver, yes.  This means
that such a beast would be both a DNS64 server and a DNS64 resolver.
That's consistent with the dual name of recursive servers/recursive
resolvers in plain DNS, though, no?

> Is this the same definition as in other documents?

Ha!  If only 1034 actually defined this.  RFC 4033 has this, which is
as close to a definition as we have:

   Security-Aware Recursive Name Server: An entity that acts in both the
      security-aware name server and security-aware resolver roles.  A
      more cumbersome but equivalent phrase would be "a security-aware
      name server that offers recursive service".

We could follow the same convention, and define recursive resolver as
a system that acts in both name server and resolver modes, and then
we'd need to define name server and resolver.  Name server is kind of
defined in 1034 Sec 2.4., as is resolver.  The text in 1034 is
sufficiently poor that many people seem to forget that recursive name
servers can end up cached (sometimes without people knowing it), and I
was trying to draw that information out.  But maybe this is a poor
place to do so.

> Mumble, is "zone data file" a good wording? Should one not talk about "generated on request" instead? Maybe it is the best wording? Although some records might be in a database, and not at all in a…

Yeah, I originally had just "any zone data", and someone insisted that
wasn't good enough because the synthetic RR could be in a cache
somewhere.  (For the same reason, "generated on request" won't exactly
work either.)  What about this:

    Synthetic RR: A DNS resource record (RR) that is not contained in
      the authoritative servers' zone data, but which is instead
      sythesized from other RRs in the same zone.  An example is a
      synthetic AAAA record created from an A record.

?

> In an authoritative server they do not have to be synthesized.

In that case, it's not DNS64.  We actually suggest later in the
document that you should not use DNS64 on the authoritative server,
and that you should instead populate the real zone with the relevant
records if you're planning to use NAT64.  Is this not clear?

> Maybe a reference to 5.1.6/5.1.7 (see below) here.

Ok.

> I.e. like a flowchart. One of the subsections matches. That makes it easier to know what to do and how to implement.

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.

> 5.1.6 and 5.1.7 should really be merged, and the section should be "errcode != 3 and an empty answer section"

Why?  These are strictly speaking distinct steps.  After all, if you
wanted to populate your authoritative zone with DNS data that would
cause a NAT64 to be used, you'd want the output from 5.1.6 but not
5.1.7, right?

> Not really...it should be the smallest of 600 and the TTL for the A, right?

Oh, good catch.

> Why not just stop after saying it should be the smallest of the TTL of the A and the SOA, and then let the rest be up to the implementor? I am nervous over more "fixed default values" for negative…

I felt the same way, but the WG (and Mark Andrews in particular) was
quite sure we needed a default.

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

> Why is this "however" listed in a normative specification?

Well, I think the entire option for querying in parallel ought not to
be allowed, on DNS performance grounds, but the web people keep
insisting that they need this to achieve acceptable speed.  I'm
willing to tear it out, but I'd actually like to recommend against
such parallel querying.

> There is nothing in 5.1 (what to do when querying for AAAA records) about the additional or authoritative section.

No, because that's dealt with in 5.3.  Why should it be in 5.1?

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

> ...or the default well known prefix (that was not to be configured).

Good catch, thanks.

> What about DNS64 resolvers that receive PTR queries?

Hrm.  Yes, I guess that needs to be "There are two alternatives for DNS64 to. . ."
 
> See Apple Bonjour for example.

I agree.  This option is only there because Mark Andrews insisted it
be.  I think the whole thing is a bad idea: you should follow option
1, which is the only safe response IMO.  But the WG seemed to want
option 2 as well.

> >   respond authoritatively or with a referral, as appropriate.

Yes.

> No other RR Types need special treatment?

No other RR types need treatment like PTRs do. 

> I.e. the flow is weird here as well in the document. Because other RR Types comes as 5.3.3.

Do you want us to swap that with 5.3.2?

> The normative part of 5.3.2 should stop here. Remove the rest or move to non-normative section of this document.

Ok.

> Here we have some text on how to do synthesis again?

No, this is not how to do synthesis.  This is how to assemble the
response (i.e. the thing you're going to ship back).  The _synthesis_,
strictly speaking, was just the creation of the AAAA record from the
A, and that goes into an answer section.  That answer section is now
one of the pieces assembled to make a DNS response packet.

> 5.5. DNSSEC processing: DNS64 in validating recursive resolver

Oh, good catch.  Thanks.

> Too much discussion. And (for example) last sentence have "should" in lower case. What does that imply?

It implies that different people have read DNSSECbis and come to
different conclusions about whether the AD bit means anything.  Rob
Austein and some of the other document editors, as well as several
other people, are sure that the _only_ way to trust the answer is to
set CD and check yourself.  But one of the largest vendors out there
seems to have decided that the AD bit is significant and useful.  This
text was the compromise we were able to come up with.

I think the "too much discussion" is a suggestion that the second
paragraph be moved to a non-normative section?  (I'm just trying to be
sure what you thought was discussion there.)
 
> (Re)move second paragraph.

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

> It should be noted what might happen if the translator between IPv4 and IPv6 is not in sync with this box.

You mean, if the DNS64 has the wrong Pref::/64 configured, like?

> There is no text on how to handle the query and additional section of the request/response.

Sure there is.  Section 5.3.2 explicitly says that you may not muck
with the additional section, and section 5.4 says you copy the
question from the original query.  The additional and authority
sections are similarly copied from the real DNS answer.  Or am I
missing something you'd like to see?

Thanks for the review!

A

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

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 23 Aug 2010 16:43:32 +0200

[copying also Suzanne that had some questions]

> of these changes yet.  See below inline.

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.

> So if we just remove it, that'd be ok?

Yes. I.e. do not do any judgement. And specifically for DNSSEC, that is something people should not be scared away from, which they might be with text like this. "Oh no, advanced stuff, costs $$$."

> We could restate this in the definitions section.  Ok?

I think that would be good.

> are normative and which not.  Ok?

What I think you should do is one of two things:

1. In the introduction mention what is normative and not, and then remove that text from the various sections.

2. Add in each section a word, text etc on the status of that section. But do it the same way in every section.

I think (1) is the best.

Be consistent.

> nervous that the reasoning behind not synthesizing when CD=1 wouldn't

Ok. Fair.

> We can if you like, sure.

Yes please. The way I read the text above it says that for the resolver "DNSSEC is not a concern", which might be read as if the resolver is not to do validation (at all). I can very well envision cases where A buys a service from B where B runs the DNS64 service (and Nat64) and requires validation in the resolver. If B now does NOT do validation, I do not want B to reference this document and say "as you did send DO bit clear, I ignore DNSSEC completely -- see RFC".

> personally get this use case at all, but people have insisted on it so

When I have read this document (this version and older versions) I have also been confused. I think the DNS64 server case is so special it just does not make any sense. And, I feel the authoritative server then by definition is authoritative for the records regardless of whether they are "configured" or "synthesized on the fly" (whats the difference?).

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.

> function "modifies" it.

Yes but...

> I concede that it is a little uncomfortable

Yes, it does make sense. I still do not like it ;-)

> with the terminology section.

Should not be so hard I think. Just make up your mind. And ensure you for every case talk about every case.

> I'm also ok with request.

Just make up your mind, and ensure you do not get stuck if DNS64 is used for dynamic updates... Maybe you should just be clear if you talk about all query types or not? Maybe you are...I do not have the document in front of me now.

I have, honestly, not really been thinking of what happens with DNS64 and dynamic updates and other non-queries.

>> Does it have to be synthesized? Also if it is a DNS64 server?

Ok. I understand that is how it is designed. Mumble...

> we not define additional terms we don't strictly need.

No, I do not think we should have more terms.

My point was that it was called "DNS64 resolver" and here you have "DNS64 recursor". Below you talk about "stub resolver" and "recursive resolver", above "recursor".

> resolvers in plain DNS, though, no?

Yes. I do think you try to define things like this:

DNS64 recursive resolver
DNS64 stub resolver
DNS64 authoritative server
DNS64 resolver: DNS recursive resolver + DNS64 stub resolver
DNS64 server: DNS recursive resolver + DNS64 authoritative server

I.e. ensure you absolutely do have the sets clearly defined, without any grammar changes in English. Not all readers do understand what "recursor" is. Is that a new term?

> was trying to draw that information out.  But maybe this is a poor

Mumble...we need a DNS terminology document. Although, we would never agree on anything in that document...

>      synthetic AAAA record created from an A record.

Yes, much better. Thanks.

That include all RR that are generated. Not only the ones that are generated on request.

> records if you're planning to use NAT64.  Is this not clear?

It is. Comments to some degree end up like this if one read detailed review in a one-pass-process.

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

1. DNS64 server that receives a query for AAAA
1.1. Issue query for AAAA
1.1.1. If RR Code is zero
1.1.2. If RR Code is non-zero
1.2. Issue query for A
1.2.1. If RR Code is zero
1.2.2. If RR Code is non-zero
2. DNS64 server that receives a query for PTR
3. DNS64 server that receives a query for other RR Types
4. Synthezising responses

Etc...

Then one can do section 1 and 2 and 3, follow step by step, and then get references to section 4, 5 etc as subroutines. As it is now the flowchart is sort of mixed with "think of this if the errcode is..." or "this is how you synthesizes a record".

Next version of the document.

> cause a NAT64 to be used, you'd want the output from 5.1.6 but not

Explanation to my view: It might be confusing for the reader to understand that it should do more than one subsection of 5.1 but still not all of them. I.e. the way I like documents, subsections should either all of them be used, or only one, and in the latter case, the header (or first paragraph) should clearly have a requirement or test that should evaluate to TRUE if the section is to be used.

But ok... I see your way of looking at it.

>> Not really...it should be the smallest of 600 and the TTL for the A, right?

Yeah! One good catch! :-D

> quite sure we needed a default.

Hmm...ok.

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

> willing to tear it out, but I'd actually like to recommend against

No, ok, let it be there.

I am just *personally* very tired of long RFC with lots of text (that you give to programmers and they do not get it).

This document is good in that it have normative and non-normative stuff, and the normative stuff is in reality very small. But one need lots of explanations. Right?

FWIW, I have myself inside Cisco written a DNS64 thing that is shorter regarding "what to do", but have lots of explanations...

Some people that implement stuff does not have to know what to do, and if they really want to, they can read the explanatory stuff.

But, that is also one of my windmills in the IETF that I am fighting.

Shorter documents! Just write what is needed in the normative section. When you can not remove a single word more, you are done.

That said, long explanations, examples and what not.

> No, because that's dealt with in 5.3.  Why should it be in 5.1?

Ok, sorry, confusion...

Let me exaggerate a bit, and show how confusing I find it. I think 5 should be split in 5 and a new section 6. The new section 6 should include the subsections of 5 that today is only "support" to the other subsections. Then titles of the subsections of 5 should be such that one for each case should read one and only one of the sections.

We have:

> 5.1 Resolving AAAA queries and the answer section

Is this for only AAAA queries, or for AAAA queries and answer section for query for any RR Type?

> 5.2. Generation of the IPv6 representations of IPv4 addresses

Is this for AAAA queries, or all queries? We have already walked through how to handle the answer section in 5.1?

> 5.3. Handling other Resource Records and the Additional Section

What about the Query and Authoritative section? Is this Additional Section for all RR Types, or just non-AAAA RR?

> 5.4. Assembling a synthesized response to a AAAA query

Is this a subsection of? When should I read this? AAAA query, but that was 5.1, or?

> 5.5.  DNSSEC processing: DNS64 in recursive resolver mode

Is this not DNS64 resolver mode in general?

>> Should not queries for other RR Types be in 5.2, and this be part of the "synthesizing responses" above, or some other section?

Because that is the only case when this does happen?

>> ...or the default well known prefix (that was not to be configured).

:-)

> Hrm.  Yes, I guess that needs to be "There are two alternatives for DNS64 to. . ."

Thanks.

> 1, which is the only safe response IMO.  But the WG seemed to want

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.

Good.

Good.

> Do you want us to swap that with 5.3.2?

No. See above. I think I talk about a larger restructuring in the next version of the document.

>> The normative part of 5.3.2 should stop here. Remove the rest or move to non-normative section of this document.

Once again. See above. Do not do the change.

> one of the pieces assembled to make a DNS response packet.

Ok...

>> 5.5. DNSSEC processing: DNS64 in validating recursive resolver

:-)

> different conclusions about whether the AD bit means anything.

Hmm...

> Rob

Ok. Fair.

> sure what you thought was discussion there.)

Or just let it be.

But you are right in general.

>> (Re)move second paragraph.

Oh, I see...now... Hmm...leave it.

> But you agree with this approach?  This point is in fact exactly

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.

Yes.

> missing something you'd like to see?

No, I was missing it. See above.

> Thanks for the review!

Thanks for the pushing...

   paf

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 23 Aug 2010 21:40:22 -0400

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.

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

> I.e. have the sections like a flowchart.

Yep, I get it.  But you want to leave this for dns64-bis, correct?

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

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

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

> 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
[email-masked]
Shinkuro, Inc.

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 24 Aug 2010 04:00:15 +0200

> dns64-bis document as soon as practical if people think that would be

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

> what to do with the next version of this draft.  Right?

Absolutely!

DNS64-bis

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

> with when hoping to do that job ;-)

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

Yes.

> I'm willing to ask on the list why this isn't MUST, and to recommend

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.

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

> representation and the synthesis, since one is just a step in the

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

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

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

Ok.

> But the DISCUSS on this document was

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.

> this means I'm going to hassle you about the -bis document, right?

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

   Patrik