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

Bug #1318975 reported by psl
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
bind9 (Ubuntu)
Confirmed
Wishlist
Unassigned

Bug Description

This is not a bug report. It is request for missing feature...

/usr/bin/host utility to check DNS is limited to send DNS queries to port 53. There is no option to change port for DNS queries. Other utilities, like dig, can change port. I can change DNS server but port is always 53.

I found this missing feature while I was troubleshooting my DNS. My ISP is hijacking port 53 and I found I cannot use host utility to diagnose this problem...

psl (slansky)
affects: virtualbox (Ubuntu) → iputils (Ubuntu)
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in iputils (Ubuntu):
status: New → Confirmed
Revision history for this message
Moses Moore (moses-ubuntu) wrote :

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?

Revision history for this message
psl (slansky) wrote :

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

affects: iputils (Ubuntu) → bind9 (Ubuntu)
Changed in bind9 (Ubuntu):
importance: Undecided → Wishlist
Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Revision history for this message
psl (slansky) wrote :

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

Revision history for this message
psl (slansky) wrote :

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

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.