Replace host dependency by...ldns?

[HLFH]

@raforg Hi.

I was looking at packaging danectl for Arch Linux.

On Arch Linux, /bin/host is provided by bind which makes the whole thing slightly bloated. Why not using drill instead provided by the slim ldns utility?

Here will be all the impacted functions:

• tlsa_check()
• check_prerequisites()
• check_sshfp_prerequisites()
• sshfp_check()
• openpgpkey_check()
• smimea_check()

[raforg]

Hi, and thanks again! However, I think this is really an issue for the Arch bind package. On Debian, Bind9 is split up into multiple packages: one for the server, one for its utilities, one for most of the client utilities, and one for host by itself:

bind9 (server)                       1077k
bind9-dnsutils (nslookup + 5 others)  711k
bind9-host (host)                     376k
ldnsutils (drill + 25 others)         755k

So, by solving a minor bloat issue on Arch, this change would create the very same (minor) issue on Debian. By using host, it only needs a 376k package, but this change would require a 755k package.

Would you consider creating an Arch package for host instead? That would also benefit any Arch user that wanted a pretty DNS client but didn't need a DNS server. Mind you, the Bind9 server is an excellent choice for a DNSSEC-enabled DNS server which is needed by danectl users. Not necessarily on the same server, but it is convenient.

More importantly, this change (as it is) would cause breakage for anyone who upgrades danectl from an earlier version unless they already have drill installed. That's not acceptable. I expect that host is more popular and more likely to be installed than drill.

