/usr/bin/host utility cannot change port for DNS querires

Status changed to 'Confirmed' because the bug affects multiple users.

for what it's worth, `nslookup` can also set the port for a query:

dig @localhost -p 8600 mysql.service.consul
nslookup -po=8600 mysql.service.consul localhost

... but both "nslookup" and "dig" come from package "dnsutils", which brings in six other packages and 512kB of diskspace for amd64 packages. Would any but the smallest of embedded systems be burdened?

This issue was created in 2014. I just verified that "host" in Ubuntu 18.04.1 still uses hard-coded port 53; there was no progress during last 4 years. It looks like an easy change.

Some hints for an easy test. OpenDNS runs DNS server listening at port 53, 443 and 5353.

# host resolver1.opendns.com
resolver1.opendns.com has address 208.67.222.222
resolver1.opendns.com has IPv6 address 2620:119:35::35

All these commmands work (test at port 53, 443 and 5353):
# nslookup -po=53 www.ubuntu.com 208.67.222.222
# nslookup -po=443 www.ubuntu.com 208.67.222.222
# nslookup -po=5353 www.ubuntu.com 208.67.222.222

the host command is from the bind9 package not from iputils right?

the request should probably be reported upstream on https://gitlab.isc.org/isc-projects/bind9

I have no bind9 package installed! It is possible that utility host is in several packages and these utilities are not the same...

This issue is about
# host -V
host 9.11.3-1ubuntu1.3-Ubuntu

OK, I accept bind9 package; /usr/bin/host is from package bind9-host (dpkg -L bind9-host)

Hi,
imho the problem with this is that it is not a change a Distribution would usually take a Delta to the upstream package for. It usually has two ways to resolve such issues and you'll see they are rather similar.

a) an Ubuntu dev likes the case, but since this isn't high prio he can only work on it in spare time. Eventually he has something and submits it upstream. From the next upstream release we will pick it up.
b) somebody, mostly people active on the respective project, likes the case. Eventually he has something and submits it upstream. From the next upstream release we will pick it up.

Comment #3 here effectively says "a) did n't work out" and that is true.
It seems it never was important enough to anyone to code that.

But we should not forgot about "b)".
And to give that a chance IMHO you should create an upstream bug (or mailing list post) about it.
If you end up filing a bug upstream please mention it here as we can then track in which release a change would end up.

TL;DR: If you wouldn't mind, please consider filing also an upstream bug about it.