Label expansion problems

Hi,

I've been looking at the expansion of labels in the ares_expand_name()
function and there seems to be a bit odd logic which I cannot relate to
an RFC.

From ares_expand_name.c starting from line 102:
    if ((*p & INDIR_MASK) == INDIR_MASK)
        ...
    else
        ...

This construct detects pointers in labels, where the two MSB are set for
pointers and unset for length ((*p & 0xc0) == 0xc0). However, the other
two, notably the deprecated binary label construct of rfc2673 ((*p &
0x40) == 0x40) and the invalid ((*p & 0x80) == 0x80) are not detected.

The binary labels were described in original EDNS(0) rfc2671 and
deprecated in rfc6891.

Bind (the DNS server) uses a strict check in the on-wire label format
and disallows all values between >= 0x40 and < 0xc0. C-ares should also
disallow these invalid labels.

Then, later from line 117:
              if (*p == '.' || *p == '\\')
                *q++ = '\\';
              *q++ = *p;

The label is tested for having a backslash or period, in which the
expanded label will have a backclash prepended. However, there is no
such requirement in the RFCs. Actually, RFC2181 section 11 specifically
notes that labels may be of any arbitrary binary form/content. Adding a
backslash to the label invalidates the result and upstream cannot rely
on the content.

My guess is that the introduction of the backslash in above code stems
from RFC4343 section 2.1, which describes escaping labels. However, that
discussion describes escaping labels in zone-files, not how the resolver
should interpret labels.

The same issues as above are also present in function name_length()
(line 40 in same file).

-- 
Greetings Bertho
(disclaimers are disclaimed)