Sam,
On 7/25/19 1:22 AM, Samuel Weiler wrote:
> On Tue, 2 Jul 2019, Matthijs Mekking wrote:
>
>> Here's a draft with discussion why also the protocol should go
>> away. We would like to hear what you think about it.
>
> The discussion of the private network use case in section 2 has two
> minor errors plus one bit that is unclear.
>
> When we designed DLV, we certainly considered a private network use
> case. RFC5074 does not strictly have public trust anchors take
> precedence over ("mask") DLV records [1].
I read text from RFC 6840 (Section C.3):
When the trust anchors have come from different sources (e.g.,
automated updates ([RFC5011]), one or more DNSSEC Lookaside
Validation (DLV) registries ([RFC5074]), and manual configuration), a
validator may wish to choose between them based on the perceived
reliability of those sources. The order of precedence might be
exposed as a configuration option.
> I suggest replacing the text in section 2 starting with "One other..."
> with:
>
> One other possible reason to keep DLV is to distribute trust anchors
> for private enterprises. The authors are not aware of any such use
> of DLV.
>
> That does not include the argument in the below bullet, which I find
> unclear. What does "name redirection" mean in this context?
>
> o Since the zones are related to private networks, it would make
> more sense to make the internal network more secure to avoid name
> redirection, rather than complicate the DNS protocol.
Thanks, I made the change in the GitHub repository (BTW I also resolved
Paul Wouters nit comments from earlier).
Best regards,
Matthijs
> -- Sam
>
>
> [1] Specifically, 5074 says to use public trust anchors first. If they
> give a validation result other than "Secure", then do DLV processing.
> I'm not 100% sure of how BIND's logic works here.
>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
