freebsd-stable Digest, Vol 350, Issue 7
freebsd-sta...@freebsd.org
freebsd...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
or, via email, send a message with subject or body 'help' to
freebsd-sta...@freebsd.org
You can reach the person managing the list at
freebsd-st...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-stable digest..."
Today's Topics:
1. Re: panic during work with jailed postgresql8.4 (Bjoern A. Zeeb)
2. Re: Results of BIND RFC (Jeremy Chadwick)
3. Re: panic during work with jailed postgresql8.4 (Oleg Lomaka)
4. Re: Results of BIND RFC (Guido Falsi)
5. Re: panic during work with jailed postgresql8.4 (Bjoern A. Zeeb)
6. Re: panic during work with jailed postgresql8.4 (Oleg Lomaka)
7. Re: Results of BIND RFC (Kevin Oberman)
8. Re: Results of BIND RFC (Reko Turja)
9. Re: Results of BIND RFC (Doug Hardie)
10. Re: Results of BIND RFC (Charles Sprickman)
11. Re: Results of BIND RFC (Daniel Eischen)
12. Re: Results of BIND RFC (Doug Barton)
13. Re: 6.4-RELEASE missing from mirrors (Ken Smith)
14. Re: Results of BIND RFC (Freddie Cash)
15. Re: Results of BIND RFC (Adam Vande More)
16. Re: Results of BIND RFC (Peter Jeremy)
17. Re: Results of BIND RFC (Ian Smith)
18. Re: Results of BIND RFC (Arseny Nasokin)
19. Re: Results of BIND RFC (Arseny Nasokin)
----------------------------------------------------------------------
Message: 1
Date: Fri, 2 Apr 2010 12:02:47 +0000 (UTC)
From: "Bjoern A. Zeeb" <bzeeb...@lists.zabbadoz.net>
Subject: Re: panic during work with jailed postgresql8.4
To: Oleg Lomaka <oleg....@gmail.com>
Cc: freebsd...@freebsd.org
Message-ID: <2010040212...@maildrop.int.zabbadoz.net>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Thu, 1 Apr 2010, Oleg Lomaka wrote:
Hi,
> I have a kernel panic when connect to postgresql8.4 server installed in one of jails from another jail. It's 100% reproducible.
> Also I have tried to connect from host machine to jailed pg server. That way it works fine without crash.
>
> Server configuration uses geli and zfs. Four disks encrypted using geli. And raidz2 is using ad8.eli, ad10.eli, ad12.eli, ad14.eli providers. All jails located at this raidz2 pool.
>
> Also I use ezjail for jails management. And it uses NFS to mount directories with base system.
>
> atal double fault
> rip = 0xffffffff8063510a
> rsp = 0xffffff80eaec5f50
> rbp = 0xffffff80eaec6040
> cpuid = 1; apic id = 02
> panic: double fault
> cpuid = 1
> Uptime: 7m11s
> Physical memory: 8169 MB
>
> uname -a
> FreeBSD cerberus.regredi.com 8.0-STABLE FreeBSD 8.0-STABLE #7 r206031: Thu Apr 1 13:43:57 EEST 2010 ro...@cerberus.regredi.com:/usr/obj/usr/src/sys/GENERIC amd64
>
> Link to dmesg.boot:
> http://docs.google.com/leaf?id=0B-irbkAqk9i7OGY2ZWJiODgtOWJmMy00NDQ1LTliZDctZjU3N2YwNmMxNjZl&hl=en
>
> Link to kernel core backtrace:
> http://docs.google.com/Doc?docid=0AeirbkAqk9i7ZGc5Yzc2ZndfM2M4NzYydmRw&hl=en
>
> Can I help to spot this trouble by providing additional info?
Looking at the info I doubt it's related to jails or Pg in first
place. Have you been running that same setup already before your Apr
1st, r206031, kernel? If so, from when was your last kernel?
/bz
--
Bjoern A. Zeeb It will not break if you know what you are doing.
------------------------------
Message: 2
Date: Fri, 2 Apr 2010 05:15:26 -0700
From: Jeremy Chadwick <fre...@jdc.parodius.com>
Subject: Re: Results of BIND RFC
To: "Svein Skogen (Listmail Account)" <svein-l...@stillbilde.net>
Cc: freebsd...@freebsd.org
Message-ID: <20100402121...@icarus.home.lan>
Content-Type: text/plain; charset=us-ascii
On Fri, Apr 02, 2010 at 12:44:55PM +0200, Svein Skogen (Listmail Account) wrote:
> On 02.04.2010 12:28, 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.
> >
> >> 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.
>
> With the risk of sounding like a me-too-ist: "me too!"
Since I made a bikeshed reference I don't want to continue arguing my
point -- I've said my piece, and that's that. But I'm just one man,
with one opinion (that IS in fact shared by others), but I hold high
respect for others' views despite being different from my own.
However, I want to make some things perfectly clear, because there's
some misconceptions (IMHO), addressed below. I won't respond to this
thread past this point.
> I can see the point some have in wanting to run a version from ports
> over running the base system one. This is doable in the current setup.
> However the bundled versions of bind (and the other base system
> packages) are rock stable and there for a reason.
1) In most scenarios (historically speaking), what gets updated quicker:
base or ports? Answer: ports. For **security issues only**, the base
system gets updated quickly. Of course, in some cases (depending on
the software), this requires an **entire world rebuild**. Why not just
rebuild only what's dependent upon what got fixed? "OpenSSL security
hole fixed, gotta rebuild.... uh, world?" Yes, there are sometimes
exceptions to this rule, but depending upon what the software is, world
is usually what you have to resort to.
2) What has proper infrastructure for dependencies and tracking of
installed files as part of a software package? Answer: ports. The base
system has src/ObsoluteFiles.inc which has been stated *by developers*
as "being regularly neglected" and "is a hack, not fully effective".
This is what "make delete-old" and "make delete-old-libs" uses, and
where WITHOUT_xxx comes into play. Ponder this for a while.
3) How often do you see people posting problems with key pieces of
FreeBSD infrastructure (device support/reliability or storage-related
subsystems), followed by a response from a developer stating "this has
been fixed in -STABLE" or "can you try the code from HEAD?" Answer:
often.
What all this means: change is happening much more rapidly than in the
past. The days of "I installed FreeBSD on a box and didn't touch it for
60,000 years" are long gone -- assuming you care about true reliability
and security.
> Following the "I want this slimmed down and moved to the ports/packages
> section", further, you could argue that ls, dd, and basically most of
> /usr/bin could go the same way.
Yes, and it should be, IMHO. Have you ever looked in src/contrib? A
lot of FreeBSD's software these days -- the stuff you've come to rely
upon -- is in src/contrib. Let me know if you don't use any of the
software in there. :-)
> Giving FreeBSD the same "distribution nightmare" that some of the ...
> other unix-like os'es have. Is this really where the users of the OS
> want it to go? We'll end up spending more time updating tidbits of the
> system now moved to packages, than actually using it.
Nothing *forces* you to update a package/port. If you want to run some
old crusty version of some software (maybe there's legitimate reason for
it, maybe the newer stuff is buggy), you can do this with ports. You
could do this with the base system being package-ised or port-ised like
I describe as well.
But you cannot easily do this with the base -- the instant you csup to
update base (for something else), you've now updated everything. And
it's been stated many times by developers that your supfiles should use
src-all and NOT select src-xxx pieces -- because world/kernel WILL
break during build. To this day there are still "I tried to build world
but it didn't work" "Show us your supfile" "<random src-xxx stuff
removed which the user felt they didn't need>" reports coming in.
> But why stop
> there? We could do the same to the src/sys/dev subdirectories as
> well...
That probably should happen too, *especially* for the networking and
storage subsystems, which are being constantly updated to fix bugs. Not
just improvements, but downright bugs.
Do I really need to point you to all the mails about bce(4), bge(4),
re(4), em(4), fxp(4), msk(4), ata(4), ahci(4), ZFS, blah blah blah...
Again, see my point above, re: how often people report bugs with
maintainers of these pieces telling folks to update things.
Welcome to 2010.
--
| 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 |
------------------------------
Message: 3
Date: Fri, 2 Apr 2010 15:16:05 +0300
From: Oleg Lomaka <oleg....@gmail.com>
Subject: Re: panic during work with jailed postgresql8.4
To: "Bjoern A. Zeeb" <bzeeb...@lists.zabbadoz.net>
Cc: freebsd...@freebsd.org
Message-ID: <363ECEF2-62D3-4F97...@gmail.com>
Content-Type: text/plain; charset=us-ascii
On Apr 2, 2010, at 3:02 PM, Bjoern A. Zeeb wrote:
> On Thu, 1 Apr 2010, Oleg Lomaka wrote:
>> I have a kernel panic when connect to postgresql8.4 server installed in one of jails from another jail. It's 100% reproducible.
>> Also I have tried to connect from host machine to jailed pg server. That way it works fine without crash.
>>
>> Server configuration uses geli and zfs. Four disks encrypted using geli. And raidz2 is using ad8.eli, ad10.eli, ad12.eli, ad14.eli providers. All jails located at this raidz2 pool.
>>
>> Also I use ezjail for jails management. And it uses NFS to mount directories with base system.
>>
>> atal double fault
>> rip = 0xffffffff8063510a
>> rsp = 0xffffff80eaec5f50
>> rbp = 0xffffff80eaec6040
>> cpuid = 1; apic id = 02
>> panic: double fault
>> cpuid = 1
>> Uptime: 7m11s
>> Physical memory: 8169 MB
>>
>> uname -a
>> FreeBSD cerberus.regredi.com 8.0-STABLE FreeBSD 8.0-STABLE #7 r206031: Thu Apr 1 13:43:57 EEST 2010 ro...@cerberus.regredi.com:/usr/obj/usr/src/sys/GENERIC amd64
>>
>> Link to dmesg.boot:
>> http://docs.google.com/leaf?id=0B-irbkAqk9i7OGY2ZWJiODgtOWJmMy00NDQ1LTliZDctZjU3N2YwNmMxNjZl&hl=en
>>
>> Link to kernel core backtrace:
>> http://docs.google.com/Doc?docid=0AeirbkAqk9i7ZGc5Yzc2ZndfM2M4NzYydmRw&hl=en
>>
>> Can I help to spot this trouble by providing additional info?
>
> Looking at the info I doubt it's related to jails or Pg in first
> place. Have you been running that same setup already before your Apr
> 1st, r206031, kernel? If so, from when was your last kernel?
Yes, this configuration works on another server fine (8.0-STABLE FreeBSD 8.0-STABLE #3 r205202)
Made few more tests. All tests I make using psql command (as it is 100% reproducible, may be now try spot it using telnet/netcat, without involving pg). psql accomplish login operation fine, panic appears after i run any command like \d, so I think it depends on packet size.
Current picture is:
1. When connect from host machine - works fine.
2. When I connect from other server - works fine.
3. When connect from another jail on the same box as db's jail (tried from few jails) - kernel fault.
Also tried security.jail.allow_raw_sockets on/off - nothing changes.
------------------------------
Message: 4
Date: Fri, 2 Apr 2010 14:46:34 +0200
From: Guido Falsi <m...@madpilot.net>
Subject: Re: Results of BIND RFC
To: sth...@nethelp.no
Cc: ra...@psg.com, do...@FreeBSD.org, freebsd...@FreeBSD.org,
st...@FreeBSD.org, p...@phk.freebsd.dk, freebsd...@FreeBSD.org,
freebs...@FreeBSD.org, fre...@jdc.parodius.com
Message-ID: <20100402124...@megatron.madpilot.net>
Content-Type: text/plain; charset=us-ascii
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 <m...@madpilot.net>
------------------------------
Message: 5
Date: Fri, 2 Apr 2010 13:12:40 +0000 (UTC)
From: "Bjoern A. Zeeb" <bzeeb...@lists.zabbadoz.net>
Subject: Re: panic during work with jailed postgresql8.4
To: Oleg Lomaka <oleg....@gmail.com>
Cc: freebsd...@freebsd.org
Message-ID: <2010040213...@maildrop.int.zabbadoz.net>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Fri, 2 Apr 2010, Oleg Lomaka wrote:
Hey,
>>> uname -a
>>> FreeBSD cerberus.regredi.com 8.0-STABLE FreeBSD 8.0-STABLE #7 r206031: Thu Apr 1 13:43:57 EEST 2010 ro...@cerberus.regredi.com:/usr/obj/usr/src/sys/GENERIC amd64
>>>
>>> Link to dmesg.boot:
>>> http://docs.google.com/leaf?id=0B-irbkAqk9i7OGY2ZWJiODgtOWJmMy00NDQ1LTliZDctZjU3N2YwNmMxNjZl&hl=en
>>>
>>> Link to kernel core backtrace:
>>> http://docs.google.com/Doc?docid=0AeirbkAqk9i7ZGc5Yzc2ZndfM2M4NzYydmRw&hl=en
>>>
>>> Can I help to spot this trouble by providing additional info?
>>
>> Looking at the info I doubt it's related to jails or Pg in first
>> place. Have you been running that same setup already before your Apr
>> 1st, r206031, kernel? If so, from when was your last kernel?
>
> Yes, this configuration works on another server fine (8.0-STABLE FreeBSD 8.0-STABLE #3 r205202)
>
> Made few more tests. All tests I make using psql command (as it is 100% reproducible, may be now try spot it using telnet/netcat, without involving pg). psql accomplish login operation fine, panic appears after i run any command like \d, so I think it depends on packet size.
>
> Current picture is:
> 1. When connect from host machine - works fine.
> 2. When I connect from other server - works fine.
> 3. When connect from another jail on the same box as db's jail (tried from few jails) - kernel fault.
>
> Also tried security.jail.allow_raw_sockets on/off - nothing changes.
In addition to the private mail I have just sent you, the first thing
you might try it to updat again; I hadn't realized before that your
r206031 seems to be in the middle of a multi-commit merge from two
people.
It would be worth to update to the latest stable/8 and try again
first.
/bz
--
Bjoern A. Zeeb It will not break if you know what you are doing.
------------------------------
Message: 6
Date: Fri, 2 Apr 2010 17:53:18 +0300
From: Oleg Lomaka <oleg....@gmail.com>
Subject: Re: panic during work with jailed postgresql8.4
To: "Bjoern A. Zeeb" <bzeeb...@lists.zabbadoz.net>
Cc: freebsd...@freebsd.org
Message-ID: <B5326E21-6CA2-4EFE...@gmail.com>
Content-Type: text/plain; charset=us-ascii
On Apr 2, 2010, at 4:12 PM, Bjoern A. Zeeb wrote:
> On Fri, 2 Apr 2010, Oleg Lomaka wrote:
>
>>>> uname -a
>>>> FreeBSD cerberus.regredi.com 8.0-STABLE FreeBSD 8.0-STABLE #7 r206031: Thu Apr 1 13:43:57 EEST 2010 ro...@cerberus.regredi.com:/usr/obj/usr/src/sys/GENERIC amd64
>>>>
>>>> Link to dmesg.boot:
>>>> http://docs.google.com/leaf?id=0B-irbkAqk9i7OGY2ZWJiODgtOWJmMy00NDQ1LTliZDctZjU3N2YwNmMxNjZl&hl=en
>>>>
>>>> Link to kernel core backtrace:
>>>> http://docs.google.com/Doc?docid=0AeirbkAqk9i7ZGc5Yzc2ZndfM2M4NzYydmRw&hl=en
>>>>
>>>> Can I help to spot this trouble by providing additional info?
>>>
>>> Looking at the info I doubt it's related to jails or Pg in first
>>> place. Have you been running that same setup already before your Apr
>>> 1st, r206031, kernel? If so, from when was your last kernel?
>>
>> Yes, this configuration works on another server fine (8.0-STABLE FreeBSD 8.0-STABLE #3 r205202)
>>
>> Made few more tests. All tests I make using psql command (as it is 100% reproducible, may be now try spot it using telnet/netcat, without involving pg). psql accomplish login operation fine, panic appears after i run any command like \d, so I think it depends on packet size.
>>
>> Current picture is:
>> 1. When connect from host machine - works fine.
>> 2. When I connect from other server - works fine.
>> 3. When connect from another jail on the same box as db's jail (tried from few jails) - kernel fault.
>>
>> Also tried security.jail.allow_raw_sockets on/off - nothing changes.
>
> In addition to the private mail I have just sent you, the first thing
> you might try it to updat again; I hadn't realized before that your
> r206031 seems to be in the middle of a multi-commit merge from two
> people.
>
> It would be worth to update to the latest stable/8 and try again
> first.
That's it. r206088 works fine. Thank you for help.
------------------------------
Message: 7
Date: Fri, 02 Apr 2010 09:50:02 -0700
From: "Kevin Oberman" <obe...@es.net>
Subject: Re: Results of BIND RFC
To: Jeremy Chadwick <fre...@jdc.parodius.com>
Cc: Stanislav Sedov <st...@FreeBSD.org>, Doug Barton
<do...@FreeBSD.org>, freebsd...@FreeBSD.org, Randy Bush
<ra...@psg.com>, Poul-Henning Kamp <p...@phk.freebsd.dk>,
freebsd...@FreeBSD.org, freebs...@FreeBSD.org
Message-ID: <201004021650...@ptavv.es.net>
> Date: Fri, 2 Apr 2010 03:14:54 -0700
> From: Jeremy Chadwick <fre...@jdc.parodius.com>
> Sender: owner-free...@freebsd.org
>
> On Fri, Apr 02, 2010 at 09:24:51AM +0000, Poul-Henning Kamp wrote:
> > In message <20100402021715...@FreeBSD.org>, Stanislav Sedov writes:
> > >On Fri, 02 Apr 2010 08:55:07 +0000
> > >"Poul-Henning Kamp" <p...@phk.freebsd.dk> 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: obe...@es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
------------------------------
Message: 8
Date: Fri, 2 Apr 2010 20:22:19 +0300
From: "Reko Turja" <reko....@liukuma.net>
Subject: Re: Results of BIND RFC
To: "freebsd-current+AEA-FreeBSD.ORG" <freebsd...@FreeBSD.org>
Cc: freebsd...@FreeBSD.org, freebs...@FreeBSD.org
Message-ID: <77FCD9C7615944DBBD3369EC4E5A5C94@rivendell>
Content-Type: text/plain; format=flowed; charset="utf-7";
reply-type=original
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
------------------------------
Message: 9
Date: Fri, 2 Apr 2010 10:39:53 -0700
From: Doug Hardie <bc...@lafn.org>
Subject: Re: Results of BIND RFC
To: FreeBSD Current <freebsd...@freebsd.org>, FreeBSD-STABLE
Mailing List <freebsd...@freebsd.org>, freebs...@freebsd.org
Message-ID: <6E191581-F8EB-4B85...@lafn.org>
Content-Type: text/plain; charset=us-ascii
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.
------------------------------
Message: 10
Date: Fri, 2 Apr 2010 14:08:27 -0400
From: Charles Sprickman <sp...@bway.net>
Subject: Re: Results of BIND RFC
To: Reko Turja <reko....@liukuma.net>
Cc: "freebsd-current+AEA-FreeBSD.ORG" <freebsd...@FreeBSD.org>,
"freebsd...@FreeBSD.org" <freebsd...@FreeBSD.org>,
"freebs...@FreeBSD.org" <freebs...@FreeBSD.org>
Message-ID: <2972DD89-7D7D-4869...@bway.net>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
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" <reko....@liukuma.net> 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...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org
> "
------------------------------
Message: 11
Date: Fri, 2 Apr 2010 14:29:26 -0400 (EDT)
From: Daniel Eischen <deis...@freebsd.org>
Subject: Re: Results of BIND RFC
To: Kevin Oberman <obe...@es.net>
Cc: Randy Bush <ra...@psg.com>, Doug Barton <do...@freebsd.org>,
freebsd...@freebsd.org, Stanislav Sedov <st...@freebsd.org>,
Poul-Henning Kamp <p...@phk.freebsd.dk>, freebsd...@freebsd.org,
freebs...@freebsd.org, Jeremy Chadwick <fre...@jdc.parodius.com>
Message-ID: <Pine.GSO.4.64.10...@sea.ntplx.net>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Fri, 2 Apr 2010, Kevin Oberman wrote:
>> Date: Fri, 2 Apr 2010 03:14:54 -0700
>> From: Jeremy Chadwick <fre...@jdc.parodius.com>
>> Sender: owner-free...@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
------------------------------
Message: 12
Date: Fri, 02 Apr 2010 12:07:52 -0700
From: Doug Barton <do...@FreeBSD.org>
Subject: Re: Results of BIND RFC
To: freebsd...@FreeBSD.org, freebsd...@FreeBSD.org,
freebs...@FreeBSD.org
Message-ID: <4BB64088...@FreeBSD.org>
Content-Type: text/plain; charset=ISO-8859-1
-----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
SSHFP record, http://tools.ietf.org/html/rfc4255. And there are always
TXT records. :)
Now all THAT said, there is an element of DNSSEC that I am rather
strongly leaning toward putting in the ports, trust anchor
configuration. Currently you have essentially 2 choices for DNSSEC
validation, manually configure trust anchors, or use a DNS Lookaside
Validation (DLV) service, of which the most popular is ISC's. Both
options have their benefits and their drawbacks, which are outside the
scope of this post. OTOH, if things continue going according to plan the
root zone will be signed with real DNSSEC keys in July. That will make
it possible to do "regular" DNSSEC validation for those zones that are
signed from the root down by only configuring one trust anchor, the root
zone key. (If you need to validate something on a "secure island," i.e.,
one or more parent zones is not signed, you are back to the first 2
choices, but once again, out of scope.)
In the ideal world the root zone trust anchor would function like the
root.hints file does now. It is stable (not updated often) and failure
to update it in a timely manner would not be catastrophic.
Unfortunately, the first is not guaranteed, and the latter is the
opposite of the truth. There has already been on incident where an OS
distribution had shipped with trust anchors manually configured and when
they became outdated hilarity ensued. I would like to avoid that for our
users.
At this time my plan is to add hooks for "easy" incorporation of DNSSEC
validation into the base named.conf, with instructions for how to
install the port/package, the importance of keeping it up to date, etc.
Before I make any changes I'll be seeking input from experts in the
DNSSEC community and posting something a little more focused on -arch at
least. If the release engineer or security officer teams have
"something" in mind for FreeBSD that will require DNSSEC, we'll have to
coordinate efforts on this, but I don't imagine it will be too difficult
even with a bind-dnssec-config port.
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-----
------------------------------
Message: 13
Date: Fri, 02 Apr 2010 15:08:16 -0400
From: Ken Smith <kens...@buffalo.edu>
Subject: Re: 6.4-RELEASE missing from mirrors
To: David Boyd <David...@insightbb.com>
Cc: freebsd...@freebsd.org
Message-ID: <1270235296.6...@bauer.cse.buffalo.edu>
Content-Type: text/plain; charset="us-ascii"
On Thu, 2010-04-01 at 11:07 -0400, David Boyd wrote:
> The link (actually file) called "6.4 moved to ftp-archive" is missing from
> most/all mirrors.
>
> We have been using these files to "follow" the releases when they move.
>
> It works as long as the "6.4 moved to ftp-archive" file is present.
>
> Please help.
>
> Thanks.
>
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"
>
>
Sorry about that, it should be fixed on ftp-master now and will
propagate out to the mirrors as they do their next sync.
--
Ken Smith
- From there to here, from here to | kens...@buffalo.edu
there, funny things are everywhere. |
- Theodore Geisel |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100402/c93f4b38/attachment-0001.pgp
------------------------------
Message: 14
Date: Fri, 2 Apr 2010 14:08:24 -0700
From: Freddie Cash <fjw...@gmail.com>
Subject: Re: Results of BIND RFC
To: freebsd...@freebsd.org, freebsd...@freebsd.org,
freebs...@freebsd.org
Message-ID:
<j2hb269bc571004021408ga...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Fri, Apr 2, 2010 at 3:14 AM, Jeremy Chadwick <fre...@jdc.parodius.com>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
fjw...@gmail.com
------------------------------
Message: 15
Date: Fri, 2 Apr 2010 15:49:54 -0600
From: Adam Vande More <amvan...@gmail.com>
Subject: Re: Results of BIND RFC
To: Freddie Cash <fjw...@gmail.com>
Cc: freebsd...@freebsd.org, freebsd...@freebsd.org,
freebs...@freebsd.org
Message-ID:
<g2s6201873e1004021449re...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Apr 2, 2010 at 3:08 PM, Freddie Cash <fjw...@gmail.com> 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
------------------------------
Message: 16
Date: Sat, 3 Apr 2010 09:32:02 +1100
From: Peter Jeremy <peter...@acm.org>
Subject: Re: Results of BIND RFC
To: Jeremy Chadwick <fre...@jdc.parodius.com>
Cc: freebsd...@freebsd.org, freebs...@freebsd.org
Message-ID: <20100402223...@server.vk2pj.dyndns.org>
Content-Type: text/plain; charset="us-ascii"
Firstly, congratualtions to doubg@.
On 2010-Apr-02 05:15:26 -0700, Jeremy Chadwick <fre...@jdc.parodius.com> wrote:
>1) In most scenarios (historically speaking), what gets updated quicker:
>base or ports? Answer: ports.
In some ways this is a problem. On the downside, it means that a
-RELEASE will never have bleeding edge features. On the upside, it
means that a -RELEASE will never have bleeding edge bugs.
>2) What has proper infrastructure for dependencies and tracking of
>installed files as part of a software package? Answer: ports.
I agree that this is a deficiency in the base system. I have often
wished that there was some way of tracking exactly what part of
installworld had installed what file - but I accept that this is
a "difficult" problem. It might be useful if there was a target as
part of install{world,kernel} that built a mtree database of what
was installed.
>3) How often do you see people posting problems with key pieces of
>FreeBSD infrastructure (device support/reliability or storage-related
>subsystems), followed by a response from a developer stating "this has
>been fixed in -STABLE" or "can you try the code from HEAD?" Answer:
>often.
That's true of any non-trivial piece of software that has distinct
"developer" and "end-user" branches. Moving to ports won't really
resolve the problem - the answer will still be "you need to update
to a newer version of that code".
Whilst I'd occasionally like to see less "bloat" (ie anything that I
don't use) in base, there is one significant benefit that I don't
recall seeing discussed in this thread - integration testing. The
base system it built and tested as a whole. This isn't practical for
the ports system. Without the integration testing, you wind up in the
situation where port A and port B work in isolation but don't work
together - the port A maintainer says that the problem is port B and
the port B maintainer says that port A is relying on an optional part
of port B that they don't have the time/interest/expertise to
maintain.
--
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100402/3145dcaa/attachment-0001.pgp
------------------------------
Message: 17
Date: Sat, 3 Apr 2010 14:57:18 +1100 (EST)
From: Ian Smith <smi...@nimnet.asn.au>
Subject: Re: Results of BIND RFC
To: Doug Barton <do...@freebsd.org>
Cc: freebsd...@freebsd.org, freebsd...@freebsd.org,
freebs...@freebsd.org
Message-ID: <2010040314...@sola.nimnet.asn.au>
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
------------------------------
Message: 18
Date: Sat, 3 Apr 2010 10:54:44 +0400
From: Arseny Nasokin <eir...@gmail.com>
Subject: Re: Results of BIND RFC
To: Doug Barton <do...@FreeBSD.org>
Cc: "freebsd...@FreeBSD.org" <freebsd...@FreeBSD.org>,
"freebsd...@FreeBSD.org" <freebsd...@FreeBSD.org>,
"freebs...@FreeBSD.org" <freebs...@FreeBSD.org>
Message-ID: <741A5195-385B-42A1...@gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
On 2 Apr 2010, at 23:07, Doug Barton <do...@FreeBSD.org> 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...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-curre...@freebsd.org
> "
------------------------------
Message: 19
Date: Sat, 3 Apr 2010 10:42:40 +0400
From: Arseny Nasokin <eir...@gmail.com>
Subject: Re: Results of BIND RFC
To: Doug Barton <do...@FreeBSD.org>
Cc: "freebsd...@FreeBSD.org" <freebsd...@FreeBSD.org>,
"freebsd...@FreeBSD.org" <freebsd...@FreeBSD.org>,
"freebs...@FreeBSD.org" <freebs...@FreeBSD.org>
Message-ID: <22D22D6D-8976-4EBD...@gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
On 2 Apr 2010, at 23:07, Doug Barton <do...@FreeBSD.org> 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
> http://tools.ietf.org/html/rfc4398. For ssh fingerprints there is the
> SSHFP record, http://tools.ietf.org/html/rfc4255. And there are always
> TXT records. :)
>
> Now all THAT said, there is an element of DNSSEC that I am rather
> strongly leaning toward putting in the ports, trust anchor
> configuration. Currently you have essentially 2 choices for DNSSEC
> validation, manually configure trust anchors, or use a DNS Lookaside
> Validation (DLV) service, of which the most popular is ISC's. Both
> options have their benefits and their drawbacks, which are outside the
> scope of this post. OTOH, if things continue going according to plan
> the
> root zone will be signed with real DNSSEC keys in July. That will make
> it possible to do "regular" DNSSEC validation for those zones that are
> signed from the root down by only configuring one trust anchor, the
> root
> zone key. (If you need to validate something on a "secure island,"
> i.e.,
> one or more parent zones is not signed, you are back to the first 2
> choices, but once again, out of scope.)
>
> In the ideal world the root zone trust anchor would function like the
> root.hints file does now. It is stable (not updated often) and failure
> to update it in a timely manner would not be catastrophic.
> Unfortunately, the first is not guaranteed, and the latter is the
> opposite of the truth. There has already been on incident where an OS
> distribution had shipped with trust anchors manually configured and
> when
> they became outdated hilarity ensued. I would like to avoid that for
> our
> users.
>
> At this time my plan is to add hooks for "easy" incorporation of
> DNSSEC
> validation into the base named.conf, with instructions for how to
> install the port/package, the importance of keeping it up to date,
> etc.
> Before I make any changes I'll be seeking input from experts in the
> DNSSEC community and posting something a little more focused on -
> arch at
> least. If the release engineer or security officer teams have
> "something" in mind for FreeBSD that will require DNSSEC, we'll have
> to
> coordinate efforts on this, but I don't imagine it will be too
> difficult
> even with a bind-dnssec-config port.
>
>
> 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...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-curre...@freebsd.org
> "
------------------------------
End of freebsd-stable Digest, Vol 350, Issue 7
**********************************************