Enhance DNSLink with something similar to HTTPSSVC records

[RubenKelevra]

Currently, it takes a lot of time to find the right data for a website that has a DNSLink record in DNS.

Since most websites are hosted on a known node with a fixed IP/Port and/or NodeID we could reduce the time-to-first-byte significantly with a "hint" record which avoids that a node has to crawl the DHT in most cases.

A node that requests an ipns would also request the SRV-records (for IPFS) for this domain name, which leads to hostnames of the nodes.

Those hostnames can be resolved to A/AAAA records, so the node now knows the port and the IP. We need an additional record type for the Node-ID on the hostnames. The CERT records look like a perfect fit for this.

On the first roundtrip the node would request:

• A/AAAA record (for HTTPS fallback)
• IPNS record
• SRV record (for ipfs)

If there's an SRV record, the second roundtrip would request:

• the A/AAAA record for these hostnames
• The CERT records for these hostnames

If both are supplied the node can connect to the IP/Port with a known public key and directly request the IPNS/CID from the specified node.

Since QUIC can deliver the first data on the first roundtrip, we should be able to receive the first byte after the three roundtrips (two to DNS).

[lidel]

Closing, as I believe this idea is already tracked in:

• Content routing hint via DNS records #6516: Content routing hint via DNS records
  • It improves on the SRV+CERT idea by using TXT on the same hostname as dnslink itself -- this way no additional DNS lookups are added.
• Content routing hint via HTTP headers #6515: Content routing hint via HTTP headers