On Tue, 10 Jan 2017, Matthijs Mekking wrote:
I personally think the simplification of using all zero's is good. If
someone accidentally changes the wrong number in the DS record when
changing parameters, it will prevent a mistaken delete request. While,
the zone might still fail, at least it won't be forced to go through a
period of insecure while the parental DS gets repopulated.
I am fine with using all zero's. I just don't think the change in
resource record format is a good idea, dropping the last RDATA field
from the CDS record.
Ohh, I think Matthijs actually found a bug:
The CDS RDATA is identical to the DS RDATA format, which is
according to RFC 4034:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | Algorithm | Digest Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Digest /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The draft states:
The keying material payload is represented by a single 0.
So the CDS delete entry currently specified as:
CDS 0 0 0
Should in fact be:
CDS 0 0 0 0
And similarly, the CDNSKEY is currently specified as:
CDNSKEY 0 3 0
and should be:
CDNSKEY 0 3 0 0
Olafur, do you agree? Should we push a new draft version with this fix?
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
