Hi Ben,
Thanks for the feedback!
On 16/07/2024 17:55, Ben Schwartz wrote:
I think dry-run DNSSEC is an interesting idea. I suggest that the
authors also consider how it would interact with DELEG, which aims to
improve the state of DNSSEC configuration and improve delegation
flexibility. Some variants of the DELEG proposal might already enable
some kind of dry-run DNSSEC capability.
Since both dry-run and deleg would need updated resolvers, there is an
argument that they could benefit from each other.
However the deleg group has just started and I am not sure what the
final solution would be. I will keep the deleg work in mind as this
document progresses.
For this draft, I find the current text hard to read. I also think that
the expectations are underspecified. This specification permits some
rather complex arrangements with mixtures of "dry-run" and "production"
DS records, and I couldn't say with any confidence what a resolver is
supposed to do when confronted with such a mixture.
The idea is for the resolver to first try the dry-run DS(es) and when
DNSSEC failure happens, fallback to the non-dry-run DSes.
This is part of the "Overview" section
(https://datatracker.ietf.org/doc/html/draft-yorgos-dnsop-dry-run-dnssec-02#section-3-6)
but now that you mention it I think it needs its own explicit section.
I opened an issue for this for a future version
(https://github.com/NLnetLabs/draft-yorgos-dnsop-dry-run-dnssec/issues/5)
The text is in no way in final form and me keeping the IETF feedback in
there for these early stages of the document does not help with the text
flow. For the next version I'll focus more on the flow consistency of
the document.
If you have specific text that is hard to parse let me know.
I'm also interested in the possibilities for malicious use of this
extension. Can a malicious domain cause a resolver to do an enormous
amount of work? Can a malicious intermediary cause an enormous volume
of error reports?
For validation work, the resolver could be made to try validation twice;
once with dry-run DSes, and if that fails, once more with the real DSes.
"try validation" could mean a lot of things for validating software but
with the recent KeyTrap family of vulnerabilities, validators should
have sufficient strategies/limits to mitigate excessive use of
validation time.
Since dry-run may need to restart validation with the real DSes those
strategies/limit would need to be restarted as well.
For error reports, dry-run relies on DNS Error Reporting (RFC 9567) and
this is indeed a concern raised in the "Security Considerations" section
there.
I have added issues for both of these:
- https://github.com/NLnetLabs/draft-yorgos-dnsop-dry-run-dnssec/issues/6
- https://github.com/NLnetLabs/draft-yorgos-dnsop-dry-run-dnssec/issues/7
Best regards,
-- Yorgos
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
