[gentoo-user] Why does bind-tools 9.18 depend on bind?

[gentoo-user] Why does bind-tools 9.18 depend on bind?

[Grant Edwards]

Portage suddenly wants to install net-dns/bind so it can update
bind-tools from 9.16 to 9.18. I've always had bind-tools installed,
but it has never required that I install the bind server and its
dependencies (for which I have no use). Older versions of bind-tools
didn't require bind. The ebuilds for bind-tools 9.20 that I've found
at on overlays don't require bind.

What's so special about bind-tools 9.18 that it has to have bind
installed?

Is there another package that will provide a command line dns lookup
tool that can be used for troubleshooting that doesn't require me to
install a DNS server all of its extra faff?

--
Grant

Re: [gentoo-user] Why does bind-tools 9.18 depend on bind?

[Matt Jolly]

Hi Grant,

On 25/10/24 04:45, Grant Edwards wrote:
> Portage suddenly wants to install net-dns/bind so it can update
> bind-tools from 9.16 to 9.18. I've always had bind-tools installed,
> but it has never required that I install the bind server and its
> dependencies (for which I have no use). Older versions of bind-tools
> didn't require bind. The ebuilds for bind-tools 9.20 that I've found
> at on overlays don't require bind.
> 
> What's so special about bind-tools 9.18 that it has to have bind
> installed?


The commit that added 9.18.0[1] gives some context:

  >This is just a proxy for net-dns/bind. Splitting the ebuilds is *way* too
  >fragile and gains nothing because the same software gets built again 
anyway,
  >just thrown away at the end.

> Is there another package that will provide a command line dns lookup
> tool that can be used for troubleshooting that doesn't require me to
> install a DNS server all of its extra faff?
> 

Try net-dns/doggo[2]


1: 
https://github.com/gentoo/gentoo/commit/754524d4345dd41ff9e31cba85afb4f104a9815a
2: https://packages.gentoo.org/packages/net-dns/doggo

[gentoo-user] Re: Why does bind-tools 9.18 depend on bind?

[Grant Edwards]

On 2024-10-24, Matt Jolly <kangie@gentoo.org> wrote:

> The commit that added 9.18.0[1] gives some context:
>
>  >This is just a proxy for net-dns/bind. Splitting the ebuilds is
>  >*way* too fragile and gains nothing because the same software gets
>  >built again anyway, just thrown away at the end.

I'm just not keen on have extra, uneeded accounts, groups, binaries,
and libraries, but I'm probably being overly paranoid.

>> Is there another package that will provide a command line dns lookup
>> tool that can be used for troubleshooting that doesn't require me to
>> install a DNS server all of its extra faff?
>
> Try net-dns/doggo[2]

Cool, and it doens't want to install 4 other new packages like
bind-tools does.  [OK, two are just account/group packages, so it's
not quite as bad as it sounds.]

Thanks.

Re: [gentoo-user] Re: Why does bind-tools 9.18 depend on bind?

[Michael Orlitzky]

On 2024-10-25 00:47:27, Grant Edwards wrote:
> >
> > Try net-dns/doggo[2]
> 
> Cool, and it doens't want to install 4 other new packages like
> bind-tools does.  [OK, two are just account/group packages, so it's
> not quite as bad as it sounds.]

It's a Go package though, so it will quietly install a mountain a
random outdated static libraries from github.

Try it:

  $ emerge --fetchonly --nodeps doggo
  $ tar -tf /var/cache/distfiles/doggo-1.0.5-deps.tar.xz

BIND may actually be the least bad option. The Knot DNS server
provides alternatives like kdig, but you'll still wind up with a
full-fledged DNS server on your hands.

Depending on how serious this is, you could use package.provided and
INSTALL_MASK to block everything you don't want.

[gentoo-user] Re: Why does bind-tools 9.18 depend on bind?

[Holger Hoffstätte]

On 2024-10-25 11:59, Michael Orlitzky wrote:
> On 2024-10-25 00:47:27, Grant Edwards wrote:
>>>
>>> Try net-dns/doggo[2]
>>
>> Cool, and it doens't want to install 4 other new packages like
>> bind-tools does.  [OK, two are just account/group packages, so it's
>> not quite as bad as it sounds.]
> 
> It's a Go package though, so it will quietly install a mountain a
> random outdated static libraries from github.

What? No, it will not. Those dependencies are absolutely not installed,
they are only used for building & linking the executable.

$equery f doggo
  * Searching for doggo ...
  * Contents of net-dns/doggo-1.0.5:
/usr
/usr/bin
/usr/bin/doggo
/usr/share
/usr/share/bash-completion
/usr/share/bash-completion/completions
/usr/share/bash-completion/completions/doggo
/usr/share/zsh
/usr/share/zsh/site-functions
/usr/share/zsh/site-functions/_doggo

I could not agree more that Go is dumb and basically useless for shared
infrastructure, but that train has sailed.

Holger

[gentoo-user] Re: Why does bind-tools 9.18 depend on bind?

[Grant Edwards]

On 2024-10-25, Michael Orlitzky <mjo@gentoo.org> wrote:
> On 2024-10-25 00:47:27, Grant Edwards wrote:
>> >
>> > Try net-dns/doggo[2]
>> 
>> Cool, and it doens't want to install 4 other new packages like
>> bind-tools does.  [OK, two are just account/group packages, so it's
>> not quite as bad as it sounds.]
>
> It's a Go package though, so it will quietly install a mountain a
> random outdated static libraries from github.
>
> Try it:
>
>   $ emerge --fetchonly --nodeps doggo
>   $ tar -tf /var/cache/distfiles/doggo-1.0.5-deps.tar.xz

