More tracing reveals why the times are sometimes as high as I reported...
It first got my attention because commands like "netstat -t" and "ntpq
-p" took quite some
time to execute when 44.x.x.x addresses were in the listing, stopping for each reverse
lookup.
I had also noticed that "ping callsign.ampr.org" always takes some time before
it sends the first ping.
So I decided to investigate.
I used this command to time it: time host
callsign.ampr.org
It appears that when the callsign exists, this does two lookups, for the A and MX record.
When the callsign does not exist (I also tested that), it also does two lookups: the
specified
one, and the one with .ampr.org appended a second time. This is caused by "search
ampr.org"
in /etc/resolv.conf. It was put there by the Linux installer, I know many Linux
distributors do that.
(you specifiy a hostname and domainname during install, and it will put the domainname in
/etc/resolv.conf
as a search line)
That explains the long execution time of "host" that could not be explained by a
single lookup.
I think it is not very clever of the resolver library to append a search domain that
already was in the query,
but maybe there are some cases where this is useful?
Anyway, I removed that from resolv.conf as this machine is not for end-users anyway, and I
don't
mind typing full domain names. It doubles the speed of all lookups of nonexisting names,
and reduces
the load on the
ampr.org nameservers as well.
This doubles the speed of the host command, but of course the reverse lookups are not
affected.
When using those two local DNS servers first, they are fast. Bind should learn and
remember that,
I think. It is only good that
ampr.org DNS servers are around the globe, and a pity that
bind does
not take that to an advantage. It does do that for forwarders, at least that is written
in the docs.
(this machine runs bind as a caching resolver and the nameserver in resolv.conf is
127.0.0.1)
Rob