[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Routers and resolv.conf: [was: extremely slow to ssh out from my machine]



On Mon, 2005-02-28 at 22:53 +0100, Jan C. Nordholz wrote:
> 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,
> > > >

{snip}

> 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...

I've not seen how to monitor the router's traffic. I'm intrigued by why
inserting, as 1st nameserver entry, the IP 212.85.249.130
into /etc/resolve.conf seems to work fine (this IP is what the router
calls its ProxyDNS)...

> Are there any other nameservers you could replace the refusing one with?
> Just for experimentation, you could insert my IP... ;)

I've not got access to said machine at the mo, but I think the above
(current reply) covers this?

Michael




Reply to: