[Unbound-users] Setting Unbound as validating resolver for stub zones

W.C.A. Wijngaards wouter at NLnetLabs.nl
Wed Feb 23 07:02:53 UTC 2011

Hash: SHA1

Hi Sebastian,

On 02/23/2011 06:01 AM, Sebastian Castro wrote:
> 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: at 53053
> 	port: 53
> 	do-ip4: yes
> 	do-ip6: no
> 	access-control: allow
> 	access-control: allow
> 	access-control: allow
> 	access-control: allow
> 	access-control: 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 at 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 at 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 @ -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,
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/


More information about the Unbound-users mailing list