• Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?

    From @lbutlr@kremels@kreme.com to bind-users on Sun Jul 19 05:06:21 2020
    From Newsgroup: comp.protocols.dns.bind

    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. 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.

    This. Exactly this.



    --
    "Yessir, Captain Tight Pants."

    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From tale@d.lawrence@salesforce.com to @lbutlr on Mon Jul 20 12:09:30 2020
    From Newsgroup: comp.protocols.dns.bind

    On Sun, Jul 19, 2020 at 7:06 AM @lbutlr <kremels@kreme.com> wrote:
    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.

    Well, one minor bit of clarification is important. While highlighting
    the significant change in software might have been the motivation for
    why some installers chose to go with the name bind9 in place of named
    in some contexts, it was also a major design goal of BIND9 that it
    could run as a drop-in replacement for BIND8 on most configurations.
    It achieved this goal. The basic syntax was unchanged and
    configuration behavior was largely the same but for a little bit
    around the edges.

    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".
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Dennis Clarke@dclarke@blastwave.org to bind-users on Mon Jul 20 16:34:07 2020
    From Newsgroup: comp.protocols.dns.bind


    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".

    No one ever calls named anything other than named. In a sane world.


    --
    Dennis Clarke
    RISC-V/SPARC/PPC/ARM/CISC
    UNIX and Linux spoken
    GreyBeard and suspenders optional
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Mark Andrews@marka@isc.org to Ted Mittelstaedt on Tue Jul 21 09:05:37 2020
    From Newsgroup: comp.protocols.dns.bind


    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
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Mark Andrews@marka@isc.org to Ted Mittelstaedt on Tue Jul 21 13:13:10 2020
    From Newsgroup: comp.protocols.dns.bind

    Just for the record here are the release dates for each maintenance series. 9.0.0 2000-09-16 (one off - marked not for production)
    9.1.0 2001-01-18 - 9.1.3 2001-07-03 (6 months)
    9.2.0 2001-11-25 - 9.2.9 2007-09-25 (5 years 10 months)
    9.3.0 2004-09-22 - 9.3.6 2008-11-19 (4 years 2 months)
    9.4.0 2007-02-23 - 9.4.3 2008-11-19 - 9.4-ESV-R5 2011-08-01 (4 years 6 months) 9.5.0 2008-05-29 - 9.5.2 2009-09-23 (1 year 3 months)
    9.6.0 2008-12-23 - 9.6.3 2011-02-04 - 9.6-ESV-R11 2014-01-31 (5 years 2 months) 9.7.0 2010-02-16 - 9.7.7 2012-10-09 (2 years 8 months)
    9.8.0 2011-03-01 - 9.8.8 2014-09-29 (3 years 6 months)
    9.9.0 2012-02-29 - 9.9.13 2018-07-11 (6 years 4 months, ESV)
    9.10.0 2014-04-30 - 9.10.8 2018-07-11 (4 years 3 months)
    9.11.0 2016-10-04 - 9.11.21 2020-07-15 (Current Stable, ESV)
    9.12.0 2018-01-23 - 9.12.4 2019-03-01 (1 year 2 months)
    9.13.0 2018-05-25 - 9.13.7 2019-02-27 (development)
    9.14.0 2019-03-22 - 9.14.12 2020-05-19 (1 year 2 months)
    9.15.0 2020-03-06 - 9.15.8 2020-01-22 (development)
    9.16.0 2020-03-06 - 9.16.5 2020-07-15 (Current Stable, (should be future ESV)) 9.17.0 2020-03-18 - 9.17.3 2020-07-15 (current development)
    ESV = Extended Support Version
    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
    --
    Mark Andrews, ISC
    1 Seymour St., Dundas Valley, NSW 2117, Australia
    PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From @lbutlr@kremels@kreme.com to bind-users on Tue Jul 21 02:23:34 2020
    From Newsgroup: comp.protocols.dns.bind

    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.
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Reindl Harald@h.reindl@thelounge.net to bind-users on Mon Jul 20 19:53:14 2020
    From Newsgroup: comp.protocols.dns.bind



    Am 20.07.20 um 19:45 schrieb Ted Mittelstaedt:
    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.

    how has this anything to do with the fact that there is one named in
    whatever version in your distribution?

    it has also nothing to do with bind9 versus bind

    it's a debian hobby to make such things like apache2 or bind9 where the
    service is just httpd and named, no number and a completly different
    name as debian is using

    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.

    when i use a pure cache i run unbound and don't know why i wouldn't do
    so on whatever OS which can run it
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Mark Andrews@marka@isc.org to @lbutlr on Tue Jul 21 22:37:53 2020
    From Newsgroup: comp.protocols.dns.bind


    On 21 Jul 2020, at 18:23, @lbutlr <kremels@kreme.com> wrote:

    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.
    Anything that talks to the net is critical path from a security perspective.
    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
    --
    Mark Andrews, ISC
    1 Seymour St., Dundas Valley, NSW 2117, Australia
    PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From @lbutlr@kremels@kreme.com to bind-users on Tue Jul 21 16:23:48 2020
    From Newsgroup: comp.protocols.dns.bind

    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.
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Mark Andrews@marka@isc.org to @lbutlr on Wed Jul 22 09:28:37 2020
    From Newsgroup: comp.protocols.dns.bind


    On 22 Jul 2020, at 08:23, @lbutlr <kremels@kreme.com> wrote:

    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.
    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
    for packets of death.
    A packet of death that does nothing else has a CVS 3.0 score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
    CVSS, v3.0, a score of 0.0 receives a "None" rating; a 0.1-3.9 score gets a "Low" severity rating; a score of 4.0-6.9 is a "Medium" rating; score of 7.0-8.9 is a "High" rating; and a score of 9.0 - 10.0 is a "Critical" rating.
    If it the fault leads to a potential remote compromise you get into the Critical range.
    --
    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
    --
    Mark Andrews, ISC
    1 Seymour St., Dundas Valley, NSW 2117, Australia
    PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Ted Mittelstaedt@tedm@ipinc.net to Mark Andrews on Wed Jul 22 21:28:17 2020
    From Newsgroup: comp.protocols.dns.bind



    On 7/20/2020 4:05 PM, Mark Andrews wrote:




    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?


    Those kinds of bug reports need to be kicked back to the user with a
    "refer to distro maintainer"

    But truthfully you are proving my point. The simple fact is that bind
    will compile WITHOUT using a FreeBSD port. Linux is 10 times worse
    because they aren't even including the c 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.

    This is a bit like the development of the automobile. When the Model T
    came out it came with a toolbox and a big book that allowed the owner to completely troubleshoot and fix anything that went wrong with the car.
    But gradually as more and more people bought cars you had more people
    who didn't know squat about cars buying them. So Ford stopped shipping
    the manual and made it an extra cost item.

    Nowadays Ford and Chevy don't even sell a manual at all anymore.
    Instead you have to get an alldata subscription to get access to the
    service manual. And if you stop paying the subscription you have no
    more manual. But a running shop is always going to be paying a
    subscription so it's not a problem for them. For the DIYers they
    can get a 3 day alldatadiy subscription then spend 3 hours printing
    every page of the manual but maybe 1 out of 10,000 car buyers ever
    does this.

    Microsoft ran into this problem and had to split windows into a server
    and desktop version. Right after that happened "windows admins" who
    knew the desktop only were fine. But today all the MS server
    applications have to be controlled via the command line via powershell,
    plus the server version of the OS is 4 times more expensive and both
    these things tend to chase away the people who aren't system admin
    types who are willing to get down and dirty and technical.

    Linux did this as well although the "server versions" of the
    distributions are horrendously lacking. FreeBSD really
    should do this but they don't likely have enough people working on the
    distro. So they make it so that the non-tech types can use it
    and expect that the admin types know better.

    None of these solutions are really solutions. The real solution would
    be for the users to get more educated. But the majority of people don't
    really care about an OS they just use it as a platform to run the
    software that they do care about. Thus creating the means for gigantic
    DDoS networks since none of them bother patching their OSes.

    BIND chose the path of servicing the needs of the people who knew what
    they were doing. Unbound went the other direction and chose the path
    of servicing the non-technical users. There's more non-techs than
    educated people so
    sooner or later paths are going to diverge. It always makes me laugh to
    read these flame wars from the non-techs who think that just because
    their simple-and-not-configurable programs work for them on the
    desktop that they should work on the server and the world should switch
    to them. Whaah Whaah Whaah the real world is complicated, simplify it
    for me or I'm gonna have a tantrum. We have one of those dunsels in the
    White House in the USA right now.

    The BIND developers should
    forget about the non-techs and continue servicing the people who know
    what they are doing and laugh also.

    Ted
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Michael De Roover@isc@nixmagic.com to bind-users on Thu Jul 23 06:59:31 2020
    From Newsgroup: comp.protocols.dns.bind


    On 7/23/20 6:28 AM, Ted Mittelstaedt wrote:
    Linux is 10 times worse because they aren't even including the c
    compiler or development tools
    anymore.
    Every distribution I've laid my hands on so far has GCC packages and
    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?

    --
    Met vriendelijke groet / Best regards,
    Michael De Roover
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Ted Mittelstaedt@tedm@ipinc.net to bind-users on Wed Jul 22 22:19:18 2020
    From Newsgroup: comp.protocols.dns.bind



    On 7/22/2020 9:59 PM, Michael De Roover wrote:

    On 7/23/20 6:28 AM, Ted Mittelstaedt wrote:
    Linux is 10 times worse because they aren't even including the c
    compiler or development tools
    anymore.
    Every distribution I've laid my hands on so far has GCC packages and
    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.

    Ted
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Michael De Roover@isc@nixmagic.com to bind-users on Thu Jul 23 08:12:32 2020
    From Newsgroup: comp.protocols.dns.bind


    On 7/23/20 7:19 AM, Ted Mittelstaedt wrote:
    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?)

    People would find out when an unnecessary service is started up though,
    no? Especially with services, you can see those with netstat/ss right
    away. Additionally, the distribution maintainers are (or at least should
    be) the ones compiling it. It could be argued that by installing their distribution, there is already a certain level of trust being given to
    said maintainers.

    For example I don't trust Manjaro's maintainers, since they screwed up
    their TLS certificate renewal no less than 3 times. That's complete and
    utter incompetence on their part. How they didn't already put certbot in
    a cron job after the first time is beyond me. On the other hand, I have started to get fond of Debian.. though also not entirely. But enough to consider that their packages are probably just fine. I could also verify
    this by compiling it myself and comparing the result. They publish their downstream source code along with any modifications they made.

    You are making an argument that is a desktop argument.  That is, the argument goes Those That Know Better Will Do It For You.

    Not quite, rather my goals for the system sufficiently align with those
    of the distribution I end up going with on this or that system. And on a server I don't like compiling from source for the same reason that I
    wouldn't install and run a desktop environment on it. I consider it unnecessary cruft. And keeping those packages up-to-date... I forgot to manually update software I built from a git repository more often than
    I'd like to admit. I also lost count.

    With my internal BIND servers now running on Alpine (because super lightweight), that blurs the lines a bit. With 9.14.12, they ship an EOL version of BIND. And their stock configuration for it was pretty much
    unusable anyway. Everything on that was replaced. Compiling from source
    or sticking with what they provide, perhaps notifying Alpine's
    maintainers that they should look into it? I don't know. But compiling
    9.16 ESV there probably wouldn't be a bad idea. Certainly doable, but
    not as convenient.

    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.

    That's an issue of licensing, it is super annoying, and having older
    source code still available in those cases is indeed really useful. I
    don't know how relevant this is to this discussion though (granted, can
    we still pretend to be on-topic anyway?) given that this is more about
    open source projects merely providing binary packages (with the source available), rather than said project completely denying source code access.

    Regarding the ballistic rampage... I can't help but think that this is
    what's happening in BIND right now. Fortunately it was only a few days
    worth of commits that dealt with.. that totally 100% necessary change of nomenclature.
    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.

    Fair points. And I agree, having the option is absolutely something I
    wouldn't want to give away for proprietary software either. But in all
    the software I use (be it on workstations or servers, I run Linux on
    both) I do have that option. It's just not as convenient and I certainly wouldn't want every distro to turn into a Gentoo for increased merit or reasons like that. If the distro makes compiling from source (be it
    upstream or their downstream version) easy, either to compare or to
    actually put it to use, all the better.

    (My preferred term for for crashing and burning servers would probably
    not be suitable for this list)

    --
    Met vriendelijke groet / Best regards,
    Michael De Roover
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Mauricio Tavares@raubvogel@gmail.com to comp.protocols.dns.bind on Thu Jul 23 06:30:54 2020
    From Newsgroup: comp.protocols.dns.bind

    On Tue, Jul 21, 2020 at 4:24 AM @lbutlr <kremels@kreme.com> wrote:

    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 was taught in kitty school "less critical if those packages
    have security issues" is never a good argument. Just because getting-into-a-desktop-and-then-using-it-as-launchpad-to-go-after-servers
    is a traditional Windows attack vector does not mean Linux computers
    are immune of that.

    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
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Fred Morris@m3047@m3047.net to bind-users on Thu Jul 23 05:36:05 2020
    From Newsgroup: comp.protocols.dns.bind

    If you're running Alpine, you should know that it uses MUSL which has a
    stub resolver which is/was lacking in some respects: http://postfix.1071664.n5.nabble.com/Outgoing-DANE-not-working-tp105397p105420.html

    On Thu, 23 Jul 2020, Michael De Roover wrote:
    [...]
    With my internal BIND servers now running on Alpine (because super lightweight), that blurs the lines a bit.

    --

    Fred Morris

    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Michael De Roover@isc@nixmagic.com to bind-users on Thu Jul 23 15:49:37 2020
    From Newsgroup: comp.protocols.dns.bind

    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
    --
    Met vriendelijke groet / Best regards,
    Michael De Roover
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From charlie derr@cderr@simons-rock.edu to bind-users on Thu Jul 23 10:44:43 2020
    From Newsgroup: comp.protocols.dns.bind

    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.

    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.

    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?


    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.

    Thanks much for this fascinating discussion,
    ~c



    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

    --
    Charlie Derr Director, Instructional Technology 413-528-7344 https://www.simons-rock.edu Bard College at Simon's Rock
    Encryption key: http://hope.simons-rock.edu/~cderr/
    Personal writing: https://medium.com/@cderr Pronouns: he or they
    Home landline: 860-435-1427
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From charlie derr@cderr@simons-rock.edu to bind-users on Thu Jul 23 10:56:02 2020
    From Newsgroup: comp.protocols.dns.bind



    On 7/23/20 10:44 AM, charlie derr wrote:
    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.

    Nevermind my previous question, obviously i didn't read carefully enough
    (sonce their repo would expose the compiled binaries).

    /back to lurk mode

    ~c
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Fred Morris@m3047@m3047.net to bind-users on Thu Jul 23 08:13:52 2020
    From Newsgroup: comp.protocols.dns.bind

    On Thu, 23 Jul 2020, charlie derr wrote:
    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?

    They actually run a very large build farm in AWS, and they claim that all binaries are made just for you. Basically you change your distro's package repositories to theirs. Preventing people from examining the binaries in
    order to craft working memory exploits which work across a large installed base is exactly what they're aiming to prevent.

    Disclosure: I've heckled their CTO in a friendly fashion for making better idiots, but I paid for my own Old Fashioned.

    --

    Fred Morris

    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Ted Mittelstaedt@tedm@ipinc.net to bind-users on Thu Jul 23 11:22:50 2020
    From Newsgroup: comp.protocols.dns.bind



    On 7/23/2020 7:44 AM, charlie derr wrote:

    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?


    I don't think there is much value because getting access isn't only done
    by buffer overflows and such on compiled programs. If you can find one
    then sure you might be able to get root access if the program you break
    into is running at root. But you can do an awful lot of damage by
    merely having unprivileged access. All you need is authentication
    credentials and regular users are horrible about keeping
    their credentials private.

    In fact the only place I can see a whole lot of value to is the
    manufacturers of cell phones since companies like Verizon lock the boot
    loaders as they do not wish owners of their phones to root them and
    get rid of annoying Verizon advertising and other suchlike. Rooting
    those devices is mainly done by breaking into security holes on the phone.

    Ted
    --- Synchronet 3.18a-Linux NewsLink 1.113