>> 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. You can overcome the problem with the glue records by putting all the NS server in a different domain not below your zone. But this of course wouldn't help on DS or NS updates.
>> 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. I've written a client tool to update NS, DS and glue records and uses TSIG (only) authenticated DNS UPDATEs. $ zkt-delegate -h usage: zkt-delegate -h|-v usage: zkt-delegate -k keyfile [-d] [-t ttl] [-s server] [-p port] [-o origin] <cmd> [parameter ...] -h, --help print out this help message -V, --version print out version and exit -v, --verbose -k, --keyfile=tsigfile name of file with tsig key (named.conf syntax) -d, --delete switch update delete processing (default: In file mode delete old RRSet before adding new ones) -t, --ttl <ttlspec> specify ttl of RR (default depends on cmd) -o, --origin=zone specify domain (default is tsig keyname) -s, --server=master specify master server for updates (default is SRV or SOA record) -p, --port=<port> specify port for updates (default is 53) <cmd> ns {-f zonefile | [nsname ...]} change delegation record (NS) ds {-d dsfile | -f zonefile_with_CDS} change delegation signer record (DS) glue {-f zonefile | nsname [ipaddr ...]} change glue address record (A/AAAA) It's not very well tested yet and is part of the latest ZKT [1] version (which is actually not the same as the one in the BIND contrib dir). The tool requires the ldns library which doesn't support SIG(0) for updates (as far as I know). Holger [1] https://github.com/hzuleger/ZKT
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
