cel committed Update publish/update usageLatest: c6437ca on 11/5/2016, 12:32:13 AM | |
📄 | .gitignore |
📄 | LICENSE |
📄 | README.md |
📄 | index.js |
📁 | lib |
📄 | package.json |
dnssb
It's fairly easy to serve dns from a nodejs process.
scuttlebot makes it easy to work with a peer-to-peer log store.
So let's mash them together.
What could go wrong?
Installation
Via npm:
npm i -g ssb-dns;
Or via git:
git clone https://github.com/ansuz/dnssb;
cd dnssb;
npm i -g;
Usage
dnssb
assumes that you have a scuttlebot instance running.
You can find out more about scuttlebot here.
Alternatively, you can run dnssb server
as a scuttlebot plugin:
cd dnssb
mkdir -p ~/.ssb/node_modules
ln -rs . ~/.ssb/node_modules/dns
sbot plugins.enable dns
# restart sbot
Publish a record
NOTE:So far the publishing script is hardcoded to reject records which don't end in .ssb
.
This was cSmith's idea.
In the future this might be genralized to squat even more TLDs, or to simply be unopinionated about them.
dnssb publish [{prev record key}...] {domain name} [{ttl}] [{dns class}] {record type} {value}
To replace some existing dnssb records, pass their ssb message id(s) as the first arguments to the publish command. To append a record to the set of existing records, omit the message ids.
To replace all existing records for a name+type+class, use update
:
dnssb update {domain name} [{ttl}] [{dns class}] {record type} {value}
Display all records
I want to use this
You'll only be able to resolve records that your node knows about.
You can print a list of valid records with:
dnssb dump
Fetch a record
First launch the server in one terminal:
dnssb server {port: 53053} {host: 127.0.0.1}
Then query it for a record:
dig @localhost -p 53053 {name} {type}
FAQ
Can I use this without running scuttlebot?
You could get a friend to host dnssb for you if you really trust them and don't care if they see all your dns requests. Once running, you should be able to use the dns server as you would any other dns provider.
Is it Enterprise-Ready?
That depends on your the needs of your Enterprise, but I would lean towards no.
Does it protect against name-squatting?
The records available to dnssb are sourced from your ssb social network, so the quality of your results will depend on who you choose to follow (and who they choose to follow).
How can I deal with malicious behaviour?
Records must be published by someone in your social network, and all such records are cryptographically signed using their private key.
If you notice malicious behaviour, it can always be traced back to the person who published it, through your social graph, if need be. Naming things is a social problem, and the best way to resolve conflicts is probably to discuss it.
Additionally, in the future there will be better support for reporting and blocking abusive behaviour.
Does it resolve conflicts if they occur?
Not yet.
What is it good for?
- If there is a DNS outage you can still resolve any records you or your friends have published to ssb.
- As with everything committed to ssb, records are stored locally (and indefinitely) in a set of hash chains (one for each user). As such, if you don't have access to the internet at all, this will continue to work
- You can use this as a kind of distributed hosts file
How optimized is this?
Not much, but it should get better over time if people are interested in using it.
Is there a web interface?
Not yet, but I'd like there to be!
Does it handle wildcard entries?
Not yet, but I'd like it to!
Built with git-ssb-web