> On 14 Nov 2017, at 5:45 am, Edward Lewis <edward.le...@icann.org> wrote: > > On 11/13/17, 13:30, "DNSOP on behalf of Evan Hunt" <dnsop-boun...@ietf.org on > behalf of e...@isc.org> wrote: > >> Mark's idea to push updates to the parent instead of relying on polling used >> a SRV query to identify the correct recipient of an UPDATE: >> >> ...draft-andrews-dnsop-update-parent-zones-04... > > This would mean then signing all the SRV sets, so I assume to preserve the > benefits of "OPTOUT", you'd want these only for the names that had DS sets. > For the others, I assume either no answer or the wildcard ... in the TLD. > (That latter thought might be unsettling to some people.) What I mean is > that there is still a scaling problem, in some dimension, to deal with > because the DNS is inherently a "down-only" tree. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
That part of the namespace doesn’t require signing as the UPDATES themselves are signed and can be easily split off as a separate zone. The worst that would happen is that the UPDATE request would be blocked if a spoofed response was accepted. Using servers that relay the UPDATE request (which is what slave zones do today for UPDATE) only requires a single SRV record. Even if the SRV records are all signed and the registry doesn’t run a UPDATE relay there still isn’t a scaling issue. It is possible to serve COM with every delegation being a secure delegation even though we don’t do it today. At worst this creates a zone of slightly smaller size. Add to that there would be a ramp up process as registrars come online supporting this method. Remember the draft was designed to handle ALL record updates to the parent zone after being approved by the registrar in a unified manner. NS, DS, A, DNAME, AAAA, TXT, CNAME, etc. This isn’t restricted to DS records. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
