On 23 Apr 2025, at 16:15, Philip Homburg <[email protected]> wrote:
> But I want to say I'm surprised that a document by 'the ICANN Security and > Stability Advisory Committe' does not mention DNSSEC at all, except in a > footnote in an appendix. And does not analyse an insecure delegation from > the root. > > For this working group, I think it is safe to assume that ICANN will not > create an insecure delegation for internal. I don't know how to predict what ICANN will or will not do. I'm also not sure why it is useful to speculate. I was a member of SSAC at the time SSAC made its recommendation to the ICANN board, but I was not one of the people who contributed significantly to the document as far as I remember, so be aware (as usual!) that everything I say may be nonsense. I think the SSAC document does not discuss or propose an insecure delegation from the root zone in order to avoid the advice to the board being complicated by conflicts with existing root zone management (both in the general sense and in the sense of RZM, the software used to manage delegations from the root zone). I am fairly confident the mechanics of the implementation were understood and discussed by those involved in writing the document. I don't think it's reasonable to imagine that people just didn't think of this. Given the number of times we have heard Mark Andrews talk about this at microphones around the world it seems impossible that anybody is unaware of it. Personally, I agree with John Levine that it's common practice for people to use top-level domains in a private environment and whatever complexities might exist in theory with DNSSEC do not seem to be much of a problem in practice. So I agree that this particular issue does not seem like much of a reason for this working group to spend time on this. > So in my opinion this draft should not be adopted. The best solution is > no IETF document at all. That leaves the IETF out of this issue. Joe _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
