Re: [v6ops] draft-byrne-v6ops-dnssecaaaa

[Lee Howard <[e-mail]>]

I think this document should be BCP, not Informational.

Section 2

s/mechanism/mechanisms in the first instance in the first sentence.

How is HEv2 a transition mechanism?

I'd rephrase to say, "DNS64 is a key part of widely deployed IPv6-only 
transition mechanisms, including several large 464xlat [RFC6877] 
deployments, and all NAT64 deployments." I think that clarifies that 
we're talking about specific deployments here.

Since the discussion of DNSSEC in RFC6147 is so brief, I think it's 
worth discussing here, so the explanation of why it is an insufficient 
workaround is sufficient. I'd like to replace the last sentence of 
section 2 with a new paragraph:

RFC6147 ("DNSSEC") outlines how validation may occur in the presence of 
DNSSEC:

An existing DNSSEC validator (i.e., one that is unaware of DNS64)

    might reject all the data that comes from DNS64 as having been
    tampered with (even if it did not set CD when querying).  If it is
    necessary to have validation behind the DNS64, then the validator
    must know how to perform the DNS64 function itself.  Alternatively,
    the validating host may establish a trusted connection with a DNS64,
    and allow the DNS64 recursive resolver to do all validation on its
    behalf. [RFC6147 - DNS64]


However, the domain administrator has no control over the client doing 
the validating, and clients (or their validating resolvers) cannot be 
expected to know about the presence of DNS64 a priori. Clients who might 
trust an authoritative name server for some content may not be as 
trusting of their carrier's DNS64 server.

Section 3

s/to changes/to change
s/not recommend/not recommended
To soften the blow, I'd suggest adding a sentence, after "in tandem."  
"The IPv6 deployment may be as light weight as a translator, such as 
SIIT-DC [RFC7755]."


There's more I'd add to the document, and it's the "So what?"

For instance, in Security Considerations:
"If clients trust RRs that fail validation (because they were invented 
by an DNS64 server), there is increased risk that they will trust other 
RRs that fail validation. Further, a compromised or hostile 
man-in-the-middle DNS64 server will be undetected, despite DNSSEC signing."
In Section 2, I admit I don't know what a client actually sees, if 
anything. Do browsers or other applications warn that a name failed 
validation? I'm sure I can test it tomorrow. I don't know how to inform 
users or their content providers that "This record cannot be guaranteed 
to be accurate, since it failed DNS Security validation. It appears to 
be a synthetic record, since the name only has an IPv4 record."


Even though my comments are longer than the draft, I like this effort, 
and wish I had initiated it.

Lee


On 09/05/2018 11:28 AM, Ron Bonica wrote:
> Folks,
>
> Each week between now and IETF 103, we will review and discuss one draft with an eye towards progressing it.
>
> This week, please review and comment on draft-byrne-v6ops-dnssecaaaa.
>
>                                        Fred and Ron
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops