unbound trust-anchor

[Ernie Luzar]

Igor V. Ruzanov wrote:
> On Sun, 8 Oct 2017, Chris Gordon wrote:
> 
> |
> |> On Oct 8, 2017, at 8:08 PM, Ernie Luzar <luzar722 at gmail.com> wrote:
> |> 
> |> If I comprehend the unbound-anchor man page correctly, at unbound start time a trust-anchor is fetched from a unbound website. This is required for dnssec. Is this really necessary. I do not like any software application to be dialing home. Way to easy for that website to become compromised and bad things happen to my host.
> |
> |This function is to get the trust anchors for DNSsec validation.  If you don’t want to use DNSsec, then you don’t need them.  If you’re going to disable this then be sure you do NOT have DNSsec validation enabled in your configuration.

Is the unbound.conf auto-trust-anchor-file parameter the parameter 
needed to enable trust anchors and if it's missing disables trust 
anchors?  I do not have a auto-trust-anchor-file parameter in my 
unbound.conf file.


> |
> |For those that want to do DNSsec validation, this automatic anchor retrieval is very nice.  In fact ICANN just announced delaying rolling over the root zone KSKs since there were too many resolvers that had not updated their trust anchors and they didn’t want all of those DNS resolvers to suddenly stop working.
> 
> Totally agree with Chris. This is hot example of the resolver that "don’t 
> want to use DNSsec" for some non-objective reasons ;) In general 
> DNSSEC introduction is very similar to "slow start" of ISDN technology 
> meny years ago: "It Still Does Nothing"
> 
> |
> |The default site where the file is pulled is data.inana.org.  This is not a site associated with unbound but with IANA.  I understand and agree with your desire to minimize where your machine(s) pull data, but for me having working DNSsec validation out weights the risks of getting a “compromised” trust anchor.  Note that if you have a compromised/corrupt trust anchor, DNSsec validation will fail and DNS wouldn’t work for you.  Though DNS not working would be a very “bad” thing, it would be quick to diagnose and fix.

It's not a question of getting a “compromised” trust anchor. It's the 
packet conversation being intercepted and continuing after the anchor 
has completed downloading. This gives the hackers complete access to my 
box until I reset the firewall internal keep-state tables. The fetch 
anchor function is an ideal single intrusion point situation offering 
high gain for penetration effort extended.

I have been running Freebsd since release 3.0 with the same ipfilter 
firewall and have never had any intruders or any thing more that 
script-kiddies pounding ports 21 22, 23, 25, and 80. All the inbound 
ports from the public are closed. On the same day I enabled the package 
version of unbound I started to see failed login attempts to ftp and ssh 
which is only available to the LAN.

I have now through the process of trial & error narrowed the likely 
candidate to unbound with this fetch anchor function being the target of 
current investigation. If the symptoms stop after disabling the fetch 
anchor function, then I will have something to officially report. If the 
   symptoms continue then I will disable and uninstall the unbound port 
all together as the final test to see if the unbound port itself is 
compromised.



> |
> |> Can unbound function without this dial home feature?
> |> How would I go about disabling it.
> |
> |Take a look at /usr/local/etc/rc.d/unbound.  You could just modify this and then make sure you don’t have validation enabled in unbound.conf.
> |
> |Chris

Local_unbound and unbound should be pretty much configured the same way. 
But comparing /usr/local/etc/rc.d/unbound  to /etc/rc.d/local_unbound 
it's very easy to see their completely different.

/usr/local/etc/rc.d/unbound should check the unbound.conf file looking 
for the auto-trust-anchor-file parameter and if there then do the fetch 
anchor function otherwise skip it.