-
Notifications
You must be signed in to change notification settings - Fork 237
Open
Labels
need/triageNeeds initial labeling and prioritizationNeeds initial labeling and prioritization
Description
Hello!
DNS is currently the weakest part of the Internet stack and first entrypoint to censorship and government interference. Mostly because it's centralized by few big tech companies and government owned TLD registrars.
What I want to share here is an idea of a simple, yet effective way of using IPNS entries as domain names resolving to IPv4 or IPv6 addresses and "classic" (i.e not dweb) web pages and network services.
Use case
For the sake of this document let's name this service IPDNS (Inter Planetary Domain Name Service)
- User enters into browser's address-bar domain
k51qzi5uqu5dlvj2baxnqndepeb86cbk3ng7n3i46uzyxzyqj2xjonzllnv0v8.ipns - Browser (or browser plugin or upstream proxy) resolves hash as IPNS name. IPNS entry points to an IPFS file with standardized "hosts" format. For example:
{
"version": 1,
"ttl": 3600,
"__root__": {
"AA": ["141.101.64.20", "190.93.240.21"],
"AAAA": ["2606:2800:220:1:248:1893:25c8:1946"]
},
"subdomain": {
"AA": ["141.101.64.25"]
}
}
- Browser/proxy uses fetched hosts file and caches it. Then it's able to open
k51qzi5uqu5dlvj2baxnqndepeb86cbk3ng7n3i46uzyxzyqj2xjonzllnv0v8.ipnsweb page as any other by requesting HTTP(S) to 141.101.64.20 or opensubdomain.k51qzi5uqu5dlvj2baxnqndepeb86cbk3ng7n3i46uzyxzyqj2xjonzllnv0v8.ipnsby opening connection to 141.101.64.21.
PROS
- Anyone can create and manage long term IPDNS domain name same way as creating and managing any IPNS entry. Updating hosts file requires just pointing IPNS entry to a new file.
- Method allows to utilize existing web infrastructure, servers, etc - increasing resistance and accustoming people to IPNS before dweb adoption reaches higher levels.
- similar UX to existing Tor "onion" domains, but allowing free-form human readable subdomains.
- solution is as resilient as rest of IPFS/IPNS infrastructure
- entries are secure and trusted by design (as long as someone trusts public key owner for given IPDNS entry).
- potential to delegate subdomains to other parties by pairing subdomain with another IPNS entry
CONS
- domain entries are not user friendly, but this is broader issue for all IPNS. Subdomains are user friendly though.
- latency to resolve IPDNS entry to IP will be order of magnitude larger than DNS. This can be at least partially mitigated by adding root entry as IPNS metadata field so browser can start fetching main site as soon as IPNS entry is retrieved and download rest of hosts entries in the background. Still - IPDNS with latency is better than no DNS at all given certain scenarios.
- problem to solve with domains in TLS certificates, until Let's Encrypt starts to support IPDNS ;). Alternatively certificate hash can be part of hosts file and be trusted by browser for that particular IPDNS entry and subdomains.
Potential implementation and adoption methods
- IPFS Companion being able to resolve
.ipnsTLD and fetch/use relevant hosts files from IPNS + IPFS. - Squid proxy plugin with similar functionality but transparent for all web clients
- DNS or DNS over HTTPS resolver being able to resolve
.ipnsdomains along with regular TLD's.
Metadata
Metadata
Assignees
Labels
need/triageNeeds initial labeling and prioritizationNeeds initial labeling and prioritization