headers
Daniel Stenberg | 1 Jan 2009 22:51
Picon
Favicon
Gravatar

Re: a HAVE_ define check in ares.h

On Mon, 22 Dec 2008, Gisle Vanem wrote:

>> Yet it currently features a check for the HAVE_STRUCT_IN6_ADDR define. This 
>> really can't be right.
>
> I think it was me who added this. An easy fix would be to define a private 
> ares_in6_addr structure.

Yes right, that would work if we made a 'ares_in6_addr' struct unconditonally 
instead. The only thing that struct me is that we then risk actually changing 
the struct (ABI) for systems that for some reason have a different in6_addr 
struct and already run c-ares IPv6 enabled.

Does anyone know of or can think of a case where a system's in6_addr struct 
would be different?

--

-- 

  / daniel.haxx.se
Permalink | Reply | 501 comments |
headers
Alexey Simak | 9 Jan 2009 12:32
Picon

Callback for DNS query

Hi Daniel,

We use c-ares in a project and need to log DNS requests
sent to DNS server. Unfortunately c-ares provides to
callback only received DNS answers.

I suggest to call callback also before sending request to
server. To implement this feature we can use existing
callback( need to add new status code in this case ) 
or introduce a new request callback.

Which way is preferable from your point of view?

Thanks,
Alexey Simak
Permalink | Reply | 7 comments |
headers
Phil Blundell | 9 Jan 2009 23:34
Favicon

ares_expand_name() return codes

A few weeks ago my company started shipping its software (which uses
c-ares for name lookups) with IPv6 enabled by default.  Since then, it
has become depressingly evident that quite a lot of the consumer-grade
router/NAT boxes on the market include their own nameserver
implementations which mis-handle AAAA queries in a variety of inventive
ways, ranging from flatly ignoring the query (leaving the client to time
out) to sending back some or other mangled response packet.

In an attempt to work around this latter behaviour, I have patched our
copy of c-ares to treat an ARES_EBADRESP result from an AAAA query as if
it were ARES_ENODATA, i.e. to try again by asking for A records.  This
works in almost all cases, except that I have now discovered one
particular router model whose responses are causing ares_expand_name to
return ARES_BADNAME.  This error code then percolates upwards and causes
my lookups to fail.

So, my question: is it actually useful for ares_expand_name() to return
ARES_BADNAME, or would it make more sense for it to return ARES_BADRESP
if its input is malformed?  As far as I can tell this function is used
only to parse server responses, so it would seem that an invalid name
encountered here must always imply a malfunctioning server.

p.
Permalink | Reply | 3 comments |
headers
Daniel Stenberg | 10 Jan 2009 20:08
Picon
Favicon
Gravatar

Re: ares_expand_name() return codes

On Fri, 9 Jan 2009, Phil Blundell wrote:

> So, my question: is it actually useful for ares_expand_name() to return 
> ARES_BADNAME, or would it make more sense for it to return ARES_BADRESP if 
> its input is malformed?  As far as I can tell this function is used only to 
> parse server responses, so it would seem that an invalid name encountered 
> here must always imply a malfunctioning server.

ares_expand_name() is in the API and it doesn't explicitly deal with 
responses, thus making it returning ARES_EBADRESP seems odd.

But internally (like in all the ares_parse_*_reply() functions) in c-ares when 
ares_expand_name() is used on a response, I think a returned error could very 
well be translated to a ARES_EBADRESP to return from the public function that 
was called.

--

-- 

  / daniel.haxx.se
Permalink | Reply | 2 comments |
headers
Daniel Stenberg | 10 Jan 2009 23:16
Picon
Favicon
Gravatar

Re: Callback for DNS query

On Fri, 9 Jan 2009, Alexey Simak wrote:

> I suggest to call callback also before sending request to server. To 
> implement this feature we can use existing callback( need to add new status 
> code in this case ) or introduce a new request callback.
>
> Which way is preferable from your point of view?

I would prefer a new callback since the current callback as you say is used 
for the response (or lack of response).

And if you do add a new callback, keep in mind that we don't want to break the 
ABI so you should probably add that with a new ares_set_* function.

What about resolves that are done by the use of /etc/hosts etc? Will they call 
the callback too?

--

-- 

  / daniel.haxx.se
Permalink | Reply | 6 comments |
headers
Phil Blundell | 11 Jan 2009 11:37
Favicon

Re: ares_expand_name() return codes

On Sat, 2009-01-10 at 20:08 +0100, Daniel Stenberg wrote:
> ares_expand_name() is in the API and it doesn't explicitly deal with 
> responses, thus making it returning ARES_EBADRESP seems odd.
> 
> But internally (like in all the ares_parse_*_reply() functions) in c-ares when 
> ares_expand_name() is used on a response, I think a returned error could very 
> well be translated to a ARES_EBADRESP to return from the public function that 
> was called.

Ah, right, I hadn't noticed that ares_expand_name was in the public API.

Here's a patch, then.

p.
Attachment (expand-name.diff): text/x-patch, 7479 bytes
Permalink | Reply | 1 comment |
headers
Phil Blundell | 11 Jan 2009 11:47
Favicon

workaround broken AAAA handling

Also, here's a small patch to make ares_gethostbyname() work better in
the face of nameservers which do weird things in response to AAAA
queries.

p.
Attachment (bad-v6.diff): text/x-patch, 1273 bytes
Permalink | Reply | 2 comments |
headers
Phil Blundell | 11 Jan 2009 14:29
Favicon

randomize retry timeouts

This patch adds some pseudo-random variance to the retry timers used for
c-ares requests.  

Again, this was motivated by a bad experience with the internal DNS
servers in ADSL router boxes: it seems that some of these will start
dropping requests very quickly if they receive more than a couple of
queries within a short time.  In our case, our application was sending
off a handful of requests almost simultaneously, which overwhelmed the
router and caused almost all of them to time out.  But, since the retry
time was constant for all the channels, all the retries were then
transmitted simultaneously as well, causing the same thing to happen
again and again.  Allowing c-ares to vary the exact point at which the
retransmission is sent causes the retries to end up more evenly
distributed, rather than being clumped, and reduces the chance of this
problem occurring.

p.
Attachment (timeout.diff): text/x-patch, 889 bytes
Permalink | Reply | 0 comments |
headers
Daniel Stenberg | 11 Jan 2009 14:49
Picon
Favicon
Gravatar

Re: ares_expand_name() return codes

On Sun, 11 Jan 2009, Phil Blundell wrote:

> Ah, right, I hadn't noticed that ares_expand_name was in the public API.
>
> Here's a patch, then.

Thanks, applied and commited now!

--

-- 

  / daniel.haxx.se
Permalink | Reply | 0 comments |
headers
Daniel Stenberg | 13 Jan 2009 00:20
Picon
Favicon
Gravatar

Phil Blundell for commit access!

Hello

Allow me to welcome Phil Blundell as a committer in the c-ares CVS repo, he 
can now commit his good stuff directly instead of getting slowed down by 
routing the work via me.

A note to all committers:

Remember to add proper notes to CHANGES and RELEASE-NOTES when you do changes, 
so that we keep good track of things.

--

-- 

  / daniel.haxx.se
Permalink | Reply | 0 comments |

Gmane