Possible to share port for web console and DoH?

[IngmarStein]

Is it possible to configure Technitium DNS so that the web console and DoH are served over the same port, e.g. 443?
That is, could I have https://dns.example.com serve the web console and https://dns.example.com/dns-query respond to DNS-over-HTTPS queries?

Or alternatively, could the web server decide via vhost/SNI which service to use (dns.example.com:443 for the web console, doh.example.com:443 for DoH)?

My use case: my self-hosted services are made available through a Cloudflare Zero Trust tunnel. Inside the local network, I bypass Cloudflare and hand out local IPs via DNS. This means that port numbers have to be identical for internal and external access and because Zero Trust HTTPS tunnels can only use port 443, there is no choice. If both the web console and DoH should be accessible over a public network, it would mean running two instances on two local IPs so that I can dispatch to two services on port 443 (in case port sharing is not possible).

[ShreyasZare]

Thanks for asking. The admin web panel service and the DoH service are served by different web servers and combining them is not feasible. This has been done deliberately to keep both services independent so as to not affect each other and also make it possible to provide admin panel access to only firewalled networks for security reasons.

You can still achieve the same result by using a reverse proxy like nginx where you configure domain names and proxy the /dns-query calls to DoH service port. I have similar setup on a few production deployments.

[IngmarStein]

Yes, a reverse proxy is a usable workaround. I just wanted to see if it can be done without one to reduce the number of moving pieces and network hops - especially because both services are provided by the same process.

I have an nginx running anyway which I can repurpose for this, but I guess I need to solve a follow-up problem: can the A records which deliver local addresses be made visible only when the requester is on the local network? External clients would need to use the external addresses. Currently, I set up a conditional forwarding zone which forwards to "this-server" and has a few A & HTTPS records with local IPs. AFAIK, the Split Horizon app can only deliver different static results for a given request but not forward to another server in one case, right?

[ShreyasZare]

Yes, the Split Horizon app can only return either an A or CNAME type record. If you wish to do forwarding based on client IP or subnet then you can do that by using the Advanced Forwarding app.

[IngmarStein]

The example configuration of the Advanced Forwarding app seems to suggest that it's there to forward to different upstream servers. What I'm looking for is:
a) clients on public network: always resolve recursively (with blocking, of course)
b) clients on internal network: honor conditional forwarding zones to resolve some addresses to internal IPs, otherwise same as a)
Would that be possible with the Advanced Forwarding app? The documentation seems a bit sparse.

[ShreyasZare]

Thanks for the details. The requirements you have are still not very clear to me. Is the setup only about serving a specific zone or is it about having a recursive resolver setup in general? I am not clear about the forwarding part. Is the forwarding being done to a public DNS server or some authoritative server which hosts the same zone? If its to an authoritative server then why not use NS records to delegate instead?

If it about having these conditions for a domain name you own then you can use Split Horizon app and use CNAME responses to direct different users to different domain names that resolver as per the requirements. For example, test.example.com APP record would return CNAME public.example.com for public networks while return private.example.com for private networks. Now, you can further configure those subdomain names with the addresses to return.

[IngmarStein]

Let me try to clarify the requirements. The DNS server should

1. act as a recursive resolver in general
2. block ads
3. forward requests for localdomain to the gateway / DHCP server
4. serve internal IPs for services in a domain I own and host on Cloudflare (example.com below)

I currently use it only for internal users, but I'd like to explore the idea to also use it from mobile devices via DoH, hence the original question.

Not resolving the localdomainzone for public clients for should be easy with an ACL.

The CNAME approach is promising. The only problem I see is that I would have to pollute the authoritative example.com zone with public aliases which point to the same target as the original, right?
An example in the Conditional Forward zone:

• internal: service.example.com -> private-service.example.com -> internal IP
• public: service.example.com -> public-service.example.com -> forward to recursive resolver -> Cloudflare NS -> public IP

Or is there a way to resolve public-service.example.com as service.example.com using the recursive resolver? Ideally, the authoritative zone would remain unchanged and all the conditional logic lives inside the local DNS.

