ncdns Direction & Discussion Thread
ncdns Direction & Discussion Thread
(It's about time a thread was created for this. I think Jeremy and sugarpuff have matters to discuss about ncdns and we keep failing to meet to do so. Not really "official", but this felt like the best forum; it can be moved if someone disagrees.)
ncdns
This is the discussion thread for ncdns, an authoritative .bit nameserver daemon.
https://github.com/hlandau/ncdns.t
ncdns
This is the discussion thread for ncdns, an authoritative .bit nameserver daemon.
https://github.com/hlandau/ncdns.t
-
- Posts: 36
- Joined: Thu Jul 23, 2015 7:58 pm
- os: windows
Re: ncdns Direction & Discussion Thread
I'll try and get ncdns running with Unbound on several different platforms. The instructions look pretty comprehensive. I'll keep you posted.
-
- Posts: 36
- Joined: Thu Jul 23, 2015 7:58 pm
- os: windows
Re: ncdns Direction & Discussion Thread
Downloaded ncdns.t-master from github. But the Make command on my Linux Mint machine fails. Here's the terminal session:
Suggestions?
Code: Select all
john@john-ThinkPad-X300 ~/Downloads/ncdns.t-master $ make
go get github.com/hlandau/ncdns
# gopkg.in/hlandau/service.v2/daemon/caps
src/gopkg.in/hlandau/service.v2/daemon/caps/caps_linux.go:7:28: fatal error: sys/capability.h: No such file or directory
#include <sys/capability.h>
^
compilation terminated.
make: *** [.gotten] Error 2
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: ncdns Direction & Discussion Thread
Not certain, but try "apt-get install libcap-dev libcap2" first.barkingdoggy wrote:Downloaded ncdns.t-master from github. But the Make command on my Linux Mint machine fails. Here's the terminal session:Suggestions?Code: Select all
john@john-ThinkPad-X300 ~/Downloads/ncdns.t-master $ make go get github.com/hlandau/ncdns # gopkg.in/hlandau/service.v2/daemon/caps src/gopkg.in/hlandau/service.v2/daemon/caps/caps_linux.go:7:28: fatal error: sys/capability.h: No such file or directory #include <sys/capability.h> ^ compilation terminated. make: *** [.gotten] Error 2
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: ncdns Direction & Discussion Thread
So, I was intending to have a lengthy IRC discussion about ncdns project direction and management, but that failed to materialize, so I'm just going to put some thoughts here.
Point 1: We should try to evaluate the arguments that have been put forth about ncdns compared to NMControl. In particular, reproducibility of builds, and better compatibility with the DNS specs. I'd definitely like to see reproducible builds happen for ncdns sooner rather than later. Also, better install scripts would be good -- particularly relating to the installation and configuration of dnssec-trigger and Unbound.
Point 2: Pull requests should be evaluated by multiple people prior to merging. Lack of interest in testing things is not an excuse for merging code that doesn't have sufficient ACKs. I was informed by a lawyer that we should expect attempts to sabotage our code -- multiple reviewers is the most effective defense against this. I don't know details of how the Bitcoin Core devs handle things, but their process seems to work pretty well, and I don't see a reason to deviate from what they do. Anyone particularly familiar with how Bitcoin Core does things?
Point 3: In terms of ncdns project leadership, I'd favor having three project leads: Hugo, Phelix, and myself. (That's assuming Phelix has an interest.) Other Namecoin devs should be included in the process. We also should be trying to encourage outside contributions. For example, Greg Slepak from okTurtles should be encouraged to submit pull requests to ncdns rather than work on the dead end that is the DNSChain codebase. Political issues should be left out of this equation, as with Bitcoin. It goes without saying that people other than Hugo, Phelix, and myself should also be reviewing code and design choices; "project leads" != "the only heavily involved people".
Point 4: We should compose a feature matrix of ncdns, NMControl, DNSChain, and NamecoinToBind, and put together a plan for bringing ncdns any features that are missing. A REST API seems particularly relevant here. DNSChain and NMControl both have sucky REST API's; this is a good chance to standardize on something better.
Point 5: ncdns should support the newer Namecoin Core features like REST, block/tx callbacks, and unconfirmed name ops.
Point 6: ncdns should disable by default all d/ spec features that don't have full consensus from developers. Enabling such features was fine when ncdns was basically a playground for prototyping the spec, but if it's going to become an official Namecoin project, it's a very bad thing because it encourages websites to build on things that we will want to change later. The features that come to mind immediately are alias, translate, and all of the non-DNS types. A simple command-line flag "--enable-beta-spec-features" seems to be a decent way to enable such features for people who know what they're doing.
Point 7: Documentation should be produced for namecoin.org. The new Jekyll site should make this much easier.
Point 8: The request by Greg Slepak to keep things blockchain-agnostic should be taken seriously. Ethereum seems to be pursuing a naming system; we should be aiming to collaborate with the Ethereum devs on areas of common interest.
That's all I can think of offhand. Anyone else have comments on this topic?
Point 1: We should try to evaluate the arguments that have been put forth about ncdns compared to NMControl. In particular, reproducibility of builds, and better compatibility with the DNS specs. I'd definitely like to see reproducible builds happen for ncdns sooner rather than later. Also, better install scripts would be good -- particularly relating to the installation and configuration of dnssec-trigger and Unbound.
Point 2: Pull requests should be evaluated by multiple people prior to merging. Lack of interest in testing things is not an excuse for merging code that doesn't have sufficient ACKs. I was informed by a lawyer that we should expect attempts to sabotage our code -- multiple reviewers is the most effective defense against this. I don't know details of how the Bitcoin Core devs handle things, but their process seems to work pretty well, and I don't see a reason to deviate from what they do. Anyone particularly familiar with how Bitcoin Core does things?
Point 3: In terms of ncdns project leadership, I'd favor having three project leads: Hugo, Phelix, and myself. (That's assuming Phelix has an interest.) Other Namecoin devs should be included in the process. We also should be trying to encourage outside contributions. For example, Greg Slepak from okTurtles should be encouraged to submit pull requests to ncdns rather than work on the dead end that is the DNSChain codebase. Political issues should be left out of this equation, as with Bitcoin. It goes without saying that people other than Hugo, Phelix, and myself should also be reviewing code and design choices; "project leads" != "the only heavily involved people".
Point 4: We should compose a feature matrix of ncdns, NMControl, DNSChain, and NamecoinToBind, and put together a plan for bringing ncdns any features that are missing. A REST API seems particularly relevant here. DNSChain and NMControl both have sucky REST API's; this is a good chance to standardize on something better.
Point 5: ncdns should support the newer Namecoin Core features like REST, block/tx callbacks, and unconfirmed name ops.
Point 6: ncdns should disable by default all d/ spec features that don't have full consensus from developers. Enabling such features was fine when ncdns was basically a playground for prototyping the spec, but if it's going to become an official Namecoin project, it's a very bad thing because it encourages websites to build on things that we will want to change later. The features that come to mind immediately are alias, translate, and all of the non-DNS types. A simple command-line flag "--enable-beta-spec-features" seems to be a decent way to enable such features for people who know what they're doing.
Point 7: Documentation should be produced for namecoin.org. The new Jekyll site should make this much easier.
Point 8: The request by Greg Slepak to keep things blockchain-agnostic should be taken seriously. Ethereum seems to be pursuing a naming system; we should be aiming to collaborate with the Ethereum devs on areas of common interest.
That's all I can think of offhand. Anyone else have comments on this topic?
Re: ncdns Direction & Discussion Thread
I have added support for building without cgo.biolizard89 wrote:So, I was intending to have a lengthy IRC discussion about ncdns project direction and management, but that failed to materialize, so I'm just going to put some thoughts here.
Point 1: We should try to evaluate the arguments that have been put forth about ncdns compared to NMControl. In particular, reproducibility of builds, and better compatibility with the DNS specs. I'd definitely like to see reproducible builds happen for ncdns sooner rather than later. Also, better install scripts would be good -- particularly relating to the installation and configuration of dnssec-trigger and Unbound.
Code: Select all
$ go install github.com/hlandau/ncdns
$ strings bin/ncdns | grep /tmp
(non-deterministic tmp paths)
# No cgo:
$ cp -a /usr/lib/go go-nocgo
$ GOROOT=`pwd`/go-nocgo CGO_ENABLED=0 go install github.com/hlandau/ncdns
$ ldd bin/ncdns
not a dynamic executable
$ strings bin/ncdns | grep /tmp
/tmp
$ sha256sum bin/ncdns > ncdns.sha256.1
$ touch src/github.com/hlandau/ncdns/main.go
$ GOROOT=`pwd`/go-nocgo CGO_ENABLED=0 go install github.com/hlandau/ncdns
$ sha256sum bin/ncdns > ncdns.sha256.2
$ diff -u ncdns.sha256.*
$
- Privilege dropping is not supported at all on Linux.
- UIDs and GIDs must be specified numerically, not as names.
- No supplementary GIDs are configured when dropping privileges (the empty set is configured).
- setproctitle is not supported.
Agreed. It looks like Bitcoin Core just has people post approvals in a PR.Point 2: Pull requests should be evaluated by multiple people prior to merging. Lack of interest in testing things is not an excuse for merging code that doesn't have sufficient ACKs. I was informed by a lawyer that we should expect attempts to sabotage our code -- multiple reviewers is the most effective defense against this. I don't know details of how the Bitcoin Core devs handle things, but their process seems to work pretty well, and I don't see a reason to deviate from what they do. Anyone particularly familiar with how Bitcoin Core does things?
Sure.Point 3: In terms of ncdns project leadership, I'd favor having three project leads: Hugo, Phelix, and myself. (That's assuming Phelix has an interest.) Other Namecoin devs should be included in the process. We also should be trying to encourage outside contributions. For example, Greg Slepak from okTurtles should be encouraged to submit pull requests to ncdns rather than work on the dead end that is the DNSChain codebase. Political issues should be left out of this equation, as with Bitcoin. It goes without saying that people other than Hugo, Phelix, and myself should also be reviewing code and design choices; "project leads" != "the only heavily involved people".
I'm not convinced that namecointobind needs to be maintained. It should be trivial to use ncdns's conversion code to dump a zone file.Point 4: We should compose a feature matrix of ncdns, NMControl, DNSChain, and NamecoinToBind, and put together a plan for bringing ncdns any features that are missing. A REST API seems particularly relevant here. DNSChain and NMControl both have sucky REST API's; this is a good chance to standardize on something better.
Sure.Point 5: ncdns should support the newer Namecoin Core features like REST, block/tx callbacks, and unconfirmed name ops.
Since ncdns serves... DNS, I'm not sure what you have in mind in terms of disabling non-DNS types? I'm against disabling alias and translate; they're standard parts of DNS. How do you expect alias/translate to change later?Point 6: ncdns should disable by default all d/ spec features that don't have full consensus from developers. Enabling such features was fine when ncdns was basically a playground for prototyping the spec, but if it's going to become an official Namecoin project, it's a very bad thing because it encourages websites to build on things that we will want to change later. The features that come to mind immediately are alias, translate, and all of the non-DNS types. A simple command-line flag "--enable-beta-spec-features" seems to be a decent way to enable such features for people who know what they're doing.
Sure.Point 7: Documentation should be produced for namecoin.org. The new Jekyll site should make this much easier.
Agreed. However, I don't think there are any codebase implications at this time. There's no point adding an abstraction layer until we have some concrete alternative to work with; otherwise the requirements of the abstraction layer and any "impedence discontinuities" it will need to work with are unknown. Abstractions developed under such conditions tend to suck.Point 8: The request by Greg Slepak to keep things blockchain-agnostic should be taken seriously. Ethereum seems to be pursuing a naming system; we should be aiming to collaborate with the Ethereum devs on areas of common interest.
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: ncdns Direction & Discussion Thread
Ah, excellent. Hopefully I can tinker around with Gitian a bit and verify that this works reproducibly. Have you tested with Go 1.4.x? Last I checked that's still what Tor is using; it would be nice if we could delay Go 1.5.x until Tor has produced Gitian descriptors for it.hla wrote:I have added support for building without cgo.biolizard89 wrote:Point 1: We should try to evaluate the arguments that have been put forth about ncdns compared to NMControl. In particular, reproducibility of builds, and better compatibility with the DNS specs. I'd definitely like to see reproducible builds happen for ncdns sooner rather than later. Also, better install scripts would be good -- particularly relating to the installation and configuration of dnssec-trigger and Unbound.When not using cgo, the following restrictions apply:Code: Select all
$ go install github.com/hlandau/ncdns $ strings bin/ncdns | grep /tmp (non-deterministic tmp paths) # No cgo: $ cp -a /usr/lib/go go-nocgo $ GOROOT=`pwd`/go-nocgo CGO_ENABLED=0 go install github.com/hlandau/ncdns $ ldd bin/ncdns not a dynamic executable $ strings bin/ncdns | grep /tmp /tmp $ sha256sum bin/ncdns > ncdns.sha256.1 $ touch src/github.com/hlandau/ncdns/main.go $ GOROOT=`pwd`/go-nocgo CGO_ENABLED=0 go install github.com/hlandau/ncdns $ sha256sum bin/ncdns > ncdns.sha256.2 $ diff -u ncdns.sha256.* $
- Privilege dropping is not supported at all on Linux.
- UIDs and GIDs must be specified numerically, not as names.
- No supplementary GIDs are configured when dropping privileges (the empty set is configured).
- setproctitle is not supported.
I agree that NamecoinToBind should be deprecated -- I'm just saying that we should figure out a plan to bring any useful functionality that it has into ncdns.hla wrote:I'm not convinced that namecointobind needs to be maintained. It should be trivial to use ncdns's conversion code to dump a zone file.Point 4: We should compose a feature matrix of ncdns, NMControl, DNSChain, and NamecoinToBind, and put together a plan for bringing ncdns any features that are missing. A REST API seems particularly relevant here. DNSChain and NMControl both have sucky REST API's; this is a good chance to standardize on something better.
There's no consensus on whether the non-DNS types should be exposed via DNS, and if so whether they should be CNAME or TXT. Similarly there's no consensus on whether CNAME and DNAME should have AD=1 when DNSSEC is enabled. That's why I think they should both be disabled by default at the moment until consensus on those issues is reached.hla wrote:Since ncdns serves... DNS, I'm not sure what you have in mind in terms of disabling non-DNS types? I'm against disabling alias and translate; they're standard parts of DNS. How do you expect alias/translate to change later?Point 6: ncdns should disable by default all d/ spec features that don't have full consensus from developers. Enabling such features was fine when ncdns was basically a playground for prototyping the spec, but if it's going to become an official Namecoin project, it's a very bad thing because it encourages websites to build on things that we will want to change later. The features that come to mind immediately are alias, translate, and all of the non-DNS types. A simple command-line flag "--enable-beta-spec-features" seems to be a decent way to enable such features for people who know what they're doing.
I suppose the main thing that can be easily abstracted is the choice of TLD. Multiple TLD's could be run as separate ncdns instances on different ports, and Unbound would just contain config for each TLD. Any REST interface would also benefit from an abstraction of TLD. Other thing that I should have mentioned is the possibility of picking a project name other than "ncdns". The rest of the abstractions, yes, it would be better to find out what Ethereum's needs are before engineering such abstractions.hla wrote:Agreed. However, I don't think there are any codebase implications at this time. There's no point adding an abstraction layer until we have some concrete alternative to work with; otherwise the requirements of the abstraction layer and any "impedence discontinuities" it will need to work with are unknown. Abstractions developed under such conditions tend to suck.Point 8: The request by Greg Slepak to keep things blockchain-agnostic should be taken seriously. Ethereum seems to be pursuing a naming system; we should be aiming to collaborate with the Ethereum devs on areas of common interest.
Re: ncdns Direction & Discussion Thread
I've added a zonefile dumping tool to the ncdns repository. It's slower than namesync-powerdns-AXFR, though.
Also, "we can't agree on the AD bit, therefore burn the feature entirely" doesn't seem like a sane solution.
ncdns is an authoritative nameserver. It has nothing to do with the AD bit, which is set purely by resolvers.There's no consensus on whether the non-DNS types should be exposed via DNS, and if so whether they should be CNAME or TXT. Similarly there's no consensus on whether CNAME and DNAME should have AD=1 when DNSSEC is enabled. That's why I think they should both be disabled by default at the moment until consensus on those issues is reached.
Also, "we can't agree on the AD bit, therefore burn the feature entirely" doesn't seem like a sane solution.
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: ncdns Direction & Discussion Thread
Ah, yes. Agreed, disregard my inattention to detail.hla wrote:ncdns is an authoritative nameserver. It has nothing to do with the AD bit, which is set purely by resolvers.There's no consensus on whether the non-DNS types should be exposed via DNS, and if so whether they should be CNAME or TXT. Similarly there's no consensus on whether CNAME and DNAME should have AD=1 when DNSSEC is enabled. That's why I think they should both be disabled by default at the moment until consensus on those issues is reached.