IPNS record DNSSEC proofs

[Winterhuman]

Related: ipfs/kubo#8799

Using TXT records, you can link https://domain.tld to /ipns/k51key..., however, navigating to k51key... will not redirect you to the domain. Moreover, anyone can create a TXT record to point their domain to k51key... without anything stopping them. This could be seen as problematic since users may assume "Well, if the domain points to k51key, then I guess the domain and the record owners are the same and I should use https://false-domain.tld from now on".

Handshake, a decentralised DNS alternative, demonstrated that DNSSEC proofs can be used to prove ownership over a domain (https://github.com/handshake-org/hsd#claiming-a-name). Using DNSSEC proofs in IPNS records could do a few things:

1. IPNS records could add new fields which allow specifying a domain alongside a DNSSEC proof, IPFS Gateways would then know to redirect https://k51key.ipns.gateway.tld to https://domain-tld.ipns.gateway.tld in order to give users a more human-friendly link to the IPNS address.
2. If given https://false--domain-tld.ipns.gateway.tld, IPFS Gateways can check the DNSSEC proof in the IPNS record to verify that the owner of https://false-domain.tld and k51key... are the same. If the DNSSEC proof doesn't work for https://false-domain.tld, the Gateway will inform/give an error to the user that this domain is claiming ownership of resources that aren't there's.
3. If the record owner does not want any domain to be able to point to k51key..., the domain field can be left blank and the DNSSEC field can be set to something such as deny to prevent any form of domain-tld.ipns.gateway.tld association.
4. The record owner could choose to leave the domain field set to blank, but still set the DNSSEC field, to allow their domain to link to k51key..., but prevent IPFS Gateways from redirecting https://k51key.ipns.gateway.tld to https://domain-tld.ipns.gateway.tld.
5. Some applications might want to use the domain + DNSSEC fields to introduce new features and concepts in unintended ways, maybe using the domain field to point to other gateways, or for verified redirection, etc.

[Winterhuman]

Just realised #296 (comment) covers this idea already. Closing issue