bug: allow using bind9-boshrelease without defining zones

[lrstanley]

Currently, when one doesn't define a zone in the deployment manifest, bind9 fails with something along the lines of:

usage: named-checkzone [...] /some/path/*.db

Because there are no files for it to check is why it fails. Adding a zone, and it works without issue.

The issue seems to be with:

https://github.com/cloudfoundry-community/bind9-boshrelease/blob/master/jobs/named/templates/bin/named#L42-L49

I believe bash will still invoke the for loop, with an empty variable, because no files are found.

---

Problem is, bind9 is useful to use as a form of DNS caching. Other alternatives don't seem to work consistently:

• bosh-dns requires cert generation, which requires credhub. On some of our bosh deployments which are bare (not managed by opsman), they don't have credhub setup, so the cert management is a huge pain (it's also undocumented). It's also overkill if we don't need local service discovery, and just want a cache for external resolvers.
• consul seems to have issues caching with some kinds of hosts, in addition to it being overkill for just caching external resolvers.

Here is our config right now:

  jobs:
  [...]
  - name: named
    release: bind9
    properties:
      zones:
        10.in-addr.arpa: |+
          $TTL 1h
          $ORIGIN 10.in-addr.arpa.
          @ IN SOA <some-random-zone because it needs one to start>
      bind_options:
        forward: "only"
        dnssec-validation: "yes"
      recursion:
        allow_from: ["1.2.3.4/27", "localhost", "localnets"]
        forwarders: [1.1.1.1, 2.2.2.2, 3.3.3.3, 4.4.4.4]

I would like to cut out the entire zones property if possible, thoughts?

[jhunt]

That's an excellent use case, that I'd not previously thought of!

The issue probably stems from the fact that if you give bash a glob that doesn't match anything, it will give back the glob as the result: i.e. "echo *.enoent" will echo a literal *.enoent. In the context of a bash for loop, this is a valid token, so it loops once and the named-checkzone gets exec'd with a bad (non-existent) zone file.

I think this is as simple as a set -o nullglob, to skip the loop body altogether. I'm testing that locally in my lab right now.

[jhunt]

Yes, as I suspected:

[Thu Aug 13 15:25:02 UTC 2020] checking named configuration...
[Thu Aug 13 15:25:02 UTC 2020] named configuration OK

[Thu Aug 13 15:25:02 UTC 2020] checking zone '*' (in /var/vcap/sys/run/named/data/*.db)...
usage: named-checkzone [-djqvD] [-c class] [-f inputformat] [-F outputformat] [-J filename] [-t directory] [-w directory] [-k (ignore|warn|fail)] [-n (ignore|warn|fail)] [-m (ignore|warn|fail)] [-r (ignore|warn|fail)] [-i (full|full-sibling|local|local-sibling|none)] [-M (ignore|warn|fail)] [-S (ignore|warn|fail)] [-W (ignore|warn)] [-o filename] zonename filename

It's treating a literal * as the filename to check.

[jhunt]

Check out v1.3.0 which has this fix in it.

https://github.com/cloudfoundry-community/bind9-boshrelease/releases/tag/v1.3.0

[lrstanley]

Tested, and working. Thanks!