Hi,
On 24-06-17 17:45, Ondřej Caletka wrote:
Hello,
Dne 24.6.2017 v 15:25 Dick Franks napsal(a):
I beg to disagree.
In each case,
CDS 0 0 0 0
CDNSKEY 0 3 0 0
the final "0" is a conventional token representing a zero-length key
field. In neither case is it an attempt to specify a single octet key value.
I believe this has been discussed between 04 and 06 versions of the
draft in this thread:
https://mailarchive.ietf.org/arch/msg/dnsop/PsRIQOtd1bxFSEEm9lfv0WaHKeE >
The result that made it to the RFC is that there should be indeed one
byte with value of 00 in the Digest/Public key field instead of no data
at all.
To be precise: We actually agreed that there should be *one field with
the value of 0* instead of no data at all.
This avoids the need of defining new format and updating all the
deployed software. It's not only about parsers of the wire format but
also about zone file parsers, that would need an update as the single
zero is not conformant with currently defined presentation format of
CDS/CDNSKEY RRs.
I raised the specific issue because the to be RFC 8078 was going to
change the CDS and CDNSKEY RDATA format from a fixed length RDATA to a
variable length: In case of the DELETE operation, the Digest in
presentation format was omitted.
While I agree with Paul in that thread that we should use all zeros for
the DELETE operation, I believe it was an oversight that the proper
encodings (hexadecimal, base64) should be used.
So to me this errata is valid.
Best regards,
Matthijs
I believe changing RRdata format just for this one purpose would add an
unnecessary complexity.
--
Best regards,
Ondřej Caletka
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop