Every (public) node should have a Subdomain and a trusted TLS certificate, so that browser nodes can connect using /wss (Secure WebSockets transport).

We will support manual certificate configuration, and ACME automation for user’s domain names, but these setups require some manual step/input from the user.

Here, we discuss a protocol for providing TLS cert for /wss for all remaining nodes in a way that happens automatically, without user’s involvement.

Name Resolution

To get a TLS cert, we need a DNS name that points at a node, so it is able to perform ACME challenges on its own behalf.

There are two ways we can point a DNS name to an IP address. For the purpose of this discussion, let’s assume that we have one PL-controlled “gatekeeper” node that has (programmatic) access to the DNS configuration of dweb.link.

  1. Actively: configuring a A (AAAA) record in DNS. The node would inform the gatekeeper node about current IP address, and the gatekeeper would publish the A record.
    1. Con: every node sends a request to gatekeeper during node’s init or IP change
    2. Pro: the node just needs a certificate for <subdomain>.dweb.link
    3. Pro / Con: We can use the HTTP-01 / TLS-01 challenge. Note that this requires the ability to bind to port 80 / 443 on your machine.
    4. Con: the DNS will now contain a list of IP addresses of all nodes
    5. Con: we need one record per IP address
    6. Con: we will be updating DNS records a lot
  2. Passively: using wildcard certificates and DNS name with IP inline in a DNS label, as done by nip.io (127-0-0-1.libp2p-peer.dweb.link)
    1. Pro: DNS configuration of A / AAAA record is simple and static: DNS zone can be configured to act like nip.io and return A records based on IP values in subdomain (echo-like).
    2. Pro: nodes don’t need to inform central gatekeeper about their new IP address. The cert is valid for any IP address under their subdomain.
    3. Pro: nodes can use the same certificate for all IP addresses under their control
    4. Con: Nodes need a wildcard certificate for *.<subdomain>.dweb.link
      1. Con: To obtain a wildcard certificate, only the DNS-01 challenge can be used. This means that nodes need to request the gatekeeper to temporarily publish a TXT record.
      2. Pro: TXT records only need to be published for a short period of time once every 90 days, so there will be a lot less updates to our DNS config

Getting TLS cert via ACME

Getting TLS cert in automated fashion relies on ACME protocol, which supports different challenge types. Depending on which way we do the name resolution, we may decide to attempt autonomous HTTP-01 and fallback to DNS-01 facilitated by our gatekeeper.

Using Let’s Encrypt

Rate limits

Let’s Encrypt imposes pretty strict rate limits on the issuance of new certificates. The current limit is 50 certificates per domain per week, where each certificate can contain up to 100 subdomains (although this is not recommended, the certificate gets impractically big).

Rate limits for Public Suffix domains

It seems like the rate limit does not apply for domains on the Public Suffix List (PSL), if I understand correctly, the limit would apply for subdomains.

We control the [dweb.link](<http://dweb.link>) domain on the PSL, which means that rate limits would apply to <subdomain>.dweb.link, not dweb.link. That means we won't run into any rate limits, as long as we give nodes subdomains of the form <subdomain>.dweb.link(and not, let's say, <subdomain>.node.dweb.link).

This also means that we probably don’t need any involvement of LE.

<aside> 💡 Reusing [dweb.link](<http://dweb.link>) (public gateway domain) here brings increased risk in both directions (dmca takedowns, censorship, antimalware software blocks etc). As a compromise, it may be acceptable to use .dweb.link for now, fill PSA request for adding something else like libp2p.direct and switch to that domain over time, just to minimize risks.

</aside>

Possible Design with DNS Gatekeeper (A)