From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 18:56:27 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 5580C1065678 for ; Tue, 21 Aug 2012 18:56:27 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 22B5914DACE; Tue, 21 Aug 2012 18:56:21 +0000 (UTC) Message-ID: <5033D9D7.808@FreeBSD.org> Date: Tue, 21 Aug 2012 11:56:23 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <5031FAAB.9020409@FreeBSD.org> <86a9xobo2c.fsf@ds4.des.no> <5033C7BB.1040702@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , FreeBSD Hackers Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 18:56:27 -0000 On 8/21/2012 11:08 AM, Bjoern A. Zeeb wrote: > On Tue, 21 Aug 2012, Doug Barton wrote: >> Neither importing ldns nor removing BIND is going to have any effect on >> the stub resolver library in libc. > > Yes it does as if we are not carefull, we'll neither have a _proper_ > validating caching resolver but 4 different resolver libraries 3 of > which needing crypto and only 2 with a well known support plan and > only 2 with the same interface in base. Can you please enumerate what resolver libraries you're talking about, because I don't understand what you're referring to here. The way that I'm using the terms above: 1. A validating, caching resolver is a full server type thing, such as BIND or Unbound. 2. The stub resolver library is (as currently implemented) part of libc, and currently uses code from a completely separate import of the BIND resolver library implementation. To be clear, removing src/contrib/bind9 won't affect that at all. 3. ldns _can_ be used to make a resolver library, but it does not have to be. Under the plan that des and I have it would be used as the basis of the dig-like tool called drill, and the host-alike tool that Vitaly provided. It's also a dependency of Unbound, FWIW. I have also said on numerous occasions that I don't think we should have a _single_ validating resolver in the base at all, however I understand that you think differently, which is why you raise the objection above. > Can you see why Simon's question > is important to not make the current problem worse? Of course I understand Simon's question. That's why I answered it. :) > (rhetorical for > you, Des will answer). Can we make sure if we do this that things > like portsnap and freebsd-update will not stop working (using the > command line tools for example)? I've been testing Vitaly's host-alike tool, and haven't run into any problems where the output is different. Obviously we would have to test the dependencies before we pulled BIND out altogether. That's why we are only contemplating doing this in HEAD, long before 10.0-RELEASE. It's also worth pointing out that if we stick to the plan *cough* that we have less than a year before 10-RELEASE, so getting started sooner rather than later here is a good thing. > Can we have a longer plan of where > we want to be in a year, which parts we need from where and how to get > them, and if we feel like it, add names to this? It's strange that > others in this thread have asked for it already, not just me yelling > "stop". But those things have already been discussed, most recently in this thread. Really, you need to pay attention if you want to be involved. :) Plan 0: Import ldns/drill/host-alike, remove BIND. Following which ... Plan A: Allow user to choose from a list of validating resolvers at install time, including at minimum Unbound and BIND. Plan B: Import Unbound Both Plans [AB] involve support for DNSSEC for whatever solutions we make available to the users. IMO in order to be considered for inclusion as a validating resolver the software has to support RFC 5011 rollovers, which means that the difficult part of DNSSEC support is the bootstrapping of the root trust anchor. I have an idea for how I want to do that for BIND in the ports, but lately I have been thinking that it might make more sense to write an rc.d script for the base that can do this in a generic way at boot time. What is definitely *not* going to be acceptable is a hard-coded "set and forget" scheme. We've already seen that fail in another OS, and I don't want to repeat that mistake. >> And if you have much larger plans for resolver libraries, especially >> validating ones, it would be great if they were discussed IN PUBLIC, so >> that those of us who know a little something about the topic can be >> involved in the discussion BEFORE all the decisions are made, and all >> the balls start rolling. > > Do you understand the part about the wiki from above? I can put an > ACL on to exclude everyone but the secret cabal, having investigated > days the last 18 months on the topic, talked to people on multiple > continents, from different projects, ... but I hadn't planned to .. > and I am not the only one. The fact that it's not written down is, > as I said, things are only no longer totally nebulous since last week. I'm sorry, I don't understand most of the paragraph above, but what it sounds like is that you have been talking to people privately about what you think this stuff should look like for 1 1/2 years. I think that's great, but whatever private discussions you may have had don't give you ownership of the problem. This is too important for any one person (myself included) to deal with on their own. Whatever plans we may have in this area need to be thoroughly discussed, IN PUBLIC, before decisions are made, or actions are taken. Not to mention that if the discussion had been public we could potentially have benefited from the ability of many contributors being able to make progress faster than 1 person trying to own the problem solo (no matter how many continents they travel to). > Given the only thing you currently want to do is getting rid of > solving the problem of no longer maintaing named in base (which I > think no one disagrees with per se) but do not want to invest in any > of the other work, That isn't true, and you know it isn't. I was the one who first raised the issue of how important robust DNSSEC support is going to be to re@ (of which you are a member) years ago. I said at the time that I am not only willing, but highly motivated to provide assistance in that area. When you first mentioned your private discussions and plans for a validating resolver in the base in that context a year or so ago, I asked to be included at that time. You have chosen not to do that. So, either you have an incredibly selective memory, or you are blatantly lying in order to make me look bad. I find either option highly disturbing. > I'd highly appreciate a lower noise level so > others could in fact move forward in a more productive way. Um, no, I am definitely NOT going to lower the noise level on this. It's too important. > I could > have started the wiki page rather than replying for example. The fact that you chose one course of action over the other says more about you than it does about me. :) Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909)