GitLab

Summary

In the kskroll-sentinel code, the is-ta result comes back NXDOMAIN instead of NOERROR.

(This is marked as confidential because I don't want people to think that I'm ragging on folks who are implementing kskroll-sentinel; that could get in the way of adoption.)

Steps to reproduce

1. Set up an authoritative server with the right kskroll-sentinel records. My running example is below.
2. Create BIND (in this case, from the git repo in the 'v9_12' branch)
3. Configure it trivially. My running example is below.

What is the current bug behavior?

# dig @bind-on-234.proper.com root-key-sentinel-is-ta-20326.this-is-signed.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35304
;; AUTHORITY SECTION:
this-is-signed.com.	29	IN	SOA	q.com. phoffman.proper.com. 2018052100 300 60 1209600 300

What is the expected correct behavior?

You should get a NOERROR with the A record

Relevant configuration files

$ORIGIN this-is-signed.com.
$TTL 60
$INCLUDE Kthis-is-signed.com.+008+39331.key
@ IN  SOA q.com. phoffman.proper.com. (2018052100 5m 1m 2w 5m )
@ IN NS r.secondary2.com.
@ IN NS q.secondary2.com.
@ IN A 192.241.207.161
sentinel IN A 192.241.207.161
root-key-sentinel-is-ta-20326 IN A 192.241.207.161
root-key-sentinel-not-ta-20326 IN A 192.241.207.161
bogus IN A 192.241.207.161

options {
recursion yes;
listen-on { any; };
dnssec-enable yes;
dnssec-validation auto;
};

Relevant logs and/or screenshots

May 21 16:36:27 bind-on-234 named[56216]: client @0x7f975800b8e0 45.79.105.33#55492 (root-key-sentinel-is-ta-20326.this-is-signed.com): root-key-sentinel-is-ta query label found
May 21 16:36:36 bind-on-234 named[56216]: client @0x7f975c1007d0 45.79.105.33#41482 (root-key-sentinel-not-ta-20326.this-is-signed.com): root-key-sentinel-not-ta query label found