Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Cannot set empty forwarders for zone #204

Open
apeschel opened this issue Feb 24, 2017 · 2 comments
Open

Cannot set empty forwarders for zone #204

apeschel opened this issue Feb 24, 2017 · 2 comments

Comments

@apeschel
Copy link
Contributor

It's not possible to override the forwarders for a zone to be empty. This means that authoritative zones will use the default forwarders from the options file even if this is not the desired behavior.
@ghost
Copy link

ghost commented Mar 4, 2017

I can think of three ways to fix this:

  1. Add a new boolean parameter, something like force_empty_forwarders or something, which will tell the zone to include the forwarders { } list even if it's empty
  2. Change the default value of the allow_forwarders to undef, which would mean no forwarders { } list is defined in the zone, and change the behavior of an empty allow_forwarders array to create an empty forwarders { } list in the zone. This is a breaking change and would require a major version bump.
  3. Add a new forwarders parameter that has the semantics described above, and deprecate the existing allow_forwarders parameter. If both are specified, they would be merged together; if only allow_forwarders is specified, it would have the same semantics as the current parameter. Deprecating the parameter requires a minor version bump; removing the deprecated parameter later would require a major version bump.

@solarkennedy @ajjahn any preferences? I sort of lean towards deprecating the current parameter and introducing a new parameter with the desired semantics.

@solarkennedy
Copy link
Collaborator

@jearls I agree on #3.

@ghost ghost mentioned this issue Mar 6, 2017
Closed
@jjthiessen jjthiessen mentioned this issue Aug 17, 2018
Open
prolixalias pushed a commit to autostructure/puppet-dns that referenced this issue Oct 23, 2019
@johnson-earls @prolixalias
Add forwarders to dns::zone; deprecate allow_forwarder
a97885b 
This change adds the `forwarders` parameter to `dns::zone`, deprecating
`allow_forwarder` in favor of `forwarders`.  `forwarders` extends
`allow_forwarder` by allowing both an *empty* forwarders list as well as
an *undefined* forwarders list (the former meaning that the zone does not
forward, while the latter leaves the global forwarders option in place):

> [*forwarders*]
> An array of IP addresses and optional port numbers to which queries
> for this zone will be forwarded (based on the *forward_policy*
> setting).  If the optional port number is included, it must be
> separated from the IP address by the word `port` - for example,
> `[ '192.168.100.102 port 1234' ]`.  If passed an empty array or the
> boolean value `false`, the zone will not forward.  If passed `true`
> or left undefined, the zone will use the global forwarders defined
> in `dns::server::options`.
> *Note* - this parameter deprecates and should be used in place of
> the *allow_forwarder* parameter.  If both parameters are passed in,
> only *forwarders* will take effect.

This addresses Issue ajjahn#204
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@solarkennedy @apeschel