In fact, the ONLY reason that the name "bind9" was ever even coined
at all was because the changes from bind8 both in the syntax of the
config file and how the program operated they wanted to boot admins
in the behind to get them to change their config files. It should
have been put to bed as a name a long time ago, or named "bind
version 9" like every other software program does with their versions.
On 17 Jul 2020, at 11:56, Ted Mittelstaedt <tedm@ipinc.net> wrote:
In fact, the ONLY reason that the name "bind9" was ever even coined
at all was because the changes from bind8 both in the syntax of the
config file and how the program operated they wanted to boot admins
in the behind to get them to change their config files.
This. Exactly this.
And for what it's worth, not all systems moved away from "named" to
"bind9". I've been running FreeBSD for decades, and I can't remember
ever calling the service "bind9".
On 21 Jul 2020, at 03:45, Ted Mittelstaedt <tedm@ipinc.net> wrote:
On 7/17/2020 11:35 AM, John W. Blue wrote:There where lots of things happening at the time. There was misinformation propagated to *BSD that BIND 9 going away much faster that any plans we had. BIND 10 (now defunct) hadn’t even reached feature parity with BIND 9 which was still being developed because the DNS protocol is still be developed.
Speaking about things to be annoyed over ..
I am still ticked that FreeBSD dropped BIND from the distribution for something called unwinding or whatever it is.
I'm not happy that happened either but the simple fact is that if BIND would quit dropping support so fast for it's older versions that never would have happened. The fundamental problem was that BIND dropped support for it's older versions before the distros dropped support for their distros. This is happening with a lot of other software packages.
When FreeBSD was used mostly for servers it wasn't a problem. But more
and more people are using it for desktop use where they want to basically install it and forget about it, never run patches, never give
a fig about security. Simpler programs like Unbound have less code
and so less things to go wrong, need less patches, and are easier to
support for a longer period of time so they get supported for a longer
period of time. Also, Unbound's main purpose in life is as a caching
dns program. Nobody who runs a server on FreeBSD uses Unbound.
Ted
John_______________________________________________
-----Original Message-----
From: bind-users [mailto:bind-users-bounces@lists.isc.org] On Behalf Of Ted Mittelstaedt
Sent: Friday, July 17, 2020 12:57 PM
To: bind-users@lists.isc.org
Subject: Re: AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?
Your personal experience is not the gobal truth. It is your opinion but other experienced pepole see it different than you.
Hmm I'm a bit late to this discussion but I will chime in with the others. The service always was called "named" pronounced "name Dee"
it was called that in the Nutshell book which is easily the authoritative book on the subject, it was called this before you were born and it was kind of the height of hubris for it to ever be named
bind9 in a software distro.
In fact, the ONLY reason that the name "bind9" was ever even coined at all was because the changes from bind8 both in the syntax of the config file and how the program operated they wanted to boot admins in the behind to get them to change their config files. It should have been put to bed as a name a long time ago, or named "bind version 9" like every other software program does with their versions.
So as an experienced person who has been doing this you-nuxs thing since
1982 - I DON'T see it different - and in fact, I see it as a RETURN to what it originally was!
Ted
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list--
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
On 21 Jul 2020, at 09:05, Mark Andrews <marka@isc.org> wrote:
On 21 Jul 2020, at 03:45, Ted Mittelstaedt <tedm@ipinc.net> wrote:
On 7/17/2020 11:35 AM, John W. Blue wrote:
Speaking about things to be annoyed over ..
I am still ticked that FreeBSD dropped BIND from the distribution for something called unwinding or whatever it is.
I'm not happy that happened either but the simple fact is that if BIND would quit dropping support so fast for it's older versions that never would have happened. The fundamental problem was that BIND dropped support for it's older versions before the distros dropped support for their distros. This is happening with a lot of other software packages.
There where lots of things happening at the time. There was misinformation propagated to *BSD that BIND 9 going away much faster that any plans we had. BIND 10 (now defunct) hadn’t even reached feature parity with BIND 9 which was still being developed because the DNS protocol is still be developed.
As for support life times. BIND 9.17 will load most BIND 8.0 configurations. Thats 20+ years of backwards compatibility.
Distributions also need to look at their own practices. They ask us to supply long term support but do not actually integrate the maintenance releases but instead cherry-pick just the security fixes. Maintenance is not just security fixes. That means that we keep seeing bug reports that need to be diagnosed about bugs we have fixed years ago. That really isn’t a good use of peoples time. Not ours, not the distributions maintainers nor the users time. Is there little wonder that we stop producing bug fixes releases for old version when the distributions don’t use them?
When FreeBSD was used mostly for servers it wasn't a problem. But more
and more people are using it for desktop use where they want to basically install it and forget about it, never run patches, never give
a fig about security. Simpler programs like Unbound have less code
and so less things to go wrong, need less patches, and are easier to
support for a longer period of time so they get supported for a longer
period of time. Also, Unbound's main purpose in life is as a caching
dns program. Nobody who runs a server on FreeBSD uses Unbound.
Ted
John_______________________________________________
-----Original Message-----
From: bind-users [mailto:bind-users-bounces@lists.isc.org] On Behalf Of Ted Mittelstaedt
Sent: Friday, July 17, 2020 12:57 PM
To: bind-users@lists.isc.org
Subject: Re: AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?
Your personal experience is not the gobal truth. It is your opinion but other experienced pepole see it different than you.
Hmm I'm a bit late to this discussion but I will chime in with the others. The service always was called "named" pronounced "name Dee"
it was called that in the Nutshell book which is easily the authoritative book on the subject, it was called this before you were born and it was kind of the height of hubris for it to ever be named
bind9 in a software distro.
In fact, the ONLY reason that the name "bind9" was ever even coined at all was because the changes from bind8 both in the syntax of the config file and how the program operated they wanted to boot admins in the behind to get them to change their config files. It should have been put to bed as a name a long time ago, or named "bind version 9" like every other software program does with their versions.
So as an experienced person who has been doing this you-nuxs thing since >>> 1982 - I DON'T see it different - and in fact, I see it as a RETURN to what it originally was!
Ted
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list--
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
And for what it's worth, not all systems moved away from "named" toThe service is always named, the package is bind. I stopped adding the 9 many years ago unless I need to specify a specific version like "bind nine dot eleven".
"bind9". I've been running FreeBSD for decades, and I can't remember
ever calling the service "bind9".
When FreeBSD was used mostly for servers it wasn't a problem. But moreBind is a poor choice for desktop use. Packages like unbound are much better for that sort of use, and it is fr less critical if those packages have security issues.
and more people are using it for desktop use where they want to basically install it and forget about it, never run patches, never give
a fig about security.
On 7/17/2020 11:35 AM, John W. Blue wrote:
Speaking about things to be annoyed over ..
I am still ticked that FreeBSD dropped BIND from the distribution for
something called unwinding or whatever it is.
I'm not happy that happened either but the simple fact is that if BIND
would quit dropping support so fast for it's older versions that never
would have happened. The fundamental problem was that BIND dropped
support for it's older versions before the distros dropped support for
their distros. This is happening with a lot of other software packages.
When FreeBSD was used mostly for servers it wasn't a problem. But more
and more people are using it for desktop use where they want to
basically install it and forget about it, never run patches, never give
a fig about security. Simpler programs like Unbound have less code
and so less things to go wrong, need less patches, and are easier to
support for a longer period of time so they get supported for a longer
period of time. Also, Unbound's main purpose in life is as a caching
dns program. Nobody who runs a server on FreeBSD uses Unbound.
On 21 Jul 2020, at 18:23, @lbutlr <kremels@kreme.com> wrote:Anything that talks to the net is critical path from a security perspective.
On 20 Jul 2020, at 10:09, tale <d.lawrence@salesforce.com> wrote:
And for what it's worth, not all systems moved away from "named" to
"bind9". I've been running FreeBSD for decades, and I can't remember
ever calling the service "bind9".
The service is always named, the package is bind. I stopped adding the 9 many years ago unless I need to specify a specific version like "bind nine dot eleven".
On 20 Jul 2020, at 11:45, Ted Mittelstaedt <tedm@ipinc.net> wrote:
When FreeBSD was used mostly for servers it wasn't a problem. But more
and more people are using it for desktop use where they want to basically install it and forget about it, never run patches, never give
a fig about security.
Bind is a poor choice for desktop use. Packages like unbound are much better for that sort of use, and it is fr less critical if those packages have security issues.
I agree that anyone using a FreeBSD install as a server should be using bind, but I also agree it should not be the default install. You install bind when you figure out you need it, and not before.
--
Mickey and Mallory know the difference between right and wrong; the
just don't give a damn.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list--
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
On 21 Jul 2020, at 18:23, @lbutlr <kremels@kreme.com> wrote:There are different levels of critical, and unbound is a lot further down that list that bind.
Bind is a poor choice for desktop use. Packages like unbound are much better for that sort of use, and it is fr less critical if those packages have security issues.
Anything that talks to the net is critical path from a security perspective.
On 22 Jul 2020, at 08:23, @lbutlr <kremels@kreme.com> wrote:I would beg to differ. From an exposure perspective they are identical. They both ask questions onto the network and both have to parse and process those answers. They both produce similar CVSS scores, which are a much more objective way of analysis the need to pay attention to a security issues. BIND and UNBOUND both have had CVSS scores of 7.5
On 21 Jul 2020, at 06:37, Mark Andrews <marka@isc.org> wrote:
On 21 Jul 2020, at 18:23, @lbutlr <kremels@kreme.com> wrote:
Bind is a poor choice for desktop use. Packages like unbound are much better for that sort of use, and it is fr less critical if those packages have security issues.
Anything that talks to the net is critical path from a security perspective.
There are different levels of critical, and unbound is a lot further down that list that bind.
--
We are born naked, wet and hungry; then it's all downhill.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list--
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Distributions also need to look at their own practices. They ask us
to supply long term support but do not actually integrate the
maintenance releases but instead cherry-pick just the security fixes. Maintenance is not just security fixes. That means that we keep
seeing bug reports that need to be diagnosed about bugs we have fixed
years ago. That really isn’t a good use of peoples time. Not ours,
not the distributions maintainers nor the users time. Is there
little wonder that we stop producing bug fixes releases for old
version when the distributions don’t use them?
Linux is 10 times worse because they aren't even including the cEvery distribution I've laid my hands on so far has GCC packages and
compiler or development tools
anymore.
But many "systemadmins" out there think they are Unix admins
yet are afraid to compile programs. They will go to the FreeBSD port or
the Linux precompiled apt-get stuff. The reason is more and more non-technical people are getting their hands on this stuff.
On 7/23/20 6:28 AM, Ted Mittelstaedt wrote:
Linux is 10 times worse because they aren't even including the cEvery distribution I've laid my hands on so far has GCC packages and
compiler or development tools
anymore.
most development packages affixed with either -dev or -devel (most of
the time).
But many "systemadmins" out there think they are Unix admins
yet are afraid to compile programs. They will go to the FreeBSD port or
the Linux precompiled apt-get stuff. The reason is more and more
non-technical people are getting their hands on this stuff.
I don't disagree with this but I also think there's more to it than
that. For me personally I avoid compiling from source when I can get
away with it - not because I can't run make - but simply because binary packages are convenient. Having a package manager take care of updates
in the whole system is convenient. Having distribution maintainers that
say "okay we are going to go stable, bleeding edge or whatever with the
whole project" is useful when they can spend the time looking at the
upstream projects, and choose the most fitting software versions and
such to suit that goal. And when there's billions of machines running
very similar architectures, there is an argument to be made that making
every single one of them compile everything from source is rather
pointless. Why should every machine in existence be tasked with
CPU-intensive compilation workloads when a handful of dedicated
compilation servers can do exactly that, and a million times better?
Well for starters there is no way for ME to validate that the compiled software you built for me isn't busy running your Doom network server
behind my back. (do people still even run Doom servers?)
You are making an argument that is a desktop argument. That is, the argument goes Those That Know Better Will Do It For You.
Also, I have had at least 5 Open Source programs over the years that
I found Really Useful to have that the authors decided they wanted to
"take commercial" or they had other religious conversions that made them decide to go on a rampage and issue take down notices everywhere they
could find their source. One of those for example was when Nasty-Company-Who-Shall-Not-Be-Graced-With-A-Mention decided to start charging
for software that created .gif files and the graphics community went
on a ballistic rampage jihad and destroyed every scrap of .gif code it
could find so as to force users to migrate to .png. I did not wish to migrate to .png so I was very glad that I had saved all the old code,
safe from the fires of the religious zealots.
Lastly, the way I look at it is when I field a new server, if it cannot recompile it's OS, kernel, make world, and all of it's applications from source, then it's a piece of excrement that I do not want in service.
It is also a fact that I have had pre-production servers blow up on
"make worlds" In a few cases this was bad ram, in one case the server
was returned to the manufacturer under warranty. These are machines
that did not display any issues before the OS load. Do not ask me why
it was possible to install all the binaries for the OS and have it boot
with no problems yet blow chunks/blue screen/abend/take a dive into the toilet/whatever your preferred term for crashing and burning is.
I don't generally run FreeBSD or Linux as a desktop OS, BTW so that
does affect my view of things.
So yes, there is definitely an argument in favor of compiling the
stuff at least on a server.
On 20 Jul 2020, at 11:45, Ted Mittelstaedt <tedm@ipinc.net> wrote:
When FreeBSD was used mostly for servers it wasn't a problem. But more
and more people are using it for desktop use where they want to basically install it and forget about it, never run patches, never give
a fig about security.
Bind is a poor choice for desktop use. Packages like unbound are much better for that sort of use, and it is fr less critical if those packages have security issues.
I agree that anyone using a FreeBSD install as a server should be using bind, but I also agree it should not be the default install. You install bind when you figure out you need it, and not before.
--
Mickey and Mallory know the difference between right and wrong; the
just don't give a damn.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list--- Synchronet 3.18a-Linux NewsLink 1.113
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
[...]
With my internal BIND servers now running on Alpine (because super lightweight), that blurs the lines a bit.
Perhaps slightly OT, but here's a company which has a whole business--
model based on one nonobvious (?) reason to compile from source: https://polyverse.com/
--
Fred Morris
The idea is pretty interesting, seems like they provide a repository
with packages compiled with their own compiler that changes various memory-related elements. It is true that memory is usually the culprit
behind security flaws.
According to their page at https://polyverse.com/products/polymorphing-linux-security/ :
"Polymorphing takes source code and runs it through a polymorphic
compiler, changing register usage, function locations, import tables and other targets. This produces individually unique binaries that are semantically equivalent to the source. Polymorphing applies the compiler
to the totality of the Linux stack."
For this to work at all though, they'd have to provide all packages
simply as source code (why not use the distribution's own source repositories?) and compile it on the target. But even then I think it's
more of a security by obscurity thing. Sure it makes it more difficult
to exploit a memory flaw by means of automated exploits and other such scripts. But nothing stops you from taking the unmodified source code,
the binary and a disassembler to find out how exactly the resulting
binary has been changed / polymorphed.
I'm not very familiar with
reverse engineering and disassemblers but I don't think there's much
more to it than that, at least to thwart this defense. All of it is
possible if an attacker can read, retrieve and execute a binary on the affected server. The flaws are still there, only their memory locations
have changed. It would probably defend against script kiddies, but I
doubt it would keep out a determined attacker.
Personally I prefer Google's approach to this for Chromium. They
documented it at https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md
. Implementing programs in memory safe languages where possible is
something I believe to be a more solid long-term solution. Additionally Google's Project Zero team is behind a lot of the security research and disclosures. They audit the actual code instead, which I believe to be
far more suitable.
While the idea is valid to some extent (and could be worth it in highly confidential environments), I wouldn't consider it worth compiling
everything from source for, with a nonstandard compiler no less. If
servers would just be updated more often and (security) bug fixes
actually make their way through to the distribution releases reliably,
we'd already go a long way I think. Of course there are also
configuration mistakes that could compromise a network component. From
what I've seen so far, this seems to be more often the case with those
leaked databases and whatnot.
On 7/23/20 2:39 PM, Fred Morris wrote:
Perhaps slightly OT, but here's a company which has a whole business
model based on one nonobvious (?) reason to compile from source:
https://polyverse.com/
--
Fred Morris
Caveat: i'm far from an expert on compiling, linking, disassembling,
etc... (in fact i know *very* little about these domains), so it's
possible my comment/question below won't even really make sense.
Still, i'm not going to learn more without asking, so...
On 7/23/20 9:49 AM, Michael De Roover wrote:
The idea is pretty interesting, seems like they provide a repository
with packages compiled with their own compiler that changes various
memory-related elements. It is true that memory is usually the culprit
behind security flaws.
On 7/23/20 9:49 AM, Michael De Roover wrote:
[...][...]
For this to work at all though, they'd have to provide all packages
simply as source code (why not use the distribution's own source
repositories?) and compile it on the target.
While it would still *technically* be security by obscurity, it would
seem to me that there's some value to this approach because access to
the compiled binary wouldn't necessarily be easy to obtain (especially
if the sysadmin provisioning the system takes extra efforts to *not*
share it with anyone). Or am i missing something?
While it would still *technically* be security by obscurity, it would
seem to me that there's some value to this approach because access to
the compiled binary wouldn't necessarily be easy to obtain (especially
if the sysadmin provisioning the system takes extra efforts to *not*
share it with anyone). Or am i missing something?
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 991 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 146:06:28 |
| Calls: | 12,962 |
| Files: | 186,574 |
| Messages: | 3,266,537 |