On 7/19/24 10:34, Philip Homburg wrote:
To prevent this discrepancy between how dry-run and real validation
is done, the resolver either needs to halve its work bounds (which
is a disadvantage for real deployments), or commit to twice the
work it is willing to do.
This would be a problem is t
DS is the wrong logical point to signal dry run or at least there should also
be a key flag otherwise a parent can downgrade the security of zones that don’t
want dry run semantics. Additional validation doesn’t require the DS to be
present. It is only required to validate the DNSKEY RRset.
--
Hi Mark,
On 21/07/2024 00:20, Mark Andrews wrote:
DS is the wrong logical point to signal dry run or at least there should also
be a key flag otherwise a parent can downgrade the security of zones that don’t
want dry run semantics. Additional validation doesn’t require the DS to be
present.
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
Hi Joe,
On 21/07/2024 02:15, Joe Abley wrote:
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.
No problem!
Even after you have tested with a dry run mechanism, you need to make
material cha
