FR: Support the resolution of HTTPS Resource Records (DNS) in the Tailscale client for coordination server connections

### What are you trying to do?

I own a domain, lets call it example.com

I am currently trying to self host the coordination server via headscale at subdomain.example.com (While I understand headscale is not affiliated with Tailscale, however the resolution to this issue appears to sit on the client side, and as the tailscale client does support the `--login-server` flag, I am hoping this will still be considered relevant).

However the challenge I have is that I have a dynamic IP address. To work around this, I am using a VPN with port forwarding support - the VPN service provides me with a dedicated port number & publicly accessible IP address, with all traffic destined for that ip:port combination automatically forwarded to my local server, running headscale. I have tested connecting to the headscale service by specifying https://[ip]:[port] as the login-server, and the Tailscale client is able to connect successfully. I can also connect via https://subdomain.example.com:[port], so it seems my solution is suitable for the service so far...

However, I am now trying to host the coordination server at https://subdomain.example.com without the need to specify the port number when connecting, in case the port number changes at any point in the future. Ideally, users of the tailnet only ever have to remember the subdomain and domain in order to connect, with the up to date connection specifics such as IP & port being handled at the domain administration level.

Thanks to the new HTTPS RR (Resource Record) type, it is now possible to provide resolution of IP address, Port, and supported connection protocol at the DNS resolution level, which is incredibly convenient. A Single HTTPS Record for the subdomain would be the only configuration needed to handle resolution of traffic to https://subdomain.domain.com to the publicly accessible endpoint. There are 3 major benefits to handling connectivity resolution in this way:

1) Any changes to the address of the publicly accessible endpoint can be mitigated by automating the update of the HTTPS Record with a single API call, triggered when changes to the IP or Port are detected, massively simplifying domain & service management and removing the onus from the connecting client to seek up to date information entirely - the login server address would always remain the same.

2) The HTTPS resource record facilitates a HTTPS connection with a single call, compared to the multiple calls traditionally required to establish a HTTPS connection. This improves both performance and security (Especially if the h3 protocol is used for the ALPN).

3) By using a VPN intermediary, my real IP address is concealed from public view, supporting privacy.

(Side note, the SRV DNS Record type could also achieve this, however the HTTPS Record standards are more modern, secure, and an SRV record wouldn't offer benefit #2 above).

However, neither the use of an SRV, nor an HTTPS record currently facilitate the connection of a Tailscale client to the Coordination server. After much troubleshooting & support seeking, I have been informed that connecting clients must specifically support the use of these record types in order to utilise them.

The simplicity of this implementation approach & it's ongoing management seems to be unparalleled, especially when considering that clients that can benefit from HTTPS Resource Records need only know the subdomain where a service is hosted, and a single configuration file automatically handles every aspect of the resolving the addressable connection to a service in the majority of network configurations, doing so with excellent security! It seems supporting the use of HTTPS Resource Records is a no-brainer when it comes to removing a ton of headaches from a network administration perspective, and the end user is greeted with a clean URL with which to interface with.

I have yet to find information on what exactly it means for a client to "support" HTTPS Resource Records, but as the responsibility to do so seems to lie with the client, I am hopeful that such support can be added to Tailscale clients.

### How should we solve this?

Support the use of the new HTTPS Resource Record Type for DNS in Tailscale Clients.

Optionally, support the use of SRV Resource Record Types for DNS in Tailscale Clients (increasing service compatibility, at the expense of reduced security and perfomance when compared to the use of HTTPS Resource Records).

If I learn more specifics with regards to how support of such records is defined, I will update this section.

### What is the impact of not solving this?

Tailnet admins using self-hosted login-servers are unable to provide a clean https://subdomain.domain.tld link to end users when hosting via intermediary services in order to mitigate dynamic IP changes, and/or mask their real IP.

End users may need to seek out up to date connection information in the event of changes to address when mitigating dynamic IP disruptions, leading to additional effort on the end users part and a less seamless experience.

HTTPS connections are negotiated with reduced performance / security in comparison to via the handling of an HTTPS Resource Record.

Network administrators are required to undertake comparatively significant effort in many cases to architect a solution that suits their individual environments & use cases, in many cases having to resort to less clean solution that may require the end user to modify their behaviour (undesirable).

As this one solution covers a wide range of network architectures and environments, not solving this results in many niche and specific tailored solutions to be explored and devised, increasing effort, and reducing the liklihood that one scenario's solution can be applied to another.

### Anything else?

Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) at the IETF Datatracker: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/

IETF Specification: https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-12.html

Easy to read summary of the implementation and benefits of HTTPS Resource Records: https://gcore.com/docs/dns/dns-records/what-is-an-https-record-and-how-is-it-configured