Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#49264 closed defect (fixed)

unbound don't promote DNSSEC under El Capitan

Reported by: macuserguru Owned by: nerdling (Jeremy Lavergne)
Priority: Normal Milestone:
Component: ports Version: 2.3.4
Keywords: haspatch Cc: macuserguru, danielluke (Daniel J. Luke)
Port: unbound

Description (last modified by danielluke (Daniel J. Luke))

I had run unbound under Yosemite and DNSSEC works well.

Now after upgrade to El Capitan I delete all ports and reinstalled all new.

Now unbound don't promote DNSSEC but it runs well.

update root key works well to /opt/local/var/run/unbound/root.key

a part of unbound.conf

        chroot: "/opt/local/etc/unbound"
	username: "unbound"
	directory: "/opt/local/etc/unbound"	
	logfile: "/logs/unbound.log"
	use-syslog: no 	
	log-time-ascii: yes
	log-queries: yes
        root-hints: "/named.cache"
        harden-glue: yes
        harden-dnssec-stripped: yes

What could I do to resolve this?

Attachments (2)

unbound.conf (6.9 KB) - added by macuserguru 9 years ago.
Current unbound.conf
move_root.key_patch.diff (2.0 KB) - added by danielluke (Daniel J. Luke) 9 years ago.
move root.key inside of chroot

Download all attachments as: .zip

Change History (30)

comment:1 Changed 9 years ago by macuserguru

Cc: fritzs@… added

Cc Me!

comment:2 Changed 9 years ago by danielluke (Daniel J. Luke)

I can replicate this. If I uncomment auto-trust-anchor-file: "/opt/local/var/run/unbound/root.key" in the unbound.conf, and start with verbose/debug, I get the following in syslog:

Oct 13 15:55:00 xeon unbound[13437] <Notice>: [13437:0] notice: init module 0: validator
Oct 13 15:55:00 xeon unbound[13437] <Error>: [13437:0] error: unable to open /opt/local/var/run/unbound/root.key for reading: No such file or directory
Oct 13 15:55:00 xeon unbound[13437] <Error>: [13437:0] error: error reading auto-trust-anchor-file: /opt/local/var/run/unbound/root.key
Oct 13 15:55:00 xeon unbound[13437] <Error>: [13437:0] error: validator: error in trustanchors config
Oct 13 15:55:00 xeon unbound[13437] <Error>: [13437:0] error: validator: could not apply configuration settings.
Oct 13 15:55:00 xeon unbound[13437] <Error>: [13437:0] error: module init for module validator failed
Oct 13 15:55:00 xeon unbound[13437] <Critical>: [13437:0] fatal error: failed to setup modules

which is odd, because the file is there and readable by the 'unbound' user.

comment:3 Changed 9 years ago by danielluke (Daniel J. Luke)

Description: modified (diff)

comment:4 Changed 9 years ago by danielluke (Daniel J. Luke)

Cc: dluke@… added

Cc Me!

comment:5 Changed 9 years ago by danielluke (Daniel J. Luke)

Owner: changed from macports-tickets@… to snc@…
Port: unbound added

comment:6 Changed 9 years ago by danielluke (Daniel J. Luke)

I'll also note here that I've had to change my configuration on 10.11 to only run a single thread (num-threads: 1) in order to prevent a kernel panic (already reported to Apple, and it was closed as a duplicate).

Changed 9 years ago by macuserguru

Attachment: unbound.conf added

Current unbound.conf

comment:7 Changed 9 years ago by macuserguru

I uncomment auto-trust-anchor-file: "/opt/local/var/run/unbound/root.key" in the unbound.conf, unbound don't start.

as far as I know the path to root.key is hard coded in unbound

browser:trunk/dports/net/unbound/Portfile

configure.args-append   --with-pidfile=${prefix}/var/run/${name}/${name}.pid \
                        --with-rootkey-file=${prefix}/var/run/${name}/root.key
Last edited 9 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:8 Changed 9 years ago by macuserguru

I run unbound in two threads: num-threads: 2

and on all available interfaces interface: 0.0.0.0 interface: ::0

If I use the fix interface IP addresses in unbound.conf Little Snitch blocks unbound at start the Mac.

