[PR #229] Use config api.api_domain for API hostname #356

New issue

Open

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/229
Author: @DigitalBrains1
Created: 5/24/2020
Status: 🔄 Open

Base: master ← Head: api-domain

📝 Commits (1)

9f66a17 Use config api.api_domain for API hostname

📊 Changes

4 files changed (+20 additions, -12 deletions)

View changed files

📝 config.cfg (+3 -0)
📝 dns.go (+7 -2)
📝 main.go (+8 -8)
📝 main_test.go (+2 -2)

📄 Description

WARNING: The actual patch in this PR is intended as a suggestion from someone with no experience with the Go language

So I merely grepped the source, made some changes, tried the result and ran go test -v -race. (I did not use run_tests.sh because the user account doesn't have sudo rights and the user's TMPDIR is executable anyway)

And finally, thanks for your work! I really like what you've made here, it does exactly what I need.

Well, with that out of the way :-)

As #215 notes, there is some duplication of address data due to the need for DNS glue records. Because the DNS server responsible for resolving auth.example.org to an IP address is auth.example.org itself, there is a catch-22 which DNS solves with glue records in the delegating DNS server that serves example.org. Now, whenever an IP address changes, it needs to be changed in two DNS zones.

I'd like to avoid the need for glue records. After I implemented something, I stumbled upon a configuration item in the [api] section that is there but not used (or used only in a dependency): api_domain (leading to the object Config.API.Domain). So I re-implemented using that name. And then finally the realisation came that actually, it was all superfluous for the intended purpose. Why? Because nothing in acme_dns ever checks the hostname used for the HTTPS connection! Still, I spent quite some time on this as I do not know a word of Go and I'm generally fastidious. So this is offered in the hope that it is useful anyway. It offers to configure the hostname for the HTTPS API. At the very least, it makes explicit that actually the HTTPS API does not need to be at the same host name as the DNS zone and/or the DNS server.

Now, given this configuration:

[general]
listen = "[2001:980:a370::8]:53"
protocol = "both6"
domain = "acme-auth.digitalbrains.com"
nsname = "acme-auth-ns.digitalbrains.com"
nsadmin = "hostmaster.digitalbrains.com"
records = [
    "acme-auth.digitalbrains.com. NS acme-auth-ns.digitalbrains.com.",
    "api.acme-auth.digitalbrains.com. AAAA 2001:980:a370::80",
]
debug = false
[database]
engine = "sqlite3"
connection = "/var/local/lib/acme-dns/acme-dns.db"
[api]
ip = "[2001:980:a370::80]"
# Hostname to serve api
# Note that if this is outside our DNS zone, you should provide a TLS cert manually
api_domain = "api.acme-auth.digitalbrains.com"
disable_registration = false
port = "443"
tls = "letsencryptstaging"
tls_cert_privkey = "/etc/tls/example.org/privkey.pem"
tls_cert_fullchain = "/etc/tls/example.org/fullchain.pem"
acme_cache_dir = "api-certs"
corsorigins = [
    "*"
]
use_header = false
header_name = "X-Forwarded-For"
[logconfig]
loglevel = "debug"
logtype = "stdout"
logformat = "text"

we have the HTTPS API server running on https://api.acme-auth.digitalbrains.com/ and serving the DNS through the following delegation:

$ORIGIN digitalbrains.com.
acme-auth-ns AAAA 2001:980:a370::8
acme-auth NS acme-auth-ns

Note that the IP address for the nameserver now only needs to be listed in the digitalbrains.com zone. The IP address for the HTTPS API is only in the subdomain.

What I am actually using is this (some stuff elided):

[general]
listen = "[2001:980:a370::8]:53"
protocol = "both6"
domain = "chal.acme-auth.digitalbrains.com"
nsname = "acme-auth.digitalbrains.com"
nsadmin = "hostmaster.digitalbrains.com"
records = [
    "chal.acme-auth.digitalbrains.com. NS acme-auth.digitalbrains.com.",
]
[api]
ip = "[2001:980:a370::8]"
api_domain = "acme-auth.digitalbrains.com"
tls = "cert"
tls_cert_privkey = "/etc/letsencrypt/live/acme-auth.digitalbrains.com/privkey.pem"
tls_cert_fullchain = "/etc/letsencrypt/live/acme-auth.digitalbrains.com/fullchain.pem"

and the following delegation from digitalbrains.com:

$ORIGIN digitalbrains.com.
acme-auth               AAAA    2001:980:a370::8
chal.acme-auth          NS      acme-auth

This means the built-in support for getting a certificate through ACME no longer works. I use this instead:

certbot certonly -d acme-auth.digitalbrains.com --standalone --preferred-challenges http --http-01-address 2001:980:a370::8

And because the built-in support for the certificate is no longer needed, this configuration actually runs fine with an unchanged, original acme-dns daemon.

By the way, first I thought that config.nsname would be used in several important places, but upon inspection it turned out config.nsname is only used in the SOA record to indicate the MNAME (RFC 1035 section 3.3.13), which I think has little application outside Dynamic DNS. Dynamic DNS is not used here, so it's mostly decorative. You might as well hard-code the SOA MNAME to config.domain so there is one less option in the config file.

