The reason to do an insecure delegation is so that the public dns doesn’t securely deny the existence of the zone. If there is a secure denial of existence, a validating stub resolver will not use responses from the local resolver because they will be bogus.
On Wed, Apr 30, 2025, at 12:49 PM, Paul Hoffman wrote: > Coming back to the topic of insecure delegation, because some people here > have said that is the reason they want the draft to be adopted in this WG. > > Can anyone say who benefits from insecure delegation of .internal, and how? > This might be a lack of creativity on my part, but I cannot think of any > party in the DNS that would be helped by insecure delegation of .internal, > and I can think of one (validating stub resolvers) that would in fact be hurt > by it. > > --Paul Hoffman > > On Apr 24, 2025, at 09:50, Joe Abley <[email protected]> wrote: > > > > Replying to myself, hooray, > > > > On 23 Apr 2025, at 18:16, Joe Abley <[email protected]> wrote: > > > >> 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). > > > > Some kind people reminded me of events of the past, so in case it's > > interesting... > > > > It turns out that the SSAC work party responsible for that document did > > indeed decide not to recommend an insecure delegation for the reason above, > > and so it's definitively not the case that people didn't think of it or > > think that it was a good idea to recommend it. > > > > I was one of the people that thought it was better not to include that > > specific recommendation, for the reason above, and in fact I said so loudly > > and stubbonly at the time. I had just forgotten. > > > > I still think this was a reasonable recommendation to drop, and I still > > think that the resulting resolution shouldn't stand in the way of any > > particular technical implementation of the document's overall > > recommendation. People shouldn't read too much into the word "delegation" > > just because they're used to seeing it through a DNS lens. It definitely > > has other meanings in the context of the policies surrounding root zone > > management. > > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
