I am aware of the fact that unbound has "replaced" BIND in the base system, starting with 10.0-RELEASE. What surprised me was recent commits to ports/dns/bind99 (and presumably other versions) that appears to take away the supported chroot capabilities. OTOH, it appears that unbound has been given these capabilities. I have no issues with removing BIND from base, but taking away the very robust chroot support that FreeBSD had for BIND is something I would oppose. I like the idea of leveling the playing field for users of other systems, but the way things have been implemented thus far--taking away functionality from BIND while preferring unbound--seems counter-productive. It doesn't really level the playing field, it just turns it the other way. It seems like it would be pretty easy to preserve the /etc/rc.d/named startup script and BIND.chroot.dist from 9.x and add them to the BIND ports, so that people who need to run a full-blown BIND installation can "just install the port" as was advised back in 2012 when the BIND/unbound change was first being discussed on -hackers. What are the obstacles to doing something like this? michael
+1 On 12/3/13, Michael Sinatra <michael at rancid.berkeley.edu> wrote:> I am aware of the fact that unbound has "replaced" BIND in the base > system, starting with 10.0-RELEASE. What surprised me was recent > commits to ports/dns/bind99 (and presumably other versions) that appears > to take away the supported chroot capabilities. OTOH, it appears that > unbound has been given these capabilities. > > I have no issues with removing BIND from base, but taking away the very > robust chroot support that FreeBSD had for BIND is something I would > oppose. I like the idea of leveling the playing field for users of > other systems, but the way things have been implemented thus far--taking > away functionality from BIND while preferring unbound--seems > counter-productive. It doesn't really level the playing field, it just > turns it the other way. > > It seems like it would be pretty easy to preserve the /etc/rc.d/named > startup script and BIND.chroot.dist from 9.x and add them to the BIND > ports, so that people who need to run a full-blown BIND installation can > "just install the port" as was advised back in 2012 when the > BIND/unbound change was first being discussed on -hackers. What are the > obstacles to doing something like this? > > michael > _______________________________________________ > freebsd-stable at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org" >
On Tue, Dec 3, 2013, at 2:56, Michael Sinatra wrote:> I am aware of the fact that unbound has "replaced" BIND in the base > system, starting with 10.0-RELEASE. What surprised me was recent > commits to ports/dns/bind99 (and presumably other versions) that appears > to take away the supported chroot capabilities. OTOH, it appears that > unbound has been given these capabilities. > > I have no issues with removing BIND from base, but taking away the very > robust chroot support that FreeBSD had for BIND is something I would > oppose. I like the idea of leveling the playing field for users of > other systems, but the way things have been implemented thus far--taking > away functionality from BIND while preferring unbound--seems > counter-productive. It doesn't really level the playing field, it just > turns it the other way. > > It seems like it would be pretty easy to preserve the /etc/rc.d/named > startup script and BIND.chroot.dist from 9.x and add them to the BIND > ports, so that people who need to run a full-blown BIND installation can > "just install the port" as was advised back in 2012 when the > BIND/unbound change was first being discussed on -hackers. What are the > obstacles to doing something like this? >I would start by filing a PR; I don't think this was intentional.
03.12.2013 12:56, Michael Sinatra ?????:> I am aware of the fact that unbound has "replaced" BIND in the base > system, starting with 10.0-RELEASE. What surprised me was recent > commits to ports/dns/bind99 (and presumably other versions) that appears > to take away the supported chroot capabilities./usr/ports/UPDATING has some info about the matter. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
On 12/4/13, 9:05 AM, Mark Andrews wrote:> As far as I could tell it was a religious issue.I believe this to be the case, and as with a lot of religious issues, truth is often "adjusted" for particular points of view.> > [...] > As for 9.9.x ESV it will be support for to at least June 2017, which> is 5+ years from BIND 9.9.0, and 4 years after 9.9.x was announced as > the ESV series with BIND 9.9.3. BIND 9.6 went ESV in Mar 2010 and > will be EoL in Jan 2014. BIND 9.10 in is alpha at the moment. BIND 10 > is still in development. So, basically, we were not told the entire story.. We were told that bind-9 was a dead-end.. if it is not I feel kind of disappointed by the people who made the change. We trust other developers to be honest about these things as we can't all track all other projects.. It's a pitty that you didn't join the conversation when it was being discussed. Some fact injection may have made a difference and saved us some heartache.
On Tue, Dec 03, 2013 at 12:56:37AM -0800, Michael Sinatra wrote:> I am aware of the fact that unbound has "replaced" BIND in the base > system, starting with 10.0-RELEASE. What surprised me was recent > commits to ports/dns/bind99 (and presumably other versions) that appears > to take away the supported chroot capabilities. OTOH, it appears that > unbound has been given these capabilities. > > I have no issues with removing BIND from base, but taking away the very > robust chroot support that FreeBSD had for BIND is something I would > oppose. I like the idea of leveling the playing field for users of > other systems, but the way things have been implemented thus far--taking > away functionality from BIND while preferring unbound--seems > counter-productive. It doesn't really level the playing field, it just > turns it the other way. > > It seems like it would be pretty easy to preserve the /etc/rc.d/named > startup script and BIND.chroot.dist from 9.x and add them to the BIND > ports, so that people who need to run a full-blown BIND installation can > "just install the port" as was advised back in 2012 when the > BIND/unbound change was first being discussed on -hackers. What are the > obstacles to doing something like this? >It's not as simple as you describe, trust me I tried :-) The one point people in this thread seem to be missing is why BIND should be treated differently than all the other DNS severs? BIND may have a bad security reputation back from the 4 and 8 days, but do you really think that BIND9 is so much more insecure than say NSD or Knot that it needs special treatment in ports? Or what about Apache for that matter? If you really think that, a chroot really isn't going to help you much and what you really want is a jail(8). What should be done is to create an easy to do so, but for any port, not just one single port. I think we have all the tools available, so it is probably just a matter of writing some good documentation to add to the porters handbook, though to make it really easy might require some additions to the ports framework. The way the BIND ports are now is actually in line with all the other ports in how they start and where the configuration files are. The chroot code was a relic of history and the slight security benefit it may have today is far outweighed by the increased complexity and decreased consistency with the rest of the ports tree, both from a ports maintainance perspective and from the user perspective. I will be happy to look into general frameworks to jail any daemon installed from ports, but will not make exceptions to a handful of ports. Hope this explains some of the reasoning for not readding chroot support. Cheers, Erwin -- Erwin Lansing http://droso.dk erwin at FreeBSD.org http:// www.FreeBSD.org