[PR #243] [MERGED] Relax subdomain validation from UUID to actual subdomain #355

New issue

Closed

opened 2026-03-13 16:19:19 +03:00 by kerem · 0 comments

kerem commented

2026-03-13 16:19:19 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/acme-dns/acme-dns/pull/243
Author: @jvanasco
Created: 9/8/2020
Status: ✅ Merged
Merged: 1/11/2021
Merged by: @joohoi

Base: master ← Head: feature-relaxed_validation

📝 Commits (1)

d099acd relax subdomain validation from UUID to actual subdomain

📊 Changes

2 files changed (+9 additions, -6 deletions)

View changed files

📝 validation.go (+6 -5)
📝 validation_test.go (+3 -1)

📄 Description

I hope you will consider this PR as it will make implementing and maintaining a private acme-dns server easier for certain users. I fully understand the concerns against merging this, and won't be too disappointed if rejected... but I do hope you consider this...

The current check for valid subdomains ( github.com/joohoi/acme-dns@75d4a30c1f/validation.go (L27-L33) ) parses the subdomain candidate to ensure it is a UUID. This works perfectly, because acme-dns generates UUIDs for subdomains. UUID created == UUID validated. Simple enough!

This PR replaces the UUID parsing with a regular expression to check if the payload is actually a valid subdomain component (initial and trailing characters are alpha-numeric, middle characters are alphanumeric + dash).

The reason for this PR - this change will allow an acme-dns administrator to manually update the database after a call to /register, and replace the generated uuid subdomain with a custom domain. This ability allows for an ACME user to delegate authorization to predictable subdomains on the acme-dns server - which can then streamline enrollment and make reinstalls or server changes painless. For example, the change to DNS when validating foo.example.com might be be:

- CNAME	_acme-challenge	uuid-uuid-uuid-uuid.auth.example.com
+ CNAME	_acme-challenge	com-example-foo.auth.example.com

This PR does not support this feature itself, nor am I proposing that acme-dns support this feature; this PR simply enables a server administrator to have a bit more control if they want to. The acme-dns server administrator would still need to manually edit the database and update the records and txt tables with a custom domain. This is all advanced stuff that violates the Public API, but small changes like this PR open up a lot of possibilities.

Getting custom subdomains to work with acme-dns is tricky. Because the subdomain is validated when /update is invoked, an acme-dns client must use the original subdomain (i.e. the records table must remain intact). I've been using a hack to update the subdomains in the txt table after invoking an /update, but that takes increasingly more work to keep running and won't scale well.

I would love a public api tool/script that admins could use to handle some of this stuff too, like #161 and even something to update the subdomain on an account... but I think this is a good first step for a certain type of users.

99 out of 100 acme-dns users will not need this feature -- but those working with automated systems and/or whitelabel platforms do. As we often do not control the DNS ourselves we need the abilities to (1) pre-determine target subdomains, because we are telling out clients where/how to delegate; (2) ensure/force a set of credentials into the database, because our customers must have a seamless experience if we encounter a data loss (accidents, server migrations, etc).

Thank you for your consideration.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/acme-dns/acme-dns/pull/243 **Author:** [@jvanasco](https://github.com/jvanasco) **Created:** 9/8/2020 **Status:** ✅ Merged **Merged:** 1/11/2021 **Merged by:** [@joohoi](https://github.com/joohoi) **Base:** `master` ← **Head:** `feature-relaxed_validation` --- ### 📝 Commits (1) - [`d099acd`](https://github.com/acme-dns/acme-dns/commit/d099acd86552078d074dd942165453349b903d26) relax subdomain validation from UUID to actual subdomain ### 📊 Changes **2 files changed** (+9 additions, -6 deletions) <details> <summary>View changed files</summary> 📝 `validation.go` (+6 -5) 📝 `validation_test.go` (+3 -1) </details> ### 📄 Description I hope you will consider this PR as it will make implementing and maintaining a private acme-dns server easier for certain users. I fully understand the concerns against merging this, and won't be too disappointed if rejected... but I do hope you consider this... The current check for valid subdomains ( https://github.com/joohoi/acme-dns/blob/75d4a30c1fefcc64a2b90183e42feeb8c59cbdd2/validation.go#L27-L33 ) parses the subdomain candidate to ensure it is a UUID. This works perfectly, because acme-dns generates UUIDs for subdomains. UUID created == UUID validated. Simple enough! This PR replaces the UUID parsing with a regular expression to check if the payload is actually a valid subdomain component (initial and trailing characters are alpha-numeric, middle characters are alphanumeric + dash). The reason for this PR - this change will allow an acme-dns administrator to manually update the database after a call to `/register`, and replace the generated uuid subdomain with a custom domain. This ability allows for an ACME user to delegate authorization to predictable subdomains on the acme-dns server - which can then streamline enrollment and make reinstalls or server changes painless. For example, the change to DNS when validating `foo.example.com` might be be: - CNAME _acme-challenge uuid-uuid-uuid-uuid.auth.example.com + CNAME _acme-challenge com-example-foo.auth.example.com This PR does not support this feature itself, nor am I proposing that acme-dns support this feature; this PR simply enables a server administrator to have a bit more control if they want to. The acme-dns server administrator would still need to manually edit the database and update the `records` and `txt` tables with a custom domain. This is all advanced stuff that violates the Public API, but small changes like this PR open up a lot of possibilities. Getting custom subdomains to work with acme-dns is tricky. Because the subdomain is validated when `/update` is invoked, an acme-dns client must use the original subdomain (i.e. the `records` table must remain intact). I've been using a hack to update the subdomains in the `txt` table after invoking an `/update`, but that takes increasingly more work to keep running and won't scale well. I would love a public api tool/script that admins could use to handle some of this stuff too, like #161 and even something to update the subdomain on an account... but I think this is a good first step for a certain type of users. 99 out of 100 acme-dns users will not need this feature -- but those working with automated systems and/or whitelabel platforms do. As we often do not control the DNS ourselves we need the abilities to (1) pre-determine target subdomains, because we are telling out clients where/how to delegate; (2) ensure/force a set of credentials into the database, because our customers must have a seamless experience if we encounter a data loss (accidents, server migrations, etc). Thank you for your consideration. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>