Cert for domain with only internal / delegated DNS

Problem: Internal valid domain with only internal reachable DNS (samba active directory).
So you must delegate your DNS to your internal server. If you don't, many clients (Firefox, iOS, Android) won't talk to the DHCP assigned internal DNS server but to there build-in DNS (,, ...).

Example for our office:
Domain: cologne.intradesys.com
dig +trace -t NS cologne.intradesys.com
DNS-server for this Domain: hal-cologne.intradesys.com. with internal IP

So certbot can't reach and can't resolve the DNS challenge for _acme-challenge.foo.cologne.intradesys.com

CNAME wouldn't help as the CNAME would be in the internal cologne.intradesys.com zone as well..

So it should be possible to set the DNS challenge to _acme-challenge.intradesys.com which would resolve external (as needed for wildcard certs...)

1 Like

Actually you can simply create the DNS TXT record _acme-challenge.foo.cologne.intradesys.com on your external DNS server directly. A lot of company already doing it.

You are not obliged to delegate foo.cologne.intradesys.com to some other servers to create _acme-challenge.foo.cologne.intradesys.com. This record can exist on the intradesys.com zone directly.


No not solved, wrong klicked, this won't work:

If you ask "our" nameserver for intradesys.com

dig -t txt _acme-challenge.foo.cologne.intradesys.com @ns8.zoneedit.com.

The server knows that it self delegates the zone for cologne.intradesys.com and you get this as answer:

;_acme-challenge.foo.cologne.intradesys.com. IN TXT

cologne.intradesys.com. 1200 IN NS hal-cologne.intradesys.com.
cologne.intradesys.com. 1200 IN NS hal-failover-cologne.intradesys.com.

hal-cologne.intradesys.com. 1800 IN A
hal-failover-cologne.intradesys.com. 1800 IN A

Domain: foo.cologne.intradesys.com
Type: dns
Detail: DNS problem: SERVFAIL looking up TXT for _acme-challenge.foo.cologne.intradesys.com - the domain's nameservers may be malfunctioning

I think you can try creating _acme-challenge.foo.cologne.intradesys.com. on the zone intradesys.com directly? (not on the delegated zone cologne.intradesys.com)

(similar concept of glue record)

1 Like

Yes, i did, the txt-record is there, but the server unfortunately knows, that it is not responsible for this record. The only answer is the (internal) adress of the responsible DNS server (in our office...).

Although AD must use it's own DNS server, your external DNS server is not obliged to delegate the zone to AD.

Why your external DNS server need resolve cologne.intradesys.com to AD? As long as your internal clients set DNS to your internal AD, there is no requirement that cologne.intradesys.com have to be delegated from external DNS server.

Or you simply expose your AD server as DNS server? In this case you would need to consider Split-Brain DNS


Many clients (Firefox, Windows for arm) rely on there "own" DNS server ( and won't talk to the DNS-server given by your dhcp-server.
So without delegation you have several clients that can't resolve internal domains like foo.cologne.intradesys.com...

Why? You mean your users override the default system DNS settings? Firefox does not use alternative DNS server unless explicitly configured to do so.

If you control their gateway, you can NAT (or any other external IP) to an internal DNS resolver.
One that can have a conditional forward for the internal zone.


I expect this largely works now but is eventually not going to work.

See also



That should use TCP port 853 [securely].
I was referring to TCP/UDP port 53 [only].


Yes, my thought is just that some day network administrators won't be able to consistently choose what resolver services clients on their networks are required to use, unless they block connectivity to fairly large portions of the Internet entirely.


Yes, until now you can trick out these devices, but for the next years you will need internal/own consistent DNS (with sec and over https) with valid certs.

The nice thing with let's encrypt: you don't have to ask anybody in your (smaller - not CA-pinning) company to get valid certs for any intranet-device.
You don't have to ask your manager for yearly 15$ for a cert. The costs are not the problem, but the manager, who needs to approve the 15$ :wink:

1 Like

Those big companies actually already doing so - by forcing them to use a proxy.


This is so true and the real reason so much stuff gets built internally rather than just buying something that does the same job.

You can also use certs from a cloud service like Azure or AWS, that way the cert gets hidden in the cloud billing they already have :slight_smile:


DNS over HTTPS requires a IP address certificate, which can only be public IP address if it is to be issued by a public CA.

Looks like you'd need a public DNS service for your intranet names in order to get a public CA to validate your domains. [it doesn't matter if IPs are internal, it matters if the CA can query your DNS]

Alternatively, run your own CA using smallstep etc and distribute your own trusted root certificate to all devices that need to connect using TLS to internal services.


I read RFC 8484 and I don't see using an IP cert as being a requirement.
FWIW, I use name-based certs; And they work just as well.


Using a hostname instead of IP address however could lead to catch-22 issues, as the hostname would need to be resolved and one needs a DNS server for that. If the hostname would be the only method of resolving itself, it would fail.

However, one could e.g. use /etc/hosts to "prime" the initial resolving of the DNS server hostname.


That is the same "catch-22" we all deal with for everyday DNS.
Where are my trusted roots?