In message <55e63378.3010...@mirix.org>, Matthias-Christian Ott writes: > Since 6renum is concluded I thought this WG could most likely help to > address the following problem: > > If the IPv6 network of an authoritative nameserver is renumbered and the > parent zones of zones that are served by the nameserver contain glue > records for the nameserver, the glue records need to be changed as well. > As described in RFC 7010, the nameserver could update the glue records > through Secure Dynamic DNS Updates and the nameserver of the parent zone > could restrict dynamic DNS updates to the AAAA RRs for the name of the > nameserver through ACLs (principle of least privilege). So in theory the > problem the problem is solved. > > In practice subdomains registered under public suffixes do not allow > dynamic DNS updates. Glue records and NS records can only be changed > through EPP or proprietary protocols of the respective registries and in > some cases only through fax or letter. Most registrars expose their > interface to the registry, including glue record management, directly to > registrants either through a self-service web interface that can be > scraped, EPP or some proprietary protocol and only few require > interaction with their customer support. So it is still possible to > automatically update the glue records of a nameserver when its network > is renumbered. However, there is no fine-grained access control - even > if you interface directly with the registry. That means that you have to > store the credentials that can be used to change all details of your > domain in the registry on every nameserver if you want that nameserver > to be able automatically update its glue records. If your domain uses > DNSSEC with separate KSK and ZSK, it suffices to compromise a secondary > nameserver to replace the KSK which undermines the security model. > > After some thinking the only countermeasure that I could come up with is > to either to have a trusted gateway to the registrar/registry that you > assume to be secure and highly-available or monitor the registry for key > changes and have an emergency plan to limit the damage. Both > countermeasures seem unsatisfactory to me. > > Obviously registries and registrars could introduce more fine-grained > access control but I doubt that this is going to happen, especially > considering the interfaces provided by registrars. > > Has this problem been addressed somewhere or is there an ongoing effort > that would address it?
https://datatracker.ietf.org/doc/draft-andrews-dnsop-update-parent-zones/ Provided a mechanism to do this which allowed fine grain access control base on tsig / sig(0) name. It could also use SIG(0) instead of TSIG though the draft doesn't state that. > - Matthias-Christian > > _______________________________________________ > 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: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
