namecoin / ncdns

:globe_with_meridians: Namecoin to DNS bridge daemon

ncdns

A Go daemon to bridge Namecoin to DNS. The daemon acts as an authoritative nameserver and queries a Namecoin daemon over JSON-RPC in order to obtain zone data.

The daemon can optionally sign zones with DNSSEC and supports the use of DS records in Namecoin. It works best when used by Unbound or another recursive resolver, or as an authoritative nameserver for a stub zone.

Using ncdns to provide a suffix

The daemon acts as an authoritative nameserver for any name containing a 'bit' label. For example, all of the following queries return the same records:

• example.bit.
• example.bit.example.com.

This enables the easy use of suffixes. (Note that this will cause a different hostname to be transmitted for protocols like HTTP, and server configuration may need to be modified to enable this. In some cases there may be no simple solution to enabling arbitrary suffix use with a given piece of server software, in which known suffixes can be configured; patches for such software would be desirable.)

Using ncdns with a recursive resolver

Of course the daemon can also be used simply as an authoritative nameserver for bit. directly. One way to do this is to run a recursive resolver (such as Unbound) and configure it to serve the zone as a 'stub zone'. An example Unbound configuration is in _doc/unbound.conf.d/ncdns.conf.

If you don't want to use DNSSEC, an additional Unbound configuration is in _doc/unbound.conf.d/ncdns-insecure.conf.

If you do want to use DNSSEC, see the instructions below.

Note how you can specify a port other than 53. This allows you to run both Unbound and ncdns on the same machine. Alternately, you could add an additional loopback IP address (127.0.0.2) and bind ncdns to that. This is useful if your recursive resolver doesn't support a port number other than 53.

Using DNSSEC

To use DNSSEC, generate keys with dnssec-keygen or ldns-keygen. You will need to generate a key-signing key and a zone-signing key:

# Generate KSK.
$ dnssec-keygen -a RSASHA256 -3 -b 2048 -f KSK bit

# Generate ZSK.
$ dnssec-keygen -a RSASHA256 -3 -b 2048 bit

Each of these commands will generate a pair of files, a .key file and a .private file. Make a note of which is the KSK and which is the ZSK. If you forget, check the comments inside the .key file. (If there are no comments for some reason, a KSK usually contains the string DNSKEY 256 and a ZSK DNSKEY 257.)

