On Mon, 19 Mar 2018, Stephane Bortzmeyer wrote:
I'm opposed to this idea.
Can you clarify whether you oppose to be a user of this new flag, or
whether you oppose of giving others the option of using this flag?
While the root and TLD zones are asumed to be almost exclusively
delegation-only zones,
This is unrelated. You mix two different things, the administrative
issue and the technical one (every subdomain in its own zone). gouv.fr
is administratively a delegation from .fr but is in the same zone.
The idea is that the current technology cannot tell this difference,
but we know at some point down the chain there (usually) is a real owner
change. This allows a zone to publish that information.
One of the side effects is that is there is no zone cut when traversal
a label, that to use this new flag, you have to turn this label change
into a real zone cut. I believe the setup of that is easy and that there
are no real operational impacts caused by this, but I'm happy to hear
from operators, especially TLDs, if there are any concerns with such
a conversion.
That's the DNS. It is a tree. Protecting childs against the parent is
a non-goal
If you can't not trust your friends, who can you not trust? :)
We also did not publish TLSA records in the zone in the old days. Now
we do so there is a clear (new) need to add a bit of protection for the
children against potentially malicious parents. It's completely an
opt-in option for the parent.
Rather then hearing "That's the DNS", I'm more interested in hearing
about whether TLDs would be willing to adopt this solution, and if not,
what actual operational (or organisational?) concerns they would have.
or otherwise we should move to some alternative to DNS
That is outside the scope of this proposed solution :)
The aim here is to counter the argument that the root key and TLD
keys are all powerful and under government control, and can therefor
never be trusted.
I've read the draft and still can understand nothing in this sentence.
I'm happy to talk in person this week if that helps. Otherwise if you
have specific questions, I can try to answer them here.
2) Allow the creation of DNSSEC transparency logs
May be mentioning draft-zhang-trans-ct-dnssec would be nice?
This document is not about ct-dnssec itself. It has as one of its goals,
to make some kind of ct-dnssec possible. But that will be pursued with
another document (and probably on the trans list)
The DELEGATION_ONLY flag has a strong overlap in functionality with
the Public Suffix List as both signal a formal split of authority
between parent and child.
May be mentioning the defunct DBOUND working group would be a good
idea?
What specifically about DBOUND is worth mentioning in the document?
Paul
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
