unbound-checkconf: fatal error: config file is not inside chroot

Unbound
1

Hi,

configuration managment systems seem to place files they manage into
some temp directory, run a validation command and then move the config
file into the final destination. (I tried salt stack's "check_cmd" and
ansible's "validate" option.)

This does not play well with unbound-checkconf since it complains if
the config file is not placed inside the chroot. I note that
nsd-checkconf does not have this restriction.

Maybe this can be removed from unbound-checkconf as well?

Something like this:

diff --git smallapp/unbound-checkconf.c smallapp/unbound-checkconf.c
index ea46479172c..255ffa4cda8 100644
--- smallapp/unbound-checkconf.c
+++ smallapp/unbound-checkconf.c
@@ -463,19 +463,6 @@ morechecks(struct config_file* cfg, const char* fname)
     !is_dir(cfg->chrootdir)) {
     fatal_exit("bad chroot directory");
   }
- if(cfg->chrootdir && cfg->chrootdir[0]) {
- char buf[10240];
- buf[0] = 0;
- if(fname[0] != '/') {
- if(getcwd(buf, sizeof(buf)) == NULL)
- fatal_exit("getcwd: %s", strerror(errno));
- (void)strlcat(buf, "/", sizeof(buf));
- }
- (void)strlcat(buf, fname, sizeof(buf));
- if(strncmp(buf, cfg->chrootdir, strlen(cfg->chrootdir)) != 0)
- fatal_exit("config file %s is not inside chroot %s",
- buf, cfg->chrootdir);
- }
   if(cfg->directory && cfg->directory[0]) {
     char* ad = fname_after_chroot(cfg->directory, cfg, 0);
     if(!ad) fatal_exit("out of memory");

2

Apparently there seems to be a misunderstanding at my end, e. g. where
is the point of validation if the majority of domains are not signed?

My DANE/DNSSEC adoption survey is tracking ~9 million DNSSEC-signed
delegations which are immediate descendents of Public Suffix List
parent domains. Based on published numbers from some of the larger
registries for which I am as yet unable to get complete zone data,
my estimated world-wide total is around 10 million.

While many of the largest domains are not presently signed, some
are. Deployment is somewhat concentrated in Northern Europe, but
there is also significant deployment in Brazil, the Check republic
and Poland. There is a non-trivial number of signed domains in the
USA, but the global reach of the .com/.net/.org TLDs does not make
this readily apparent.

In my current (and now updated!) understanding, in all these cases I can
never be sure to actually talk to the web site I wanted to?

Well, (HTTPS) web sites are authenticated via their X.509 certificates,
not their IP address.

My conclusion so far: DNSSEC remains an illusion. Would that be correct?

No, DNSSEC is not an illusion, but deployment is around 3% of domains
globally. However, signed domains are O(50%) for the .NL, .CZ, .PL,
.SE, .NO, .BR, .EU, ... TLDs. The ".bank" and ".insurance" TLDs are
100% signed, but are not actively used by most registrants, who have
mostly just reserved the names.

Validation protects caches from poisoning with forged
data (as might easily happen via a BGP hijack) and protects the
integrity of DANE TLSA records, which are already used to protect
SMTP transport for ~330 thousand domains whose MX hosts have DANE
TLSA records.

DANE for SMTP is used by, e.g., web.de, gmx.de, freenet.de and
comcast.net, covering tens of millions of users. DANE support is
available in the Postfix, Exim, Halon, PowerMTA, ... mail servers.

DANE is not presently supported by browsers, I'm working on removing
obstacles.

3

Hi Florian,

Hi,

configuration managment systems seem to place files they manage into
some temp directory, run a validation command and then move the config
file into the final destination. (I tried salt stack's "check_cmd" and
ansible's "validate" option.)

This does not play well with unbound-checkconf since it complains if
the config file is not placed inside the chroot. I note that
nsd-checkconf does not have this restriction.

Sure, removed that check. Thanks for the mention.

Best regards, Wouter