feat(gw): DNSLink names on https:// subdomains #7847
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Problem statement and rationale for doing this can be found under "Option C" at: ipfs/in-web-browsers#169 TLDR is: `https://dweb.link/ipns/my.v-long.example.com` can be loaded from a subdomain gateway with a wildcard TLS cert if represented as a single DNS label: `https://my-v--long-example-com.ipns.dweb.link`
lidel
changed the title
lidel
changed the title
lidel
commented
Jan 4, 2021
Comment on lines
+406
to
+411
| # DNSLink on Public gateway with a single-level wildcard TLS cert | ||
| # "Option C" from https://github.com/ipfs/in-web-browsers/issues/169 | ||
| test_expect_success \ | ||
| "request for example.com/ipns/{fqdn} with X-Forwarded-Proto redirects to TLS-safe label in subdomain" " | ||
| curl -H \"Host: example.com\" -H \"X-Forwarded-Proto: https\" -sD - \"http://127.0.0.1:$GWAY_PORT/ipns/en.wikipedia-on-ipfs.org/wiki\" > response && | ||
| test_should_contain \"Location: https://en-wikipedia--on--ipfs-org.ipns.example.com/wiki\" response |
There was a problem hiding this comment.
PR in action:
- User opens
ipns://en.wikipedia-on-ipfs.org/wiki - User agent (eg. web browser) resolves
ipns://URI via public gateway athttps://example.com/ipns/en.wikipedia-on-ipfs.org/wikiwhich returns HTTP 301 redirect tohttps://en-wikipedia--on--ipfs-org.ipns.example.com/wikiifX-Forwarded-Proto: httpsis present.
lidel
commented
Jan 4, 2021
Comment on lines
+552
to
+555
| test_expect_success \ | ||
| "request for {single-label-dnslink}.ipns.example.com with X-Forwarded-Proto returns expected payload" " | ||
| curl -H \"Host: dnslink--subdomain--gw--test-example-org.ipns.example.com\" -H \"X-Forwarded-Proto: https\" -sD - \"http://127.0.0.1:$GWAY_PORT\" > response && | ||
| test_should_contain \"$CID_VAL\" response |
There was a problem hiding this comment.
.. after redirect:
3. Inlined DNSLink name returns expected payload.
autonome
approved these changes
Jan 5, 2021
As suggested in #7847 (comment)
lidel
commented
Jan 14, 2021
This kinda enables to run their custom DNS resolver with custom tlds/names that are independent from the public DNS network.
aschmahmann
approved these changes
Jan 14, 2021
This was referenced Jan 29, 2021
Closed
lidel
added a commit
to ipfs/in-web-browsers
that referenced
this pull request
Feb 3, 2021
Simplify DNSLink handling: ipfs/kubo#7847 will ship with go-ipfs 0.8.0 and is already supported at dweb.link
lidel
added a commit
to ipfs/in-web-browsers
that referenced
this pull request
Feb 4, 2021
* docs: simplified DNSLink handling on subdomain gws Simplify DNSLink handling: ipfs/kubo#7847 will ship with go-ipfs 0.8.0 and is already supported at dweb.link * style: replace code block with table * docs: link to suborigin status * docs: clarify types of content handled by gateways * docs: simplify TLDR
kingwel-xie
pushed a commit
to kingwel-xie/go-ipfs
that referenced
this pull request
Feb 5, 2021
As suggested in ipfs#7847 (comment)
2 tasks
hacdias
pushed a commit
to ipfs/boxo
that referenced
this pull request
Jan 27, 2023
As suggested in ipfs/kubo#7847 (comment) This commit was moved from ipfs/kubo@88dd257
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TLDR
This PR enables users of public gateways to load DNSlink websites without TLS error described in ipfs/in-web-browsers#169.
It not only makes DNSLink websites more resilient, but makes it easier to resolve
ipns://URIs in Opera Mobile and Brave (when a public gateway is selected as a resolution method).Details
dweb.linkto provide DNSLink hosting service over HTTPS with astandard single-level-wildcard TLS certificate.
X-Forwarded-Proto: httpsis present (opt-in made by gateway operator), no additional configuration is needed.How DNSlink name inlining works
Below is a real life example of a DNSlink name inlined into a single DNS label that works with a wildcard TLS cert for
*.ipns.dweb.link:/ipns/en.wikipedia-on-ipfs.org→ipns://en.wikipedia-on-ipfs.org→https://dweb.link/ipns/en.wikipedia-on-ipfs.orghttps://en-wikipedia--on--ipfs-org.ipns.dweb.link👈 a single DNS label, no TLS errorUse cases fixed by this PR
my.v-long.example.combut the original HTTP server is down. The hostname has DNSLink set up.User should be able to load website not only from a local gateway, but any public one.
ipns://URIs using public gateway (eg.dweb.link).ipns://my.v-long.example.com→https://dweb.link/ipns/my.v-long.example.com→ (HTTP 301) →https://my-v--long-example-com.ipns.dweb.link