Closed jbenet closed 8 years ago
Related: the paper says that IPNS DNS records can point either directly to IPFS objects or recursively to other IPNS paths. Right now, the code only handles resolving direct references to IPFS objects, and the TXT record encoding scheme doesn't specify how to distinguish the two.
I assume it should be:
ipns=/ipfs/QmSomeHash
or for an ipns path:
ipns=/ipns/QmSomeOtherHash
I started on this at https://github.com/jbenet/go-ipfs/commits/ipns-resolution -- that's a stash, the last commit doesn't even compile.
In the interest of only using one DNS TXT key, and making it non-ipfs specific (/ extensible to other resolution):
dnslink=/ipfs/Qm...
dnslink=/ipns/Qm...
Then there's also other unresolved questions, like recursive resolution depth-- how far should ipns names be able to point to each other?
normally unix systems define MAXLINKS to be around 32
Hi,
have you considered using other type of DNS entrie such as :
_ipns.example.com. 86400 IN SRV 10 10 0 _ipfs.QmSomeHash.
_ipns.example.com. CNAME _ipfs.QmSomeHash.
this might make sense if you want to do something non-ipfs specific
@maxired yep we considered them, but SRV has a bunch of complicated rules (specific to its target use case) and CNAME doesnt work (it must be another domain, we want a unix path).
The format of the DNS TXT record is currently:
// format
<hash>
// example
QmajFHHivh25Qb2cNbnnnEeUe1gDLHX9ta7hs2XKX1vazb
The format will be:
// format
dnslink=<ipfs-path>
// example
dnslink=/ipfs/QmZfqVvnqesSyFosEAQPZBcfeepfey5efkLZSwm3sySp36/cat.jpg
You should be able to add both records and have it (a) work now, and (b) work when we change it.
Since 28th April (v0.3.3) both schemas are working.
Is it a time to remove old schema?
@Kubuxu sure, wanna file a PR for that?
Sure
This is done.
AFAICT the IPNS record lookup is currently incorrect:
It should be:
I'll be changing it, which may break people's IPNS names.