Handshake support for dnslink

[Delivator]

Overview

Currently the dnslink api does not resolve handshake domains.
Using a root domain throws the error "domain" is not a valid domain
And with a subdomain it throws ENOTFOUND: _dnslink.sub.domain TXT record doesn't exist

Design or Proposal

Make use of the included hns full node to resolve handshake dnslinks

[kwypchlo]

I am not sure we want to include that - it seems like we're adding a layer on top of another layer here. You can use the same resolver skylink for dnslink and for handshake domain and it will do the trick.

[kwypchlo]

@dghelm I'll let you chime in, if you agree with my assessment feel free to close this

[Delivator]

@kwypchlo Let me try to give you an practical example.
My goal is to access a skylink/Skapp using a hns domain directly.

I am using a HNS compatible DNS resolver on browser so that I can open hns domains directly without a skynet webportal hns resolver.

I then set a CNAME and TXT record for app2.auth1 like this

Of course in this case I still have the CNAME record pointing to siasky.net so its not fully decentralized, but thats not my point.
(How) Can I do this with the current configuration only using resolver links?

[dghelm]

Just to clarify the conversation, Namebase supports a way to make this work, but we don't support DNSLink first-class like with ENS and traditional domain names. So, using https://docs.siasky.net/integrations/hns-names#hosting-at-an-hns-name you can setup a single HNS domain to point different resources: http://dghelm.hns.to/ and https://dghelm.hns.siasky.net/ . The first uses Namebase's sia.namebase.io. reverse-proxy service, which could be seen as an analog for how Cloudflare delivers ENS content.

With Opera announcing support of HNS names, I think we should consider supporting DNSLink for HNS names without reliance on Namebase operating their service.

As a feature request, DNSLink support for HNS would have the benefits of:

1. creating consistency for support across domain-name types
2. allowing users to set a "default portal" using a CNAME and not trust Namebase

Downsides:

1. Added complexity for how Skynet + HNS interact. We already see this though.
2. TLS/SSL certs could be a pain depending on how Opera handles this. For reference, ENS via metamask just redirects to the skylink, which is easy to handle, and Cloudflare handles name.eth.link URLs.

[pcfreak30]

Just want to ping in and say effectively lume web == handshake for DNSLink. There is no need to implement this as DNSLink as this is really web3 domains. I can see this was questioned a few months ago, but I feel it is a moot issue now.

Additionally the SSL issue is very very hard to solve since you need to trustlessly generate a CA and cert across many portals in a way that's the deterministic for a domain, and then get the browser to programmically use it via an extension, if even possible, and use LUA to serve it.

[dghelm]

Just want to ping in and say effectively lume web == handshake for DNSLink. There is no need to implement this as DNSLink as this is really web3 domains. I can see this was questioned a few months ago, but I feel it is a moot issue now.

Additionally the SSL issue is very very hard to solve since you need to trustlessly generate a CA and cert across many portals in a way that's the deterministic for a domain, and then get the browser to programmically use it via an extension, if even possible, and use LUA to serve it.

Supporting something at a protocol level is different than relying on an external tool to solve it. We could consider this "unsolvable" for the portal, since SSL will be tricky, but that's different than considering it "solved" because another tool has a workaround.

Lume and plenty of HNS Resolvers "solve" this, some in better ways than others, but this isn't the same as using the HNS Full Node on every portal to do this work and in a way that satisfies the developer expectations in the Handshake ecosystem.