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

[JORDI PALET MARTINEZ <[e-mail]>]

I’ve a similar document in sunset4.

 

Maybe we want to combine both of them, now that sunset4 is sleeping ...

 

https://tools.ietf.org/html/draft-palet-sunset4-ipv6-ready-dns-00


Regards,

Jordi

 

 

 

De: v6ops <[e-mail]> en nombre de Lee Howard <[e-mail]>
Fecha: jueves, 6 de septiembre de 2018, 7:35
Para: <[e-mail]>
Asunto: Re: [v6ops] draft-byrne-v6ops-dnssecaaaa

 

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

_______________________________________________ v6ops mailing list [e-mail] https://www.ietf.org/mailman/listinfo/v6ops 



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.