Gateway: DNS resolution export with DNSSEC records

[thibmeu]

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.

[lidel]

Thank you for filling this @thibmeu. I'm happy to discuss design, and if you have bandwidth to implement it, also review PR.

My initial thoughts / questions:

• If we add support for returning DNSLink resolution along with its DNSSEC proof, then it should not be limited to CARs, we would return this for every /ipns/{example.com} response.
  • Bit skeptical how useful this is for clients who fetch CAR. In my mind, those clients will most likely don't trust gateway anyway, and do all resolution and validation on their own.
  • However, there is a huge value for mobile clients etc. If we provide DNSSEC proofs for regular responses, HTML websites like https://cf-ipfs.com/ipns/en.wikipedia-on-ipfs.org/wiki/ then these hints will enable vendors like Brave to display some integrity indicator in the user interface (instead of green padlock), which is a big deal.
• DNSSEC roots
  • we would ship implicit ICANN defaults with go-ipfs + allow users to override them via config, per tld or globally, just like we do already with DoH resolvers
    • this should allow people to experiment with non-ICANN roots without the need to fork go-ipfs
• Do we know the average size of serialized resolution?
  • Websites have many subresources, and we don't want to return the same serialized DNS resolution with every response over and over again.
  • I'm thinking Gateway will cache this DNSSEC proof/resolution for some time, just like it caches IPNS record and DNSLink record resolutions, so we could add it as a binary blob to IPFS (format tbd) and return a CID in the header. This way, clients who care will be able to fetch it on-demand.

    Dnslink-Dnssec-Proof: {CID}
    

  • In regard to serialization format: I did not dig too deep into the prior art in https://github.com/cloudflare/go-ipfs/tree/master/namesys/dnssec yet, but it sounds like original DNS records are serialized as protobuf. I think we would change that and use IPLD Data Model using dag-cbor. It will enable use to link to reusable DNSKEY/RR/RRSIGs minimizing the amount of data that needs to be fetched each time clients wants to calculate the DNSSEC proof.

[BigLep]

@thibmeu : is this something you have bandwidth to drive forward?

[thibmeu]

I am still considering to drive it forward. Has this been made part of a roadmap or does it have strong dependencies @BigLep ?

I like the proposition to implement an IPLD based DNS schema. I don't think only returning the CID would suffice, because there would be an expectation for gateways to store the content, which I don't think is a good approach. Gateway should be stateless as much as possible. This was the reasoning behind Cloudflare using a request header to understand if the client is willing to consume the DNS proof, and return it along with the content.

I agree with the mobile client verification, this would be a great improvement. It's light, and makes implementation faster and easier on the browser side.

The size of the resolution varies, especially in the case of a complex DNS setup. For our current implementation, we limit the number of links to 30, which can lead to an overhead in the order of 10kB maximum. This is still reasonable, especially considering this could be cached. Using dag-cbor would help indeed.

[lidel]

@thibmeu this is not on our immediate roadmap, but would accept it as a contribution.
I am available for reviewing things if you are willing to drive it and spec out details around this new header.

[lidel]

ipfs/specs#296 (review)