[Pkg-clamav-devel] Bug#531998: clamav-unofficial-sigs: host -T doesn't work with all DNS servers

[Bill Landry]

Paul Wise wrote:
> tags 531998 + upstream
> forwarded 531998 Bill Landry <bill at inetmsg.com>
> thanks
> 
> Hi Bill,
> 
> I got a bug report about clamav-unofficial-sigs not working with some
> DNS servers. Sounds like some DNS servers don't support TCP, since the
> -T option enables using TCP.
> 
> http://bugs.debian.org/531998

Hi Paul,

It's only used twice in the script, and it was added because other users
had reported that their DNS queries were being truncated due to DNS UDP
packet size limitations, which "host -T" (TCP mode) overcomes.

And the problem is not that DNS servers don't support TCP (all do), it's
that some admins block TCP over port 53 on their firewalls, for some
reason, which will cause problems when DNS servers automatically
fall-back to TCP mode when the query response would be larger than a
single UDP packet can support.

Debian does not support "host -T", doesn't it?  If you do:

   host <enter>

don't you get something like:

Usage: host [-aCdlriTwv] [-c class] [-N ndots] [-t type] [-W time]
            [-R number] [-m flag] hostname [server]
       -a is equivalent to -v -t ANY
       -c specifies query class for non-IN data
       -C compares SOA records on authoritative nameservers
       -d is equivalent to -v
       -l lists all hosts in a domain, using AXFR
       -i IP6.INT reverse lookups
       -N changes the number of dots allowed before root lookup is done
       -r disables recursive processing
       -R specifies number of retries for UDP packets
       -s a SERVFAIL response should stop query
       -t specifies the query type
       -T enables TCP/IP mode
       -v enables verbose output
       -w specifies to wait forever for a reply
       -W specifies how long to wait for a reply
       -4 use IPv4 query transport only
       -6 use IPv6 query transport only
       -m set memory debugging flag (trace|record|usage)

including the "-T" flag as shown above?

I've only heard one other complaint about this in the past, and I
advised the person to open TCP on port 53 on their firewalls and that
resolved the problem for them.  Ask the person reporting the problem to
check both their internal firewall (iptables, shorewall, etc.) and any
external firewall (router ACL, PIX, WatchGuard, etc.) to make sure that
TCP over port 53 is permitted and report back if that resolves the issue
for them, as well.

Thanks,

Bill