> On Thu, 28 Aug 2008, Brian Dickson wrote:
> 
> >>    (I would posit that the folks generating the DNSKEY will also
> >>    want to generate the DS hash on their known, trusted signing tools
> >>    instead of trusting the parent w/ the DNSKEY materials)
> >
> > Well, here's why:
> >
> > - The DS is a deterministic function
> > - Having DS sent to the parent, rather than calculated locally by the
> > parent, introduces a host of human and/or process risks/requirements
> 
> How does the parent know it is not getting spoofed, assuming this is the
> first time a DS record is created for the sub domain?

DS/DNSKEYs need to be supplied to the parent over the same channel
that NS updates are supplied over.  If you are not already applying
anti-spoof techniques to NS updates you can't trus DS/DNSKEY updates.

> > - Nothing in the DNSKEY, or in the building of the DS, involves private
> > keys, only public keys - so there is no trust issue with the materials.
> 
> Getting the wrong public key in the DS record is a trust issue.

So's getting the wrong NS RRSet or getting bad glue A and AAAA records.

> > - The DNSKEY is already published, so the parent can trivially get it,
> 
> Really? Getting it securely is not that trivial.

It doesn't need to be secure it should just be for conformation of
the existing information over the existing channel.

> > in a way that is not subject to poisoning (the NS glue is hardcoded in
> > the parent zone, after all)
> 
> IP spoofing is possible.

DNSSEC really does not change the level of security parents should
be applying to delegation updates.  If the parent is using a third
party then that third party for delegation updates also needs to
apply similar proceedures for DS/DNSKEY as for NS, A and AAAA.

Mark

> See RFC5011 ?
> 
> Paul
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [EMAIL PROTECTED]
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to