About Little Snitch: https://www.obdev.at/products/littlesnitch/index-en.html

comment:9 Changed 9 years ago by macuserguru

any idea what happens?

$ dig +noall +comments dnssec-failed.org
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33064
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 0
$ dig org. SOA +dnssec

; <<>> DiG 9.8.3-P1 <<>> org. SOA +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15888
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 7

http://www.unbound.net/documentation/howto_anchor.html If you then dig com. SOA +dnssec you should see the AD flag there. If things go wrong, try the unbound option val-log-level: 2 that will log explanations why the DNSSEC validation fails (one line per failed query).

comment:10 Changed 9 years ago by danielluke (Daniel J. Luke)

comment:11 Changed 9 years ago by danielluke (Daniel J. Luke)

upstreamworkaround:

chroot: ""
auto-trust-anchor-file: "/opt/local/var/run/unbound/root.key"

appears to work.

comment:12 Changed 9 years ago by macuserguru

whats a greater security hole - without chroot and with DNSSEC or with chroot and without DNSEC on a single machine ;-)

must adapt the path from logfile, root-hints too?

        chroot: ""
	username: "unbound"
	directory: "/opt/local/etc/unbound"	
	logfile: "/logs/unbound.log"
	use-syslog: no 	
	log-time-ascii: yes
	log-queries: yes
        root-hints: "/named.cache"
        harden-glue: yes
        harden-dnssec-stripped: yes
        auto-trust-anchor-file: "/opt/local/var/run/unbound/root.key"

comment:13 Changed 9 years ago by macuserguru

what your opinion - comes a unbound version which works both - chroot and DNSSEC soon? If yes I could wait.

Last edited 9 years ago by macuserguru (previous) (diff)

comment:14 Changed 9 years ago by danielluke (Daniel J. Luke)

This can be fixed by moving the root.key file into the chroot dir (/opt/local/etc/unbound)

Changed 9 years ago by danielluke (Daniel J. Luke)

Attachment: move_root.key_patch.diff added

move root.key inside of chroot

comment:15 Changed 9 years ago by danielluke (Daniel J. Luke)

Keywords: haspatch added

Patch attached for review.

comment:16 Changed 9 years ago by nerdling (Jeremy Lavergne)

Looks good to me. I can test and commit it in 30m; if you want to commit now, go for it.

comment:17 in reply to:  16 Changed 9 years ago by danielluke (Daniel J. Luke)

Replying to snc@…:

Looks good to me. I can test and commit it in 30m; if you want to commit now, go for it.

I didn't test the startupitem, so I'll let you double check it and commit.

comment:18 Changed 9 years ago by nerdling (Jeremy Lavergne)

Just tried it out: not getting the AD flag and no output in the log. Please let me know how to correct my testing.

I'm using the unbound.conf-dist, and adding this to the server section:

server:
    logfile: "${prefix}/etc/unbound/unbound.log"
    val-log-level: 2
$ dig +dnssec www.isoc.org. @127.0.0.1

; <<>> DiG 9.8.3-P1 <<>> +dnssec www.isoc.org. @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48420
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.isoc.org.			IN	A

;; ANSWER SECTION:
www.isoc.org.		86400	IN	A	212.110.167.157
www.isoc.org.		86400	IN	RRSIG	A 7 3 86400 20151111205000 20151028205000 23792 isoc.org. aoU3XNuKOIznZmE4lFQ4niUpvFnrQqfy9hk79F/xtcLgCIQDnst6LC/J ua2Xr0P6uI8Tcqnyt+jMo59gG4jpt96zZgsVEZNnqJa1ph9zW12aSV8L Iq2i81B1Yyht78q7kP5Iozs0svYOgqsAGfX+XWnMGhD/akZGuz995WP3 5/4=

