In message <[email protected].>, [email protected]
roshi.com writes:
> On Tue, Mar 02, 2010 at 08:05:38PM +0000, Alex Bligh wrote:
> > Ed,
> > 
> > --On 2 March 2010 14:39:45 -0500 Edward Lewis <[email protected]> wrote:
> > 
> > >Telling someone one to change the name server from "ns1.example.tld." to
> > >"newdns.example." or "127.0.10.2 to 192.0.2.3" is easier than saying
> > >change something from:
> > >"94DC01F2763CCB12F4B66AC63910830BC34082F6FE95CD75DAA3C5B37F99DD81"
> > >to:
> > >"6CDE2DE97F1D07B23134440F19682E7519ADDAE180E20B1B1EC52E7F58B2831D"
> > 
> > So, if the registrar is running DNS, then he pushes the DS keys directly
> > using EPP or whatever. And the problem arises, if I understand it right,
> > when someone other than the registrar (or for that matter the registry) is
> > generating the information that goes in the DS record. And whilst
> > nameservers (for instance) are likely to be static, this is relatively
> > volatile.
> > 
> > My concern is that whatever automatic update mechanism you choose has
> > to use some greater level of security than merely relying on the
> > zone being signed. So to pick a trivial example
> > _DSKEY IN TXT [blob]
> > isn't going work, because if you are changing the DS key because
> > you fear your keys may have been compromised, that can be compromised
> > too. I may be having a failure of imagination but I don't immediately
> > see how without some external authentication (yet another key) you
> > can securely automatedly push DS key changes about.
> > 
> > -- 
> 
>       hum... maybe I should be hounding Ed on this... but I think we should
>       draw a bright line...  we are (imho) talking about pushing DS records
>       from child to parent.  entirely w/in the perview of the DNS protocol/wg
> .
> 
>       for non-DNSprotocol players (registries/registrars/registrants) that us
> e
>       EPP or its varients for pushing DNS data around - thats not w/in scope.
>       at least for this WG's consideration.

I recommend something that is UPDATE + TSIG like.  The child's key manager
component can send the updates.
 
> --bill
> _______________________________________________
> DNSOP mailing list
> [email protected]
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to