On 9. 10. 2013, at 15:47, Paul Wouters <[email protected]> wrote: > On Wed, 9 Oct 2013, Ondřej Surý wrote: > >> We also have a signaling mechanism... >> >> We can just somewhat abuse the DNS Update mechanism to send DNS UPDATE >> to parent master (from SOA) server with DNSKEYs + RRSIGs as contents >> of the DNS UPDATE message.
Paul, > Some TLD operators I talked to did not want UPDATEs heading towards > their existing deployment. So your signaling only works if those > TLDs can re-purpose the SOA entry to specify such a _new_ server. One > could also use a new RRTYPE for it (but prob not put it in the apex) It doesn't have to go directly to "registry". The child can also send UPDATEs to registrars (authenticated by the data in the registry bootstrapped by some other channel). > I still think the most transparent way of signaling the child can do > is by publishing something in their zone. It will get DNSSEC protection, > and even "transparency" by being published to anyone who cares to look. I think that publish-in-the-child-zone and UPDATE mechanisms complement each other and it's up to parent policy if they accept UPDATE and what to do when they receive the UPDATE. One option would be to drop the contents of UPDATE and check the child zone and pull the correct data from there. > It also requires no new firewall rules at the TLDs to let in new kind of > messages like UPDATE. Don't tell me that "oh, no, I need to add new firewall rule" argument should be a showstopper when designing new protocol. O. -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:[email protected] http://nic.cz/ tel:+420.222745110 fax:+420.222745112 -------------------------------------------
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
