host stops searching domains when it gets back NSEC record

[Jonathan Kamens]

Suppose that:

1. you have a "search" line in your /etc/resolv.conf file;
2. it has two domains in it; and
3. the first of the two domains does DNSSEC, including returning NSEC records for nonexisting hosts.

In this situation, if you use the "host" command to look up a host name in the second domain, then "host" will stop searching after it gets back the NSEC record from the first domain, rather than moving on to the second domain and searching there, as it should.

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: bind9-host 1:9.10.3.dfsg.P4-10.1ubuntu5.1
ProcVersionSignature: Ubuntu 4.10.0-33.37-generic 4.10.17
Uname: Linux 4.10.0-33-generic x86_64
ApportVersion: 2.20.4-0ubuntu4.5
Architecture: amd64
CurrentDesktop: Unity:Unity7
Date: Wed Sep 13 15:55:50 2017
InstallationDate: Installed on 2016-08-09 (399 days ago)
InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719)
SourcePackage: bind9
UpgradeStatus: Upgraded to zesty on 2017-04-19 (147 days ago)

[Jonathan Kamens (jik)]

See also https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1717015 .

[Christian Ehrhardt  (paelzer)]

Hi Jonathan,
I currently parse dormant bugs and this clearly is one.
I see also the other bug against systemd resolver sort of expired as incomplete :-/

I'm not sure why nothing happened here but you might help potential debugging if you'd have more detailed repro steps. In the other bug I saw you have some DNS servers - could one debugging this over here use the same config to trigger?

If so could you provide the config to trigger the bug locally without the need to set up a DNSSEC server locally?
Hopefully that helps to get this debugged at some point.

[Andreas Hasenack (ahasenack)]

17.04, against which this was originally reported, is EOL by now, and we would like to have a configuration that reproduces this bug. We also have to be careful about which resolver is being used. Nowadays it's systemd-resolve, for example.

[Jonathan Kamens (jik)]

I'm now on 18.10.

This is my /etc/resolv.conf:

```
search quantopian.com kamens.us
nameserver 127.0.0.53
```

Now observe:

```
$ host jik5.quantopian.com.
$ host jik5.kamens.us.
jik5.kamens.us has address 146.115.43.199
$ host jik5
$
```

The first and third of these is returning the wrong thing. The first should return host unknown, but isn't. The third should return the same as the second, since it should first try looking up the host in quantopian.com, discover it isn't there, and then try looking it up in kamens.us in find it.

Systemd-resolved isn't the problem here. The same behavior occurs when I change my nameserver in /etc/resolv.conf to 8.8.8.8.

Note that this problem doesn't just occur with the `host` command, e.g., you will see the same behavior with `ping`:

```
$ ping jik5
ping: jik5: Name or service not known
```

[Robie Basak (racb)]

Thanks. I think I understand the problem you're reporting, and your expected behaviour seems reasonable to me. Unless there's some special new expected behaviour I don't know about.

If this affects ping (I haven't verified myself) then I don't think it'd related to the bind package.

However if bind9-host is providing host then is this two separate bugs?

I don't get exactly the same behaviour you see however. I tried, in a fresh Cosmic container, making /etc/resolv.conf exactly:

search quantopian.com kamens.us
nameserver 127.0.0.53

and then:

# getent hosts jik5.quantopian.com.
# getent hosts jik5.kamens.us.
146.115.43.199 jik5.kamens.us
# ping jik5
PING jik5.kamens.us (146.115.43.199) 56(84) bytes of data.
...

Are there any other special steps needed to reproduce what you're seeing, perhaps DNSSEC related on my network?

This does however fail as you describe:

# host jik5
#

So perhaps this is a bind9-only bug after all, but it doesn't explain how your ping command fails.

[Jonathan Kamens (jik)]

Here's my /etc/NetworkManager/NetworkManager.conf, it may be relevant:

[main]
plugins=ifupdown,keyfile
dns = default
rc-manager = resolvconf

[ifupdown]
managed=false

[device]
wifi.scan-rand-mac-address=no

(In particular, I've changed the "dns" and "rc-manager" settings.) Other than that I don't know what else could be different in my environment, I don't think there is anything.

[Robie Basak (racb)]

Thanks.

To make progress I think we need to isolate this to steps to reproduce that don't involve Network Manager or resolvconf, etc. Ideally it'd be some commands in a fresh VM or container only.

Though this bug sounds valid to me, I can't justify prioritising it right now. But anyone can help, and if the bug can be isolated and fixed, patches will be gratefully accepted.

[Launchpad Janitor (janitor)]

[Expired for bind9 (Ubuntu) because there has been no activity for 60 days.]