;; AUTHORITY SECTION:
isoc.org.		86400	IN	NS	a0.dig.afilias-nst.info.
isoc.org.		86400	IN	NS	b0.dig.afilias-nst.info.
isoc.org.		86400	IN	NS	c0.dig.afilias-nst.info.
isoc.org.		86400	IN	NS	d0.dig.afilias-nst.info.
isoc.org.		86400	IN	NS	ns-ext.nlnetlabs.nl.
isoc.org.		86400	IN	RRSIG	NS 7 2 86400 20151111205000 20151028205000 23792 isoc.org. tnO/TBGTR0fBA+GoJWA+sn539EYcQzofMWbfsytJkpr0zoIp6i7p1eWx 0F7XI+liajyjaVFB3QDxJ6YM+5D4+DY0vdjOQH6XFcl7tYuNb6AZew06 aEtTXjtlf2xM6IXIeyJOv25Tj/vEkRZNA1bPxSMadDVHblT3PK7xQJtu jHY=

;; Query time: 297 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 29 11:52:46 2015
;; MSG SIZE  rcvd: 514
Last edited 9 years ago by nerdling (Jeremy Lavergne) (previous) (diff)

comment:19 Changed 9 years ago by danielluke (Daniel J. Luke)

It works with my 'regular' config, but not with the -dist (for no obvious reason). I'll see if I can narrow it down.

comment:20 in reply to:  19 Changed 9 years ago by danielluke (Daniel J. Luke)

Replying to dluke@…:

It works with my 'regular' config, but not with the -dist (for no obvious reason). I'll see if I can narrow it down.

... and now I can't get it to fail, even with the -dist conf file.

comment:21 Changed 9 years ago by nerdling (Jeremy Lavergne)

You did unload/load, right? ;-)

So you always get AD record. Perhaps my upstream DNS does not, and that's the real reason I'm not seeing it.

comment:22 in reply to:  21 Changed 9 years ago by danielluke (Daniel J. Luke)

Replying to snc@…:

You did unload/load, right? ;-)

For troubleshooting I was running a new process with sudo -u unbound /opt/local/sbin/unbound -dvvv and then killing it (control-c) and starting a new one.

So you always get AD record. Perhaps my upstream DNS does not, and that's the real reason I'm not seeing it.

'upstream dns'? I don't think the default config forwards requests to other recursors.

Maybe try an alternate test:

dig sigok.verteiltesysteme.net @127.0.0.1 (should work) dig sigfail.verteiltesysteme.net @127.0.0.1 (should fail)

and/or

dig www.dnssec-failed.org @127.0.0.1 (should fail)

comment:23 Changed 9 years ago by nerdling (Jeremy Lavergne)

I got AD records this time: just realized I had left off the auto-trust-anchor-file: "${prefix}/etc/unbound/root.key".

comment:24 Changed 9 years ago by nerdling (Jeremy Lavergne)

Do we want to modify the unbound.conf-dist file to set the trust anchor?

Similarly, do we want to install the default config file (I think we want to force the user to configure the program so I'm currently against this but open to ideas).

Last edited 9 years ago by nerdling (Jeremy Lavergne) (previous) (diff)

comment:25 in reply to:  24 Changed 9 years ago by danielluke (Daniel J. Luke)

Replying to snc@…:

Do we want to modify the unbound.conf-dist file to set the trust anchor?

up to you, but I think it's probably a good idea.

Similarly, do we want to install the default config file (I think we want to force the user to configure the program so I'm currently against this but open to ideas).

this is also up to you, just make sure you have a really conservative default conf if you go that route - the internet doesn't need more open resolvers for people to abuse. (I don't have the bind9 conf file installed by default - and so I think it's reasonable to require a person to manually set it up).

comment:26 Changed 9 years ago by nerdling (Jeremy Lavergne)

Alrighty, I'll modify the unbound.conf-dist but not copy it to unbound.conf (letting unbound run on its expected, safe defaults).

Last edited 9 years ago by nerdling (Jeremy Lavergne) (previous) (diff)

comment:27 Changed 9 years ago by nerdling (Jeremy Lavergne)

Resolution: fixed
Status: newclosed

Updated in r141858.

comment:28 Changed 9 years ago by macuserguru

This brings the right answer now:

$ dig org. SOA +dnssec @127.0.0.1

; <<>> DiG 9.8.3-P1 <<>> org. SOA +dnssec @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10818
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 1

My DNS resolution is only set to 127.0.0.1

Last edited 9 years ago by macuserguru (previous) (diff)
Note: See TracTickets for help on using tickets.