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 (1.1.1.1, 8.8.8.8, ...).
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.
...
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)
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 (1.1.1.1) 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...
If you control their gateway, you can NAT 1.1.1.1 (or any other external IP) to an internal DNS resolver.
One that can have a conditional forward for the internal zone.
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$
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.
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.
