BCP doesn’t require vendors to change code to bring themselves into compliance. Updating the specifications in theory does. -- Mark Andrews
> On 2 Oct 2025, at 17:46, Philip Homburg <[email protected]> wrote: > > >> >> Uhmmmm ? The world isnt that black and white. Additionally, flag >> days are bad as it turns production quality and certified solutions >> into old crap on a single unfortunate day in the future these >> deployments have no reason to monitor or track now. > >> It is as no one remembered these discussions we had a number of >> times now. Environments with KSK and ZSK split might find it hard >> to guarantee this - even if they could, it inserts a human component >> in a protocol flow where no human is needed now. And the reason >> for doing so have not convinced many people on this list. >> >> There is no consensus and it is time to drop this idea. > > I agree that flag days are bad. However, I think a BCP that says: > "a DNSSEC signer MUST NOT sign a DNSSEC RRset that contains key tag > collisions" > would be a good step forward. We can see if we can figure out if we can or > should say something about temporal collisions. > > At home, I sign some of my domains with shell scripts around ldns-signzone. > Those shell scripts do not avoid collisions. There is no easy way to avoid > collisions and I suspect something will go terribly wrong when a collision > occurs. However, I don't consider those scripts properly engineered. > > If there are signers that cannot avoid collisions then it is time to rethink > those signers. > > It is not a reason to break them at some flag day, but certainly a reason > to either fix to signers or move away from them. > > > _______________________________________________ > 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]
