djbdns
[Top] [All Lists]

Re: getting an error on a prt-request takes too long

To: dns@list.cr.yp.to
Subject: Re: getting an error on a prt-request takes too long
From: Jeff King <peff@peff.net>
Date: Mon, 15 Jan 2007 15:43:45 -0500
Delivered-to: sp-com-lists@consult.net
Delivered-to: gmail-djbdns@securepoint.com
Delivered-to: sp.com.list@gmail.com
Delivered-to: mailing list dns@list.cr.yp.to
In-reply-to: <45AB5F61.7060504@mesman.nu>
Mail-followup-to: dns@list.cr.yp.to
Mailing-list: contact dns-help@list.cr.yp.to; run by ezmlm
References: <45AB5F61.7060504@mesman.nu>
On Mon, Jan 15, 2007 at 12:02:57PM +0100, Ben Mesman wrote:

> When I am querying for a hostname for the ip-address 213.201.233.108
> there is a huge difference between dig and dnsq:
> 
> $ dnsq ptr 108.233.201.213.in-addr.arpa 213.201.128.21
[takes 11 seconds]
> $ dig ptr 108.233.201.213.in-addr.arpa @213.201.128.21
[comes back instantly]
> The question is, why does it take so long for dnsq to fail? If it works
> as designed, what is the design?

The server returns a response code of 2. From RFC 1035, this means:

  Server failure - The name server was unable to process this query due
  to a problem with the name server.

dnsq retries the query several times with a backoff algorithm (try
strace -t -e send dnsq ...) under the assumption that the server's
failure was temporary. dig only tries once and reports the error.

The response from dig is arguably more useful for debugging (you want to
see the result of a single query, not the overall result); however, the
result of dnsq more closely models what an actual resolver would do.

-Peff

<Prev in Thread] Current Thread [Next in Thread>