-
Notifications
You must be signed in to change notification settings - Fork 413
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.
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
Recursive Queries are not supported by default #45
Comments
➤ Will Sloan commented: The solution for this is to add an ACL group, specify which clients are included in it, and set an option for recursive DNS resolution. Sample here: acl trusted { options { The ISC does not recommend allowing any client to do recursive queries because it opens a vulnerability where any malicious client can turn the DNS server into part of a DDOS. This recommendation can be found in this article However, this may be the best option for this general of a project. |
➤ Edward Cheadle commented: There is a way to do it from the webmin console. On the login screen open: |
➤ Hans van den Bogert commented: @echeadle the TS has a different use-case for his DNS server. Recursion is for zones that are not configured on the server itself. E.g., if the DNS server get's a request for google.com, it realizes that it doesn't have the zone file for that, so then it recurses from the root domains to google's nameservers to get the record for google.com. That is what recursion is. In your case you're describing access to the local zones. That's not recursion. Therefore, the TS's problem is still not solved |
As of BIND 9.4.1-P1, new options have become available (and are required) to allow recursive DNS entries as explained by this ISC article. Therefore, after this container is started, it will not allow clients outside of the host to do recursive DNS entries with the current configuration.
Expected Behavior:
After the container is started with the default, included config, this server will be able to resolve recursive DNS entries from other clients on the network as implied by this example article.
Actual Behavior:
The server responds with this message to the client:
** server can't find google.com: REFUSED
The logs on the client read:
client 192.168.2.202#64300 (google.com): query (cache) 'google.com/A/IN' denied
The text was updated successfully, but these errors were encountered: