The DNS Helper tool provides assistance with configuring different types of DNS servers. The tool works by collecting specifications regarding the RHEL version and DNS server type, then generates a bash script to automatically create and configure the server. The three available server types are:
- Authoritative DNS server with one Master node
- Authoritative DNS server with one Master node and slave nodes
- Recursive DNS server for caching
Was this helpful?
We appreciate your feedback. Leave a comment if you would like to provide more detail.
It looks like we have some work to do. Leave a comment to let us know how we could improve.
Subscriber exclusive content
An active Red Hat subscription is required to participate.Log In
Awesome tool guys!
Again, awesome tool folks!
It seems there're at least a couple minor bugs, however:
Toward the end of all the scripts I read through, we have these blocks of code, which differ slightly based on RHEL version:
For RHEL 6:
For RHEL 7:
The bug occurs in the sequence from enabling the service (after the first
ifstatement) to testing for a non-zero exit status of (re)starting named-chroot in the second
ifstatement. For the second
ifstatement to evaluate a valid test, the exit status will need to be captured for whichever of the consequent- or alternate-consequent lists are executed in the first
ifstatement (i.e., restarting and starting named-chroot, respectively).
And here're a few suggestions that may help:
Scripts don't have any comments ID'ing the key/initial parameters selected (e.g., RHEL Version, DNS Server Type). While the descriptive file name of the scripts is useful, it may be helpful to users to have that documentation near the head of their script(s).
Scripts don't check for or advise on execution as root. As this is a tool produced and owned by Red Hat, and the helper scripts essentially need rootly powers to complete successfully, it seems something should be noted on the matter for users who may not be fully aware of the risks of running a scripted program they got from the Internet as root. (Helper scripts pulled down from Red Hat is an exception to that rule, of course, but these scripts offer a great opportunity to advise against such things as root in most other cases.)
As SELinux is enforcing by default in RHEL, their should probably be some check on its status and subsequent flow based on the result (of the status). For example, in the script produced for configuring the slave server(s), there are these four lines toward the end of the script:
While the fourth line may serve as a fair reminder that further action may be needed as it relates to SELinux contexts (and for those who understand what they're looking at), it may be more helpful for all users if such conditional behavior is also automated.
Thank you very much, Darron! We will investigate on it.
Hi Darron, I'm the developer of this app, thanks so much for your feedback. It's very usefully for us to improve the quality of the app. And I've updated it based on your comment.
Here're the details:
1 b.root-servers.net seems to be missing its corresponding IPv6 address (i.e., 2001:500:84::b). (This is consistent for at least RHEL 6 and RHEL 7 scripts.)
[Jingjing] In the script you will see, I will use the default /var/named/named.ca supplied by the bind package, if it doesn't exist I will make this file with the content that .
So I don't have the permission or resource to add IPv6 for b.root-servers.net. And my team will forward this issue to corresponding product team.
2 Yes, you are right:
Same with script on rhel6
[Jingjing]: Has added the comment with important option in the header of the scripts
[Jingjing]: Has already add the tip in the download page to tell the user to execute the script with root user.
[Jingjing]: Has confirmed with the expert of DNS, /var/named/slaves is the default folder for slave dns , don't need to change any selinux label whether the selinux is enable. And in this app, we doesn't supply the option to customer to use other folder for salve dns. So I've removed the following lines:
Feature suggestion: Could it be extended to cover reverse-DNS as well? Or even more advanced: sub net delegation ? P.S. I appreciate the idea of helpers/labs! Great tootls.