luzar722 at gmail.com
Mon Oct 9 14:48:42 UTC 2017
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
> |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
> |> 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.
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.
More information about the freebsd-questions