in the default configuration installed by the helper script local-unbound-setup, local-unbound(8) sends out DNS lookups for "private" networks (10.xxx/8, 192.168.xxx/16 etc.) out to the internet: the option is set to unblock-lan-zones=yes in the config file installed, whereas this setting defaults to "no" (RFC-compliant & safe).
Is this because the intended use of local-unbound(8) is to use it e.g. in a VPN setup?
Or is it assumed other settings should be adjusted accordingly, i.e. to set up internal and external interfaces?
I.e. it is assumed noone would ever start up local-unbound(8) with the shipped config unedited?
1st I wanted to file in a bug report, but then I thought "wait, there's a dns/unbound and a local-unbound(8), so this might be according to it's intended use?" Thus I want to ask the gurus 1st.
Thanks in advance!
EDIT added "the helper script" to "in the default configuration installed by the helper script local-unbound-setup,..."
unblock-lan-zones:<yesorno>
Default is disabled. If enabled, then for private address
space, the reverse lookups are no longer filtered. This allows
unbound when running as dns service on a host where it provides
service for that host, to put out all of the queries for the
'lan' upstream. When enabled, only localhost, 127.0.0.1 reverse
and ::1 reverse zones are configured with default local zones.
Disable the option when unbound is running as a (DHCP-) DNS net-
work resolver for a group of machines, where such lookups should
be filtered (RFC compliance), this also stops potential data
leakage about the local network to the upstream DNS servers.
Do I understand this correctly, the enabling-by-default of this option exposes the internal LAN addresses which are hooked to the particular computer and use it as DNS cache, so that the DNS server operators get all the interesting metadata about your internal network, its computers and their [users'] usage patterns?
If this is true, then I'd agree that this option should be left disabled, like the Unbound makers suggest.
I mean, a "secure OS" should leak user data only if explicitly told so. But that's only my personal opinion.
I read in the PR comments that the RFCs leave this decision up to the user, and thus I would really be interested in the reasons why this needs to be enabled by default in FreeBSDs' local unbound.
Apparently the common suggestion is people should use dns/unbound package instead if they want to do more than only caching on localhost.
Honestly, I not really understand why this.
Afraid of potential headaches by having the same program twice on the computer, I decided just to reconfigure the built-in unbound (eg local-unbound for usage on my local network.
When I configured it, I found myself glad that I checked every setting while reading the man page, and stripped all what I didn't like.
It wasn't exactly a pleasure to find such privacy-leaking settings enabled.
Do I understand this correctly, the enabling-by-default of this option exposes the internal LAN addresses which are hooked to the particular computer and use it as DNS cache, so that the DNS server operators get all the interesting metadata about your internal network, its computers and their [users'] usage patterns?
The point is: if you do want to only have a local-only caching nameserver, once you invoke that script to produce a default configuration, it will leak that metadata about your local network(s) out to the Weltnetz.
Afraid of potential headaches by having the same program twice on the computer, I decided just to reconfigure the built-in unbound (eg local-unbound for usage on my local network. When I configured it, I found myself glad that I checked every setting while reading the man page, and stripped all what I didn't like.
I can only guess. Someone took that wrong decision, and now has to admit that flaw. False pride? I already called "network expert wizzard" & wrote "Soothsaying? Sorcery? Do we ship magic cristal balls?" Maybe that's not wise from a political viewpoint.
Unbound is provided in the FreeBSD base system. By default, it will provide DNS resolution to the local machine only. While the base system package can be configured to provide resolution services beyond the local machine, it is recommended that such requirements be addressed by installing Unbound from the FreeBSD Ports Collection.
I never understood why it seems to be the recommended practice to have the same program twice, especially when - like the handbook admits - it would be sufficient just to configure the built-in unbound.
As I have almost no idea of system administration and easily get confused between /etc/unbound and /var/unbound(), I decided not to follow the handbook and just configure the local unbound.
Even if this might be frowned upon as bad practice. So I'd be happy if somebody could teach me why it is considered good practice to have 2x unbound on the computer?
# If unbound is running service for the local host then it is useful
# to perform lan-wide lookups to the upstream, and unblock the
# long list of local-zones above. If this unbound is a dns server
# for a network of computers, disabled is better and stops information
# leakage of local lan information.
# unblock-lan-zones: no
# The insecure-lan-zones option disables validation for
# these zones, as if they were all listed as domain-insecure.
# insecure-lan-zones: no
<domainname>
Sets domain name to be insecure, DNSSEC chain of trust is
ignored towards the domain name. So a trust anchor above the
domain name can not make the domain secure with a DS record,
such a DS record is then ignored. Can be given multiple times
to specify multiple domains that are treated as if unsigned. If
you set trust anchors for the domain they override this setting
(and the domain is secured).
This can be useful if you want to make sure a trust anchor for
external lookups does not affect an (unsigned) internal domain.
A DS record externally can create validation failures for that
internal domain.
Import unblock-lan-zones feature backported from upstream svn trunk.
This is a partial fix for reverse lookups in RFC 1918 networks. With
this option enabled, unbound no longer ignores these queries
Again, I honestly don't understand this, as I have almost no idea of networking.
Does this enable reverse lookups into the users' local LAN?
Or is it harmless?
With info found by Snurg in previous post I can see some logic in this, but...
Assuming that local_unbound either always respect /etc/resolv.conf (where I assume nameserver(s) in local network, in example local router) or has set forwarders only in local network and doesn't try to resolve hostnames recursively down from the root DNS zone (which I didn't bother to evaluate for now), it may:
- be useful to be able to resolve hostnames on local network either statically or dynamical (for example from DHCP) set
- be not inherently insecure, if upstream local nameserver is sanely configured and doesn't try to resolve RFC 1918 networks hostnames which are unknown to it (meaning don't forward such queries which doesn't have DNS record locally to the internet/upstream, just return NX domain), which is probably too much to ask from cheap wireless routers which would be most used devices in such situation.
I didn't try to study local-unbound-setup script (yet), but it should not be hard to add question/option to it to enable unblock-lan-zones, unblock-lan-zones only if upstream DNS server is in local network, unblock-lan-zones only if upstream DNS is in RFC 1918 networks (for large networks, VPNs etc.) and defaulting to no. As this doesn't change configurations already generated, there is no POLA violation except probably for possible usage in deployment scripts, which can be handled in release notes accompanied with information why this was done and that users are encouraged to revisit/reconsider configurations already deployed.
When local-unbound(8) is activated to provide a DNS cache on my standalone laptop, it is itself the subject in resolv.conf(5): nameserver 127.0.0.1 (or 127.0.0.x, x ≠ 1, when jail(8)ed or chroot(8)ed).
I never understood why it seems to be the recommended practice to have the same program twice, especially when - like the handbook admits - it would be sufficient just to configure the built-in unbound.
Neither twice nor incomplete should be installed. The whole nsd should be in base. A whole DNS server
as was the case when bind was there. This remembers me the discussion about sendmail, one wanted to
mutilate MTA support to his needs, that was his argument against sendmail in base. And these problems
with configuration scripts are typical from Linux distributions.
I didn't try to study local-unbound-setup script (yet), but it should not be hard to add question/option to it to enable unblock-lan-zones, unblock-lan-zones only if upstream DNS server is in local network, unblock-lan-zones only if upstream DNS is in RFC 1918 networks (for large networks, VPNs etc.) and defaulting to no.
If we are going to discuss what should be in base and what not, my 2 cents is - base is base for something. For me, something is servers and routers, for someone other it may be workstation, for yet other entity it may be game console or routers family sold for business. Most of those usages doesn't require authoritative only DNS server or full fledged MTA. So I am happy that we don't have NSD in base and would be even happier if sendmail disappears. It would be always easier for me pkg install <light_MTA_of_my_choose> then disabling sendmail and doing exactly the same. Do you see? One step less and lot of code/executables missing, good for me. I understand, that it may not be good for you, but it is what it is.
My proposal is actionable, doesn't break anything existing, may make some future installations less information leaky and properly documented may also help to educate some users. Yours not so much at least in couple years following. I may also add some files to /etc and /lib/exec to make it even more linux-y if it would make you happier, but you can not ask me for configuration via writing somewhere in /dev or /sys. Even me is not so much user friendly
Most of those usages doesn't require authoritative only DNS server or full fledged MTA. So I am happy that we don't have NSD in base and would be even happier if sendmail disappears.
Then you are one of those that demolish what consider not necessary. BSD had from the beginning a full DNS
server and a full MTA, that did not bother anyone other than some desktop users that also get upset seeing
the messages when booting the system. The same logic: not anyone understand and needs to see
the messages, hence they must be hidden like in many Linux distributions.
And the argument of disabling is also meaningless: sendmail, DNS work only after configuring and starting
them. It is not like Ubuntu and Co that run immediately after installing them.
These troubles like with DNS are the consequence of the desktop-user-mentality. Do we need more such
users, also as developers? I better tell them: go and use Linux, Windows, MacOS.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
