cloudfoundry-community/bind9-boshrelease

A BOSH release for running DNS via BINDv9

bind9-boshrelease's Issues

New release with PR#10

Hi, thanks for merging my PR (#10). Could we please have a new release of this package so we can use it in our manifests without relying on our own dev releases? Many thanks!

bug: allow using bind9-boshrelease without defining zones

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?

Upgrade to latest BIND9 (9.15.2)

https://ftp.isc.org/isc/bind/9.15.2/

Cannot deploy bind9 when using proxy

Using latest 1.1.3 version with Xenial support fails when proxy is set up. This is caused by this line that tries to install ply:

bind9-boshrelease/packages/bind9/packaging

Line 9 in cf84cae

pip install ply

Here is an error we got:

Task 41156 | 10:52:55 | Compiling packages: bind9/a2f77814b8953b0e8785ae8d5724e74255f30344 (00:01:10)
                     L Error: Action Failed get_task: Task 76899f7f-0b7f-43f6-6eae-422a53d12125 result: Compiling package bind9: Running packaging script: Running packaging script: Command exited with 1; Stdout:   Cannot fetch index base URL https://pypi.python.org/simple/
  Could not find any downloads that satisfy the requirement ply
Cleaning up...
No distributions at all found for ply
Storing debug log for failure in /root/.pip/pip.log
, Stderr: + export PYTHONPATH=
+ PYTHONPATH=
+ source /var/vcap/packages/python-2.7/bosh/compile.env
++ export PATH=/var/vcap/packages/python-2.7/bin:/var/vcap/bosh/bin:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
++ PATH=/var/vcap/packages/python-2.7/bin:/var/vcap/bosh/bin:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
++ export PYTHONPATH=/var/vcap/packages/python-2.7/lib/python2.7/site-packages:
++ PYTHONPATH=/var/vcap/packages/python-2.7/lib/python2.7/site-packages:
++ grep -c '^processor' /proc/cpuinfo
+ cpus=2
+ version=9.14.0
+ pip install ply

Task 41156 | 10:54:19 | Error: Action Failed get_task: Task 76899f7f-0b7f-43f6-6eae-422a53d12125 result: Compiling package bind9: Running packaging script: Running packaging script: Command exited with 1; Stdout:   Cannot fetch index base URL https://pypi.python.org/simple/
  Could not find any downloads that satisfy the requirement ply
Cleaning up...
No distributions at all found for ply
Storing debug log for failure in /root/.pip/pip.log
, Stderr: + export PYTHONPATH=
+ PYTHONPATH=
+ source /var/vcap/packages/python-2.7/bosh/compile.env
++ export PATH=/var/vcap/packages/python-2.7/bin:/var/vcap/bosh/bin:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
++ PATH=/var/vcap/packages/python-2.7/bin:/var/vcap/bosh/bin:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
++ export PYTHONPATH=/var/vcap/packages/python-2.7/lib/python2.7/site-packages:
++ PYTHONPATH=/var/vcap/packages/python-2.7/lib/python2.7/site-packages:
++ grep -c '^processor' /proc/cpuinfo
+ cpus=2
+ version=9.14.0
+ pip install ply


Task 41156 Started  Tue Jul 23 10:48:15 UTC 2019
Task 41156 Finished Tue Jul 23 10:54:19 UTC 2019
Task 41156 Duration 00:06:04
Task 41156 error

Updating deployment:
  Expected task '41156' to succeed but state is 'error'

Exit code 1

Configurable logging

https://kb.isc.org/docs/aa-01526

Any thoughts on adding a configurable logging block so operators can get log lines such as queries made against the server?

Can submit a PR when time permits, figured I'd ask the general question first, though 👍

feel free to close whenever

Update bind9 to 9.13.3 on 9.14.0 to comply with EDNS

As specified on https://dnsflagday.net, is-it possible to update bind9 package to version 9.13.3(dev) on 9.14.0(Production) in order to support EDNS.

"templates/make_manifest" doesn't exist

In the README, it feels like there's a claim that manifest for bosh-lite or AWS are generated:

For bosh-lite, you can quickly create a deployment manifest & deploy a cluster:

templates/make_manifest warden
bosh -n deploy
For AWS EC2, create a single VM:

templates/make_manifest aws-ec2
bosh -n deploy

this folder doesn't exist, and make_manifest isn't a file.

Can this be removed from the README? and just have the assumption that the only provided manifest is manifests/bind9.yml?

Thanks!

Clean up templates and scripts

They've got a lot of bosh-gen cruft in them.

Rolling upgrades and high availability

In order to maintain HA during stemcell repaves, config updates, etc., should the max_in_flight be set to a lower number? Or is relying on the passed canary & then upgrading every other server at the same time acceptable?

I currently have it configured for max_in_flight of 1 because I'm a wuss. But any advice or practical production experience with this deployment is welcome.

background context

We've been tasked with doing split-horizon DNS to forward certain zones to onprem DNS servers, and public DNS for everything else. Currently, in our BIND9 deployment, we have 1 leader and 3 followers. The BOSH director's cloud config is setup such that every BOSH-managed VM uses the 3 follower VM's IPs for DNS. (It's a backlog item to setup an internal LB which points to these BIND9 VMs, and then configure the cloud-config DNS to use the LB's address)

This works exactly as expected, but the fear is that if the DNS servers are out, everything is out. So I figure it's worth asking if others have had a similar experience / use these BIND servers in a similar fashion, and if they do a less aggressive rolling upgrade on these BIND9 servers.

Thanks a lot 👍

New release to include forward zone

Could we have a new release to include the latest commits with forward zone feature?

Cannot deploy bind9 in dynamic network

In cloud config I have defined network:

- name: net
  type: dynamic
  subnets:
  - az: z1
    cloud_properties:
      subnet: ((net_id_1))
  - azs: [z2]
    cloud_properties:
      subnet: ((net_id_2))

And now when I try to deploy bind9 using this network it fails because in the also-notify we got domain address instead of IP:
also-notify { 04a81a10-49b1-4538-9e5b-e93b9a77e29a.slave.net.dns.bosh; };

This is done by https://github.com/cloudfoundry-community/bind9-boshrelease/blob/master/jobs/master/templates/config/master.conf#L32 link which returns DNS domain and acording to bosh spec we cannot change it, even with ip_addresses set to true:

ip_addresses [Boolean]: Instructs the director to use ip addresses instead of DNS names. This property is ignored in the case of dynamic networks, which always use DNS addresses. Defaults to false. See dns for more details.

---

bosh-dns config is the default one https://github.com/cloudfoundry/bosh-deployment/blob/fa4b0a5602b67b370c14de9b5ac387e4cdfead76/runtime-configs/dns.yml

bind version should be update

we are currently using bind9-9.10.2-P3 from 2015
bind9-9.13.2 is available.

im mentioning this.
because we noticed intermittent dns resolving issues after bind is running for a few weeks

notetoself:
we can get the latest version from https://ftp.isc.org/isc/bind/