feat!: support DNS over HTTPS and DNS-JSON over HTTPS #55
Conversation
Adds support for resoving DNSLink TXT entries from public DNS-Over-HTTPS servers (RFC 1035) and also DNS-JSON-Over-HTTPS since they are a bit kinder on the resulting browser bundle size. Fixes #53
| return answer.TTL | ||
| } | ||
|
|
||
| export const MAX_RECURSIVE_DEPTH = 32 |
packages/ipns/src/index.ts
Outdated
| (domain: string, options?: ResolveDnsLinkOptions): Promise<string> | ||
| } | ||
|
|
||
| export interface ResolveDNSOptions extends AbortOptions, ProgressOptions<ResolveDnsLinkProgressEvents> { |
There was a problem hiding this comment.
Can we add MAX_RECURSIVE_DEPTH as a configurable option in here?
| const txtType = 16 | ||
|
|
||
| return { | ||
| Status: 0, |
There was a problem hiding this comment.
Do we need the status field? If so, what for? it's not part of rfc8427 nor rfc1035
| dnslinkRecord = await resolve(domain, options) | ||
| } | ||
|
|
||
| const result = dnslinkRecord.replace('dnslink=', '') |
There was a problem hiding this comment.
we can return this here if depth === 0
There was a problem hiding this comment.
technically, depth inside this scope was already checked, and the depth===0 at the top would have checked if it was 0. The check below on line 94 is a duplicate and should never fire. So we should technically check if depth is 1, and we can return if we want to prevent erroring on further recursion to allow a user to do so if they wish?
@achingbrain what do you think
There was a problem hiding this comment.
it really depends on whether we want to allow infinite recursion and error if infinite recursion exists, or recurse as far as MAX and return what we have so far (user could then request to resolve that further if they want)
could be a config option.
|
Feature request: ability to "set and forget", i.e. provide an array of resolvers as the default option for all subsequent calls; check if this is present before falling back to |
resolvers/dns-json-over-https.ts:71:22)
website is down and dig +noall +answer TXT _dnslink.tableflip.io returns empty
see cac6ba9 |
use ipns(helia, {}) instead of ipns(helia, [...routers], [...resolvers])
BREAKING CHANGE: ipns factory function options as args object
SgtPooki
changed the title
## [@helia/ipns-v3.0.0](https://github.com/ipfs/helia-ipns/compare/@helia/ipns-v2.0.3...@helia/ipns-v3.0.0) (2023-12-05) ### ⚠ BREAKING CHANGES * alters the options object passed to the `ipns` factory function ### Features * support DNS over HTTPS and DNS-JSON over HTTPS ([#55](#55)) ([2ac0e8b](2ac0e8b))
| @@ -60,7 +60,6 @@ | |||
| "@libp2p/peer-id-factory": "^3.0.3", | |||
| "@libp2p/tcp": "^8.0.4", | |||
| "@libp2p/websockets": "^7.0.4", | |||
| "aegir": "^41.0.0", | |||
There was a problem hiding this comment.
This should be left in place. Each package in a monorepo should declare all of it's dependencies, otherwise we have some deps here, some deps there, and then it becomes hard to reason about where things are coming from and why.
Adds support for resoving DNSLink TXT entries from public DNS-Over-HTTPS servers (RFC 1035) and also DNS-JSON-Over-HTTPS since they are a bit kinder on the resulting browser bundle size.
Fixes #53