/ipns/ paths trigger false-positive DNSLink lookup

[lidel]

Example: https://specs-ipfs-tech.ipns.inbrowser.dev/ipns/ipns-record/

The /ipns/ makes verified-fetch attempt to do DNSLink lookup for ipns-record hostname.

This should not happen because we are already on subdomain gateway.

[lidel]

Early idea: service-worker-gateway should pass the original URL to verified-fetch('https://specs-ipfs-tech.ipns.inbrowser.dev/ipns/ipns-record/') so it has all information to make the right decision. Ir follows our design of shifting all conformance work to verified-fetch, when possible.

Once verified-fetch knows it is subdomain URL request, it will be able to not trigger /ipns/{id} resolution because it will know the content path is /ipns/specs.ipfs.tech/ipns/ipns-record/

@2color @SgtPooki thoughts?

[SgtPooki]

@lidel yep, we should pass everything to verified-fetch and I believe we already are. However, there are some "gateway" things happening at sw level in order to receive/route requests.. we need to make sure it's not getting in the way

[SgtPooki]

@lidel I believe the changes in ipfs/helia-verified-fetch@main...84-fix-infinite-querying-bug-reproducible-on-some-gateway-conformance-tests-that-were-disabled-in-httpsgithubcomipfshelia-verified-fetchpull81, fix this. Specifically ipfs/helia-verified-fetch@1b96aa2

Test for this at https://github.com/ipfs/helia-verified-fetch/blob/ba5f6a0cff550ea4980fd1f6d18789455e1f55fe/packages/verified-fetch/test/utils/parse-url-string.spec.ts#L936-L946