Hi,
First of all. I strongly agree with Paul: keep the record formats identical.
Second: Why the name change? I assume the TA in CTA stands for Trust
Anchor. The name CDS seems to fit better even in the DNSKEY case. After
all, we are talking about the synchronizing the Delegation Signer, not a
Trust Anchor.
On 10/03/2013 05:59 AM, Guangqing Deng wrote:
>> On Thu, 3 Oct 2013, Dickson, Brian wrote:
>
>> >>> This allows children to present DS to those parents who want DS, and
>> >>> DNSKEY to those who would prefer to calculate DS on their children's
>> >>> behalf.
>> >>
>> >> I still strongly prefer CDS (and CDNSKEY) to keep the record formats
>> >> identical, making things a lot easier on implementors and humans
> editing
>> >> zone files. I see no strong reason to merge these two things into one
>> >> RRTYPE of CTA.
Merging does not necessarily mean different record formats for DS and
DNSKEY. As said earlier, the RDATA can be one selector field + DNSKEY RDATA.
example.com. 86400 IN CDS 0 257 3 5 AQPSKmyn...
^^^^^^^^^^^^^^^^^^^
DNSKEY RDATA
>> >>
>> >
>> > There is the issue of "big zone operators would need to do twice as many
>> > queries".
>
>> Why? The big zone operators only need to support one type - the type
>> that matches their policy. If they need a DNSKEY, they look for CDNSKEY.
>> If they need a DS, they look for CDS.
>
>> > What if someone puts both types in their zone?
>> Ignore both?
>
> Maybe the parent zone needs a policy to always choose one and only one kind
> of RR (either CDS or CDNSKEY) and omit the other in this situation.
Exactly that.
Best regards,
Matthijs
>
>> Paul
>> _______________________________________________
>> DNSOP mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dnsop
>
> ------------------------------------------------------------------------
> Guangqing Deng
> cnnic
>
>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
>
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
