Lately I’ve been using CoreDNS for a work project, and have been experimenting with using it in my local network to replace dnsmasq in my dnsmasq+stubby+pihole configuration.
CoreDNS uses a “plugin” concept where DNS functionality is programmed via plugins that can be chained together. It also has an ENS plugin (https://coredns.io/explugins/ens/) so it can definitely be used as a nameserver for arbitrary protocols.
One of the problems IPNS has is that it’s pretty slow, another problem (whether or not this is a problem to you ultimately depends on your personal preferences/tastes) is that it doesn’t use human readable names.
It might be interesting to consider a LibP2P aware plugin for CoreDNS that allows implementing some sort of DNS style name resolution, but for IPFS. In theory there is probably some way to bind IPNS -> human names
You mean essentially embedding CoreDNS in the peer and using it as DNS resolver?
Might be a good integration. .eth resolution works now though (by converting to eth.link and doing normal resolution).
However, I am still worried about supporting additional providers like .crypto or alternative DNS communities… I also wonder what happens if IANA decides to kill eth.link if they get annoyed because alternatives are popping up out of their control and they “just work”, like it’s happening now.
Yea exactly, at the very least it would allow highly configurable resolvers, and “i feel like” there might be some method of using this to alleviate IPNS slowness. I can’t really put my finger on what it is that “i feel like” would help alleviate, but it certainly seems like something that might be worth an RFC to get input from the community, and help brew up a solution to IPNS slowness that’s more akin to traditional DNS systems.
However, I am still worried about supporting additional providers like .crypto or alternative DNS communities… I also wonder what happens if IANA decides to kill eth.link if they get annoyed because alternatives are popping up out of their control and they “just work”, like it’s happening now
Yea these are good points, I mean I wouldn’t necessarily recommend with implementing other crypto name systems since they aren’t thoroughly popular like ENS is. But it would certainly open up room for integrations with stuff like handshake. The great thing about a CoreDNS type integration would be that even if IANA kills eth.link, it would be possible to work around that with the ENS CoreDNS plugin.
Well, integration of a dns proper DNS server just for the node would be dope!
Not because we could decode some “crypto based” DNS names, but for securing DNSLink.
Currently it fully depends on the operating system to support DNSSec to make sure the DNSLink entry wasn’t spoofed.
DNS is also pretty much always unencrypted, which means ist obvious for everyone listening, that we’re just opening a domain via IPFS.
And additionally without DNSSec or encryption, the nodes are also prone to DNS spoofing/cache poisoning.
An internally running DNSServer which insist on strict DNSSec validation and have several remotes for encrypted DNS, including maybe some DNS-Servers inside the IPFS via Libp2pStream Mounting in the future which are randomly queried would allow for a high level of security and resistance against Man-In-The-Middle-Attacks.
This would also allow to security and secretly aquire the IPFS certificates for an DNSLink-IP for direct connections - as I explained here:
@RubenKelevra your post reminded me of a shower idea I had:
If IPFS node ships with internal DNS server that is used for DNSLink resolution, we could introduce hardening against DNS-level censorship/outrages.
The most basic implementation could be “libp2p DNS”, where for each query:
pick a subset of your peers
(ensure peers are spread across the globe / different political jurisdictions)
ask each peer to resolve DNS record using DNS server used by their operating systems
(some peers may return spoofed/hijacked/blocked results)
see if there is a quorum and pick that version, ignoring the rest
(cache result for ttl, as any other server would)
Now… if we don’t limit this internal, “hardened” DNS server to IPFS node, but expose it for general use, just like it is possible by defining DNSPort 53 in Tor, we have a DNS service which does not require running special servers, but is harder to censor by a single state actor.