Comments (6)
#185 should resolve this. Thanks for sending the note.
from puppet-unbound.
@xaque208 below is what the unbound man page states so interfaces should probably be set to ['::1', '127.0.0.1']
however that is likely to break some setups
Interface to use to connect to the network. This interface is
listened to for queries from clients, and answers to clients are
given from it. Can be given multiple times to work on several
interfaces. If none are given the default is to listen to local-
host. The interfaces are not changed on a reload (kill -HUP)
but only on restart. A port number can be specified with @port
(without spaces between interface and port number), if not spec-
ified the default port (from port) is used.
from puppet-unbound.
Thank you for sending the note.
I think its just the example that could be updated here. We also require the user to pass in the listen address, as well as the access list that will be allowed query, but the user is expected to know the impact of the values they enter since its entirely site specific.
Its worth noting, binding does not alone allow connections. Other security mechanisms that are beyond the scope of this module might be in place, such as packet filtering. Also, the service itself has a notion of providing access from particular prefixes, so merely binding to an address is not necessarily sufficient to provide access. Also, due to the often public nature of DNS, I don't really see this as bad practice or an issue generally, but perhaps I'm overlooking something. My personal expectation of deployment of DNS infrastructure is that the security decisions around DNS are weighed to determine the impact to the particular deployment, which is quite specific to the need of that infrastructure.
For example, I have private zones on servers that are not reachable from the internet, so binding to ::0
might be acceptable for me. In other cases, if one were to attach a DNS server to the internet, one might presume that the server in question is there to serve queries from the internet, in which case, the bind address is nearly irrelevant as long as the access list allows the specifics and the address that is bound is reachable.
The example in question I believe is the only place that we're referencing 0.0.0.0
, and so I can see an update there being useful to demonstrate that users can specify specific addresses that they wish to listen on.
from puppet-unbound.
Very insightful, thanks!
I think this particular instance can be considered as a smell
, something that deserves attention, but may not always lead to vulnerabilities.
from puppet-unbound.
@xaque208 i agree with all yu have said and dont see this as much of an issue, however i wanted to point out that this is not just in the example, the default does bind to 0.0.0.0, ::0
from puppet-unbound.
Ah yeah, I see it now. If we want to bubble up the default from unbound, it sounds like maybe we move that default to be undef, and avoid putting the listen line in the config. This would require the user to pass in the listen address, and a major version bump the module with a good changelog and readme update.
from puppet-unbound.
Related Issues (20)
- Wrong quoting for local-data TXT records HOT 5
- version 2.4.3 breaks the configfile for tls-upstream on CentOS 7
- `unbound_version` fact needs a test HOT 1
- Debian: module change ownership of directory /run to unbound HOT 13
- add ability to define/generate local-data + override local-zone template HOT 3
- commit 5868593634371290ad013e4a3005f25cb8d7e1fe broke the module for me HOT 6
- Fix installation on Debian distribution - e.g. unbound option auto-trust-anchor-file is provided two times HOT 8
- Handle TXT records containing double quotes and white space
- Resource default statements in module HOT 17
- Drop EOL Debian 8
- Please support 'respip' in module_config HOT 1
- add deprecation message on the forge HOT 4
- unbound_version not set on first run causing unexpected config file setting HOT 1
- No support Static record mapping to multiple IP
- Documentation is misleading when using unbound::stub
- Outgoing port permit/avoid order wrong when outgoing_port_permit_first = false
- Option trust_anchor_file is not usable
- Allow to restart instead of reload on config changes
- $conf_d and $unbound_conf_d are not documented and unclear how they differ beyond their location HOT 2
- Newer versions of Unbound require the "include:" line in its own stanza HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from puppet-unbound.