On Mon, Feb 28, 2005 at 08:42:02AM -0500, Mitchell Laks wrote:
> Dear Michael,
> Previous respondents said:
> > > I agree with Lee about how your resolv.conf gets constructed. However the
> > > problem still is that the router (who apparently behaves as if it were a
> > > query-forwarding DNS server) doesn't respond to DNS queries... is there a
> > > config option in your router to disable the router-internal DNS server
> > > (and to forward the ISP nameservers directly)?
> > > If not, you can only hardwire your resolv.conf to the two other
> > > nameservers above, and prevent it from being rebuilt. (IIRC, there is a
> > > package "resolvconf" that rebuilds this file on every reboot from various
> > > sources, among them information received via DHCP - deinstalling it or at
> > > least removing it from /etc/rc*.d/ should fix that)
> > >
> > > HTH,
> > >
> > > Jan (now replying from a different address)
> >
> > I'm at work now but will look into these when I get home this evening;
> > thanks, Michael
>
> I have had similar issues, and discovered that the 5 second (or perhaps in my
> opinion two 10 second) pauses is in fact a reverse dns failure. You do ssh
> 192.168.1.25 and then (apparently) the tcpwrappers program asks "who is
> 192.168.1.25" to reverse dns.
>
> Now you really dont care what the hostname is of 192.168.1.25 is, but the
> tcpd tcp/ip daemon wrapper program by Professor Wietse Venema
> is doing this checking
> ( look at
> man 8 tcpd ,
> man hosts.allow or
> man hosts.deny).
>
> So you can either set up a dnsserver on your router to answer questions like
> this or alteranatively, just add a line to your /etc/hosts file of the
> following sort
>
> 192.168.1.25 fred
> where fred is the hostname of the box that is trying to ssh in. This will
> immediately short circuit the whole reverse dns nonsense.
>
> If you have a properly configured dns server all will work, but laptops tend
> to have this problem when they point to dns servers on the internet when your
> lan is disconnected from the internet.
>
> I dont know why i didnt have this problem using fedora core or redhat 7.3. I
> never configured a dns server before on my old machines which ran fedora and
> they seem to have the same wrappers programs. So if i didnt want to set up a
> dns server i just added stuff to /etc/hosts.
>
> If you find out more let me know.
> Mitchell Laks
>
Hi Michael and all others,
I've just dug out your strace again that contains the DNS query your computer
is emitting... I'll copy it here again:
send(3, "\274\177\1\0\0\1\0\0\0\0\0\0\5ratty\3phy\5umist\2ac\2"..., 39, 0) = 39 <0.000056>
This is no reverse DNS - it's a normal "forward" query asking for the IP of
ratty.phy.umist.ac.uk, i.e. the ssh target host. The RD (recursion
desired) bit is set, so the router forwards the query to the other
nameservers it knows... let's again have a closer look at your strace,
because I overlooked several details last time.
We saw that it queries your router first, then one of the "official" name-
servers... but why does it do that four times? Here's why...
=== (first three tries)
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 <0.000046>
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.0.1")}, 28) = 0 <0.000030>
send(3, "\274\177\1\0\0\1\0\0\0\0\0\0\5ratty\3phy\5umist\2ac\2"..., 39, 0) = 39 <0.000080>
gettimeofday({1109534905, 304051}, NULL) = 0 <0.000016>
poll([{fd=3, events=POLLIN}], 1, 5000) = 0 <5.001755>
=== (query to your router times out)
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4 <0.000050>
connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("212.1.130.32")}, 28) = 0 <0.000030>
send(4, "\274\177\1\0\0\1\0\0\0\0\0\0\5ratty\3phy\5umist\2ac\2"..., 39, 0) = 39 <0.000074>
gettimeofday({1109534910, 306824}, NULL) = 0 <0.000016>
poll([{fd=4, events=POLLIN, revents=POLLERR}], 1, 5000) = 1 <0.043725>
ioctl(4, FIONREAD, [0]) = 0 <0.000020>
recvfrom(4, 0xbfffdc60, 1024, 0, 0xbfffd174, 0xbfffd134) = -1 ECONNREFUSED (Connection refused) <0.000023>
close(3) = 0 <0.000037>
close(4) = 0 <0.000027>
=== (query to the official NS gets _REFUSED_)
[ repeat ... ]
=== (fourth try)
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 <0.000040>
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.0.1")}, 28) = 0 <0.000026>
send(3, "\274\201\1\0\0\1\0\0\0\0\0\0\5ratty\3phy\5umist\2ac\2"..., 39, 0) = 39 <0.000058>
gettimeofday({1109534925, 503414}, NULL) = 0 <0.000016>
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1 <0.001625>
ioctl(3, FIONREAD, [55]) = 0 <0.000018>
recvfrom(3, "\274\201\201\200\0\1\0\1\0\0\0\0\5ratty\3phy\5umist\2a"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.0.1")}, [16]) = 55 <0.000027>
close(3) = 0 <0.000028>
=== (got an answer - from your router!)
The answer is not authoritative, but it's an answer - your router just
needed >15 sec to obtain it.
I'm not familiar with the kind of router you have - can you somehow monitor
its outgoing traffic, so that we can see how fast your router is forwarding
the query, and how fast the answers are coming back? Maybe your router's
queries to 212.1.130.32 are refused, too, and it takes awhile until your
router tries the next server it knows...
Are there any other nameservers you could replace the refusing one with?
Just for experimentation, you could insert my IP... ;)
Regards,
Jan
--
Jan C. Nordholz
<jckn At gmx net>
Attachment:
signature.asc
Description: Digital signature