-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 op 10-04-14 21:54, Patrik Fältström schreef: > On 10 apr 2014, at 18:34, Warren Kumari <[email protected]> wrote:
>> If we were to *require* that they match, what happens in the >> case where they *don't*? Do we fail the keyroll? That seems >> suboptimal. Do we throw a log message? No one will see it... If >> you consume CDS (or CDNSKEY), you simply ignore the other one -- >> it's not really relevant to you, and no good can come from >> looking at it. Ignorance is bliss... > > Understood. > > But I think you must explain what the parent should do. > > Fetch CDS and CDNSKEY, look at them and see that they lead to > different result. What should then the parent do? Pick CDS or > CDNSKEY, or pick one by random, or...? What should a parent do when it fetches a CDS or CDNSKEY and the Rdata does not make sense at all on its own? f.e. the Rdata does not parse as a DNSKEY or DS? If a child puts a CDS in his zone where the Rdata says "this is not a key at all", should I publish that? I think since this is a protocol definition, CDS and CDNSKEY MUST match. What a parent should do when the protocol is violated is I guess an implementation issue, BCP, or perhaps even local policy. A parent may only look at CDNSKEY or CDS or both. Saying they MUST match when they are both in the zone does not state anything on what the parent should do when they don't, same as when the Rdata is rubish. I would personally accept a CDNSKEY that does not match a CDS, knowing that the child may be in trouble when I change my policy in accepting CDS in the future. But that's the price the child pays for violating the protocol. I don't see any use case or excuse for the CDNSKEY and CDS not matching -if- they are both in the zone. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: [email protected] XMPP: [email protected] HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJTR73uAAoJEDqHrM883Agn5JgH/RYCUHkgNCcUW+ufE0eVnLHJ SocZtLncRqt4340MvFzxo5Fsdcmn+96ftF+Tvk7ixLZy80HX5OPDyW6YCOu2J9oR PLcIo3Nbps4Y9Tn8fxYsp1pcVD1e8JuI7uUFhzX86h9HjYxOPIT+nGaFe3PKn92n v5cuIeWiYoPCnGxzDcKYtuZry6PX8oY93vuvDfBwY2lr3DPHYmpV0paQ9hfZPSoG 8enurd9ENrZ7TBaDYg1FXoHc9rFP94v7LLPHS0yr44t4lJiBfY8k/TC200w8f8H8 8JmNIdcRcz3CW190ZEC9QOfHAVzJK8tlCLvOT2fCex3kRPdaY5smcsqo43cZWD0= =Hh2a -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
