Re: Results of BIND RFC
On 2010-Apr-03 19:01:52 -0700, per...@pluto.rain.com wrote: >Ruben de Groot wrote: >> defer all questions about moving out of the base system ... > >Last I knew, X was not _in_ the base system :) Well, that's an excellent topic for another bikeshed - Should X be made part of the base system? I know it is on OpenBSD. :-) :-) -- Peter Jeremy pgpDxSFAgVh1s.pgp Description: PGP signature
Re: Results of BIND RFC
Ruben de Groot wrote: > defer all questions about moving out of the base system ... Last I knew, X was not _in_ the base system :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
On Fri, Apr 02, 2010 at 02:08:27PM -0400, Charles Sprickman typed: > Can we do sendmail next April 1? Better yet, defer all questions about moving out of the base system by referring to the Grand Discussion that'll take place *next year* on the first of april. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
On 2 Apr 2010, at 23:07, Doug Barton wrote: Therefore I think that the status quo of having it all in there, and knobs to turn off the bits you don't want is a good one since it seems to please the majority of our users. I will continue to maintain the bind-tools port though, that's something that's been requested often, and I think it's a good thing to have for those who want a different DNS solution but still want access to those tools in a fairly painless manner. And of course the ability to easily change/upgrade/manage what version of BIND you use via the ports will continue to be a key component of how we deal with this going forward. Of course, the release synchronization problems I described in both the original post and the AFD post are real, so stay tuned. :) Some about BIND and XML support via port. As I know, world is enough to build everything in it, but support build something in world, which depends on some port is not good idea. Yes, it useful option, but I think it should be in port(which has much more flexibility), not in world. hth, Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) iEYEAREDAAYFAku2QIgACgkQyIakK9Wy8PvMtQCeIu/32RGMIC/798V15aO/sjP3 788AoPf53oxsgutXPriuLOszcp2DBKc1 =hUnq -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org " ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
On 2 Apr 2010, at 23:07, Doug Barton wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
So first of all, yes Virginia, this was an April Fool's Day joke. To
both those for whom this post created a false sense of despair, and
(perhaps more importantly) to those for whom it created a false
sense of
joy, my apologies. :) And for the record, everything from here on is
"just the facts."
I have always said that I will remove BIND from the base when there is
clear community consensus to do so, and I stand by that. However the
discussion always seems to go along the lines that this thread did. A
vocal group who say, "YES!" and then a lot of people who want the
resolution tools (dig, host, nslookup) to stay, and the other end of
the
bell-shaped curve with those who like having the whole thing in the
base. Toss in a few choruses of "The whole base should be more
modular,"
(a viewpoint with which I have a great deal of sympathy btw) and the
soup is pretty well complete.
In regard to the tools issue, the problem is that you need a pretty
good
majority of the code in order to build them. They require the
libraries
to be built, and once you've done that, you might as well do the
rest. :)
Total size of code in:
contrib/bind9:14.0M
contrib/bind9/lib: 7.6M
contrib/bind9/bin: 2.5M
contrib/bind9/bin/dig: 0.4M
The last is the directory that has the code for all 3 resolution
tools,
FYI.
Therefore I think that the status quo of having it all in there, and
knobs to turn off the bits you don't want is a good one since it seems
to please the majority of our users. I will continue to maintain the
bind-tools port though, that's something that's been requested often,
and I think it's a good thing to have for those who want a different
DNS
solution but still want access to those tools in a fairly painless
manner. And of course the ability to easily change/upgrade/manage what
version of BIND you use via the ports will continue to be a key
component of how we deal with this going forward.
Of course, the release synchronization problems I described in both
the
original post and the AFD post are real, so stay tuned. :)
Answers to DNSSEC concerns below.
On 4/2/2010 3:52 AM, Robert Watson wrote:
With an eye on the date of Doug's suggestive e-mail, I actually am
concerned
that we maintain support for DNSSEC validation in the base system.
If this
can be accomplished by keeping DNS debugging tools and the
lightweight
resolver in the base, then I'm fine with that world view. However,
if we
can't do DNSSEC record validation without installing the BIND
package, then
that worries me.
Unfortunately this answer is more complicated than I'd like it to
be. In
general, DNS resolution requires 4 components (and yes, this is pretty
well simplified, but I think the illustration serves to clarify my
point):
1. An end-user application that makes a request
2. A stub resolver located on the local system
3. A resolving name server
4. An authoritative name server
At this time the DNSSEC protocol only clearly addresses the behavior
of
4, and partially addresses the behavior of 3. There is no protocol
specification for 1 or 2. So in general if you want to be able to
validate DNSSEC signatures on the local system the only option
available
to you is to run a local validating resolver. It doesn't have to be
BIND, unbound is also a good candidate, but you have to run something
locally to be sure that the response(s) you've received are valid.
Now that said, if you have a special purpose in mind to validate
records
in a specific domain (or specific few domains) for which you are
prepared to individually manage trust anchors (the generic term of art
for DNSSEC keys) then you could do that using dig alone. However that
solution would not scale well, and I wouldn't recommend it for a
critical piece of the base or ports.
As we go forward, DNSSEC is going to become increasingly important,
and being
unable to bootstrap a system will be a problem, and it will become an
increasingly critical part of the security bootstrap process for
networked
systems.
Since your description above is generic, I will generically agree with
you. :) I think as time goes on and more intelligence about DNSSEC is
pushed to the edges I think it will be possible to have a validating
stub resolver, and on a trusted network reasonable to rely on an
external validating resolving name server. However there's an awful
lot
of supposition there, and as I said above, the spec doesn't even exist
yet, never mind the code.
While some DNSSEC folk consider it anathema ("DNS is not a directory
service!"), the ability to securely distribute keying material via
an existing
network service has enourmous value: for example, early DNSSEC
prototypes in
the late 1990's/early 2000's included SSH key distribution via cert
records in
DNSSEC.
The CERT record still exists, although not for ssh. See
Re: Results of BIND RFC
On Fri, 2 Apr 2010, Doug Barton wrote: > So first of all, yes Virginia, this was an April Fool's Day joke. To > both those for whom this post created a false sense of despair, and > (perhaps more importantly) to those for whom it created a false sense of > joy, my apologies. :) And for the record, everything from here on is > "just the facts." You're a proper bastard, Doug - in the strictly affectionate Aussie sense of the term. Talk about stirring the possum! Had me fired up to figure out how to add a choice menu to sysinstall .. Good to hear the DNSSEC stuff is coming along, however ponderously. KUTGW, Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
On Fri, Apr 2, 2010 at 3:08 PM, Freddie Cash wrote: > Maybe I'm just a lowly sysadmin and ex-port maintainer, but ... > > No, no, no, definitely no, no, and no!! > > The greatest thing about FreeBSD is that there is a clear separation > between > the "base OS" and everything else (ports, local installs, etc). You get a > nice, clearly defined, base to build on. You get a stable base that > changes > infrequently, that you can add software to on whatever schedule you want. > > The worst thing about Linux distros is the lack of this clear separation > between the base and third-party apps. If you want to install an updated > version of Apache, you either have to update the whole damned distro, go > searching for some unsupported backports repos, or compile everything by > hand defeating the whole point of binary packages. > > Making the tools do deal with the base could be interesting, but please, > please, please don't shove everything into the pkg_tools and turning > FreeBSD > into "just a random collection of packages that kind of work together". > IOW, don't go down the distro path. > > Keep the base OS separate from third-party apps. Keep the tools to deal > with them separate. > True word, brother! If we wanted to run linux there are options for it. debs suck, rpms really suck. Those types of systems are sometimes faster to get up and rolling as long as you want vanilla apps, but they are a major PITA for many types of customizations which are a breeze with the ports tree. You'd be killing of one of the more elegant approaches in FreeBSD. Sure there are problem with it, but IMO adopting more severe problems isn't a good answer. Maybe that was a 4/1 too though. If so, good work. -- Adam Vande More ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
On Fri, Apr 2, 2010 at 3:14 AM, Jeremy Chadwick wrote: > [1]: FreeBSD really needs to move away from the "base system" as a > concept, as I've ranted about in the past. Or if it cannot, the "base > system" needs to start using pkg_* (somehow) for use, and src.conf > WITHOUT_xxx (where xxx = some software) removed. Concept being: "I > don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; > pkg_delete base-lib32". Beautiful concept, hard to implement due to > libraries being yanked out from underneathe binaries that are linked to > them. But you get the idea. > Maybe I'm just a lowly sysadmin and ex-port maintainer, but ... No, no, no, definitely no, no, and no!! The greatest thing about FreeBSD is that there is a clear separation between the "base OS" and everything else (ports, local installs, etc). You get a nice, clearly defined, base to build on. You get a stable base that changes infrequently, that you can add software to on whatever schedule you want. The worst thing about Linux distros is the lack of this clear separation between the base and third-party apps. If you want to install an updated version of Apache, you either have to update the whole damned distro, go searching for some unsupported backports repos, or compile everything by hand defeating the whole point of binary packages. Making the tools do deal with the base could be interesting, but please, please, please don't shove everything into the pkg_tools and turning FreeBSD into "just a random collection of packages that kind of work together". IOW, don't go down the distro path. Keep the base OS separate from third-party apps. Keep the tools to deal with them separate. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
Can we do sendmail next April 1? Sent from a device with a tiny keyboard On Apr 2, 2010, at 1:22 PM, "Reko Turja" wrote: Based on the inspection of the source tree, I want my bikeshed mauve. I've not been had by AFD jokes in a while but Doug pulled this one off... -Reko ___ freebsd-sta...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org " ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
On 2 April 2010, at 04:27, Denny Lin wrote: > On Fri, Apr 02, 2010 at 10:11:50AM +0400, Andrey V. Elsukov wrote: >> On 02.04.2010 9:24, Stanislav Sedov wrote: >>> While it certainly might make sense to drop BIND out of the base, I'm not >>> sure dropping bind tools as well from it is the best decision. How hard >>> it will be to continue maintaining bind tools inside the base (so the >>> critical ones like dig and nslookup still will be available), while moving >>> the rest of it (the server itself and supporting tools) to the port? >> >> Hi, All. >> >> I'm agree with Stas. If it is not so hard to maintain "bind-tools" in the >> base, >> It is very useful to still having them in base system. > > +1 here. Dig and some of the other tools are extremely useful and > important, so it would be nice if they were in the base system instead > of a separate port. The reason dig and nslookup are used is because you have a problem with the internet connection. Thats a bit late to say "you need to install the DNS tools". If you could, you wouldn't need them. Not everyone will create a ports CD. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
So first of all, yes Virginia, this was an April Fool's Day joke. To
both those for whom this post created a false sense of despair, and
(perhaps more importantly) to those for whom it created a false sense of
joy, my apologies. :) And for the record, everything from here on is
"just the facts."
I have always said that I will remove BIND from the base when there is
clear community consensus to do so, and I stand by that. However the
discussion always seems to go along the lines that this thread did. A
vocal group who say, "YES!" and then a lot of people who want the
resolution tools (dig, host, nslookup) to stay, and the other end of the
bell-shaped curve with those who like having the whole thing in the
base. Toss in a few choruses of "The whole base should be more modular,"
(a viewpoint with which I have a great deal of sympathy btw) and the
soup is pretty well complete.
In regard to the tools issue, the problem is that you need a pretty good
majority of the code in order to build them. They require the libraries
to be built, and once you've done that, you might as well do the rest. :)
Total size of code in:
contrib/bind9: 14.0M
contrib/bind9/lib: 7.6M
contrib/bind9/bin: 2.5M
contrib/bind9/bin/dig: 0.4M
The last is the directory that has the code for all 3 resolution tools,
FYI.
Therefore I think that the status quo of having it all in there, and
knobs to turn off the bits you don't want is a good one since it seems
to please the majority of our users. I will continue to maintain the
bind-tools port though, that's something that's been requested often,
and I think it's a good thing to have for those who want a different DNS
solution but still want access to those tools in a fairly painless
manner. And of course the ability to easily change/upgrade/manage what
version of BIND you use via the ports will continue to be a key
component of how we deal with this going forward.
Of course, the release synchronization problems I described in both the
original post and the AFD post are real, so stay tuned. :)
Answers to DNSSEC concerns below.
On 4/2/2010 3:52 AM, Robert Watson wrote:
> With an eye on the date of Doug's suggestive e-mail, I actually am concerned
> that we maintain support for DNSSEC validation in the base system. If this
> can be accomplished by keeping DNS debugging tools and the lightweight
> resolver in the base, then I'm fine with that world view. However, if we
> can't do DNSSEC record validation without installing the BIND package, then
> that worries me.
Unfortunately this answer is more complicated than I'd like it to be. In
general, DNS resolution requires 4 components (and yes, this is pretty
well simplified, but I think the illustration serves to clarify my point):
1. An end-user application that makes a request
2. A stub resolver located on the local system
3. A resolving name server
4. An authoritative name server
At this time the DNSSEC protocol only clearly addresses the behavior of
4, and partially addresses the behavior of 3. There is no protocol
specification for 1 or 2. So in general if you want to be able to
validate DNSSEC signatures on the local system the only option available
to you is to run a local validating resolver. It doesn't have to be
BIND, unbound is also a good candidate, but you have to run something
locally to be sure that the response(s) you've received are valid.
Now that said, if you have a special purpose in mind to validate records
in a specific domain (or specific few domains) for which you are
prepared to individually manage trust anchors (the generic term of art
for DNSSEC keys) then you could do that using dig alone. However that
solution would not scale well, and I wouldn't recommend it for a
critical piece of the base or ports.
> As we go forward, DNSSEC is going to become increasingly important, and being
> unable to bootstrap a system will be a problem, and it will become an
> increasingly critical part of the security bootstrap process for networked
> systems.
Since your description above is generic, I will generically agree with
you. :) I think as time goes on and more intelligence about DNSSEC is
pushed to the edges I think it will be possible to have a validating
stub resolver, and on a trusted network reasonable to rely on an
external validating resolving name server. However there's an awful lot
of supposition there, and as I said above, the spec doesn't even exist
yet, never mind the code.
> While some DNSSEC folk consider it anathema ("DNS is not a directory
> service!"), the ability to securely distribute keying material via an
> existing
> network service has enourmous value: for example, early DNSSEC prototypes in
> the late 1990's/early 2000's included SSH key distribution via cert records
> in
> DNSSEC.
The CERT record still exists, although not for ssh. See
http://tools.ietf.org/html/rfc4398. For ssh fingerprints there is the
SSH
Re: Results of BIND RFC
On Fri, 2 Apr 2010, Kevin Oberman wrote: Date: Fri, 2 Apr 2010 03:14:54 -0700 From: Jeremy Chadwick Sender: owner-freebsd-sta...@freebsd.org I disagree (so what else is new?) It should be kept out of the base system. KISS: Doug pulling BIND out of the base system / going ports-only = excellent. Doug making a separate port for BIND-esque DNS query/maintenance tools = excellent. Both of the above can be made into packages. Vendors who use FreeBSD can incorporate said package(s) into their build infrastructure. Folks who do not have Internet connections (yet for some reason want said DNS tools) can install the package(s) from CD/DVD/USB. I want the bikeshed to be black. :-) I have very mixed feelings on this. I agree with arguments I have seen on both sides. I like being able to install FreeBSD and have a well integrated system with all of the basic tools installed for basic use. Things play together well. I don't use many of the base system tools. I use cups, postfix, customized ssh, and the ports version of BIND. I don't build the stuff I don't need (src.conf) and I don't mind them being there. On the other hand, for complex, heavy duty ports, keeping up to date with externally maintains tools (contrib) is a pain and the base system can get stuck with rather out of date tools as a result. (Remember perl?) Unless there is very strong support for a contributed tools, it's hopeless and, if the tool is evolving rapidly, as BIND is with DNSSEC, it's still hopeless. I really dread having to update my ports. I hate all the bloated dependencies that a lot of ports have. It's sometimes a hit or miss situtation; you never know whether your ports are going to build (update) fully or not. And it takes forever. Our ports team does a fantastic job, so no diss intended. But I am concerned about moving BIND into ports, even if there is a tools-only port. With BIND in base, I don't have to worry about updating or when to update - someone else decides when to update/patch the base BIND and I am happy with that. All I have to do is buildworld, which I do much more often than update ports. If there is already a WITHOUT_BIND knob, then I really don't see what advantage there is in moving BIND out of base. Anyone that wants to use a different resolver can already do that, with the only limitation that they have to buildworld to remove the base bind. -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
Based on the inspection of the source tree, I want my bikeshed mauve. I've not been had by AFD jokes in a while but Doug pulled this one off... -Reko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
> Date: Fri, 2 Apr 2010 03:14:54 -0700 > From: Jeremy Chadwick > Sender: owner-freebsd-sta...@freebsd.org > > On Fri, Apr 02, 2010 at 09:24:51AM +, Poul-Henning Kamp wrote: > > In message <20100402021715.669838e0.s...@freebsd.org>, Stanislav Sedov > > writes: > > >On Fri, 02 Apr 2010 08:55:07 + > > >"Poul-Henning Kamp" mentioned: > > > > >Sorry, I think I was not clear enough. > > > > Sorry for misunderstanding. > > > > Yes, the case can certainly be made that DNS query tool belongs in the > > base system. > > I disagree (so what else is new?) It should be kept out of the base > system. KISS: > > Doug pulling BIND out of the base system / going ports-only = excellent. > > Doug making a separate port for BIND-esque DNS query/maintenance tools = > excellent. > > Both of the above can be made into packages. Vendors who use FreeBSD > can incorporate said package(s) into their build infrastructure. Folks > who do not have Internet connections (yet for some reason want said DNS > tools) can install the package(s) from CD/DVD/USB. > > I want the bikeshed to be black. :-) I have very mixed feelings on this. I agree with arguments I have seen on both sides. I like being able to install FreeBSD and have a well integrated system with all of the basic tools installed for basic use. Things play together well. I don't use many of the base system tools. I use cups, postfix, customized ssh, and the ports version of BIND. I don't build the stuff I don't need (src.conf) and I don't mind them being there. On the other hand, for complex, heavy duty ports, keeping up to date with externally maintains tools (contrib) is a pain and the base system can get stuck with rather out of date tools as a result. (Remember perl?) Unless there is very strong support for a contributed tools, it's hopeless and, if the tool is evolving rapidly, as BIND is with DNSSEC, it's still hopeless. I have seen suggestions that some tools be kept in the base system. nslookup (an evil tool that I think should be put out of its misery) and dig (a good tool that not enough people understand how to use) have been explicitly mentioned. The problem is that dig needs to be in reasonable feature sync with the resolver or it can have problems. Finally, what about a stub resolver? This really MUST be in the base system and, it should understand DNSSEC soon, which just complicates things. I prefer my bikeshed in green. Black is too goth and too hot for my tastes. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
On Fri, Apr 02, 2010 at 12:28:36PM +0200, sth...@nethelp.no wrote: > > [1]: FreeBSD really needs to move away from the "base system" as a > > concept, as I've ranted about in the past. > > Strongly disagree. I'm with you! > > > Or if it cannot, the "base > > system" needs to start using pkg_* (somehow) for use, and src.conf > > WITHOUT_xxx (where xxx = some software) removed. Concept being: "I > > don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; > > pkg_delete base-lib32". Beautiful concept, hard to implement due to > > libraries being yanked out from underneathe binaries that are linked to > > them. But you get the idea. > > This *might* be workable. However, in general - a large part of the > reason why I use FreeBSD is that the FreeBSD base system gives me > most of what I want, in *one* well defined chunk, *without* having > to install a zillion extra packages, and without umpteen different > versions of config files and locations for the important information. > Also, more than that, won't splitting the "base system" in many smaller pieces moving around by themselves make every single part of freeBSD a moving target? What I mean is that what may look like a way to simplify things could make matters worse with incompatibilities in between the base packages. having everythign in the base system guarantees much more control. I'm also thinking about the nightmares this kind of splitting could cause to release engineering. This is not pure speculation. Such problems do appear in many other known open source OSes with such a split base system. In fact, if I wanted such a thing I'd install that other open source OS. I did in fact, and observed many annoying things about not having a rich base system like ours(like wasting time figuring which packet contained commands I'm used to see in the base system on any unix. > So please don't destroy this. I hope not. Another good reason not to destroy this is again that there are already many alternative OSes doing it, and I think FreebSD has a strong point in being different, not a weak spot. -- Guido Falsi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
On Fri, Apr 02, 2010 at 10:11:50AM +0400, Andrey V. Elsukov wrote: > On 02.04.2010 9:24, Stanislav Sedov wrote: > >While it certainly might make sense to drop BIND out of the base, I'm not > >sure dropping bind tools as well from it is the best decision. How hard > >it will be to continue maintaining bind tools inside the base (so the > >critical ones like dig and nslookup still will be available), while moving > >the rest of it (the server itself and supporting tools) to the port? > > Hi, All. > > I'm agree with Stas. If it is not so hard to maintain "bind-tools" in the > base, > It is very useful to still having them in base system. +1 here. Dig and some of the other tools are extremely useful and important, so it would be nice if they were in the base system instead of a separate port. -- Denny Lin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
On Fri, Apr 02, 2010 at 09:24:51AM +, Poul-Henning Kamp wrote: > In message <20100402021715.669838e0.s...@freebsd.org>, Stanislav Sedov writes: > >On Fri, 02 Apr 2010 08:55:07 + > >"Poul-Henning Kamp" mentioned: > > >Sorry, I think I was not clear enough. > > Sorry for misunderstanding. > > Yes, the case can certainly be made that DNS query tool belongs in the > base system. I disagree (so what else is new?) It should be kept out of the base system. KISS: Doug pulling BIND out of the base system / going ports-only = excellent. Doug making a separate port for BIND-esque DNS query/maintenance tools = excellent. Both of the above can be made into packages. Vendors who use FreeBSD can incorporate said package(s) into their build infrastructure. Folks who do not have Internet connections (yet for some reason want said DNS tools) can install the package(s) from CD/DVD/USB. I want the bikeshed to be black. :-) [1]: FreeBSD really needs to move away from the "base system" as a concept, as I've ranted about in the past. Or if it cannot, the "base system" needs to start using pkg_* (somehow) for use, and src.conf WITHOUT_xxx (where xxx = some software) removed. Concept being: "I don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; pkg_delete base-lib32". Beautiful concept, hard to implement due to libraries being yanked out from underneathe binaries that are linked to them. But you get the idea. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
Strongly disagree. Or if it cannot, the "base system" needs to start using pkg_* (somehow) for use, and src.conf WITHOUT_xxx (where xxx = some software) removed. Concept being: "I don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; pkg_delete base-lib32". Beautiful concept, hard to implement due to libraries being yanked out from underneathe binaries that are linked to them. But you get the idea. This *might* be workable. However, in general - a large part of the reason why I use FreeBSD is that the FreeBSD base system gives me most of what I want, in *one* well defined chunk, *without* having to install a zillion extra packages, and without umpteen different versions of config files and locations for the important information. me +1 If I wanted to go Gnu/BSD (or Loonix) route, I'd already installed either thank you. Funny though that BIND which is pretty straightforward as configuration goes and as much essential system component as Sendmail is getting the axe. I thought one of the main philosophies in FreeBSD always was being a system in itself, rather than kernel with some haphazardly thrown in components added. -Reko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
On Fri, Apr 02, 2010 at 03:14:54AM -0700, Jeremy Chadwick wrote: > > [1]: FreeBSD really needs to move away from the "base system" as a > concept, as I've ranted about in the past. Or if it cannot, the "base > system" needs to start using pkg_* (somehow) No, it does not need to do that. It might be a good idea (but I am far from convinced of it), but there most certainly is no *need* to move in that direction. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
> [1]: FreeBSD really needs to move away from the "base system" as a > concept, as I've ranted about in the past. Strongly disagree. > Or if it cannot, the "base > system" needs to start using pkg_* (somehow) for use, and src.conf > WITHOUT_xxx (where xxx = some software) removed. Concept being: "I > don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; > pkg_delete base-lib32". Beautiful concept, hard to implement due to > libraries being yanked out from underneathe binaries that are linked to > them. But you get the idea. This *might* be workable. However, in general - a large part of the reason why I use FreeBSD is that the FreeBSD base system gives me most of what I want, in *one* well defined chunk, *without* having to install a zillion extra packages, and without umpteen different versions of config files and locations for the important information. So please don't destroy this. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
On Fri, 2 Apr 2010, Poul-Henning Kamp wrote:
The result of the RFC was that bind is not a mandatory component to make "a
usable system", so you argument suffers from bad logic.
With an eye on the date of Doug's suggestive e-mail, I actually am concerned
that we maintain support for DNSSEC validation in the base system. If this
can be accomplished by keeping DNS debugging tools and the lightweight
resolver in the base, then I'm fine with that world view. However, if we
can't do DNSSEC record validation without installing the BIND package, then
that worries me.
As we go forward, DNSSEC is going to become increasingly important, and being
unable to bootstrap a system will be a problem, and it will become an
increasingly critical part of the security bootstrap process for networked
systems. While some DNSSEC folk consider it anathema ("DNS is not a directory
service!"), the ability to securely distribute keying material via an existing
network service has enourmous value: for example, early DNSSEC prototypes in
the late 1990's/early 2000's included SSH key distribution via cert records in
DNSSEC. Similarly, as proposals to tie DHCP security and mobility security to
DNSSEC expand, any decision to require a package to do DNSSEC would mean any
component depending on that also has to be outside our base.
If all requirements along these lines are met by the lightweight resolver,
then this is less of a concern.
Robert
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
In message <20100402021715.669838e0.s...@freebsd.org>, Stanislav Sedov writes: >On Fri, 02 Apr 2010 08:55:07 + >"Poul-Henning Kamp" mentioned: >Sorry, I think I was not clear enough. Sorry for misunderstanding. Yes, the case can certainly be made that DNS query tool belongs in the base system. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
On Fri, 02 Apr 2010 08:55:07 + "Poul-Henning Kamp" mentioned: > In message <20100402013353.f544e8ad.s...@freebsd.org>, Stanislav Sedov writes: > >On Fri, 02 Apr 2010 17:26:13 +0900 > >Randy Bush mentioned: > > >Ports doesn't support cross-compilation yet, > >and it would be a pity to find yourself > >bootstrapping another tiny arm platform and > >having to use ports to have a usable system. > > The result of the RFC was that bind is not a mandatory component > to make "a usable system", so you argument suffers from bad logic. > > The fact that you want BIND on your arm, is no different from > somebody else wanting postfix on a MIPS. Sorry, I think I was not clear enough. What I actually want is to have a couple of the important tools in the base while moving everything also in ports. By important tools I mean nslookup (and maybe dig), and at least the first one is cruicial for the system bringup. That one is also nice to have on the livecd, which currently includes (I believe) only the base system. -- Stanislav Sedov ST4096-RIPE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
In message <20100402013353.f544e8ad.s...@freebsd.org>, Stanislav Sedov writes: >On Fri, 02 Apr 2010 17:26:13 +0900 >Randy Bush mentioned: >Ports doesn't support cross-compilation yet, >and it would be a pity to find yourself >bootstrapping another tiny arm platform and >having to use ports to have a usable system. The result of the RFC was that bind is not a mandatory component to make "a usable system", so you argument suffers from bad logic. The fact that you want BIND on your arm, is no different from somebody else wanting postfix on a MIPS. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
On Fri, 02 Apr 2010 17:26:13 +0900 Randy Bush mentioned: > > i don't mind if dig, doc, et alia are not in base, as long as they are a > separate port from the bind hippo. > The major benefit of having them in the base is the ability to cross-compile them when building the distribution for another platform. Ports doesn't support cross-compilation yet, and it would be a pity to find yourself bootstrapping another tiny arm platform and having to use ports to have a usable system. -- Stanislav Sedov ST4096-RIPE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
> While it certainly might make sense to drop BIND out of the base, I'm not > sure dropping bind tools as well from it is the best decision. How hard > it will be to continue maintaining bind tools inside the base (so the > critical ones like dig and nslookup still will be available), while moving > the rest of it (the server itself and supporting tools) to the port? i don't mind if dig, doc, et alia are not in base, as long as they are a separate port from the bind hippo. randy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
On 02.04.2010 9:24, Stanislav Sedov wrote: While it certainly might make sense to drop BIND out of the base, I'm not sure dropping bind tools as well from it is the best decision. How hard it will be to continue maintaining bind tools inside the base (so the critical ones like dig and nslookup still will be available), while moving the rest of it (the server itself and supporting tools) to the port? Hi, All. I'm agree with Stas. If it is not so hard to maintain "bind-tools" in the base, It is very useful to still having them in base system. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
On Thu, 01 Apr 2010 15:16:59 -0700 Doug Barton mentioned: > > Of course this change will have some costs. Users of named who rely on > the current defaults will have some change management to deal with, > however the costs will be minimal. The one area that has come up > repeatedly in previous discussions about this topic is that users like > having access to the command line tools dig, host, and nslookup. To deal > with that issue I will be creating a bind-tools port so that those who > want just those tools can easily add them, without the overhead of the > rest of the BIND suite. If anyone has suggestions for other BIND tools > that should be included in the port, please let me know. Hey, Doug! While it certainly might make sense to drop BIND out of the base, I'm not sure dropping bind tools as well from it is the best decision. How hard it will be to continue maintaining bind tools inside the base (so the critical ones like dig and nslookup still will be available), while moving the rest of it (the server itself and supporting tools) to the port? -- Stanislav Sedov ST4096-RIPE pgpvEm8qc8zyJ.pgp Description: PGP signature
Re: Results of BIND RFC
On 04/01/2010 23:48, Randy Bush wrote: >> May I only hope this is legit and not a April Fool's joke :) > > actually, as an unbound user, i would be quite happy to have bind > removed. bloated, ever-buggy, config religion, ... > > randy At least I hope that this will be removed and added to the distribution as a package upon release time. -- jhell ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
> May I only hope this is legit and not a April Fool's joke :) actually, as an unbound user, i would be quite happy to have bind removed. bloated, ever-buggy, config religion, ... randy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
May I only hope this is legit and not a April Fool's joke :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Results of BIND RFC
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Greetings, SUMMARY On February 21 I sent a message to freebsd-a...@freebsd.org detailing the current state of BIND on FreeBSD, and plans for the future. You can see that message here: http://lists.freebsd.org/pipermail/freebsd-arch/2010-February/009908.html In that message I asked for feedback on my plans for dealing with BIND in the base. There wasn't much response on the lists, however I did receive a great deal of response privately, all more or less to the effect of, "Do we really need to continue having BIND in the base at all?" After careful consideration and private discussion about this issue the conclusion has been reached that the answer to this question is, "No." Therefore we will be removing BIND from the FreeBSD base. BACKGROUND "Back in the day" when the FreeBSD project started there was really only one show in the DNS town, BIND. In the last 10 years several truly viable, first-class DNS options have been developed, in both the authoritative and resolving server spaces. There are ports available for each of these options, and many FreeBSD users take advantage of them. There are of course also ports available for all supported BIND versions, as well as dns/bind9 for BIND version 9.3 which has been EOL'ed by ISC but is still in FreeBSD version 6. This also leads to the issue mentioned in the post above, the desynchronization between FreeBSD and ISC release schedules. While FreeBSD 6 is scheduled to EOL in November of this year, it contains BIND version 9.3.6-P1, which has long been EOL. There are a number of problems related to upgrading the version of BIND in a release branch of FreeBSD. Given the ease with which FreeBSD users can upgrade BIND with the ports tree, and given the characteristics of the vulnerabilities that have come to light with BIND 9.3.x to date, this hasn't been a problem. There is no guarantee that this will continue to be the case. This problem will reappear again in FreeBSD version 7 with BIND 9.4, and FreeBSD version 8 with BIND 9.6. PROS This change will have several advantages. 1) Users of all FreeBSD versions will be able to have easy access to the latest versions of BIND, and an easy upgrade path that does not involve a full OS upgrade. 2) The release synchronization problem mentioned above will no longer be a problem. 3) Users of other DNS solutions will no longer need to customize their build using the various WITH/WITHOUT_BIND* knobs. CONS Of course this change will have some costs. Users of named who rely on the current defaults will have some change management to deal with, however the costs will be minimal. The one area that has come up repeatedly in previous discussions about this topic is that users like having access to the command line tools dig, host, and nslookup. To deal with that issue I will be creating a bind-tools port so that those who want just those tools can easily add them, without the overhead of the rest of the BIND suite. If anyone has suggestions for other BIND tools that should be included in the port, please let me know. IMPLEMENTATION TIMELINE I will be removing BIND from HEAD today. Removal from the other branches will occur far enough in advance of their upcoming releases to ensure that the users have a chance to shake things out first. I'll also be committing the bind-tools and bind-config ports today so that users will continue to have easy access to the work I've done on named.conf, rc.d/named, etc. I have been maintaining BIND in the base for almost 8 years now, and while it's been challenging in a lot of ways, it's also been a great privilege to be able to help the FreeBSD community in this way. I can't say that I'll miss the drama of src updates though. :) Many happy returns of the day, Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iEYEAREDAAYFAku1G1sACgkQyIakK9Wy8PuPgQCfdrhgscMQ+KPLcoRXx66f4f6M T8wAniZqULdwM+4oRsbOkFSDZIceWn0u =Syor -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
