Up-front listing of DNS domain requirements

Contribute Room
, , ,
1

I’ve added a number of new apps recently, and many require their own domains. Setting up a domain is essential complexity for an app, so I’m fine with this, quite happy for a pretty minimal cost to get a new piece of functionality set up for myself, my family, my friends, or a community group (or who knows, a company).

However, the process often involves repeated waiting for information from diagnosis to filter into yunohost (requiring a full diagnosis first), before domain DNS configuration can be ignored and rechecked. It would be helpful to report the expected DNS entries for a domain up front, both the defaults that yunohost wants, and what can be inferred or for an app or declared by a maintainer.

It would be useful, I could work on, a format that expresses:

  • constraints yunohost core offers, or expects fulfilled by default.
  • constraints the app declares need of
  • constrains I wish my deployment to satisfy (and which I will actively ignore)
  • tests of constraints, and status as: satisfied, ignored / disabled, or unsatisfied (and how to rectify)

I argue that a declarative format which lists this essential information, can make management via the web interface, and equally the cli, easier, and can make the install as a whole more declarative, more amenable to automated deployment, or moving, between domains or hosts.

Let’s list expected DNS domain entries up-front, not just on first check.

A, AAAA, CAA, (MX / TXT - DKIM, SPF, DMARC), (XMPP)

The workflow of having to re-open DNS, or wait for domain setup to report missing expected entries, then me wait again for a full diagnosis just so I can ignore what I knew I was going to ignore, is inane, and makes me want to contribute to something better.

2

Ok, as linked to from elsewhere,

Also, support for wildcard DNS use, records on *.sub on domain.tld. Can be set up in advance for domains. at least A, AAAA, CAA, though in my experience, yunohost generates different DKIM keys for each domain it manages, so some mail records need to be unique. SPF and DMARC can be shared, all of which are stored on TXT records of sub-domains, or sub-sub-domains, of the domains they help attest and validate.

Using these wildcard records can, for now, let you avoid having to add new entries, though you’ll need to diagnose and ignore expected records.

3

Delegating a sub-domain to yunohost to manage sub-sub-domains, is worth a fair bit of effort.

I’ve set up *.etc.domain.tld so I can install new apps with just a ynh domain setup and app install, and without touching my own DNS, moving or reinstalling the app later.