When looking at #43, I found that there was an existing failing unit test. I did not correct it to keep commits contained to the related problem. I would suggest either setting the unit test to look for 'service named reload', or removing it entirely since I do not see where the class sets this information anyway.

Failures:

1. bind::server
   Failure/Error: })}
   expected that the catalogue would contain Service[named] with restart set to "/sbin/service named reload" but it is set to "service named reload" in the catalogue

   ./spec/classes/bind_server_spec.rb:14:in `block (2 levels) in <top (required)>'

chroot selector items need to be delimited otherwise catalog compile fails

puppet apply --noop ./bind/tests/server.pp

No matching value for selector param 'true' at /etc/puppet/modules/bind/manifests/init.pp:28 on node host.example.com

and

puppet apply --noop ./bind/tests/server.pp

No matching value for selector param 'true' at /etc/puppet/modules/bind/manifests/init.pp:42 on node host.example.com

Possible solution -
http://docs.puppetlabs.com/puppet/latest/reference/lang_conditional.html

diff /etc/puppet/modules/bind/manifests/init.pp /etc/puppet/modules/bind/manifests/init.pp-old

26,27c26,27
< 'true' => '-chroot',

< 'false' => '',

true  => '-chroot',
false => '',

40,41c40,41
< 'true' => '/var/named/chroot/var/log/named',

< 'false' => '/var/log/named',

true  => '/var/named/chroot/var/log/named',
false => '/var/log/named',

Puppet v2.7.23

Thanks,
/Chris C

Hello

I want to create a "define" to add new domains to a server with just one line, like this:

domain { 'example.com': domain_ip => '10.0.0.1', spf => true, dkim => true, mx => "mx" }
domain { 'example2.com': domain_ip => '10.0.0.1', spf => true, dkim => true, mx => "mx" }

This is my define:

# Class domain
# Trying to automatize domain management

define domain ($domain_ip, $spf, $dkim, $mx) {

   include bind
   bind::server::conf { '/etc/named.conf':
     listen_on_addr    => [ 'any' ],
     listen_on_v6_addr => [ 'any' ],
     forwarders        => [ '8.8.8.8', '8.8.4.4' ],
     allow_query       => [ 'localnets' ],
     zones             => {
        "${name}" => [
           'type master',
           'file "${name}.zone"',
        ],
     },
   } 

   bind::server::file { "${name}.zone":
      zone_type => "master",
      content  => template('bind/zone.erb'),
   }

}

The thing is that when I run it, I get this error:

Error: Duplicate declaration: Bind::Server::Conf[/etc/named.conf] is already declared in file /etc/puppet/modules/domain/manifests/init.pp:18; cannot redeclare at /etc/puppet/modules/domain/manifests/init.pp:18 on node example

I totally get it, I can't redefine the server::conf because I already did. Can anybody think of a workaround?

Thanks in advance.

Right now, logging appears not to be configurable, with the ERB file being hard-coded with the following stanzas:

logging {
    channel main_log {
        file "/var/log/named/named.log" versions 3 size 5m;
        severity info;
        print-time yes;
        print-severity yes;
        print-category yes;
    };
    category default{
        main_log;
    };
    category lame-servers {
        null;
    };
};

It would be helpful if the contents of main_log could be altered, for example, to permit logs to be sent to syslog instead of a specific log file.

On Debian (and derivatives - e.g. Ubuntu), /etc/bind is the preferred location for config and /var/lib/bind the preferred location for data.

Setting the directory attribute to /var/lib/bind should update the statistics file location, etc.

Also, there's currently a hard coded reference to /etc/named.rfc1912.zones in templates/named.conf.erb#L165 - this doesn't fit with Debian's policy. Please could we make it so that this module has a configurable /etc path for the bind config files.

I will attempt to put a patch together for this.

when a new zone is added, file.pp notifies Class['::bind::service'], which runs service $servicename reload. At least on CentOS, service named reload runs rndc reload when rndc reconfig is required to load new zonefiles.

Hi,
for a server that will use nsupdate for zone file maintenance, it would be a nice idea to have puppet provide the initial content of the file but not overwrite it if it already exists. The replace attribute of the file resource is there to cater for this.
Please consider adding support for this attribute to the bind::server::file class.
I can submit an untested version of the probably trivial patch if you want me to.
Greetings
Marc

As of v9.16.0, the options dnssec-enable and dnssec-lookaside are deprecated (see https://serverfault.com/questions/1105487/if-dnssec-enable-is-obsolete-and-must-be-removed-what-is-the-alternative-when). As of v9.18.0, the options have been removed from BIND. However, this puppet module sets those variables in any case, hence bind refuses to load its configuration file on Ubuntu >= 22.04 and Debian >= 11 systems, and it would emit deprecation warnings on Ubuntu 20.04 and Debian 10.

I had to use a local hack to fix the module:

diff --git a/templates/named.conf.erb b/templates/named.conf.erb
index 621e689..df828df 100644
--- a/templates/named.conf.erb
+++ b/templates/named.conf.erb
@@ -93,9 +93,9 @@ options {
 <% end -%>
 
 <% end -%>
-    dnssec-enable <%= @dnssec_enable %>;
+#    dnssec-enable <%= @dnssec_enable %>;
     dnssec-validation <%= @dnssec_validation %>;
-    dnssec-lookaside <%= @dnssec_lookaside %>;
+#    dnssec-lookaside <%= @dnssec_lookaside %>;

In your example of how to use views you give 'trusted' followed by 'default', however in practice the view names get sorted alphabetically, so 'default' will be output before 'trusted'. Since 'default' has catch all "match-clients" of "any", the 'trusted' won't trigger as first catch all 'default' match will always win out.

Changing the view name to something like 'a_trusted' will make it sort prior and fix the issue.

Note you also put in the same example code a 'zones' section, which I don't believe is allowed - if you use 'views', all zones have to be inside views.

at the moment all configuration takes place in the root named.conf; I think it'd be a good idea to be able to move different responsibilies into different files. In the default install you have

named.conf - pretty bare, loads all the other files
named.conf.local - zone configuration goes here
named.conf.options - configuration options here
named.conf.default-zones - rfc1918 zones go here

a good breakdown here - http://wiki.debian.org/Bind9#Configuration

I haven't researched if this is true on RHEL

I'm using this module to manage some zones in my bind9 installation. Additionally I setup bind to allow dynamic updates (for letsencrypt). However, this adds a new complexity level when changing a zone file. To prevent the zonefile to get out of sync with the journal file of dynamic updates, I would like to freeze a/all zone files before updating one (or more) zone files (with rndc freeze) and unfreeze them after the zone files have changed (with rndc thaw).

For now I implemented this like that:

    exec { 'rndc freeze':
      command     => '/usr/sbin/rndc freeze',
      user        => root,
      group       => root,
    }

    exec { 'rndc thaw':
      command     => '/usr/sbin/rndc thaw',
      user        => root,
      group       => root,
      require     => File['/path/to/zones/zone1', '/path/to/zones/zone2'],
    }

    bind::server::file { [ 'zone1', 'zone2' ]:
      zonedir      => '/path/to/zones',
      source_base  => 'puppet:///modules/zones/',
    }

As you might see already, this has one main disadvantage: The freeze and thaw commands are executed at each puppet run, instead of only when the zone files get updated. This might not be a problem for the dynamic updates or the DNS server at all (exept from performance or maybe whatever), however it is unnecessary to execute these commands every half an hour (for the default time puppet runs).

So, this is a request to add a way in this module to freeze and unfreeze zones when they're updated.

zone "." in{
  type hint;
  file "/etc/root.servers";
};

This will allow configuration to work in chroot environment

Under Ubuntu 16.04 bind9 package uses /etc/bind for its configuration.

named.conf and all of the zone db files are located there.

So I have wasted hours trying to use my existing puppet code using this module that works fine under RHEL 6 & 7, only to discover puppet was writing out to /etc/named.conf but the ubuntu binaries appear to check for /etc/bind/named.conf.

The module defaults to /var/named, which is fine but is RHEL specific.

bind::server::conf doesn't use params in anyway.

The default values for $dump_file, $statistics_file, $memstatistics_file should all be relative to $directory, because even if you overwrite $directory it still tries to write those files out to the preferred /var/named directory.

As the package name and service name change between OS flavours, the names should be moved into variables

Following the style guide

Makes it easier to notify/subscribe to a series of resources without needing to update the code.

Ps. Apologies for the issue torrent, these are all the things I was planning on contributing to.

In addition to 'forwarders' there is a 'forward' option, which can take values first (default) or only (usefull if you want a forward-only dns server)

Hey @thias. Thanks for putting this together. It's really great but I'm having a bit of trouble configuring everything for Ubuntu. I've forked it, and if you have a second would you mind pointing me in the right direction of how I can move the files from /var/named to /var/bind and have the configs be written to named.conf.options and named.conf.local? I'll keep messing with it but if you happen to have a second, I'd really appreciate it!

I recently converted from Puppet OS 4.9.x to 4.10.8 and Hiera 5. I've run into the following error.

Error while evaluating a Function Call, Failed to parse template bind/named.conf.erb:
Filepath: /etc/puppetlabs/code/environments/production/modules/bind/templates/named.conf.erb
Line: 44
Detail: undefined method `join' for "x.x.x.x":String