Holy shit!  Over 6000 source files.

> BIND may actually be the least bad option.

Indeed.

> The Knot DNS server provides alternatives like kdig, but you'll
> still wind up with a full-fledged DNS server on your hands.
>
> Depending on how serious this is, you could use package.provided and
> INSTALL_MASK to block everything you don't want.

It's probably not worth that much effrot...

--
Grant

Re: [gentoo-user] Re: Why does bind-tools 9.18 depend on bind?

[Michael Orlitzky]

On Fri, 2024-10-25 at 13:08 +0200, Holger Hoffstätte wrote:
> > 
> > It's a Go package though, so it will quietly install a mountain a
> > random outdated static libraries from github.
> 
> What? No, it will not. Those dependencies are absolutely not installed,
> they are only used for building & linking the executable.
> 

You're right of course but after they're all statically linked into
that executable, the executable, containing the libraries that will
never be updated, is installed. And then we use them to process
untrusted content from the network...?

[gentoo-user] Re: Why does bind-tools 9.18 depend on bind?

[Grant Edwards]

On 2024-10-25, Michael Orlitzky <mjo@gentoo.org> wrote:
> On Fri, 2024-10-25 at 13:08 +0200, Holger Hoffstätte wrote:
>> > 
>> > It's a Go package though, so it will quietly install a mountain a
>> > random outdated static libraries from github.
>> 
>> What? No, it will not. Those dependencies are absolutely not installed,
>> they are only used for building & linking the executable.
>> 
>
> You're right of course but after they're all statically linked into
> that executable, the executable, containing the libraries that will
> never be updated, is installed. And then we use them to process
> untrusted content from the network...?

And there seems to be plenty of crypto and ssh stuff in there, so
that's a bit scary.

--
Grant

Re: [gentoo-user] Re: Why does bind-tools 9.18 depend on bind?

[Eray Aslan]

On Fri, Oct 25, 2024 at 01:53:05PM -0000, Grant Edwards wrote:
> On 2024-10-25, Michael Orlitzky <mjo@gentoo.org> wrote:
> > BIND may actually be the least bad option.
> 
> Indeed.

Seconded. I find that net-dns/bind is good for authoritative dns servers
and for its tools so it tends to get installed even on laptops. Gentoo
does not start daemons on install so really no need to have a fragile
separate package only for bind provided tools.

fwiw, net-dns/unbound is a good choice for a resolver even if you are
running in a systemd environment.

-- 
Eray
> 
> 
> 
> 

Re: [gentoo-user] Why does bind-tools 9.18 depend on bind?

[Dr Rainer Woitok]

Matt and others,

On Fri, 25 Oct 2024 08:35:00 +1000 Matt Jolly wrote:
> ...
> On 25/10/24 04:45, Grant Edwards wrote:
> > ...
> > What's so special about bind-tools 9.18 that it has to have bind
> > installed?
> 
> The commit that added 9.18.0[1] gives some context:
> 
>   >This is just a proxy for net-dns/bind. Splitting the ebuilds is *way* too
>   >fragile and gains nothing because the same software gets built again 
> anyway,
>   >just thrown away at the end.

Doesn't that mean  that best practice  would be  to just ditch "net-dns/
bind-tools" and solely install  "net-dns/bind" instead?   At least up to
now the latter _also_ provides "nslookup" and "dig".

Sincerely,
 Rainer

Re: [gentoo-user] Why does bind-tools 9.18 depend on bind?

[Matt Jolly]

Hi Rainer,

> Doesn't that mean  that best practice  would be  to just ditch "net-dns/
> bind-tools" and solely install  "net-dns/bind" instead?   At least up to
> now the latter _also_ provides "nslookup" and "dig".

That is correct. The package now even says as much (since about 12
hours ago!):

 > net-dns/bind-tools is now merged into net-dns/bind and
 > net-dns/bind-tools serves as a dummy package until it is
 > eventually removed. The split was already a maintenance burden
 > because of lack of build system support for it, but this became
 > more severe with >=9.18.0.
 >
 > Please run the following commands:
 > * emerge --deselect net-dns/bind-tools
 > * emerge --noreplace net-dns/bind

Regards,

Matt

Re: [gentoo-user] Re: Why does bind-tools 9.18 depend on bind?

[Peter Humphrey]

On Saturday 26 October 2024 09:10:44 BST Eray Aslan wrote:

> fwiw, net-dns/unbound is a good choice for a resolver even if you are
> running in a systemd environment.

Interesting. I run dnsmasq here; would unbound be better, or less good? I've 
had no trouble with dnsmasq - it just does the job.

-- 
Regards,
Peter.

Re: [gentoo-user] Re: Why does bind-tools 9.18 depend on bind?

[Eray Aslan]

On Sat, Oct 26, 2024 at 11:42:32AM +0100, Peter Humphrey wrote:
> On Saturday 26 October 2024 09:10:44 BST Eray Aslan wrote:
> > fwiw, net-dns/unbound is a good choice for a resolver even if you are
> > running in a systemd environment.
> 
> Interesting. I run dnsmasq here; would unbound be better, or less good? I've 
> had no trouble with dnsmasq - it just does the job.

I should have qualified that statement. Sorry. dnsmasq is optimized and
arguably a better choice for client systems, esp with intermittent
internet access (phones, laptops etc). And I find unbound to be a better
choice for server environments.

Since I am familiar with unbound, I tend to use it everywhere but that
is just personal choice.

-- 
Eray