Named.options fix

[tedivm]

Three major big fixes which were introduced to the "named.conf" file in #112 -

• Corrected the location of the rndc.key file on debian.
• Removed the extra definition of the "." zone.
• Removed the "logging" setup, which referred to a nonexistent file.

All three of these errors will prevent bind from starting up.

This should resolve #115.

[solarkennedy]

You said this was extra, where is the duplicated entry?

[tedivm]

The "rfc1912_zones_cfg" line pulls in named.conf.default-zones. The first lines of that file are-

// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};

[solarkennedy]

Hmm. I'm not sure what to do here.
On the one hand, we have this @root_hint parameter. On redhat, does /etc/named.rfc1912.zones have the same root zone hint?

Managing this named.conf file has opened up a can of worms. I think we have to go whole-hog here and manage everything, otherwise we are going to get deeper into a bunch of distro differences.

I agree that this is duplicated for the debian case.

[darkfoxprime]

To the best of my knowledge, no ,RedHat does not put the root zone hint in the rfc1912 zones file. I will answer for sure once I manage to get my VMs working for testing puppet stuff on different OSes.

[tedivm]

I just confirmed that RedHat does not include the root zone in the rfc1912 file.

[solarkennedy]

@ajjahn @danzilio Can you guys give me a second opinion here? Managing named.conf has opened up a lot of issues. On the one hand it is nice that we are getting PR's for this, on the other hand it isn't great that there are so many bugs because of the OS differences.

What do you think about having this module control all the files? (as opposed to just referencing distro-provided files)

[ajjahn]

@solarkennedy I think I lean toward supporting managing named.conf, but I don't think we should we should muck around with sample files in /usr/share/doc/bind-9.3.6/sample/etc/ for example.

@tedivm's suggestion, #112 (comment), seems reasonable to me.

[solarkennedy]

@tedivm can you resubmit one change at a time. How about the root zone thing, how about removing the duplicate root zone entry and managing the rfc1912 file. That way we can ensure where the root hint lives no matter the os. (the rfc1912 file contents will not change, so I think it is ok for this module to manage it for us)

[tedivm]

Without both fixes being added I have a broken install, so what I would essentially be doing is submitting a known broken pull request.

I'm also not sure what you mean by "the rfc1912 file contents will not change". Isn't the problem we're having that the file itself is different between Debian and Redhat? If the file isn't going to change why manage it? Wouldn't a better solution be for me to make the chunks I removed conditional, so they do get added where needed but are discarded when they aren't?

[solarkennedy]

I'm going to merge this for now because I know it fixes this on Ubuntu platforms (which are currently broken)

I'm going to submit a PR to add an integration test suite to catch these kind of errors.

Re: rf19212 file, yea the problem is that it is different between the platforms. I think providing our own controlled zone file is the only sure way to know what kind of inputs we are giving to bind (as opposed to relying on the distro-provided zone files)