# local_unbound: why does the default config file violates RFC?



## Mjölnir (Jun 15, 2020)

Dear network wizzards,

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,..."_


----------



## Mjölnir (Mar 18, 2021)

I'd like to kindly draw your attention to this PR 248102.  So if you feel you're one of the qualified network wizzards here, please either
support my matter & tell the one who's responsible for that part of the FreeBSD source tree that s/he should give up resistance & follow my request,
or convince me I'm wrong.
Thx in advance.


----------



## hruodr (Mar 18, 2021)

It seems that concerns reverse lookup. You can try `drill -x localipaddress`.


----------



## Snurg (Mar 18, 2021)

Unbound.conf man page says


> *unblock-lan-zones:* _<yes_ _or_ _no>_
> 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
> ...


*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.


----------



## Mjölnir (Mar 18, 2021)

Snurg said:


> Unbound.conf man page says
> 
> *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?*


FMLU: yes.


Snurg said:


> I read in the PR comments that the RFCs leave this decision up to the user,


but not the one who ships the default config.


Snurg said:


> Apparently the common suggestion is people should use dns/unbound package instead if they want to do more than only caching on localhost.


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_.


Snurg said:


> Honestly, I not really understand why this.


Me neither.  IMHO it's simply a bug.


Snurg said:


> 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.


Not all sysadmins are doing that.  Many are in a hurry & just want to get things up & running quickly, because they have some more things to do.


Snurg said:


> It wasn't exactly a pleasure to find such privacy-leaking settings enabled.


Please take appropriate action & help to make our beloved _yea free BeaSD_ better.


----------



## Snurg (Mar 18, 2021)

Well, I am curious too, why instead of just fixing the issue, there is so much hum and haw.

So I also chimed in and asked for the reasons why it is apparently deemed necessary to keep that privacy-leaking setting.


----------



## hruodr (Mar 18, 2021)

BTW, where is `local-unbound-setup` documented?

I have the same files in `/etc/unbound` and `/var/unbound`.

I remember that I had a headache configuring it in freebsd, because these nice program to help people
configuring it.


----------



## Mjölnir (Mar 18, 2021)

hruodr said:


> BTW, where is `local-unbound-setup` documented?


Good question.  It's a commodity script, so I'm not angry that it has no manpage.  The point is


hruodr said:


> I remember that I had a headache configuring it in freebsd, because these nice program to help people
> configuring it.


Exactly.  Please take appropriate action like Snurg did: chime in @PR 248102.
One is ? too less.  More please.


----------



## Mjölnir (Mar 18, 2021)

Snurg said:


> Well, I am curious too, why instead of just fixing the issue, there is so much hum and haw.


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.


Snurg said:


> _So I also chimed in and asked for the reasons why it is apparently deemed necessary to keep that privacy-leaking setting._


__


----------



## Snurg (Mar 19, 2021)

hruodr said:


> I have the same files in `/etc/unbound` and `/var/unbound`.



This is the result of following the handbook.



			
				FreeBSD handbook said:
			
		

> 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?*



hruodr said:


> BTW, where is `local-unbound-setup` documented?


Me too... when I had to search, finding where that `local-unbound-setup` script was, reminded me of <self-censored> 



Mjölnir said:


> I can only guess.  Someone took that wrong decision, and now has to admit that flaw.  False pride?



Maybe the decision to leak the users' metadata is not even a FreeBSD mistake, but an upstream mistake?

I honestly do not understand what I read here:


> Upstream is set "as expected":
> 
> https://github.com/NLnetLabs/unboun...f37d0c02ab16e0b554fb/doc/example.conf.in#L701
> 
> This was a *deliberate change for FreeBSD, as it is *assumed* that you would only use it locally* (base r268840).



What does this mean? "*deliberate change for FreeBSD*"
See the diff on the phabricator:  https://reviews.freebsd.org/rS268840

The interesting part seems to be this:



Spoiler: lan zones configuration



#
# Generate lan-zones.conf
#
gen_lanzones_conf() {
    echo "# Generated by $self"
    echo "# Do not edit this file."
    echo "server:"
    echo "        # *Unblock reverse lookups for LAN addresses*"
    echo "        unblock-lan-zones: yes"
    echo "        domain-insecure: 10.in-addr.arpa."
    echo "        domain-insecure: 127.in-addr.arpa."
    echo "        domain-insecure: 16.172.in-addr.arpa."
    echo "        domain-insecure: 17.172.in-addr.arpa."
    echo "        domain-insecure: 18.172.in-addr.arpa."
    echo "        domain-insecure: 19.172.in-addr.arpa."
    echo "        domain-insecure: 20.172.in-addr.arpa."
    echo "        domain-insecure: 21.172.in-addr.arpa."
    echo "        domain-insecure: 22.172.in-addr.arpa."
    echo "        domain-insecure: 23.172.in-addr.arpa."
    echo "        domain-insecure: 24.172.in-addr.arpa."
    echo "        domain-insecure: 25.172.in-addr.arpa."
    echo "        domain-insecure: 26.172.in-addr.arpa."
    echo "        domain-insecure: 27.172.in-addr.arpa."
    echo "        domain-insecure: 28.172.in-addr.arpa."
    echo "        domain-insecure: 29.172.in-addr.arpa."
    echo "        domain-insecure: 30.172.in-addr.arpa."
    echo "        domain-insecure: 31.172.in-addr.arpa."
    echo "        domain-insecure: 168.192.in-addr.arpa."
    echo "        domain-insecure: 254.169.in-addr.arpa."
    echo "        domain-insecure: d.f.ip6.arpa."
    echo "        domain-insecure: 8.e.ip6.arpa."
    echo "        domain-insecure: 9.e.ip6.arpa."
    echo "        domain-insecure: a.e.ip6.arpa."
    echo "        domain-insecure: b.e.ip6.arpa."
}



NLnetlabs says this to the options used here:



> # 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
> ...



The unbound man page says:



Spoiler: domain-insecure



_<domain_ _name>_
              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.



The initiator for this change apparently was this:


> *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?


----------



## ondra_knezour (Mar 19, 2021)

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.


----------



## Mjölnir (Mar 19, 2021)

ondra_knezour said:


> Assuming that local_unbound either always respect /etc/resolv.conf


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).


----------



## hruodr (Mar 19, 2021)

Snurg said:


> 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.


----------



## hruodr (Mar 19, 2021)

ondra_knezour said:


> 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.


Linuxism. Better is to have the whole nsd installed, a template configuration file, some instructions in
handbook.


----------



## ondra_knezour (Mar 19, 2021)

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


----------



## hruodr (Mar 19, 2021)

ondra_knezour said:


> 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.


----------