(You could substitute something else for bit as ncdns doesn't care. However if you want to use the key as a trust anchor with a recursive resolver such as unbound, you should specify bit.)

If using Unbound as a recursive resolver, you should add the KSK's public key file as a trust anchor to unbound like so:

server:
  trust-anchor-file: "/etc/unbound/keys/bit.key"

bit.key should be the file containing the KSK DNSKEY (or DS) which ncdns is configured to use.

Building

Prerequisites:

1. Ensure you have the Go tools installed.

2. If using Linux, ensure you have the libcap development headers installed. (Most distributions will have a package called libcap-dev or similar.)

Option A: Using Go build commands without Go modules (works on any platform with Bash; only Go 1.15-1.16.x; will not work on Go 1.17+):

1. Ensure you have the GOPATH environment variable set. (For those not familar with Go, setting it to the path to an empty directory will suffice. The directory will be filled with build files.)

2. Run export GO111MODULE=off to disable Go modules.

3. Run go get -d -t -u github.com/namecoin/ncdns/.... The ncdns source code will be retrieved automatically.

4. Run go generate github.com/namecoin/certinject/.... The ReactOS property list will be parsed.

5. Run go generate github.com/namecoin/x509-compressed/.... The compressed public key patch will be applied.

6. Run go get -t -u github.com/namecoin/ncdns/.... ncdns will be built. The binaries will be at $GOPATH/bin/ncdns.

Option B: Using Go build commands with Go modules (works on any platform with Bash; Go 1.15+:

1. Clone certinject, x509-compressed, and ncdns to sibling directories.

2. Install certinject according to its instructions.

3. Install x509-compressed according to its "with Go modules" instructions.

4. Run the following in the ncdns directory to set up Go modules:

   go mod init github.com/namecoin/ncdns
   go mod edit -replace github.com/coreos/go-systemd=github.com/coreos/go-systemd/v22@latest -replace github.com/namecoin/certinject=../certinject -replace github.com/namecoin/x509-compressed=../x509-compressed
   go mod tidy
   

5. Run go install ./.... ncdns will be built. The binaries will be at $GOPATH/bin/ncdns.

Option C: Using Makefile (non-Windows platforms):

1. Run make. The source repository will be retrieved via go get automatically.

ncdns can be run as a Windows service; see the output of ncdns --help.

Configuration

ncdns uses a configuration file which is looked for at ../etc/ncdns.conf (relative to the executable path) and /etc/ncdns/ncdns.conf. You can override this and all options on the command line. An annotated example configuration file ncdns.conf.example is available in doc.

You will need to setup a namecoind, namecoin-qt or compatible Namecoin node and enable the JSON-RPC interface. You will then need to provide ncdns with the address of this interface and any necessary username and password via the configuration file.

If you only want to resolve .bit names yourself, here is a suggested setup on Linux:

• Install namecoind (or namecoin-qt) and set it to start automatically at boot or login. Set up the JSON-RPC interface and make sure it works by making a test query: namecoind name_show d/example.

• Write a ncdns configuration file and set ncdns up to start at boot. Since Unbound will tie up port 53, set a different port (ideally one >=1024, so it needn't be run as root.) Test that ncdns works by trying to resolve a .bit domain. If you want to use DNSSEC, generate keys as shown above and configure ncdns appropriately.

• Install and setup the Unbound recursive resolver on your system. On most systems, the recommended way to install Unbound is to install DNSSEC Trigger, which installs and configures Unbound automatically.

  If you wish to use DNSSEC, add the ncdns DNSKEY to Unbound as a trust anchor as shown above. See above for configuration suggestions.

• Edit /etc/resolv.conf to point to the Unbound resolver at 127.0.0.1. (If this file is generated automatically via DHCP or similar, you may find these changes keep getting wiped out. Either reconfigure whatever keeps overwriting it to stop doing so, or, as a stopgap measure, make the file immutable using chattr +i.)

Licence

Licenced under the GPLv3 or later.
© 2014-2015 Hugo Landau <[email protected]>

ncdns's Issues

Add stub-prime and stub-first to README

stub-prime and stub-first should be documented in the README, similar to https://github.com/namecoin/ncdns-nsis/blob/master/ncdns-inst.conf.in

Build failure with Go 1.11 for solaris/amd64 target

See https://travis-ci.org/namecoin/ncdns/jobs/432291271#L1755 . Appears to be a bug in miekg/dns. Doesn't happen for other targets on Go 1.11, and doesn't happen on Go 1.10.x for any targets.

Clearing the stream-isolated LRU caches not possible

In my current stream isolation PR, stream ID's and their associated LRU caches accumulate forever. The Tor stream isolation codebase will tell us when a new NYM_EPOCH has been reached; this is a safe point to delete all currently existing stream ID's and their LRU caches. (Of course, the new NYM_EPOCH event is not actually exposed via the Prop279 protocol, so we'll have to work with the Tor folks to get that added to the spec.)

Binary size is way too big

Adding ncdns and dns-prop279 to an Electrum-NMC+txtorcon .tar.xz archive increases the archive's size by 4.6 MiB. (Both Go programs were built for linux/amd64 with Go 1.10.3) This is way too high. It would be highly useful if we could find some way to decrease the binary size here.

Build Failure: x509/x509_splice.go:67:36: not enough arguments in call to buildExtensions

running Debian sid.

$ mkdir .go
$ export GOPATH=${HOME}/.go
$ go get -d -t -u github.com/namecoin/ncdns/...
$ go generate github.com/namecoin/ncdns/...
$ go get -t github.com/namecoin/ncdns/...
# github.com/namecoin/ncdns/x509
.go/src/github.com/namecoin/ncdns/x509/x509_splice.go:67:36: not enough arguments in call to buildExtensions
        have (*Certificate)
        want (*Certificate, []byte)

TLSA answer section incorrectly repeats domain twice.

My name (d/aoeu2code) has the following JSON value:

{
  "map": {
    "ns": {
      "ns": "ns.aoeu2code.com."
    },
    "www": {
      "alias": "ns",
      "map": {
        "_tcp": {
          "map": {
            "_443": {
              "tls":[{
                "d8":[
                  1,
                  "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAERPI4mIroqmBLHEQv/IKRixtlQjb32z8bvrNNIzXSxZaIHUysnk6ZDvPygIr22L6jjgQ2b7XIdotr8TPDXDruKQ==",
                  4944096,
                  5259456,
                  10,
                  "MEYCIQDBZlVZiM/qYdxcQ6DcFhoQDBlFOjMXBDBz8UB4mXzNAwIhAM/d5xSLf9Pj1HaZ5DMD+NZJCuh+C8JIYJDo6yljgsyw"
                ]
              }]
            }
          }
        }
      }
    }
  }
}

So basically, I've got a ns subdomain that just points to my nameserver, and the www subdomain CNAMEs over to the ns subdomain, while including the TLSA info under _443._tcp.

The problem is:

$ dig _443._tcp.www.aoeu2code.bit. TLSA @127.0.0.1 -p 5300

; <<>> DiG 9.10.3-P4-Debian <<>> _443._tcp.www.aoeu2code.bit. TLSA @127.0.0.1 -p 5300
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51574
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_443._tcp.www.aoeu2code.bit.	IN	TLSA

;; ANSWER SECTION:
_443._tcp.www.aoeu2code.bit._443._tcp.www.aoeu2code.bit. 600 IN	TLSA 3 0 0 308201D63082017BA003020102021351CA8DE71E424851913274603F BBB669E26CE2300A06082A8648CE3D0403023040311B301906035504 0313127777772E616F657532636F64652E6269742E3121301F060355 040513184E616D65636F696E20544C53204365727469666963617465 301E170D3137303130313030303030305A170D323030313031303030 3030305A3040311B3019060355040313127777772E616F657532636F 64652E6269742E3121301F060355040513184E616D65636F696E2054 4C532043657274696669636174653059301306072A8648CE3D020106 082A8648CE3D0301070342000444F238988AE8AA604B1C442FFC8291 8B1B654236F7DB3F1BBEB34D2335D2C596881D4CAC9E4E990EF3F280 8AF6D8BEA38E04366FB5C8768B6BF133C35C3AEE29A3543052300E06 03551D0F0101FF04040302078030130603551D25040C300A06082B06 010505070301300C0603551D130101FF04023000301D0603551D1104 16301482127777772E616F657532636F64652E6269742E300A06082A 8648CE3D0403020349003046022100C166555988CFEA61DC5C43A0DC 161A100C19453A3317043073F14078997CCD03022100CFDDE7148B7F D3E3D47699E43303F8D6490AE87E0BC2486090E8EB296382CCB0

;; Query time: 3 msec
;; SERVER: 127.0.0.1#5300(127.0.0.1)
;; WHEN: Sat Jan 06 15:43:38 CST 2018
;; MSG SIZE  rcvd: 573

In other words, NCDNS reports the TLSA record as belonging to _443._tcp.www.aoeu2code.bit._443._tcp.www.aoeu2code.bit. - even though the domain that was queried for is _443._tcp.www.aoeu2code.bit..

I did go (ha) ahead and comment out h.Name += suffix and h.Name = suffix at the end of func (v *Value) RRs in convert.go, which fixed this problem for me.

"dns: bad key" when queried by q using KSK

I noticed on 2017 April 30 that running q.exe -dnssec -check -anchor ../bit.key @127.0.0.1 bluishcoder.bit produces the error dns: bad key. Using the ZSK instead works fine.

It's not entirely clear to me what the expected behavior here is. @hlandau 's comment on Matrix was "I find the behaviour of q.exe there extremely peculiar. Unbound validates from a KSK so it seems likely to be a q.exe issue". We probably should look into this more closely (maybe it's been fixed in the year since I noticed it?), and maybe report the issue upstream to q.

Integrate ncdumpzone's Firefox mode to ncdns

We should integrate ncdumpzone's Firefox mode into ncdns, so that it's automated. See namecoin/namecoin.org#245

Audit whether the ICANN root key can sign instead of the ncdns "bit." key

It's unclear to me whether Unbound will accept responses from ncdns that are signed with the ICANN root key. If it does accept such responses, then this has the following security implications:

1. Anyone who can control the network path between Unbound and ncdns will be able to censor .bit domains. (It's unclear to me whether they can do this selectively for only certain .bit domains.)
2. Anyone who can both (a) control the network path between Unbound and ncdns, and (b) sign things with the ICANN root key, will be able to hijack arbitrary .bit domains.

Neither of these is a big deal for the default installation settings that we provide (since the network path to localhost is probably trustworthy), but it becomes a serious problem if someone is running Unbound on a separate device from ncdns (say, an Android phone running Unbound, talking to ncdns on a PC).

If Unbound won't accept such responses, then we should document a procedure for independently auditing this fact. (And it should probably be added to automated CI tests for something.)

Policy on logging sensitive data

In some cases, an end user will want to log data that is specific to visited .bit websites (e.g. to figure out why a site is broken). In other cases (the default), an end user doesn't want sensitive data (e.g. which sites have been visited) to be logged.

We should come up with a policy for which logging verbosity levels are allowed to log sensitive data.

ncdumpzone: Add support for Windows Enterprise Certificate Pinning XML output

It would be useful to add Windows Enterprise Certificate Pinning (ECP) XML as an output format for ncdumpzone. This would give us negative overrides on Windows 10 for any CryptoAPI application.

Makefile doesn't invoke `go generate`

I'm getting the following errors trying to build ncdns (version 09a88dc) using Option B:

lol@foldingmachine:~/p/ncdns$ make
    [RELOCATE]
    [GO-GET]      github.com/namecoin/ncdns
# github.com/namecoin/ncdns/x509
../gopath/src/github.com/namecoin/ncdns/x509/x509_splice.go:37: undefined: Certificate
../gopath/src/github.com/namecoin/ncdns/x509/x509_splice.go:50: undefined: signingParamsForPublicKey
../gopath/src/github.com/namecoin/ncdns/x509/x509_splice.go:58: undefined: marshalPublicKey
../gopath/src/github.com/namecoin/ncdns/x509/x509_splice.go:67: undefined: buildExtensions
../gopath/src/github.com/namecoin/ncdns/x509/x509_splice.go:72: undefined: subjectBytes
../gopath/src/github.com/namecoin/ncdns/x509/x509_splice.go:77: undefined: subjectBytes
../gopath/src/github.com/namecoin/ncdns/x509/x509_splice.go:83: undefined: tbsCertificate
../gopath/src/github.com/namecoin/ncdns/x509/x509_splice.go:114: undefined: certificate
Makefile:77: recipe for target '.gotten' failed
make: *** [.gotten] Error 2

Not sure what the problem is. I get the same error on v0.0.5 and v0.0.4.

ncdns's x509 fork doesn't build on Go 1.9+

my host MINGW64 ~/go
$ go get -t github.com/namecoin/ncdns/...

github.com/namecoin/ncdns/x509

src\github.com\namecoin\ncdns\x509\x509_splice.go:67:36: not enough arguments in call to buildExtensions
have (*Certificate)
want (*Certificate, []byte)

undefined: Certificate

I am trying to compile ncdns, but here is the error:

root@ru:~/build# go get -t github.com/namecoin/ncdns/...
# github.com/namecoin/x509-signature-splice/x509
../go/src/github.com/namecoin/x509-signature-splice/x509/x509_splice.go:98:62: undefined: Certificate
../go/src/github.com/namecoin/x509-signature-splice/x509/x509_splice.go:114:32: undefined: signingParamsForPublicKey
../go/src/github.com/namecoin/x509-signature-splice/x509/x509_splice.go:122:45: undefined: marshalPublicKey
../go/src/github.com/namecoin/x509-signature-splice/x509/x509_splice.go:127:21: undefined: subjectBytes
../go/src/github.com/namecoin/x509-signature-splice/x509/x509_splice.go:132:22: undefined: subjectBytes
../go/src/github.com/namecoin/x509-signature-splice/x509/x509_splice.go:142:21: undefined: buildExtensions
../go/src/github.com/namecoin/x509-signature-splice/x509/x509_splice.go:142:72: undefined: emptyASN1Subject
../go/src/github.com/namecoin/x509-signature-splice/x509/x509_splice.go:148:7: undefined: tbsCertificate
../go/src/github.com/namecoin/x509-signature-splice/x509/x509_splice.go:189:22: undefined: certificate
root@ru:~/build#

systemd service

It would be useful to have a systemd service for ncdns. It looks like @pcre23 has done some initial work on this, but apparently they're stuck.

make clean

We understand that the ncdns repo contains just the necessary bundle to fetch the go package. However, if there are missing dependencies, then running make pollutes the directory in a way that won't allow to rebuild after the necessary dependencies have been fetched. This requires the repository to be completely redownloaded.

Let's introduce a make clean functionality to fix this issue.

Is root needed or not?

The default port for ncdns is port 53. However, if ncdns is run as non-root, it is not able to bind port 53 due to privilege issues. On the other hand, if it is run as root, it refuses to run.

Let's fix this and allow it to drop privileges like most daemons do nowadays.

Should ncdns use name_pending for fast updates?

Missing libcap error is confusing

Making ncdns with a missing pcap dependency produces peculiar errors that are difficult to debug. An error indicating that "pcap is required, please run apt-get such and such" would be much more user-friendly.

Recommend DnssecTrigger instead of plain Unbound in README

The README says:

Install and setup the Unbound recursive resolver on your system. Set it up to start at boot.

Pretty much all the GNU/Linux distros are recommending DnssecTrigger as the package to install instead of plain Unbound, due to DnssecTrigger's interoperability with DHCP. Accordingly, we should recommend DnssecTrigger instead of Unbound. I'm pretty sure DnssecTrigger starts on boot automatically on most OS's, so there's no need to include the 2nd sentence.

Rename "hlandau/ncdns" imports to "namecoin/ncdns"

Several files in ncdns import from subpackages of github.com/hlandau/ncdns. These should be renamed to github.com/namecoin/ncdns since the canonical repo has moved.

RPC credentials exposure

Taking RPC credentials on the commandline potentially make these credentials available to any user that is able to run the ps(1) [or similar] command. ncdt and ncdumpzone ought to be able to find the necessary values in a config file or in environment variables.

Unbound reports SERVFAIL when ncdns has DNSSEC enabled

(title courtesy of Jeremy)

I was trying to set up ncdns on my Windows 10 machine, after it downloaded the blockchain a day later I was getting SERVFAIL errors when attempting to resolve .bit domains (ICANN domains are fine).

The only way I was able to get ncdns to work was to edit DnssecTrigger\unbound.conf.d\ncdns-inst.conf, comment out:

trust-anchor-file: "C:\Program Files\ncdns\bit.key"

and add:

server:
domain-insecure: bit.

As I was only playing around and guessing, I was not sure what I had done or what effect it would have, but Jeremy told me on IRC that what I did was disable DNSSEC (all NT services, Namecoin Core, and the dnssec-trigger systray icon are still running).

He suggested I go on Github, mention this situation and some .bit domains I was attempting to resolve.

Here are some examples of sites I was trying and getting SERVFAILs on before I made the change:

jamieweb.bit (this has a tutorial on use of ncdns with Linux which I was reading, I have not tested ncdns on Linux and was just reading it to learn about the software)
redblade7.bit (goes to a hidden section on an ICANN domain of mine which auto redirects to my twitter page)
redblade84.bit (same as above)
roguecentral.bit (equivalent to coredumpcentral.org)
coredumpcentral.bit (same as above)

A note on jamieweb.bit: it uses HTTPS with a self-signed certificate, which your browser will warn you about.
The others all use HTTP.

Document ncdt and ncdumpzone

ncdt and ncdumpzone are undocumented at the moment. See chatlog below:

Jeremy_Rand
hl: What does ncdt do? I've never used it, and I can't tell from glancing at the source code what its purpose is

hl
Jeremy_Rand: It outputs BIND zone file formatted records for a Namecoin d/ name and JSON value provided on the command line
J
Jeremy_Rand
hl: how does this differ from ncdumpzone?

hl
Jeremy_Rand: that just outputs a BIND zonefile for the entirety of .bit

ncdumpzone: Refactor into library

ncdumpzone's functionality (exporting a zonefile) would be useful to have in a library rather than only a standalone executable.

Subdomains of names with DNAME return NXDOMAIN

Steps to reproduce

./q @127.0.0.1 www.radio.bit
./q @127.0.0.1 www.biteater.dtdns.net

Expected results

Both queries should return the same results, since radio.bit DNAMEs to biteater.dtdns.net.

Observed results

The www.radio.bit query returns NXDOMAIN.

Other notes

I'm not sure if this is a bug in ncdns or madns.

WinNMC: Unable to test the NCDNS part of the package.

namecoind works with namecoin-cli name_show,
Unbound works with 127.0.0.1

I can not confirm that "ncdns" works.

Tested with 64 bit win7.
C:\Program Files (x86)
but found reference to C:\Program Files\

Could not resolve explorer.bit

Escaping HTML

The code at

ncdns/server/web.go

Line 93 in 09a88dc

CanonicalSuffixHTML: template.HTML(cshtml),

doesn't seem to be escaping HTML. Or at least, I can't convince myself by looking at the code that it's properly escaping HTML, and the gas static analysis tool can't convince itself of this either.

Disable non-ASCII domain names until we've evaluated homograph mitigations

Non-ASCII domain names are, on a technical level, vulnerable to homograph attacks that enable impersonation. In the DNS world, this risk is mitigated by DNS registry policies that disallow registering a domain name that is a homograph of an already-registered domain name. (Homographs of TLD's are mitigated by a similar policy at the ICANN level.)

Unfortunately, Namecoin's content-neutral design (specifically the fact that name identifiers are binary blobs without any processing performed as part of the consensus rules) makes it rather difficult for Namecoin to enforce a DNS-like policy on registration time. Enforcing a DNS-like policy on lookup time is probably possible, but it's going to be messy (I suspect that it will probably require adding an extra index, and it will probably also require keeping track of spent outputs).

As a short-term security stopgap until we've evaluated proper fixes, I'm recommending that we simply modify ncdns to refuse to resolve any non-ASCII domain names. The security improvement from disallowing homograph attacks outweighs whatever minimal usage of non-ASCII Namecoin domain names currently exists, especially since this is a security issue where we're currently significantly more vulnerable than the DNS is.

ncdns on Raspberry Pi 3, Raspbian Jessie lite

I'm trying to compile ncdns on Raspbian Jessie installed on Raspberry Pi.

I did not install go language through compiling, and instead used apt-get install golang.

Also installed libcap-dev package with apt-get install libcap-dev.

After cloning this git repo, I changed directory to ncdns, then executed make command, and following is the result with error. I'm not really sure what I need to do next to compile ncdns on Raspberry Pi:

pi@raspberrypi:~/ncdns $ make
    [RELOCATE]    
    [GO-GET]      github.com/hlandau/ncdns
# github.com/hlandau/degoutils/buildinfo
src/github.com/hlandau/degoutils/buildinfo/buildinfo.go:36: undefined: base64.RawStdEncoding
# gopkg.in/hlandau/easyconfig.v1/adaptenv
src/gopkg.in/hlandau/easyconfig.v1/adaptenv/adaptenv.go:43: undefined: os.LookupEnv
# github.com/miekg/dns
src/github.com/miekg/dns/dnssec.go:258: undefined: crypto.Signer
src/github.com/miekg/dns/dnssec.go:322: undefined: crypto.Signer
src/github.com/miekg/dns/sig0.go:17: undefined: crypto.Signer
Makefile:78: recipe for target '.gotten' failed
make: *** [.gotten] Error 2

Please help.

Build with RBM

The Tor developers are planning to migrate from Gitian to RBM. See the following Tor tickets:

• https://trac.torproject.org/projects/tor/ticket/17379
• https://trac.torproject.org/projects/tor/ticket/23213

The new RBM-based build scripts for Tor Browser are at https://gitweb.torproject.org/builders/tor-browser-build.git/ . We should look into porting ncdns to use those build scripts.

Why use a fork of btcjson?

ncdns uses a fork of Conformal's btcjson.

What is the reason for that fork? Only one substantive change seems to be present, and it's not obvious to me why it's needed.

Also, Conformal has discontinued usage of that library; their current (rewritten) code is at https://github.com/btcsuite/btcd/tree/master/btcjson and https://github.com/btcsuite/btcrpcclient .

I'm interested in switching to the new Conformal libs, but it's hard to do this without knowing what the purpose of the fork is.

Log incoming requests and attempts to contact namecoind

When I'm running ncdns, the debug output doesn't have any info about incoming DNS requests, or attempts to contact namecoind to fulfill those requests. As such, it's very hard to tell when Unbound has actually sent any DNS traffic to ncdns. This info should be logged.

Build error using new Go version. x509_splice.go: "not enough arguments to buildExtensions"

Building with the latest stable version of Go, I get the following build error:

C:\Users\rofl\go>go get -t github.com/namecoin/ncdns/...
# github.com/namecoin/ncdns/x509
src\github.com\namecoin\ncdns\x509\x509_splice.go:67:36: not enough arguments in call to buildExtensions
        have (*Certificate)
        want (*Certificate, []byte)

The build succeeds with an older version.

ncdumpzone infinite loop in Namecoin Core 0.18.0

Namecoin Core 0.18.0 omits the "name" field from name_show and name_scan results when an encoding error occurs (e.g. a non-ASCII name when the requested encoding is ASCII). Unfortunately, ncdumpzone is interpreting this as the empty string, and as a result ncdumpzone sets currentName to the empty string if the final name_scan result had an encoding error. This produces an infinite loop.

GOROOT problem on Windows

Here's the output I get when I run the build commands on Windows:

C:\Users\rofl\go>go get -d -t -u github.com/namecoin/ncdns/...

C:\Users\rofl\go>go generate github.com/namecoin/ncdns/...
install.sh: line 6: no match: C:\Go/src/crypto/x509/*
src\github.com\namecoin\ncdns\x509\x509_splice.go:9: running "bash": exit status 1

I guess backslashes in GOROOT need to be escaped.

Setting the GOROOT environment variable does not matter; I get the same error.

However, when I edit install.sh and change line 6 from cp -a $(go env GOROOT)/src/crypto/x509/* ./ to cp -a C:/Go/src/crypto/x509/* ./, the command succeeds.

EDIT: Oh, goroot, goroot!

Port ncdns to OSX

We plan to use ncdns as part of a solution to enable namecoin-based hidden service name resolution for Tor. This support will require porting ncdns to OSX. What are your plans for that?

Web server doesn't support stream isolation

All instances of Query() in server/web.go should allow the user to supply a stream isolation ID.

Windows Service support has excessive privileges

It appears that the Windows Service feature runs as LocalSystem. This is very excessive; it's basically like running as root on GNU/Linux.

Some background info is at https://msdn.microsoft.com/en-us/library/windows/desktop/ms684190%28v=vs.85%29.aspx , https://msdn.microsoft.com/en-us/library/windows/desktop/ms684188%28v=vs.85%29.aspx , and https://wiki.filezilla-project.org/Securing_your_Windows_Service_installation .

Note that using LocalService is probably more secure, but will break the TLS stuff that I'm working on. The right solution is probably to create an ncdns-specific user. (Unless there's some other preferred way in Windows which neither I nor the Filezilla developers are aware of?)

I will probably spend some time looking at this topic after the BIP9 hardfork is out of the way. Until then, I recommend not using ncdns as a Windows Service.

Backend LRU cache behavior when MaxEntries == 0 is misleading

The text that appears via ncdns --help includes the following text for the cachemaxentries flag: Maximum name cache entries (default 100). This would lead the user to believe that setting it to 0 will disable the cache. However, in the implementation of Backend, we see this:

b.cache.MaxEntries = cfg.CacheMaxEntries
if b.cache.MaxEntries == 0 {
	b.cache.MaxEntries = defaultMaxEntries
}

defaultMaxEntries is set to... 100.

This behavior is extremely misleading and is likely to cause security problems for users who think they've disabled the LRU cache in order to avoid leaking state between queries (e.g. in the case of Tor stream isolation). Granted, implementing stream-isolated LRU caches is the "right way" to solve the specific use case of Tor stream isolation, but this behavior is still misleading and dangerous.

It's not clear to me why ncdns doesn't just pass through cfg.CacheMaxEntries without the special case for 0. Does the LRU implementation break stuff if you tell it the max size is 0?

Create and/or nominate an official solution for a Windows tray supervisor process

Some kind of tray icon with at least a menu option for both "restarting" and "exiting" NCDNS would be awesome.

Keep up the good work.

ncdumpzone doesn't support stream isolation

ncdumpzone (both the library and executable) should allow the user to supply a stream isolation ID.

Error check is commented out in convert.go

The error check at

ncdns/ncdomain/convert.go

Line 339 in 0688b3e

out, err = mv.RRsRecursive(out, mk+"."+suffix, apexSuffix)

is commented out. Is there a reason for this? It's causing static analysis to complain.

ncdumpzone: Add support for Windows EMET Certificate Trust XML output

It would be useful to add Windows EMET Certificate Trust XML as an output format for ncdumpzone. This would give us negative overrides on Windows for any CryptoAPI application that is supported by EMET.

Cannot bind to port 53

Hi,
As per documentation I tried
sudo setcap 'cap_net_bind_service=+ep' ./ncdns
sudo setcap 'cap_net_bind_service=+ep' /home/myusername/goprojects/bin/ncdns

sudo /home/yield/goprojects/bin/ncdns -uid nobody
Although this I suppose it's now -service.uid
sudo /home/yield/goprojects/bin/ncdns -service.uid nobody
sudo /home/yield/goprojects/bin/ncdns -service.uid myusername

And all of them resulted in
20161111211817 [CRITICAL] ncdns.server: fatal: : listen tcp :53: bind: permission denied

Right now I'm binding it on :5454 and using ufw to make the port forward from :53 to :5454 but I don't think this is the intended use.
I'm on ubuntu 16.10 kernel 4.4.0-45-generic, ncdns compiled from git repo.
Thanks.

Unbound reports DNSSEC validation failure for nonexistent subdomains of .bit domains

Whenever I use q to query Unbound for a nonexistent subdomain of a .bit domain (e.g. the www.bluishcoder.bit subdomain, which doesn't exist while bluishcoder.bit does exist), I get SERVFAIL instead of NXDOMAIN. ncdns itself does correctly return NXDOMAIN.

The following shows up in Unbound's systemd logs when verbosity is set to 2 (the log is for looking up TLSA records in _443._tcp.bluishcoder.bit):

Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: resolving _443._tcp.bluishcoder.bit. TLSA IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: use stub bit. NS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: resolving bit. DNSKEY IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _443._tcp.bluishcoder.bit. TLSA IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was ANSWER
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _443._tcp.bluishcoder.bit. TLSA IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was DNSSEC LAME
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _443._tcp.bluishcoder.bit. TLSA IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was NXDOMAIN ANSWER
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: resolving bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: use stub bit. NS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was nodata ANSWER
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: NSEC3s for the referral proved no delegation
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: resolving _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: use stub bit. NS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was ANSWER
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: resolving bluishcoder.bit. NS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: use stub bit. NS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for bluishcoder.bit. NS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was ANSWER
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for bluishcoder.bit. NS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was nodata ANSWER
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was DNSSEC LAME
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was NXDOMAIN ANSWER
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: resolving _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: use stub bit. NS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was ANSWER
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: resolving bluishcoder.bit. NS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was DNSSEC LAME
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was NXDOMAIN ANSWER
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: resolving _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: use stub bit. NS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was ANSWER
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: resolving bluishcoder.bit. NS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was DNSSEC LAME
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was NXDOMAIN ANSWER
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: resolving _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: use stub bit. NS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was ANSWER
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: resolving bluishcoder.bit. NS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was DNSSEC LAME
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was NXDOMAIN ANSWER
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: resolving _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: use stub bit. NS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was ANSWER
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: resolving bluishcoder.bit. NS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was DNSSEC LAME
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was NXDOMAIN ANSWER
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: resolving _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: use stub bit. NS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was ANSWER
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: resolving bluishcoder.bit. NS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was DNSSEC LAME
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: response for _tcp.bluishcoder.bit. DS IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: reply from <bit.> 127.0.0.1#5391
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: query response was NXDOMAIN ANSWER
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: Could not establish a chain of trust to keys for _tcp.bluishcoder.bit. DNSKEY IN
Feb 09 01:58:38 namecoin-qa-fedora unbound[27625]: [27625:2] info: validation failure _443._tcp.bluishcoder.bit. TLSA IN

This happens for the following environments:

• ncdns v0.0.6 in Fedora, DNSSEC configured manually
• ncdns v0.0.8 in Fedora, DNSSEC configured manually
• ncdns-nsis v0.0.8 in Windows, DNSSEC configured by NSIS

I wouldn't be surprised if this is a madns bug rather than an ncdns bug, but as I can't prove that I'm posting the issue in the ncdns repo.

ncdt doesn't support stream isolation

ncdt should allow the user to supply a stream isolation ID via command-line flag.

Document testing on Windows

I realize that this could be argued to be a PEBKAC error, but there's no documentation for how to test whether ncdns is working on Windows. nslookup is (I assume) the command that would be used, but I failed to find documentation for how to use nonstandard DNS server ports with nslookup anywhere on the Internet (I looked for about 15 minutes). A simple command to copy/paste would be very nice to have documented.

Look into transparent DNS redirects for non-DNS record types

Tor onion services and ZeroNet services aren't usually accessed by DNS. However, Tor does have the ability to do some kind of transparent DNS magic that I don't fully understand, so that when an application does a DNS query for a .onion domain, Tor replies with a DNS response that results in the TCP connection being directed to an IP that Tor can intercept and route to the onion service.

We could, in theory, make ncdns mimic this behavior for .bit domains that point to an onion service. We could probably also do something vaguely analogous (though perhaps implemented differently) for .bit domains that point to a ZeroNet site.

It should be noted that doing this kind of trick will break stream isolation. It will also not work properly for DNS names that point to onion services or ZeroNet sites. It may be wiser to instead do this kind of thing via dns-prop279 or Yawning's SOCKS proxy. I'm filing this issue not because I'm convinced this is a smart thing to do, but simply because it occurred to me and I wanted to write it down and get comments.

Backend LRU cache doesn't support stream isolation

All queries to a Backend use the same LRU cache, which will leak state between queries. This is harmful for use cases such as Tor, where stream-isolated connections should not share any state. We should fix this by implementing stream-isolated LRU caches.