Struggling with HTTPS Record

I own domain, which is now configured to use deSEC’s two nameservers with my domain registrar ( &

I am trying to host a service at the subdomain

The service is intermittently available at

Indeed, with the service running, if I configure a client to connect to, then the client connects to the service successfully. I now need to get connections to to connect successfully too.

My understanding was that this could be achieved with a HTTPS Resource Record. In the deSEC web UI I have configured the following:

SUBNAME: neuro
SERVICE PARAMETERS: alpn=h3 port=53518 ipv4hint= ipv6hint=2a00:7142:20:c913:23fd:24da:7ace:fdf8 detects the record appropriately. I have also tried adding A & AAAA records for just as well as both and using the ipv4 & ipv6 addresses seen in the service parameters above. I wait for a ping from both the client and server machines to resolve, which it does successfully, before attempting to connect with the client.

I have also tried declaring h3,h2,h1 ALPN’s in the HTTPS record just in case, but nothing allows the client to connect to the service when targeting

All the while, switching the target from to results in instant success again. displays all green ticks except for one red cross for That red cross is: “No DS records found for in the is zone” - However I’m not sure if this is important, seeing as DNSKEYS appear to be ok with green ticks?

Is it possible to use deSEC to have point to so that users can connect via a FQDN? If so, how?

What client do you use? The last time i tested https-record, the client support was very limited.

Thank you for the quick reply Markus,

I am deploying the Headscale Coordination server as the service, so the client is Tailscale.

I do need to do more investigation into the finer details, but I believe the Tailscale client supports QUIC (there is an open issue with QUIC not working using the exit node, but I am not using the exit node).

Also, would you expect that to work with h2/h1 alpns? As I did try that configuration without much luck - I will reintroduce those options just in case they didn’t propagate.

https records are a feature which only modern browsers support. I would assume as of today that all other clients (curl, wget, tailscale, etc.) do not support this. The standard is new, implementations rare.

Right, ok, I see. Is there an alternative, more widely supported record implementation that would achieve resolving a subdomain.domain.tld to an IP:Port combination?

Maybe “SRV Resource Record”, but check with Headscale/Tailscale what they support.