Pieter, On Fri, May 25, 2018, at 21:37, Pieter Vandepitte wrote: > The registry I work for, developed a custom extension to manage > "nameserver" groups and "keygroups". When a registrar links a group to a > domain, all member nameservers/keys of that group are automatically > linked to that domain. This way, it is very convenient for DNS operators > to update DNS data on their complete domain portfolio with a single > group update, without forgetting a domain. > > It is used quite a lot, but I did not find other registries having this > kind of functionality (I did not perform an extensive search). I'm quite > sure we are not the only ones, so do you know other registries having > this?
I know two extensions: - the .BE/.EU one: the last time I have looked at them, it was the same, except for the namespace - the .CZ one, in fact in their Fred open source EPP server (so probably used for their others TLDs), see https://fred.nic.cz/documentation/html/EPPReference/ManagedObjects/Nssets.html and https://fred.nic.cz/documentation/html/EPPReference/ManagedObjects/Keysets.html >From memory, they cater for the same needs, but are basically incompatible, >besides the namespace. Starting with the terminology: "group" on one side, "set" on the other. I would add 2 remarks: - for nameservers it seems to me to make more sense when hosts are objects, instead of attributes while obviously it works in both case. The world is quite divided on this, gTLDs are mostly (only?) in the objects group, while ccTLDs are predominantly in the attributes group - for DNSSEC material, here we hit another problem, the DS vs DNSKEY dichotomy, partially reflected in the dsData vs keyData interfaces of secDNS-1.1 All grouping cases only make sense of course with the DNSKEY case, because the DS depends on the domain. Again, without any hard facts, I still believe that most registries are using the DS case. Some, even with the dsData interface, ask also for the underlying keyData, but only to check that the DS was correctly computed. Also, such kind of features have consequences for transfers. > Is there any interest from the community to offer such a feature to > their registrars and collaborate on a common extension? I think of > something more generic in a way that a registrar can create a "template" > for any kind of object and apply that template to other objects. This > way, besides the benefits for DNS operators, a registrar could also > define e.g. a default admin contact for every domain, or even apply > custom extensions to every domain… Note that there were various attempts to define features such as templates, containers, or bulk operations. Specifically for bulk operations, since the discussions often circled around that the primary argument was that EPP is a provisioning protocol and as such is not tailored for bulk operations. Which brings immediately this counter argument: ... but you can query for more than one object in a given <check> command. Note that while not completely the same, issues of "bundling" domain names due to IDN variants typically is also loosely related to all of this. One of the latest iteration around these concepts was this draft: https://tools.ietf.org/html/draft-gould-regext-dataset-01 HTH, -- Patrick Mevzek _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
