* Antoin Verschuren: > There are multiple reasons why a registrant may want to change it's
"its"? "their?" > changed so such rollover scenario will not work. Besides if zone > transfers are not allowed by the losing DNS operator and NSEC3 is > deployed in the zone then the gaining DNS operator will not have > certainty that all of the losing operator's RRSIGs are transferred. But you need that data anyway, to continue providing the content of the zone. So you can also provide for RRSIGs. But as you pointed, it's not going to help because the signature on the NS RRset has to change. > The second option is to sign the zone at the gaining DNS operator with > the existing keys from the losing DNS operator. This option is purely > theoretical, and should not be used in an operational environment since > it implies exposing the private keying material when it is handed over > from the losing to the gaining DNS operator. In practice, when using > Hardware Signing Machines (HSM's) it is not even possible to extract "Hardware Security Modules (HSMs)" (see the previous discussion). Moreover, the same key could be used for multiple zones, for different customers. > All three options require the losing DNS operator to cooperate in the > transfer process to some extend for the domain to work. This is because > with DNSSEC only one version of the truth can be validated by one single > trust anchor, where in the non DNSSEC world 2 or even more versions of > the truth are accepted by a non DNSSEC resolver. The mandating of the > cooperation by the losing DNS operator can either be handled by the > parent of the zone in registration policy, or in a bilateral contract > between the registrant and the DNS operator when the registrant > outsources it's DNS operations for his zone. I think it's been proposed to lock NS/DS records in the resolver to address this problem. Other resolver-side mitigation mechanisms are a side effect of dealing with the unsigned referral/glue issue. After all, if you've never validated the NS RRset and its addresses, a registrar switch is indistinguishable from a previously unnoticed attack based on a spoofed referral. -- Florian Weimer <fwei...@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
