Bug 196138
| Summary: | Unbound fails with 2(SERVFAIL) when behind NAT | ||
|---|---|---|---|
| Product: | Base System | Reporter: | rsimmons0 |
| Component: | bin | Assignee: | Dag-Erling Smørgrav <des> |
| Status: | Closed Works As Intended | ||
| Severity: | Affects Only Me | CC: | christop, des |
| Priority: | --- | ||
| Version: | 10.1-RELEASE | ||
| Hardware: | amd64 | ||
| OS: | Any | ||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198383 | ||
|
Description
rsimmons0
2014-12-19 17:47:39 UTC
I am using the local_unbound behind a NAT either and it works for me, when I disable DNSSEC in the local unbound. At least Google does not support DNSSEC: drill -D -S google.com @8.8.8.8 ;; Number of trusted keys: 1 ;; Chasing: google.com. A DNSSEC Trust tree: <no data> No trusted keys found in tree: first error was: No DNSSEC public key(s) ;; Chase failed. To disable DNSSEC for the local unbound you should add val-permissive-mode: yes to your local unbound.conf. Does this fix your issue? Can you please test 10.2-PRERELEASE to confirm if this is still an issue? Unbound has (recently) been updated to version 1.3.5 in 10.x. Yes and no.
No, because the default installation fails.
I booted FreeBSD-10.2-PRERELEASE-amd64-20150704-r285132-bootonly.iso and made an network install. Unbound is of version 1.4.22.
I do not think this a problem with the unbound software, but with the unbound configuration or DNSSEC in general.
In the default configuration with dnssec unbound tries to get the DNSSEC public keys from the upstream nameserver, but the upstram nameserver does not deliver.
Without public keys unbound cannot do validate the domain and fails.
This behaviour is correct, because otherwise any attacker could disable DNSSEC.
Yes, when I edit my /etc/resolv.conf
root@freebsd:~ # cat /etc/resolv.conf
search home
nameserver 8.8.8.8
options edns
and run
root@freebsd:~ # /etc/rc.d/local_unbound setup
Performing initial setup.
Extracting forwarders from /etc/resolv.conf.
original /var/unbound/forward.conf saved as /var/unbound/forward.conf.20150725.174438
/var/unbound/lan-zones.conf not modified
/var/unbound/unbound.conf not modified
/etc/resolvconf.conf not modified
original /etc/resolv.conf saved as /etc/resolv.conf.20150725.174438
and then unbound config looks like
root@freebsd:~ # cat /etc/unbound/forward.conf
# Generated by local-unbound-setup
# Do not edit this file.
forward-zone:
name: .
forward-addr: 8.8.8.8
After an restart of unbound
root@freebsd:~ # /etc/rc.d/local_unbound restart
unbound resolves hosts:
root@freebsd:~ # host google.com
google.com has address 216.58.213.46
google.com has IPv6 address 2a00:1450:4008:800::1007
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
When you are using DHCP, it will overwrite /etc/resolv.conf and unbound will be back to use the DHCP provided DNS Server.
In short:
Correctly configured Unbound works for me. Default configuration does not work.
DNSSEC by design does not work with forward nameserver, which does not answer for public DNSSEC keys. This should be mentioned somewhere explicitly, because in my opinion the most SOHO devices do not run a DNSSEC aware DNS Server.
Add local_unbound_forwarders="8.8.8.8" to /etc/rc.conf and re-run 'service local_unbound setup' to prevent DHCP from switching back. |