I do a lookup in hiera for the forwards value and pass that onto bind::server::conf. This was working before my latest upgrade of Puppet.

Locally I have been able to remove the .join off of line 44 in the template noted above and it is now working for me but I have not tested an array of addresses yet as my environment doesn't use more than one forwarder at this time.

Would you check support for the newest version of Puppet and Hiera lookups that is < 5.0.0?

Thanks!

Running puppet-3.2.4 (just upgraded from 2.7) - I get these complaints :(

Everything seems to work fine though.

I've upgrade to v0.4.0 - it didn't help.

(Scope(Class[Bind::Server])) Could not look up qualified variable 'hiera::host-dns02.example.dk::bind::server::packagenameprefix'; class hiera::host-dns02.example.dk::bind::server could not be found
(Scope(Class[Bind::Server])) Could not look up qualified variable 'hiera::network-unknown::bind::server::packagenameprefix'; class hiera::network-unknown::bind::server could not be found
(Scope(Class[Bind::Server])) Could not look up qualified variable 'hiera::RedHat::bind::server::packagenameprefix'; class hiera::RedHat::bind::server could not be found
(Scope(Class[Bind::Server])) Could not look up qualified variable 'hiera::common::bind::server::packagenameprefix'; class hiera::common::bind::server could not be found
(Scope(Class[Bind::Server])) Could not look up qualified variable 'fake::hiera::bind::server::packagenameprefix'; class fake::hiera::bind::server could not be found
(Scope(Class[Bind::Server])) Could not look up qualified variable 'hiera::host-dns02.yousee.idk::bind::server::chroot'; class hiera::host-dns02.yousee.idk::bind::server could not be found
(Scope(Class[Bind::Server])) Could not look up qualified variable 'hiera::network-unknown::bind::server::chroot'; class hiera::network-unknown::bind::server could not be found
(Scope(Class[Bind::Server])) Could not look up qualified variable 'hiera::RedHat::bind::server::chroot'; class hiera::RedHat::bind::server could not be found
(Scope(Class[Bind::Server])) Could not look up qualified variable 'hiera::common::bind::server::chroot'; class hiera::common::bind::server could not be found
(Scope(Class[Bind::Server])) Could not look up qualified variable 'fake::hiera::bind::server::chroot'; class fake::hiera::bind::server could not be found
(Scope(Class[Bind::Service])) Could not look up qualified variable 'hiera::host-dns02.yousee.idk::bind::service::servicename'; class hiera::host-dns02.yousee.idk::bind::service could not be found
(Scope(Class[Bind::Service])) Could not look up qualified variable 'hiera::network-unknown::bind::service::servicename'; class hiera::network-unknown::bind::service could not be found
(Scope(Class[Bind::Service])) Could not look up qualified variable 'hiera::RedHat::bind::service::servicename'; class hiera::RedHat::bind::service could not be found
(Scope(Class[Bind::Service])) Could not look up qualified variable 'hiera::common::bind::service::servicename'; class hiera::common::bind::service could not be found
(Scope(Class[Bind::Service])) Could not look up qualified variable 'fake::hiera::bind::service::servicename'; class fake::hiera::bind::service could not be found

If I can do anything to help debug, I'll gladly do so.

Puppet 8 is released for quite a while now and in default configuration the legacy facts are not available anymore (in both opensource puppet and in PE).

A trivial fix is available in #115. Any chance to get that fix upstream?

In params you assume $file_bindkeys = '/etc/named.iscdlv.key' but on Debian bullseye this value should be /etc/bind/bind.keys

ATM this is not overridable in your module AFAICS.

ATM this is making it non-trival to use your module to configure bind.

Does this module support Hiera?

Seems like all the modules name spaces exist under bind::server; what's the rationale for this?

Would the structure make sense if it was bind::thing instead?

Just wanted to give you a heads up. When I try to install from the PuppetForge I get:

Notice: Preparing to install into /etc/puppet/environments/staging/modules ...
Notice: Downloading from https://forge.puppetlabs.com ...
Notice: Installing -- do not interrupt ...
Error: No such file or directory - /etc/puppet/environments/staging/modules/bind/spec/fixtures/modules/bind/manifests

When I start taking a look at the bind/ it creates I see that it is largely empty and the file it mentions explicitly is a broken symlink. Installing the module from the tarball works as expected.

Order of views in the named.conf file matters (see http://www.zytrax.com/books/dns/ch7/view.html "Notes:" ), sorting them in the template breaks the order they have been defined in.

QuickFix: name your views AAA, BBB, CCC, DDD etc.

As per the style guide

And http://docs.puppetlabs.com/guides/parameterized_classes.html

And will make it easier to support multiple operating systems.

Hi,

I tried to use your module on Ubuntu server but it is always failed on "file not found" error. There is a lot of hardcoded path to /etc or /var/named directory but ubuntu use /etc/bind directory instead.

Considering that Puppet 4 has now reached end of life, are there any plans on certifying that the module will work with Puppet 5.x?

While I haven't tried it and it may work, it would be nice to know that the newer version has been tested.

Hello,

the named.conf template does not contain a means to define the controls clause in the configuration file. Is there something else that I can use or should I create a PR?

thanks

It would be very convenient to be able to split zone config files separatelly, which makes everything easier to maintain and read.
Having all zones defined in /etc/named/[zone].conf, loaded by /etc/named.conf would be very usefull.

I've tried declaring many instances of bind::server::conf {'/etc/named/.zonea.conf' ....
but this approach is not working, as every zone inherits the whole /etc/named.conf parameters and Bind complains (options, acls, ... are redeclared in every file).
It would n't be that complicated to add a parameter "split_zone_config" and use another template for this.

Can you add support to add also_notify arrays to the options section? Here is a patch that I believe will work.

`diff --git a/manifests/server/conf.pp b/manifests/server/conf.pp
index 14fcbc1..070c128 100644
--- a/manifests/server/conf.pp
+++ b/manifests/server/conf.pp
@@ -41,6 +41,8 @@

Array of IP addrs or ACLs to allow recursion from. Default: empty

$allow_transfer:

Array of IP addrs or ACLs to allow transfer to. Default: empty

+# $also_notify:
+# Array of IP addrs or ACLs to send notifies to. Default: empty

$check_names:

Array of check-names strings. Example: [ 'master ignore' ]. Default: empty

$extra_options:

@@ -109,6 +111,7 @@ define bind::server::conf (
$recursion = 'yes',
$allow_recursion = [],
$allow_transfer = [],

• $also_notify = [],
  $check_names = [],
  $extra_options = {},
  $dnssec_enable = 'yes',
  diff --git a/templates/named.conf.erb b/templates/named.conf.erb
  index 8d0c471..3d266f8 100644
  --- a/templates/named.conf.erb
  +++ b/templates/named.conf.erb
  @@ -78,6 +78,9 @@ options {
  <% if !@allow_transfer.empty? -%>
  allow-transfer { <%= @allow_transfer.join("; ") %>; };
  <% end -%>
  +<% if !@also_notify.empty? -%>
• also-notify { <%= @also_notify.join("; ") %>; };
  +<% end -%>
  <% if !@check_names.empty? -%>
  <% @check_names.each do |line| -%>
  check-names <%= line %>;
  @@ -116,7 +119,7 @@ logging {
  <% if [email protected]? -%>

<% @views.sort_by {|key,value| key}.each do |key,value| -%>
-<% valid_keys = %w(allow-notify allow-query allow-recursion allow-transfer allow-update-forwarding forwarders match-clients match-destinations match-recursive-only) -%>
+<% valid_keys = %w(allow-notify allow-query allow-recursion allow-transfer also-notify allow-update-forwarding forwarders match-clients match-destinations match-recursive-only) -%>
view "<%= key %>" {
<% valid_keys.sort.each do |valid_key| -%>
<% if value[valid_key] and !value[valid_key].empty? -%>
`

Thanks,
ep

Used for various monitoring/metrics collection. For example:

statistics-channels { inet 127.0.0.1 port 8653 allow { 127.0.0.1; }; };

Curious to know if you would consider adding support for zone file creation from within this module (vs a static file)

On at least Debian 8 this file resides in /etc/bind and not in /etc causing named.conf to point to a non-existing file, which in turn stops BIND from starting, giving a cryptic error of:

/etc/bind/named.conf:61: missing ';' before '/'

Lots of loss of hair later, I noticed that the include path was incorrect. Manually changing it made BIND restart happily ...

I encountered the following issue during an apply on a CentOS 6.5 VM:

Info: Applying configuration version '1420044267'
Notice: /Stage[main]/Main/Node[default]/Ssh_authorized_key[rnelson0@putty]/ensure: created
Notice: /Stage[main]/Profile::Dns/Bind::Server::Conf[/etc/named.conf]/File[/etc/named.conf]/ensure: defined content as '{md5}a5141af2b722e6558974d95a5262576f'
Info: /Stage[main]/Profile::Dns/Bind::Server::Conf[/etc/named.conf]/File[/etc/named.conf]: Scheduling refresh of Class[Bind::Service]
Error: Could not set 'directory' on ensure: Could not find group named at 60:/etc/puppet/environments/sshgw/modules/bind/manifests/server/file.pp
Error: Could not set 'directory' on ensure: Could not find group named at 60:/etc/puppet/environments/sshgw/modules/bind/manifests/server/file.pp
Wrapped exception:
Could not find group named
...
Notice: /Stage[main]/Bind::Package/Package[bind]/ensure: created
Notice: /Stage[main]/Profile::Dns/Bind::Server::File[named.nelson.va]/File[/var/named/named.nelson.va]: Dependency File[/var/named] has failures: true
Warning: /Stage[main]/Profile::Dns/Bind::Server::File[named.nelson.va]/File[/var/named/named.nelson.va]: Skipping because of failed dependencies
Notice: /Stage[main]/Bind/File[/var/log/named]/ensure: created
Notice: /Stage[main]/Profile::Dns/Bind::Server::File[named.0.0.10]/File[/var/named/named.0.0.10]: Dependency File[/var/named] has failures: true
Warning: /Stage[main]/Profile::Dns/Bind::Server::File[named.0.0.10]/File[/var/named/named.0.0.10]: Skipping because of failed dependencies
Info: Class[Bind::Service]: Scheduling refresh of Service[named]
Notice: /Stage[main]/Bind::Service/Service[named]: Dependency File[/var/named] has failures: true
Warning: /Stage[main]/Bind::Service/Service[named]: Skipping because of failed dependencies
Notice: /Stage[main]/Bind::Service/Service[named]: Triggered 'refresh' from 1 events

The file is managed early in the run (lines 14-15) and the package is added later (line 101) followed by the other settings (102-110). A second run results in a working config, so the issue is simply one of ordering.

Is it possible to add the support of the option 'response-policy'?
Basically, it will be good to be able to set this option via the server.pp

response_policy => { "rpz.domain.com"} that will end up in a list of option in named.conf. E.g.:
options {
...
response-policy { zone "rpz.domain.com"; };
...
}

thank you

Hi,

Althought in bind::server::conf the parameter to configure keys is keys, in the documentation in that define file names it as tsig

How do you prevent this from overwriting dynamic updates?