Subject: ares_expand_name() return codes

ares_expand_name() return codes

From: Phil Blundell <pb_at_reciva.com>
Date: Fri, 09 Jan 2009 22:34:07 +0000

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.
Received on 2009-01-09