Hi all,

I gave this discussion some time to converge[0], and also asked for
more comments during the (2nd) DNSOP session in Prague.

Unless I hear strong objections by Wednesday I'll mark the errata as
verified (with the minor clarification provided):
Strictly speaking, the CDS record could be "CDS X 0 X X" as only the
DNSKEY algorithm is what signals the DELETE operation, but for
clarity, the "0 0 0 00" notation is mandated -- this is not a
definition of DS digest algorithm 0.  The same argument applies to
"CDNSKEY 0 3 0 AA=="; the value 3 in the second field is mandated by
[RFC4034], Section 2.1.2.


W
[0]: Yeah, that sounds much better than "procrastinated" :-)


On Wed, Jun 28, 2017 at 7:27 AM, Ondřej Caletka
<ondrej.cale...@cesnet.cz> wrote:
> Hello,
>
>>Dick Franks:
>>> What is needed now is methodical use-case analysis based on RFC8078 as it
>>> exists now and tested against a real implementation.  The time to rewrite
>>> the RFC will come if/when we discover we are unable to live with it. We
>>> have not reached that point yet.
> Mark Andrews:
>> I can't go from RFC8078 to a working implementation because the
>> existing description is not clear enough to do it.  I don't think
>> anyone can do it.
>>
>> With the proposed errata fix I could write code.  For CDS the RRset
>> is a single RR with a rdata of 0x00 0x00 0x00 0x00 0x00.  For CDNSKEY
>> the RRset is a single RR with a rdata of 0x00 0x03 0x00 0x00 0x00.
>
> I have a confirmation from the real implementation of RFC8078 in the .CZ
> domain registry (cc jaromir.talir) that their understanding of CDNSKEY
> DELETE operation is exactly the set of RDATA quoted by Mark Andrews,
> which translates to the presentation form CDNSKEY 0 3 0 AA==
>
> I don't think there is a big room to interpret RFC 8078 differently,
> since it does not define any new presentation/wire format for
> CDS/CDNSKEY record. Therefore, even future versions of software that
> (de-)serializes RRs between wire and presentation format will have
> issues if there are not all fields mandated by RFC 4034 present in the
> rdata.
>
> --
> Ondřej Caletka
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to