ncdns Direction & Discussion Thread

Namecoin, NMControl
Post Reply
hla
Posts: 46
Joined: Mon Nov 10, 2014 12:01 am
os: linux
Contact:

ncdns Direction & Discussion Thread

Post by hla »

(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

barkingdoggy
Posts: 36
Joined: Thu Jul 23, 2015 7:58 pm
os: windows

Re: ncdns Direction & Discussion Thread

Post by barkingdoggy »

I'll try and get ncdns running with Unbound on several different platforms. The instructions look pretty comprehensive. I'll keep you posted.

barkingdoggy
Posts: 36
Joined: Thu Jul 23, 2015 7:58 pm
os: windows

Re: ncdns Direction & Discussion Thread

Post by barkingdoggy »

Downloaded ncdns.t-master from github. But the Make command on my Linux Mint machine fails. Here's the terminal session:

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
Suggestions?

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: ncdns Direction & Discussion Thread

Post by biolizard89 »

barkingdoggy wrote:Downloaded ncdns.t-master from github. But the Make command on my Linux Mint machine fails. Here's the terminal session:

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
Suggestions?
Not certain, but try "apt-get install libcap-dev libcap2" first.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: ncdns Direction & Discussion Thread

Post by biolizard89 »

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?
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

hla
Posts: 46
Joined: Mon Nov 10, 2014 12:01 am
os: linux
Contact:

Re: ncdns Direction & Discussion Thread

Post by hla »

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.
I have added support for building without cgo.

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.*
$
When not using cgo, the following restrictions apply:

- 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.
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?
Agreed. It looks like Bitcoin Core just has people post approvals in a PR.
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".
Sure.
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.
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 5: ncdns should support the newer Namecoin Core features like REST, block/tx callbacks, and unconfirmed name ops.
Sure.
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.
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 7: Documentation should be produced for namecoin.org. The new Jekyll site should make this much easier.
Sure.
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.
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.

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: ncdns Direction & Discussion Thread

Post by biolizard89 »

hla wrote:
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.
I have added support for building without cgo.

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.*
$
When not using cgo, the following restrictions apply:

- 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.
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:
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.
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.
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:
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.
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?
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:
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.
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.
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.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

hla
Posts: 46
Joined: Mon Nov 10, 2014 12:01 am
os: linux
Contact:

Re: ncdns Direction & Discussion Thread

Post by hla »

I've added a zonefile dumping tool to the ncdns repository. It's slower than namesync-powerdns-AXFR, though.
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.
ncdns is an authoritative nameserver. It has nothing to do with the AD bit, which is set purely by resolvers.

Also, "we can't agree on the AD bit, therefore burn the feature entirely" doesn't seem like a sane solution.

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: ncdns Direction & Discussion Thread

Post by biolizard89 »

hla wrote:
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.
ncdns is an authoritative nameserver. It has nothing to do with the AD bit, which is set purely by resolvers.
Ah, yes. Agreed, disregard my inattention to detail.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply