On Tuesday (2016-07-26) I gave a talk at work about domain registry APIs. It was mainly humorous complaining about needlessly complicated and broken stuff, but I slipped in a few cool ideas and recommendations for software I found useful.
The talk was based on what I learned last year when writing some
software that I called
but the talk wasn't about the software. That's what this article is about.
What is superglue?
Firstly, it isn't finished. To be honest, it's barely started! Which is why I haven't written about it before.
The goal is automated management of DNS delegations in parent zones - hence "super" (Latin for over/above/beyond, like a parent domain) "glue" (address records sometimes required as part of a delegation).
The basic idea is that
superglue should work roughly like
nsdiff takes a DNS master file, and it produces an
nsupdate script which makes the live version of the DNS zone match
what the master file says it should be.
superglue takes a collection of DNS records that describe
a delegation, and updates the parent zone to match what the delegation
records say it should be.
A uniform interface to several domain registries
superglue is a suite of programs.
When I wrote it I needed to be able to update parent delegations managed by RIPE, JISC, Nominet, and Gandi; this year I have started moving our domains to Mythic Beasts. They all have different APIs, and only Nominet supports the open standard EPP.
superglue has a framework which helps each program conform to a
consistent command line interface.
Eventually there should be a
superglue wrapper which knows which
provider-specific script to invoke for each domain.
Refining the user interface
DNS delegation is tricky
even if you only have the DNS to deal with. However,
has to take into account the different rules that various domain
For example, in my initial design, the input to
superglue was going
to simply be the delegations records that should go in the parent
But some domain registries to not accept DS records; instead you have
to give them your DNSKEY records, and the registry will generate their
preferred form of DS records in the delegation. So
to take DNSKEY records in its input, and do its own DS generation for
registries that require DS rather than DNSKEY.
There is also a problem with glue records: my idea was that
superglue would only need address records for nameservers that are
within the domain whose delegation is being updated. This is the
minimal set of glue records that the DNS requires, and in many cases
it is easy to pull them out of the master file for the delegated zone.
However, sometimes a delegation includes name servers in a sibling
domain. For example,
ic.ac.uk are siblings.
cam.ac.uk. NS authdns0.csx.cam.ac.uk. cam.ac.uk. NS ns2.ic.ac.uk. cam.ac.uk. NS sns-pb.isc.org. ; plus a few more
In our delegation, glue is required for nameservers in
authdns0; glue is forbidden for nameservers outside
sns-pb.isc.org. Those two rules are fixed by the DNS.
But for nameservers in a sibling domain, like
ns2.ic.ac.uk, the DNS
says glue may be present or omitted. Some registries say this optional
sibling glue must be present; some registries say it must be absent.
In registries which require optional sibling glue, there is a quagmire
of problems. In many cases the glue is already present, because it is
part of the sibling delegation and, therefore, required - this is the
ns2.ic.ac.uk. But when the glue is truly optional it
becomes unclear who is responsible for maintaining it: the parent
domain of the nameserver, or the domain that needs it for their
I basically decided to ignore that problem. I think you can work
around it by doing a one-off manual set up of the optional glue, after
superglue will work. So it's similar to the other delegation
management tasks that are out of scope for
registering or renewing domains.
The motivation for
superglue was, in the short term, to do a bulk
update of out 100+ delegations to add
sns-pb.isc.org, and in the
longer term, to support automatic DNSSEC key rollovers.
I wrote barely enough code to help with the short term goal, so what I have is undocumented, incomplete, and inconsistent. (Especially wrt DNSSEC support.)
And since then I haven't had time or motivation to work on it, so it remains a complete shambles.