_{🔄 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/229 **Author:** [@DigitalBrains1](https://github.com/DigitalBrains1) **Created:** 5/24/2020 **Status:** 🔄 Open **Base:** `master` ← **Head:** `api-domain` --- ### 📝 Commits (1) - [`9f66a17`](https://github.com/acme-dns/acme-dns/commit/9f66a17204fc50df5f6dcc35abbc015517029210) Use config api.api_domain for API hostname ### 📊 Changes **4 files changed** (+20 additions, -12 deletions) <details> <summary>View changed files</summary> 📝 `config.cfg` (+3 -0) 📝 `dns.go` (+7 -2) 📝 `main.go` (+8 -8) 📝 `main_test.go` (+2 -2) </details> ### 📄 Description **WARNING: The actual patch in this PR is intended as a suggestion from someone with no experience with the Go language** So I merely grepped the source, made some changes, tried the result and ran `go test -v -race`. (I did not use `run_tests.sh` because the user account doesn't have `sudo` rights and the user's `TMPDIR` is executable anyway) And finally, thanks for your work! I really like what you've made here, it does exactly what I need. Well, with that out of the way :-) As #215 notes, there is some duplication of address data due to the need for DNS glue records. Because the DNS server responsible for resolving `auth.example.org` to an IP address is `auth.example.org` itself, there is a catch-22 which DNS solves with glue records in the delegating DNS server that serves `example.org`. Now, whenever an IP address changes, it needs to be changed in two DNS zones. I'd like to avoid the need for glue records. After I implemented something, I stumbled upon a configuration item in the `[api]` section that is there but not used (or used only in a dependency): `api_domain` (leading to the object `Config.API.Domain`). So I re-implemented using that name. And then finally the realisation came that actually, it was all superfluous for the intended purpose. Why? Because nothing in `acme_dns` ever checks the hostname used for the HTTPS connection! Still, I spent quite some time on this as I do not know a word of Go and I'm generally fastidious. So this is offered in the hope that it is useful anyway. It offers to configure the hostname for the HTTPS API. At the very least, it makes explicit that actually the HTTPS API does not need to be at the same host name as the DNS zone and/or the DNS server. Now, given this configuration: ``` [general] listen = "[2001:980:a370::8]:53" protocol = "both6" domain = "acme-auth.digitalbrains.com" nsname = "acme-auth-ns.digitalbrains.com" nsadmin = "hostmaster.digitalbrains.com" records = [ "acme-auth.digitalbrains.com. NS acme-auth-ns.digitalbrains.com.", "api.acme-auth.digitalbrains.com. AAAA 2001:980:a370::80", ] debug = false [database] engine = "sqlite3" connection = "/var/local/lib/acme-dns/acme-dns.db" [api] ip = "[2001:980:a370::80]" # Hostname to serve api # Note that if this is outside our DNS zone, you should provide a TLS cert manually api_domain = "api.acme-auth.digitalbrains.com" disable_registration = false port = "443" tls = "letsencryptstaging" tls_cert_privkey = "/etc/tls/example.org/privkey.pem" tls_cert_fullchain = "/etc/tls/example.org/fullchain.pem" acme_cache_dir = "api-certs" corsorigins = [ "*" ] use_header = false header_name = "X-Forwarded-For" [logconfig] loglevel = "debug" logtype = "stdout" logformat = "text" ``` we have the HTTPS API server running on `https://api.acme-auth.digitalbrains.com/` and serving the DNS through the following delegation: ``` $ORIGIN digitalbrains.com. acme-auth-ns AAAA 2001:980:a370::8 acme-auth NS acme-auth-ns ``` Note that the IP address for the nameserver now only needs to be listed in the `digitalbrains.com` zone. The IP address for the HTTPS API is only in the subdomain. What I am actually using is this (some stuff elided): ``` [general] listen = "[2001:980:a370::8]:53" protocol = "both6" domain = "chal.acme-auth.digitalbrains.com" nsname = "acme-auth.digitalbrains.com" nsadmin = "hostmaster.digitalbrains.com" records = [ "chal.acme-auth.digitalbrains.com. NS acme-auth.digitalbrains.com.", ] [api] ip = "[2001:980:a370::8]" api_domain = "acme-auth.digitalbrains.com" tls = "cert" tls_cert_privkey = "/etc/letsencrypt/live/acme-auth.digitalbrains.com/privkey.pem" tls_cert_fullchain = "/etc/letsencrypt/live/acme-auth.digitalbrains.com/fullchain.pem" ``` and the following delegation from `digitalbrains.com`: ``` $ORIGIN digitalbrains.com. acme-auth AAAA 2001:980:a370::8 chal.acme-auth NS acme-auth ``` This means the built-in support for getting a certificate through ACME no longer works. I use this instead: ``` certbot certonly -d acme-auth.digitalbrains.com --standalone --preferred-challenges http --http-01-address 2001:980:a370::8 ``` And because the built-in support for the certificate is no longer needed, this configuration actually runs fine with an unchanged, original `acme-dns` daemon. By the way, first I thought that `config.nsname` would be used in several important places, but upon inspection it turned out `config.nsname` is only used in the SOA record to indicate the MNAME ([RFC 1035 section 3.3.13](https://tools.ietf.org/html/rfc1035#section-3.3.13)), which I think has little application outside [Dynamic DNS](https://tools.ietf.org/html/rfc2136). Dynamic DNS is not used here, so it's mostly decorative. You might as well hard-code the SOA MNAME to `config.domain` so there is one less option in the config file. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>