Daniel Nashed's Blog

Knot DNS: A Lightweight Authoritative DNS Server for ACME and Dynamic DNS

Running your own authoritative DNS server for a sub-domain can be useful even if your main DNS domains are hosted by an external provider.

For my setup, I wanted to cover two use cases:

• ACME DNS-01 validation using CNAME delegation, without modifying the DNS records of the primary domain.
• Dynamic DNS (DDNS) for devices with changing public IP addresses, without depending on a third-party DDNS service.

Both can be implemented with Knot DNS (https://www.knot-dns.cz/), an open-source authoritative DNS server that supports DNS UPDATE (RFC 2136), TSIG authentication, and fine-grained access control.

Delegating DNS Subdomains

The main domain remains hosted by the existing DNS provider. Only two dedicated subdomains are delegated to the Knot DNS server.

For example:

• validation.example.com — ACME DNS-01 validation
• dyn.example.com — Dynamic DNS records

The DNS provider only needs to configure the appropriate NS delegation records pointing to our authoritative Knot DNS server.

This allows us to manage both zones independently without moving the primary domain or changing its existing DNS infrastructure.

1. ACME DNS-01 Validation with CNAME Delegation

ACME DNS-01 challenges require a TXT record under _acme-challenge to prove control of a domain.

Instead of granting an ACME client permission to modify the primary DNS zone, we can use a CNAME record to redirect validation to our dedicated zone.

For example, in the primary DNS zone:

_acme-challenge.mail.example.com. IN CNAME mail.validation.example.com.


The ACME client creates the corresponding TXT record in the delegated zone:


mail.validation.example.com. IN TXT "acme-validation-token"


The certificate authority follows the CNAME and checks the TXT record.
The main advantage is that the ACME client only requires update permissions for the dedicated validation zone.

This is particularly interesting for HCL Domino CertMgr, which supports DNS-01 validation through DNS providers and DNS UPDATE integrations.

Multiple domains, including domains hosted at different DNS providers, can use the same validation infrastructure through CNAME delegation.

Benefits

• No DNS API credentials for the primary DNS provider are required.
• ACME clients receive access only to a dedicated validation zone.
• DNS-01 validation works without exposing an HTTP service.
• Wildcard certificate validation is supported.
• The same DNS infrastructure can serve multiple domains and certificate management systems.

2. Running Our Own Dynamic DNS Service

The second use case is a private Dynamic DNS service.

Many routers and mobile devices have changing public IP addresses. A DDNS client can update a DNS record whenever the public address changes.

For example:

slate7.dyn.example.com. IN A 203.0.113.25


Instead of using a commercial Dynamic DNS provider, the device sends an authenticated DNS UPDATE request directly to Knot DNS.

The configuration uses a dedicated TSIG key for this purpose.

acl:
 - id: slate7-updates
   key: slate7-ddns
   action: update
   update-type: [A, AAAA]
   update-owner: name
   update-owner-name: slate7.dyn.example.com.

This restricts the client to updating only the A and AAAA records belonging to its own hostname.

Even with valid TSIG credentials, the client cannot update arbitrary records in the zone.

For devices with dynamic public addresses, restricting access by source IP would be impractical. TSIG authentication and record-level restrictions provide the necessary authorization.

The result is a simple, self-hosted DDNS service based on standard DNS protocols rather than a proprietary provider API.

3. Knot DNS Configuration

Both use cases can be configured on the same Knot DNS instance.

The following example shows the relevant configuration:

server:
 listen: 0.0.0.0@53

log:
 - target: stdout
   any: info

key:
 - id: acme-update
   algorithm: hmac-sha256
   secret: xxxx=

 - id: slate7-ddns
   algorithm: hmac-sha256
   secret: yyyy=

acl:
 - id: acme-updates
   address: [127.0.0.1, 10.100.0.0/16, 1.2.3.4/32]
   key: acme-update
   action: update
   update-type: TXT

 - id: slate7-updates
   key: slate7-ddns
   action: update
   update-type: [A, AAAA]
   update-owner: name
   update-owner-name: slate7.dyn.example.com.

zone:
 - domain: validation.example.com
   storage: /storage/zones
   file: validation.example.com.zone
   acl: acme-updates
   dnssec-signing: off

 - domain: dyn.example.com
   storage: /storage/zones
   file: dyn.example.com.zone
   acl: slate7-updates
   dnssec-signing: off


The configuration separates the two applications using different TSIG keys and ACLs.

ACME updates are restricted to TXT records and a list of trusted source networks.

Dynamic DNS updates are restricted to A and AAAA records for one specific hostname.

Both zones are authoritative and independently managed.

4. Why Knot DNS?

Knot DNS is designed as a high-performance authoritative DNS server. It is not a general-purpose recursive DNS resolver.

For this scenario, that is exactly what we need.

It provides:

• Standard DNS UPDATE support (RFC 2136)
• TSIG authentication
• Granular ACLs for update types and record ownership
• Independent authoritative DNS zones
• DNSSEC support when required
• A small footprint suitable for Linux servers and containers

There is no need to implement a custom HTTP-based Dynamic DNS API or integrate with a particular DNS provider.

Clients can use the standard `nsupdate` utility or any compatible RFC 2136 implementation.

Conclusion

Delegating a couple of dedicated DNS subdomains to a self-hosted Knot DNS server provides a flexible foundation for two useful services.

ACME DNS-01 validation becomes independent of the primary DNS provider, while Dynamic DNS can be handled directly through authenticated DNS UPDATE requests.
Both services use open standards, have separate credentials and permissions, and can run on the same lightweight authoritative DNS infrastructure.
This is particularly useful in environments where certificate automation, remote devices, and self-hosted infrastructure need to work together without relying on provider-specific APIs.

• Comments [0]