An elegant solution would be ACLs on records where missing permissions would result in rendering a record (or zone) "disabled", i.e. processing continues as if the record didn't exist. As far as I can tell, it's currently only possible to deny / refuse a query based on ACLs.

[ShreyasZare]

Thanks for the details. You can configure it with Split Horizon app such that you configure only your private network in the APP json config. So when a request from the configured private network comes, it gets answered by the app. When a request comes from any other network not specified then the APP record wont respond and the DNS server will select the FWD record that you already have to resolve the request.

[IngmarStein]

Oh, an APP record doesn‘t have to be exhaustive? That‘s nice!
The only remaining complication is that I need to produce both A and HTTPS records for local clients in the example.com zone and the Split Horizon app only supports A, AAAA, and CNAME.

[ShreyasZare]

You can use the CNAME option with Split Horizon app and use a subdomain name that only exists in the forwarder zone. Add the A/HTTPS records for that subdomain name and it should work. For public clients, it would anyways resolver normally.

[IngmarStein]

Clever. I‘ll try that out, thanks a lot!

[IngmarStein]

To close the loop: it all works flawlessly, thanks again for the great support!

My conditional forwarding zone for example.com now includes only APP records for Split Horizon which produce CNAME records only for the private network pointing to ${service}.private.example.com. private.example.com is a new primary zone where each service has A and HTTPS records pointing to local IPs and the zone has an ACL which denies queries from outside the private network.

As for external access, I route the web console through a reverse proxy and let the DoH endpoint on port 443 be the direct target of a Zero Trust tunnel (where performance matters more than for the web console). Mobile devices now use https://doh.example.com/dns-query for DNS-over-HTTPS.

[ShreyasZare]

You're welcome!

[IngmarStein]

One addendum: pointing the Cloudflare tunnel to the DoH server directly didn't allow for private/public distinction because Cloudflare uses CF-Connecting-IP instead of X-Real-IP to pass the original client IP, so I had to use a reverse proxy for this case, too. I sent #1067 to enable this use case without a reverse proxy which just shovels one HTTP header to another.

[IngmarStein]

One more follow-up: do you have an idea how to make this setup compatible with DNSSEC?
I noticed that after putting the APP records in the conditional forwarding zone for example.com that validating clients failed:

❯ delv service.example.com @technitium
;; shut down hung fetch while resolving 0x103445400(service.example.com/A)
;; resolution failed: SERVFAIL
;; shut down hung fetch while resolving 0x103446800(service.example.com/DS)

I'm in the process of disabling DNSSEC for example.com, but had been looking into model 2 of multi-signer DNSSEC. If I understood https://developers.cloudflare.com/dns/dnssec/multi-signer-dnssec/setup/ correctly, I would need to add Technitium's ZSK to example.com's DNSKEY record whenever the ZSK rolls over, right?

[ShreyasZare]

Thanks for asking. Technitium DNS server currently does not support multi-signer setup. Also, it does not support online signing so dynamic record types like APP records or ANAME records do not work with signed zones.

If you wish to keep the zone signed and still use these records then it possible to do that by creating another zone for a subdomain name which is unsigned thus allowing you to have APP records. Where as your main zone remains signed and you can use CNAME records to point to those dynamic records. This option is better than unsigning your zone.

[IngmarStein]

Yeah, I saw that idea in #825, but I'm not quite sure how to make that work with Split DNS. Here's what I understood:

In example.com (conditional forward, signed):

• service CNAME service.private
• FWD to this-server (recursive resolver)

In private (primary, unsigned):

• service APP Split Horizon: if private network -> CNAME service.localdomain

In localdomain (primary)

• service A {local IP}
• service HTTPS ipv4Hint={local IP}

That would work for private clients, but from the public network, once the signed zone has unconditionally forwarded to the unsigned zone, I can no longer forward to the recursive resolver.

[ShreyasZare]

Yes, that will have issue since you need to split resolution for the main zone itself. So, its going to be an issue with validating clients downstream.

This setup with DNSSEC would work only when multi-signer is available with online signing.