For this issue to be fixed by danectl itself, it would need to be more complicated (which I'm not too in favour of). The prerequisite would have to be for "host (or drill)". The check_prerequisites() function would need to have host removed from the main list and have something like this added after it:

case "`which host 2>/dev/null`" in
    /*)
        HAVE_HOST=1
        ;;
    *)
        HAVE_HOST=0
        ;;
esac

case "`which drill 2>/dev/null`" in
    /*)
        HAVE_DRILL=1
        ;;
    *)
        HAVE_DRILL=0
        ;;
esac

[ $HAVE_HOST = 0 -a $HAVE_DRILL = 0 ] && die "Failed to find host or drill"

The check_sshfp_prerequisites() function would need a similar change.

The host -t or drill commands would need to be replaced with a function something like this:

fetchdns()
{
    if [ $HAVE_HOST = 1 ]
    then
        host -t "$@"
    else
        drill "$@"
    fi
}

And the regular expressions would have to be able to match the output of either program. Perhaps that could be made easier by piping the output of host in the fetchdns() function through sed to replace things like "has SSHFP record" to just "SSHFP". e.g.:

fetchdns()
{
    if [ $HAVE_HOST ]
    then
        host -t "$@" | sed 's/has \(.*\) record/\1/'
    else
        drill "$@"
    fi
}

Also, there are several bugs in the patch. The -Q option for drill is inappropriate. It seems to suppress the output that is needed by danectl. Also, there is code that processes the output of host that hasn't been adapted for drill output, and there's a typo in some perl code where the =~ operator has lost its ~ (and other code was removed there that needs to be put back). I'm concerned that it might not be possible to handle the output of both in a single line per instance. Unless the fetchdns function is made more complex by adjusting the output of either or both commands so that they become the same.

And the patch doesn't handle TLSA, SMIMEA or OPENPGPKEY records yet. TLSA is the most important of all of them. You mentioned that OVH's DNS service doesn't support SMIMEA or OPENPGPKEY. Testing can be done with a local Bind9 server that is configured not to verify DNSSEC (since a local test zone that doesn't have the right DS records higher up the chain won't work if it is verifying DNSSEC).

So, what do you think? Should we add all of this additional complexity, and add to the testing burden, to save a few hundred kB, or can you create a smaller Arch package for host? I don't think changing danectl in this way would improve its code, and an Arch host package would benefit other Arch users whether they use danectl or not.

[HLFH]

@raforg

Hi,

Thanks for your feedback.

It was 9 years ago that Arch Linux decided to deprecate dnsutils (dig, host, nslookup) in favour of ldns.

Would you consider creating an Arch package for host instead?

It would go against the Arch Linux Simplicity Principle:

Packages are only split when compelling advantages exist

That would be quite easy to split but I don't support the idea, even if needed to use great softwares (danectl). I also consider the host binary obsolete.

That would also benefit any Arch user that wanted a pretty DNS client but didn't need a DNS server.

We have ldns for that, I understand you feel it is bloated, it is not my opinion.

Mind you, the Bind9 server is an excellent choice for a DNSSEC-enabled DNS server which is needed by danectl users.

I was using PowerDNS, and I am starting to prefer Trust-DNS which Let's Encrypt mentioned recently in their executive letter. I maintain trust-dns-git on the AUR.

More importantly, this change (as it is) would cause breakage for anyone who upgrades danectl from an earlier version unless they already have drill installed. That's not acceptable.

It does not cause breakage for anyone who upgrades danectl from an earlier version with proper packages, no? For example, I intend to package danectl for Arch Linux. With Arch Linux packages, we specify dependencies and changes in dependencies, it is handled automatically. Isn't that the same for Debian & Ubuntu?

I expect that host is more popular and more likely to be installed than drill.

No one is using host on Arch Linux, we use drill.

Also, there are several bugs in the patch.

That's a draft PR, I have not completed every impacted function, in particular openpgpkey_check(), smimea_check() and tlsa_check() are not completed. sshfp_check() kinda is.

Testing can be done with a local Bind9 server that is configured not to verify DNSSEC

Thanks, I will test for SMIMEA and OPENPGPKEY RR on Trust-DNS.

So, what do you think? Should we add all of this additional complexity, and add to the testing burden, to save a few hundred kB, or can you create a smaller Arch package for host?

I am neither in favour of an Arch Linux host package (at this moment) nor like you a big fan of the interesting additional complexity about supporting both drill and host unless you take the lead.

I'd like drill support in danectl by a way or another. Would you be interested in it? @raforg Otherwise, happy to maintain a friendly fork of danectl that supports drill rather than host.

For licenses on your project, I see GPLv2, and GPLv3-and-later, I am slightly confused which one applies where, can you detail this?

[raforg]

Upgrades using packages would be fine, but I don't think there a many packages yet for danectl. I'm assuming that most people using danectl would have installed it from source.

I'm happy to take the lead making danectl support either host or drill. I can do it soon.

The license should be GPLv2+. I made a mistake copying over the LICENSES and .reuse directories over from another project. Thanks for noticing. I've fixed it.

[raforg]

The latest commit uses host or drill. If both are present, it uses host.

[HLFH]

Thanks @raforg! It works really well. Closing in favour of your commit. https://github.com/raforg/danectl/commit/58d810972f99a8fb0561fe6913e344de141a3e45

[HLFH]

You may want to release danectl 0.7.5. Btw, I have packaged danectl-git for Arch Linux thanks to your commit that adds drill support.

[raforg]

Thanks. That's great. I'm working on two more additions. Then I'll release 0.8.

Note: The package says it depends on bash, but any POSIX /bin/sh would do. I don't know if that matters.

[HLFH]

@raforg Thanks, I updated danectl-git and I have fixed the git versioning & upstream url ; I have also put zsh and bash as optional dependencies as any POSIX /bin/sh would do.

[raforg]

Thanks. I expected that you would add a small shell like dash (123K) or even busybox (ash) (699K). bash (1.2M) and zsh (862K) are both larger. I think zsh is not right. I don't think it ever gets installed as /bin/sh. danectl will only use whatever is installed as /bin/sh (except on Solaris). Maybe it doesn't even need to be listed, since every Arch system will have a /bin/sh. But I don't know about Arch. If it's possible on Arch to install only zsh and have /bin/sh symlinked to it, then I'm wrong about that.