Re: [arch-general] [arch-dev-public] BIND10? No, thanks.
On Sat, 9 Mar 2013 13:27:42 +1100 Gaetan Bisson <bisson@archlinux.org> wrote:
Hi guys,
Currently we use the BIND code base in two packages: - dnsutils from [core] provides basic DNS query tools; - bind from [extra] is the actual name server.
With the new BIND10 release, the ISC really outdid themselves: all formerly standalone tools have been merged and rewritten as a python script which uses bindings to the new libb10-* series of libraries that are shared with the name server. Python being such a boring dependency, they introduced another three: botan, log4cplus, and boost!
That mostly means two things: - We cannot keep splitting dnsutils and bind anymore. - I do not want to maintain these packages any further.
We already have ldns in [core], a much better written (and sane) DNS library which includes query tools that are near drop-in replacements for BIND's: use `drill` instead of `dig`, etc.
So I suggest: - Any package relying on dnsutils and its tools (dig, host, nslookup) be ported to use ldns instead - should be straightforward in most cases. - We ditch dnsutils and bind out of our repos, unless somebody finds them fun and wants to maintain them in [extra] or [community].
Comments or suggestions are welcome.
Cheers.
Great. I was actually going to open a feature request for this on flyspray. The only thing: whouldn't one need community/unbound (unbound-host AFAIR) to replace nslookup? -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sat, Mar 9, 2013 at 7:00 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
On Sat, 9 Mar 2013 13:27:42 +1100 Gaetan Bisson <bisson@archlinux.org> wrote:
Hi guys,
Currently we use the BIND code base in two packages: - dnsutils from [core] provides basic DNS query tools; - bind from [extra] is the actual name server.
With the new BIND10 release, the ISC really outdid themselves: all formerly standalone tools have been merged and rewritten as a python script which uses bindings to the new libb10-* series of libraries that are shared with the name server. Python being such a boring dependency, they introduced another three: botan, log4cplus, and boost!
That mostly means two things: - We cannot keep splitting dnsutils and bind anymore. - I do not want to maintain these packages any further.
We already have ldns in [core], a much better written (and sane) DNS library which includes query tools that are near drop-in replacements for BIND's: use `drill` instead of `dig`, etc.
So I suggest: - Any package relying on dnsutils and its tools (dig, host, nslookup) be ported to use ldns instead - should be straightforward in most cases. - We ditch dnsutils and bind out of our repos, unless somebody finds them fun and wants to maintain them in [extra] or [community].
Comments or suggestions are welcome.
Cheers.
Great. I was actually going to open a feature request for this on flyspray. The only thing: whouldn't one need community/unbound (unbound-host AFAIR) to replace nslookup?
Do I interpret this as meaning that if dnstools and bind are removed from the arch repos, then ldns carries the tools as a replacement, but that "unbound" is a dependent package that would then be the authoritative resolver that replaces bind? Or would it be that ldns would contain not only the dns tools (such as the replacement for dig etc), but also the full authoritative resolver merged into the code? Maybe I just don't understand the proposal here. Perhaps someone could clarify what the proposal means? Thanks -- mike c
On Sat, Mar 9, 2013 at 8:44 PM, Mike Cloaked <mike.cloaked@gmail.com> wrote:
Great. I was actually going to open a feature request for this on flyspray. The only thing: whouldn't one need community/unbound (unbound-host AFAIR) to replace nslookup?
Do I interpret this as meaning that if dnstools and bind are removed from the arch repos, then ldns carries the tools as a replacement, but that "unbound" is a dependent package that would then be the authoritative resolver that replaces bind? Or would it be that ldns would contain not only the dns tools (such as the replacement for dig etc), but also the full authoritative resolver merged into the code?
Maybe I just don't understand the proposal here. Perhaps someone could clarify what the proposal means?
Apologies for replying to my own previous post, but having read up a little more about authoritative and caching/recursive namerservers - it seems that a good alternative to bind (which I use on all my machines especially as a local authoritative DNS server for local networking) would be to use nsd as the pure authoritative nameserver in combination with unbound as a recursive caching nameserver. Both are packages available in arch. Once installed both have systemd service files, and it seems that setting them up is not too difficult - and I already had ldns installed (presume from the base install) so I guess having those three packages running would give a pretty good alternative to bind/dnstools though it would be nice to know if anyone is already using these and could post on how well they perform? -- mike c
[2013-03-09 21:37:01 +0000] Mike Cloaked:
Apologies for replying to my own previous post, but having read up a little more about authoritative and caching/recursive namerservers - it seems that a good alternative to bind (which I use on all my machines especially as a local authoritative DNS server for local networking) would be to use nsd as the pure authoritative nameserver in combination with unbound as a recursive caching nameserver. Both are packages available in arch. Once installed both have systemd service files, and it seems that setting them up is not too difficult - and I already had ldns installed (presume from the base install) so I guess having those three packages running would give a pretty good alternative to bind/dnstools
Thank you so much for finally doing some basic research. Let me make this entirely clear for everyone: - ldns and dnstools are query tools (their main use is to send a single DNS request to a resolving server, and display the request). - bind is a multi-purpose server. - nsd is an authoritative server. - unbound is a resolving server. We will simply remove dnstools from [core] and replace it by ldns where needed; additionally, I will stop maintaining bind and suggest people switch to nsd (if they were using bind as an authoritative server) or unbound (if they were using bind as a resolving and/or caching server).
it would be nice to know if anyone is already using these and could post on how well they perform?
No. This list is not a tea room. There is plenty of information showing that ldns+unbound+nsd perform very well (much better than bind in fact) available on the Web anyone can look up; do also note that three of the thirteen root nameservers have switched from bind to nsd in the past few years. And please just do keep using your research skills. -- Gaetan
On Sat, Mar 9, 2013 at 9:37 PM, Mike Cloaked <mike.cloaked@gmail.com> wrote:
having read up a little more about authoritative and caching/recursive namerservers - it seems that a good alternative to bind (which I use on all my machines especially as a local authoritative DNS server for local networking) would be to use nsd as the pure authoritative nameserver in combination with unbound as a recursive caching nameserver. Both are packages available in arch. Once installed both have systemd service files, and it seems that setting them up is not too difficult - and I already had ldns installed (presume from the base install) so I guess having those three packages running would give a pretty good alternative to bind/dnstools though it would be nice to know if anyone is already using these and could post on how well they perform?
I have spent some time since I posted about the issue of dns servers to research a little more on migrating from bind to nsd/unbound as the dns server/resolver for my own local network.
It is useful to note that the CVE vulnerability records for both nsd and unbound are very favourable: http://www.cvedetails.com/product/17420/Nlnetlabs-NSD.html?vendor_id=9613 http://www.cvedetails.com/product/18208/Unbound-Unbound.html?vendor_id=10197 Secondly the process of migration turned out to be fairly straightforward once several advice pages from the web were looked at and answers to questions I had about specific points on configuring my own system were available on the user lists for both packages at: https://open.nlnetlabs.nl/pipermail/nsd-users/ https://unbound.nlnetlabs.nl/pipermail/unbound-users/ It may be of interest that the approach I took was to set up unbound initially on a non-critical machine that was not my main server but within the local network first. Making this a caching/recursive dns server that forwarded dns requests for the local network to the main LAN dns server running on another machine was achieved by setting it up to listen on port 53 using advice from the mailing list plus initial tutorial instructions from: https://calomel.org/unbound_dns.html To make the changeover once the configs were ready, the config file was tested using the unbound-checkconf command, and then was simply a matter of: systemctl stop named systemctl start unbound I made sure that /etc/resolv.conf had the line: nameserver 127.0.0.1 and then ran tests using the drill command pointing at the internal server to check forward and reverse lookups. Once that was done I installed nsd on the main server machine and followed the tutorial at https://calomel.org/nsd_dns.html plus the mailing list, and some other google searches with nsd set to listen on a high private port. Config testing is simple with nsd-checkconf, and then the service can be started with: systemctl start nsd Again testing is simple with commands such as drill @127.0.0.1 -p xxxxx www.cnn.com for example with xxxxx being the private port on which nsd is listening. Once that is tested, and with bind still running at the same time, and listening on port 53, then unbound can be setup to listen on port 53 but with a local stub zone for local dns requests pointing to nsd on the private port to complete the service for both internal and external addresses. Once ready to test, and with nsd already running then: systemctl stop named systemctl start unbound will enable dns request tests to be run with commands starting drill @ 127.0.0.1 sitename.com Once the tests are all working then the named service can be disabled and nsd and unbound enabled so that they will start at boot. Naturally there are a multitude of different ways to set up dns servers to suit individual requirements, but I hope that relating my own experience is useful to others. I now have no bind services running and all the dns requirements have been running for the past few days with nsd/unbound without any problems at all. For anyone planning on migrating from bind to nsd/unbound it is useful to work on this ahead of the time when bind may no longer be a supported package in arch - my own experience suggests that nsd/unbound are excellent alternatives, and indeed more secure than a single server running all dns services, as separating the authoritative dns server from the caching/recursive server provides potentially added security. -- mike c
participants (3)
-
Gaetan Bisson
-
Leonid Isaev
-
Mike Cloaked