Setting Unbound as validating resolver for stub zones

Unbound
1

Hi:

I'm setting up Unbound to do DNSSEC validation but for zones signed in a
lab environment.

Currently the configuration says:

server:
  verbosity: 2
  interface: 192.168.22.187@53053
  port: 53
  do-ip4: yes
  do-ip6: no
  access-control: 192.168.2.0/24 allow
  access-control: 192.168.22.0/24 allow
  access-control: 192.168.157.22/32 allow
  access-control: 192.168.159.20/32 allow
  access-control: 172.0.0.0/8 allow
  chroot: ""
  logfile: "/var/log/unbound.log"
  use-syslog: no
  log-time-ascii: yes
  trust-anchor-file: "/opt/etc/unbound/ta.txt"
  val-log-level: 2
stub-zone:
  name: "parent"
  stub-addr: A.B.C.D@53
  stub-prime: no
  name: "child1.parent"
  stub-addr: A.B.C.D@53
  stub-prime: no

A.B.C.D is serving a signed zone for parent and child1.parent with valid
data (sig chasing with dig or drill works).

If I try querying Unbound for <SOA, parent>, I get an answer but no AD bit.

dig soa parent @192.168.22.187 -p 53053

; <<>> DiG 9.6-ESV-R1 <<>> soa parent @srsov-dnssecmon -p 53053
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7610
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 0

;; QUESTION SECTION:
;parent. IN SOA

;; ANSWER SECTION:
parent. 3600 IN SOA ns1.parent. hostmaster.parent. 2011022368 900 300
604800 3600

[Rest deleted]

Log file shows it's using the stub to query for <SOA. parent> and
<DNSKEY, parent> and the validation is successful.

info: validate keys with anchor(DS): sec_status_secure
info: Successfully primed trust anchor <parent. DNSKEY IN>
info: validate(positive): sec_status_secure
info: validation success <parent. SOA IN>

If we query for <SOA, child1.parent> we get SERVFAIL. The validation log
shows it's using the stub for <SOA, child1.parent> and for <DS,
child1.parent>, but it's using the NS records from the zone (which don't
have a signed zone) to look for the DNSKEY, breaking the validation.

Based on this message from the mailing list
http://www.unbound.net/pipermail/unbound-users/2008-October/000240.html
I thought when specifying the port in the stub-addr option the NS
records will be ignored, but I'm wrong.

I also tried adding as local-data the names of the nameservers for the
zone pointing to the authoritative nameserver serving the signed zone,
but it didn't work. It looks like this:

local-data: "ns1.parent A A.B.C.D"
local-data: "ns2.parent A A.B.C.D"

So, Has anyone tried this in a lab to test validation?
Any suggestions to make it work as intended?

Cheers,

2

Hi Sebastian,

Hi:

I'm setting up Unbound to do DNSSEC validation but for zones signed in a
lab environment.

Currently the configuration says:

server:
  verbosity: 2
  interface: 192.168.22.187@53053
  port: 53
  do-ip4: yes
  do-ip6: no
  access-control: 192.168.2.0/24 allow
  access-control: 192.168.22.0/24 allow
  access-control: 192.168.157.22/32 allow
  access-control: 192.168.159.20/32 allow
  access-control: 172.0.0.0/8 allow
  chroot: ""
  logfile: "/var/log/unbound.log"
  use-syslog: no
  log-time-ascii: yes
  trust-anchor-file: "/opt/etc/unbound/ta.txt"
  val-log-level: 2
stub-zone:
  name: "parent"
  stub-addr: A.B.C.D@53
  stub-prime: no

Here needs to be another stub-zone: line to start another stub-zone.

  name: "child1.parent"
  stub-addr: A.B.C.D@53
  stub-prime: no

A.B.C.D is serving a signed zone for parent and child1.parent with valid
data (sig chasing with dig or drill works).

If I try querying Unbound for <SOA, parent>, I get an answer but no AD bit.

You have to use +dnssec to get the AD bit on the reply. If the
signature failed you would not get a reply, so I think it validated.

dig soa parent @192.168.22.187 -p 53053

If we query for <SOA, child1.parent> we get SERVFAIL. The validation log
shows it's using the stub for <SOA, child1.parent> and for <DS,
child1.parent>, but it's using the NS records from the zone (which don't
have a signed zone) to look for the DNSKEY, breaking the validation.

I think the config above may be nicer, but this description could be
some other trouble perhaps, I assume it means it is confused by the lack
of a stub-zone: label creating a new stub-zone entry (and the settings
simply override the name and add an address.)

Based on this message from the mailing list
http://www.unbound.net/pipermail/unbound-users/2008-October/000240.html
I thought when specifying the port in the stub-addr option the NS
records will be ignored, but I'm wrong.

I also tried adding as local-data the names of the nameservers for the
zone pointing to the authoritative nameserver serving the signed zone,
but it didn't work. It looks like this:

local-data: "ns1.parent A A.B.C.D"
local-data: "ns2.parent A A.B.C.D"

So, Has anyone tried this in a lab to test validation?
Any suggestions to make it work as intended?

Best regards,
   Wouter

3

Hi Sebastian,

Hi Wouter,

Your indications helped and now works, thanks. Just a quick note below.

stub-zone:
  name: "parent"
  stub-addr: A.B.C.D@53
  stub-prime: no

Here needs to be another stub-zone: line to start another stub-zone.

Shouldn't unbound check for the correct syntax of the configuration
file? In this case is correct, but ambiguous.

  name: "child1.parent"
  stub-addr: A.B.C.D@53
  stub-prime: no

A.B.C.D is serving a signed zone for parent and child1.parent with valid
data (sig chasing with dig or drill works).

If I try querying Unbound for <SOA, parent>, I get an answer but no AD bit.

You have to use +dnssec to get the AD bit on the reply. If the
signature failed you would not get a reply, so I think it validated.

What a newbie! How I missed that... thanks!

Best regards,
   Wouter

Cheers,