William Ahern:

I'm not quite sure how this was happening, but I've been seeing PTR queries
  which seem to return empty responses. At least, they were empty when calling
  ares_expand_name() on the record. Here's a patch which guarantees to
  NUL-terminate the expanded name. The old behavior failed to NUL-terminate if
  len was 0, and this was causing strlen() to run past the end of the buffer
  after calling ares_expand_name() and getting ARES_SUCCESS as the return
  value. If q is not greater than *s then it's equal and *s is always
  allocated with at least one byte.

ares/CHANGES

@@ -1,5 +1,19 @@
   Changelog for the c-ares project
 
+* June 2
+
+- William Ahern:
+
+  I'm not quite sure how this was happening, but I've been seeing PTR queries
+  which seem to return empty responses. At least, they were empty when calling
+  ares_expand_name() on the record. Here's a patch which guarantees to
+  NUL-terminate the expanded name. The old behavior failed to NUL-terminate if
+  len was 0, and this was causing strlen() to run past the end of the buffer
+  after calling ares_expand_name() and getting ARES_SUCCESS as the return
+  value. If q is not greater than *s then it's equal and *s is always
+  allocated with at least one byte.
+
+
 * May 16
 
 - Added ares_getnameinfo which mimics the getnameinfo API (another feature

ares/ares_expand_name.c

@@ -106,6 +106,8 @@ int ares_expand_name(const unsigned char *encoded, const unsigned char *abuf,
   /* Nuke the trailing period if we wrote one. */
   if (q > *s)
     *(q - 1) = 0;
+  else
+    *q = 0; /* zero terminate */
 
   return ARES_SUCCESS;
 }