On 03/13/2013 07:45 AM, Joe Abley wrote:
1. Because not all parents (by policy) construct DS records on behalf
of children;
So how likely are those parents to utilize CDS records to auto-publish
DS? Or, put more simply, Do we have any indication that registry
operators will actually use this? I know that registries are not the
only zone parents, but without some significant buy-in from them I think
that regardless of the merits of this idea it may be of low utility.
2. Because sometimes you want to publish DS RRs in your parent that
correspond to standby keys that are not published in the child.
If the parents are actually using some method of accepting signals from
the child to scrape the zone (whether CDS; actual scraping of NS,
DNSKEY, etc.; or some other method) wouldn't that lower the barrier to
entry for standby keys?
Doug
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
