Nixpkgs: `host` fails on 18.03

[shosti]

Issue description

Since upgrading to 18.03, I get the following error when I try to use the host command:

host: parse of /etc/resolv.conf failed`

My /etc/resolv.conf is as follows:

# Generated by resolvconf
nameserver 192.168.1.1
nameserver fe80::xxxx:xxff:feyy:yyyy%wlp4s0
options edns0

_EDITED by vcunat hide the mac address (xxxxxxyyyyyy)_

/etc/resolvconf.conf is:

# This is the default, but we must set it here to prevent
# a collision with an apparently unrelated environment
# variable with the same name exported by dhcpcd.
interface_order='lo lo[0-9]*'
# Invalidate the nscd cache whenever resolv.conf is
# regenerated.
libc_restart='/nix/store/46nrl6ycwc140iqjrmk09wbnanj59nh5-systemd-238/bin/systemctl try-restart --no-block nscd.service 2> /dev/null'
# Options as described in resolv.conf(5)
resolv_conf_options='edns0'

Relevant lines from my configuration.nix:

  networking.networkmanager.enable = true;
  networking.enableIPv6 = false;

(The issue is the same with networking.enableIPv6 set to false.) My full configuration is here.

Steps to reproduce

host -t a google.com

Technical details

• system: "x86_64-linux"
• host os: Linux 4.14.29, NixOS, 18.03pre131587.b6ddb9913f2 (Impala)
• multi-user?: yes
• sandbox: no
• version: nix-env (Nix) 2.0
• channels(shosti): ""
• channels(root): "nixos-18.03pre131587.b6ddb9913f2"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

[dtzWill]

Hmm. At first this looked like a format string leaked into the configure file, but looking into it I think this is "correct" and is used to indicate "zone"s.

Can you:

• Post result of host -V and perhaps readlink -f $(which host)?
• Confirm behavior using 18.03's "host" with nix run -f channel:nixos-18.03 host -c host -t a google.com?
• See if the newer bind (which provides host) resolves the issue? Changelog looks promising, considering it's only a minor version bump: nix run -f channel:nixos-unstable host -c host -t a google.com

[xeji]

Same here on master

$ git rev-parse HEAD
0426d9001fbb1ecd7552aaaeebccb84ea8483fb9
$ nix run -f $HOME/nixpkgs host -c host -t a google.com
host: parse of /etc/resolv.conf failed
$ nix run -f $HOME/nixpkgs host -c host -V
host 9.12.1
$ more /etc/resolv.conf 
# Generated by resolvconf [address details removed]
nameserver 192.168.x.x
nameserver fe80::xxxx:xxff:fexx:xxxx%enp1s0f0
options edns0

[shosti]

@dtzWill :

[shosti@drogo:~]$ host -V
host 9.12.0

[shosti@drogo:~]$ readlink -f $(which host)
/nix/store/4r5nqfpj0isp7g9f3dxz83kxn07485yy-bind-9.12.0-host/bin/host

[shosti@drogo:~]$ nix run -f channel:nixos-18.03 host -c host -t a google.com
[10.3 MiB DL]
host: parse of /etc/resolv.conf failed

[shosti@drogo:~]$ nix run -f channel:nixos-unstable host -c host -t a google.com
[6 copied (28.9 MiB), 18.6 MiB DL]
host: parse of /etc/resolv.conf failed

[dtzWill]

Thanks!

Looks like it's this: https://gitlab.isc.org/isc-projects/bind9/issues/187

Which has a few solid leads.. :)

[dtzWill]

I'm not sure what to make of this, but I'm.... having trouble convincing host to barf on /etc/resolv.conf -- even when I replace mind with yours and bounce nscd. Worst that happens is it hangs (when I remove the other, valid, nameserver entries).

Oh! "Hooray!" haha, I can trigger it if I use nameserver entries like yours (with "%interface" suffix) and remove "search lan".

Furthermore I'll add that using host from 17.09 and 17.03 does not have the same error.

EDIT: Apparently latest bind "fixes" :wink: the bit that led me to remove search lan, where as it currently/previously ignored resolv.conf errors if it was present: https://gitlab.isc.org/isc-projects/bind9/commit/1f400b68a8e6b7a1111151b512eaee2c49bae2ad

[dtzWill]

FWIW the drill command from ldns seems to have no problem with these resolv.conf files, if you need something to use right now. Arch apparently moved to using that for their dns CLI needs a while back: https://www.archlinux.org/todo/dnsutils-to-ldns-migration .

[xeji]

I use drill and it seems to work fine on 18.03 and master.
As for host, we could also try to apply the patch mentioned in the upstream bug: https://gitlab.isc.org/isc-projects/bind9/commit/e50849097a05ee3fc9e7357d4e238540cb076d22 .
Or use ldns ...

Edit: That patch only fixes part of the problem - I should have read the comments more carefully...
So I guess we'd better wait for upstream to sort this out.

[vcunat]

I don't think there's much to do except to apply upstream patches for host (when available). Most software should handle link-local addresses correctly.

[xeji]

We should label such issues "waiting for upstream solution" to keep track of them but I don't think we currently have such a label.

[vcunat]

I created the label. We can easily delete/change it later in case there's such consensus.

[brainrape]

host seems to work fine on 20.03, can we close this? Thanks!

[vcunat]

Yes, it seems long fixed in versions we use. Even our 19.09 is using bind 14.