The Domain Sharing Plan

[mwild1]

People would like to use Snikket with JIDs @example.com while also having an existing website on example.com. This is currently tricky, particularly when Snikket is running on a different machine.

Things that need to happen:

• Snikket needs to be able to separate the XMPP domain and the web domain.
• We need to be able to overcome certificate issues (if example.com:80 is a website on a separate server, we can't easily get certificates for the XMPP domain)
  • Option 1) Respond to DNS challenges and instruct people to delegate via an _acme-challenge record
  • Option 2) Serve a self-signed certificate and instruct people to upload a POSH file (requires adding support in snikket-ios and snikket-server)
  • Option 3) Sit back and wait for Let's Encrypt/CABF to get moving on SRV support (BRs: Clarify how SRVName subjectAltNames should behave cabforum/servercert#268) (reality: it may never happen for end-user certs)
  • Option 4) Sit back and wait for LE or another CA to get moving on STAR certificates

[singpolyma]

Option 1 is a slam dunk IMHO. Works with letsencrypt and all clients and servers today, with the only downside being one extra DNS record on a custom domain and that if the owner of that domain wants to use dns-01 on their apex themselves they have to remember to restore the CNAME when they are done.

[worldofgeese]

I'm so looking forward to this! I have a user name that relies on my domain (so worldof AT geese) to "make sense".

[Rijul-A]

Continuing our discussion from the Snikket Project Chat, you said you want to do wildcard certificate generation via joohoi/acme-dns. I would like to start work on this.

Do you have an architectural design in mind? I'm thinking that acme-dns becomes part of the snikket-cert-manager container, and prints to stdout the relevant CNAME record that needs to be added (this will be persisted into a Docker volume for reuse later). It then waits for the CNAME record to exist before proceeding to obtain an LE certificate.

[mwild1]

Yes, I think this should be built into snikket-cert-manager.

I think it could be enabled by an environment variable, such as SNIKKET_ENABLE_ACME_DNS=1.

The CNAME thing is a little awkward. Here's how I expected it would work:

1. The admin creates A and/or AAAA records for their Snikket server, e.g. snikket.example.com, pointing to their instance's IP address(es).
2. The admin creates an NS record for snikket.example.com pointing to snikket.example.com.
3. The admin will then create three CNAME records:

• _acme-challenge.example.com CNAME cert.snikket.example.com
• _acme-challenge.share.example.com CNAME cert-share.snikket.example.com
• _acme-challenge.groups.example.com CNAME cert-groups.snikket.example.com

4. The admin sets SNIKKET_ENABLE_ACME_DNS=1 in their config and starts Snikket.
5. snikket-cert-manager (via certbot + acme-dns-certbot plugin) obtains certificates.

The primary difficulty I see is, in step 5, the targets of the CNAME records. Out of the box, acme-dns expects you to use randomly-generated domains (because it is often used for scalable mass hosting). However it should be technically possible to seed the acme-dns database with some static records instead of the UUIDs it uses by default. However this may only be possible in unreleased versions of acme-dns as it would require joohoi/acme-dns#243 which has been merged but not yet released.

Of course at this point it may be worth a sanity-check: is it still worth using acme-dns vs. a different generic small authoritative DNS server we can integrate with certbot? I haven't researched alternatives, so I can't say at this point.

[singpolyma]

- `_acme-challenge.example.com CNAME cert.snikket.example.com`

This is the only cnam you need and from it you can get a wildcard.

The primary difficulty I see is, in step 5, the targets of the CNAME records. Out of the box, acme-dns expects you to use randomly-generated domains (because it is often used for scalable mass hosting). However it should be technically possible to seed the acme-

I have a simple setup with uacme and a small shell script hook that always expects a single hostname as the cnam target I could share. My script uses cliudflare API to update the DNS but easy to change to whatever other provider.

[mwild1]

Good point about the wildcard, of course that makes sense.

As for the scripts, yes - the problem is the "whatever other provider". The reason for running a small authoritative DNS server ourselves is because it allows us to be provider-independent. If people prefer a provider-specific setup, they can always set up certbot externally to Snikket and mount in the certificates. We just want something that works for as many as people as possible with minimal configuration.

[poVoq]

Something like this could maybe also be used: https://github.com/octodns/octodns

[Rijul-A]

I have been playing around with acme-dns, and noticed one thing that might be worth documenting for those who, like me, use Cloudflare as a DNS server.

1. The admin creates A and/or AAAA records for their Snikket server, e.g. `snikket.example.com`, pointing to their instance's IP address(es).

2. The admin creates an NS record for `snikket.example.com` pointing to `snikket.example.com`.

When I attempted to do the above two steps, I got an error saying, "Non-NS records with that host already exist. (Code: 81055)." I even tried to switch the order around, but that resulted in, "NS records with that host already exist. (Code: 81056)."

Another user has reported this issue at joohoi/acme-dns#258, with the conclusion being that Cloudflare does not support glue records (at least not on the free plan); so this approach is not possible. I tried setting up the glue record at my registrar, but that didn't work either. The workaround, as documented in the issue, is to replace the first two steps with:

1. The admin creates A and/or AAAA records for their Snikket DNS server, e.g. snikket-ns.example.com, pointing to their instance's IP address(es).
2. The admin creates an NS record for snikket.example.com pointing to snikket-ns.example.com.

[apfsx]

Chiming in to say I would love for this to be a feature so I could use my domain for both purposes without a subdomain for Snikket.

[link2xt]

2. The admin creates an NS record for snikket.example.com pointing to snikket.example.com.

I have tried it when doing DNS for https://github.com/deltachat/chatmail, see deltachat/chatmail#44
I tried running https://www.nlnetlabs.nl/projects/nsd/about/ DNS server and delegating the domain to it.

Creating both A/AAAA and NS record on the same domain does not work, NS record "delegates" A/AAAA record to this server as well. So if you want to use NS record and run your own DNS server, you need a separate domain for DNS server, e.g. ns.example.org has A record and runs NSD, while snikket.example.org is delegated to it.

The best option I found for using a single domain (say snikket.example.org) is to create a subdomain ns.snikket.example.org, run DNS there, delegate chat.snikket.example.org to it and then individually delegate all snikket.example.org records one-by-one to chat.snikket.example.org via CNAME.

We do not use this solution in the end as it is quite ugly and print DNS records instead to stdout or file so admin can decide how they want to set them up, e.g. by copying to DNS server or uploading via Hetzner or Cloudflare API. Running anything else on the same domain is not supported.