I agree that the errata is correct. It is maybe suboptimal that wire format for DS/DNSKEY delete-request was not specified in the document. And I'm not sure if the authors meant that the digest/public key is zero-length or one-byte long. But luckily this can prevent some compatibility issues:
Presentation format for DS/CDS just doesn't expect zero-length digest (as opposed to NSEC3PARAM which uses dash instead of the hex encoded salt if the salt is zero-length). I tried with Knot DNS and BIND - both can write DS record in presentation format with zero-length digest but cannot parse it back. (Try it yourself with "delete-cds.example.test. IN TYPE59 \# 4 00000000". I haven't trie with DNSKEY but I expect the problem will be the same.) The implementers should be careful and avoid the trouble. In this sense, I think parent zone should accept both zero-length and one-byte long digests/keys as a request to remove the DS. Jan On Mon, Jun 26, 2017 at 10:39 AM, Matthijs Mekking <matth...@pletterpet.nl> wrote: > 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
