Struggling with HTTPS Record

Managed DNS Hosting
1

I own domain kines.is, which is now configured to use deSEC’s two nameservers with my domain registrar (ns1.desec.io & ns2.desec.org)

I am trying to host a service at the subdomain neuro.kines.is

The service is intermittently available at 128.127.104.80:53518

Indeed, with the service running, if I configure a client to connect to https://128.127.104.80:53518, then the client connects to the service successfully. I now need to get connections to https://neuro.kines.is 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:

TYPE: HTTPS
SUBNAME: neuro
PRIORITY: 1
TARGET NAME: kines.is.
SERVICE PARAMETERS: alpn=h3 port=53518 ipv4hint=128.127.104.80 ipv6hint=2a00:7142:20:c913:23fd:24da:7ace:fdf8

Nslookup.io detects the record appropriately. I have also tried adding A & AAAA records for just kines.is as well as both kines.is and neuro.kines.is 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 neuro.kines.is, 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 https://neuro.kines.is

All the while, switching the target from https://neuro.kines.is to https://128.127.104.80:53518 results in instant success again.

dnssec-analyzer.verisignlabs.com displays all green ticks except for one red cross for neuro.kines.is. That red cross is: “No DS records found for kines.is 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 https://neuro.kines.is point to https://128.127.104.80:53518 so that users can connect via a FQDN? If so, how?

2

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

3

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.

4

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.

5

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?

6

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