Checklist

• My issue is specific & actionable.
• I am not suggesting a protocol enhancement.
• I have searched on the issue tracker for my issue.

Description

#128 focuses on serving verifiable IPFS content. However, an important part of this content is requested via a naming system, such as DNS with DNSLink.
Ideally, users should be able to verify the way a gateway maps example.com to dnslink=/ipfs/bafy.... Honest gateway operators would also benefit from this work, as they can provably tell they are honest.

In #6129, @Bren2010 proposed a way to serialise DNS resolution along with its DNSSEC proof, in addition to DAG content. DAG is now taken care of by CAR (#8769), so the focus should be on the serving the serialised resolution and its proof. The proof should at least be served along with CAR response.

The only requirement on the user side is to trust DNSSEC Root keys.

Proposed design

DNS and DNSSEC records should be serialised, and passed along with the answer.

Serialisation

The serialisation could be done as follow

1. Cloudlare verifiable gateway implementation, an ad-hoc serialisation model - GitHub
2. IETF defunct serialisation standard, not updated for the last 11 years - IETF archive
3. Leveraging an IPLD format to map DNS information, I don't know enough about IPLD to architecture this proposition with it - IPLD docs

Response

Passing the serialised DNS resolution to the answer could be done via

1. an HTTP Response header, but that might be too small for certain DNS setup
2. a header to the returned binary file. This is the approach Cloudflare took. This could work well along with CAR, as an extension, providing Named Resolution aRchive
3. A follow up call, but this would require state to be maintained on the gateway side

Retrieval of DNSSEC root Key-Signing Key

DNSSEC root keys could be included along with the IPFS node, or fetched at start. I would rather use the first option, as this would avoid issues with root resolution.
At the time of writing, this is the root I can resolve.

dig @1.1.1.1 . dnskey +nosplit | grep  -e '^\.' | grep 257
.			171885	IN	DNSKEY	257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=

Non-goals

DNS is not the only name root used by IPFS nodes. Users can also leverage ENS or unstoppable for instance. These proofs cannot be serialised in such a way a user without an Ethereum nodes can validate them. Serving their proofs is not a goal of this issue.