Hi all,
Joining in on the ongoing conversation.
In the email thread, we have seen a number of messages from DNS
implementers and operators arguing that insecure delegation is required
for the proper operation of validating stub resolvers. See also RFCs
6303, 8375 and 9665, which mention insecure delegation. The new draft by
Joe Abley et al. discusses this issue in general terms with regard to
private namespaces.
The chairs have asked the IETF liaison to the ICANN Board of Directors
to also discuss this issue with the ICANN technical community. We hope
to report back to the DNSOP Working Group during the Madrid meeting. We
would like to ask the WG not to repeat the same arguments until there is
news.
Thanks,
-- Benno
for the WG chairs and secretaries
On 17/06/2025 23:08, John R Levine wrote:
On Wed, 18 Jun 2025, Mark Andrews wrote:
And if the stubs are validating then the answer for 10.in-addr.arpa DS
is a provable NOERROR NODATA response that says there is a delegation
at that point in the tree. That validator does NOT need to be
configured to say ‘DO NOT VALIDATE THIS NAMESPACE’.
We're going in circles here.
IF you have a validating stub resolver AND it gets all of its data from
the local cache AND even so it doesn't believe the cache's AD flag AND
you have some locally served zones AND none of those zones are a TLD you
picked yourself before .INTERNAL was reserved AND even though you're
sophisticated enough to do stub resolution you don't configure local
trust anchors THEN yes, the opt-outs are helpful.
On the other hand, if you think that's a rather narrow scenario and most
systems aren't quite like that, not so much.
Like I said, I don't see us coming to agreement any time soon.
Regards,
John Levine, [email protected], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]