Hi Yorgos,
I've lost the original new version announcement to reply to so apologies for
the thread crime, but I have a more fundamental question about this draft.
You say:
DNSSEC was introduced to provide DNS with data origin authentication and data
integrity. This brought quite an amount of complexity and fragility to the DNS
which in turn still hinders general adoption. When an operator decides to
publish a newly signed zone there is no way to realistically check that DNS
resolution will not break for the zone.
I think I understand the spirit of what you are saying but I am a little
unconvinced about the demand for this kind of testing.
Even after you have tested with a dry run mechanism, you need to make material
changes to your zone to progress to actually signing in a way that you expect
people to validate, and you can only get useful test results from validators
that have implemented the test mechanism. So the thing you tested is not
actually the same thing as what you deploy, and the test coverage might well ve
limited.
This doesn't make it feel like a great test.
Isn't signing a test zone with exactly the processes, protocols and software
that will be used in real life and validating it with real deployed validating
resolvers actually a better test?
Who is this mechanism for?
Joe
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
