On Thu, 2020-05-28 at 00:43 +0100, Tony Finch wrote:
> Peter van Dijk <[email protected]> wrote:
> > On Tue, 2020-05-26 at 09:10 +0200, Ondřej Surý wrote:
> > > 1. Bit 7 of the Flags fields needs to be 0.
> > 
> > Definitely [...] I noted earlier that whatever flags we might need, it's
> > definitely *not* ZONE and SEP.
> > 
> > > 2. This needs a new Protocol number
> > 
> > I understand why you would say that, but I'd love to avoid doing that.
> > I wonder how much 'IETF' pain specifying another protocol number would
> > be, but what worries me more, ironically, is how it changes the format
> > away from normal DNSSEC. The draft was written such that a lot of
> > existing software needs no changes at all - I don't know if changing
> > the protocol number is compatible with that goal.
> 
> This made me wonder if this pseudorecord should be a KEY instead, and then
> I wondered how hard it would be to persuade existing code to generate a DS
> from a KEY.

That could make semantic sense, but would muddle the connection to
'DNSKEY in EPP' and 'CDNSKEY sync from child to parent'; I think it
would add more confusion than the semantic correctness is worth.

> But anyway, this signalling and verification scheme sounds clever and neat.

Thanks!
 
Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to