DNSSEC validation is failing

[rnhmjoj]

I've tried to enable DNSSEC as described in the README.md
but the validation of .bit domains is failing. It looks like the DS record at the bit. zone is empty.

This is a trace from pdns-recursor (a recursive name server) that's showing the failure:

3 [1/1] question for 'test.bit|A' from 127.0.0.1:42272
[1] test.bit: Wants DNSSEC processing, auth data in query for A
[1] test.bit: Looking for CNAME cache hit of 'test.bit|CNAME'
[1] test.bit: Looking for DNAME cache hit of 'test.bit|DNAME' or its ancestors
[1] test.bit: No CNAME or DNAME cache hit of 'test.bit' found
[1] test.bit: No cache hit for 'test.bit|A', trying to find an appropriate NS record
[1] : no TA found for '.' among 1
[1] : setting cut state for . to Insecure
[1] : - Looking for a cut at bit
[1] : got TA for 'bit'
[1] : New state for bit is Secure
[1] : - Looking for a cut at test.bit
[1] : no TA found for 'test.bit' among 1
[1]  test.bit: Wants DNSSEC processing, auth data in query for DS
[1]  test.bit: No cache hit for 'test.bit|DS', trying to find an appropriate NS record
[1] : got status Secure for name test.bit (from bit)
[1]  test.bit: initial validation status for test.bit is Secure
[1]  test.bit: Cache consultations done, have 1 NS to contact
[1]  test.bit: Domain has hardcoded nameserver
[1]  test.bit.: Nameservers: +127.0.0.1:5333(0.00ms)
[1]  test.bit: Resolved 'bit' NS (empty) to: 127.0.0.1
[1]  test.bit: Trying IP 127.0.0.1:5333, asking 'test.bit|DS'
[1]  test.bit: Got 0 answers from (empty) (127.0.0.1), rcode=1 (Form Error), aa=0, in 37ms
[1]  test.bit: determining status after receiving this packet
[1]  test.bit: Failed to resolve via any of the 1 offered NS at level 'bit'
[1]  test.bit: failed (res=-1)
Starting validation of answer to test.bit|A for 127.0.0.1:42272
3 [1/1] answer to question 'test.bit|A': 0 answers, 0 additional, took 1 packets, 37.786 netw ms, 38.248 tot ms, 0 throttled, 0 timeouts, 0 tcp connections, rcode=2, dnssec=Indeterminate

As you can see ncdns is returning a Form Error. This is a problem because starting with version 4.3.3, pdns-recursor
treats it as a SERVFAIL, which completely breaks the bit. zone.

This is the configuration I've been using for testing:

[ncdns]
bind = "127.0.0.1:5333"
hostmaster = "[email protected]"
namecoinrpcaddress = "127.0.0.1:8332"
namecoinrpcpassword = "secret"
namecoinrpcusername = "namecoin"
privatekey = "../../var/lib/ncdns/bit.private"
publickey = "../../var/lib/ncdns/bit.key"
selfip = "1.0.0.1"
selfname = "example.com"
zoneprivatekey = "../../var/lib/ncdns/bit-zone.private"
zonepublickey = "../../var/lib/ncdns/bit-zone.key"

[service]
daemon = true

[xlog]
journal = true

[JeremyRand]

Hi, thanks for the bug report! I'll look into this as soon as I can. Might take a week or two, as I have some deadlines coming up on Sept 30 and Oct 1.

[rnhmjoj]

Thank you for looking into this.

[rnhmjoj]

Any update?

[JeremyRand]

Haven't had a chance yet, been busy with a refactor of another part of the ncdns codebase (specifically certinject). That refactor is nearing completion, so hopefully will get to this soon.

[rnhmjoj]

So, it's been almost an year... I checked again HEAD and the validation is still failing.
Any chance this will be fixed?

[JeremyRand]

Apologies for the delay, things have been busy here. Might be able to look at it after the v0.2.2 release is finished (which should be within the next week). Alas, there is not much funding available at the moment for me to work on DNSSEC-related things, so things that actually do have funding (e.g. TLS stuff) have been consuming my time.

[JeremyRand]

Hi @rnhmjoj,

According to RFC 4034 Sec. 5:

The DS RR and its corresponding DNSKEY RR have the same owner name, but they are stored in different locations. The DS RR appears only on the upper (parental) side of a delegation, and is authoritative data in the parent zone. For example, the DS RR for "example.com" is stored in the "com" zone (the parent zone) rather than in the "example.com" zone (the child zone). The corresponding DNSKEY RR is stored in the "example.com" zone (the child zone).

Given this, I'm a bit confused why pdns-recursor is issuing a DS query for the bit. zone to ncdns. Is there any reason why this isn't a pdns-recursor bug?

That said, RFC 4035 Appendix B.8 says that the correct behavior for ncdns when a resolver makes this error is to return RCODE=0. So the reported behavior definitely sounds like an RFC violation on our end, regardless of pdns-recursor having a bug or not. I'm now looking into how easy this will be to fix. Probably it's a bug in madns rather than ncdns itself.

[JeremyRand]

This is taking longer than hoped to fix, mainly because integration tests for the fix are difficult to get right. That said, I am making progress; hoping to have news next week.

[rnhmjoj]

Given this, I'm a bit confused why pdns-recursor is issuing a DS query for the bit. zone to ncdns. Is there any reason why this isn't a pdns-recursor bug?

I wouldn't really know as I'm not a expert on DNS. I guess I'll forward the question to the pdns-recursors devs.

This is taking longer than hoped to fix, mainly because integration tests for the fix are difficult to get right. That said, I am making progress; hoping to have news next week.

Great! Thank you for the working on this.

[JeremyRand]

Should be easier to do integration tests once #160 is done.