1. Because not all parents (by policy) construct DS records on behalf of children;
2. Because sometimes you want to publish DS RRs in your parent that correspond to standby keys that are not published in the child. Aue Te Ariki! He toki ki roto taku mahuna! On 2013-03-13, at 3:00, Doug Barton <[email protected]> wrote: > On 03/12/2013 11:52 AM, Johan Ihrén wrote: >> On Mar 7, 2013, at 10:58 , Tony Finch wrote: >> >>> Paul Wouters <[email protected]> wrote: >>>> >>>> To get back to the draft: I have not seen too many people talk about the >>>> CNS/GLUE record types. Should those be in this draft, a separate draft, >>>> or no where? >>> >>> Why not use the child's normal NS records? >> >> So, while I'm really late to this party due to travel, I would like to say >> that I strongly believe this to be the right approach. >> >> As many of you know I've been advocating this for years, and am using this >> in production since about 2006 or so. I.e. "sync" of the NS RRset, and the >> glue is trivial really, because it is data that is authoritative in the >> child, has a signature by the child and can be validated by the parent. >> >> The only reason that we're even discussing the CDS proposal (which I'm all >> in favour of) is that the DS record has the distinction of not being >> authoritative in the child, and hence not having a signature by the child >> anywhere. >> >> So we need a new record for that, enter CDS. > > If scraping NS is good enough for NS in the parent, why isn't scraping DNSKEY > good enough for CD in the parent? > > Doug > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
