[musl] Other DNS/stub resolver changes

[musl] Other DNS/stub resolver changes

[Rich Felker]

In the process of working out TCP fallback support, some other
potential/likely changes to the DNS/stub resolver behavior are
emerging, which I'd like to document here and open for feedback.

The EAI_NODATA is already covered in an existing thread.

One weird thing I noticed is that, while lookup_name.c's name_from_dns
is processing error RCODE values, it actually never sees them because
__res_msend just treats errors as non-answers. This probably doesn't
matter, but it does prevent us from ever issuing EAI_FAIL. And from
the standpoint of the res_* API (res_query/res_send) the caller may be
expecting to see specific errors and to be able to act on them (todo:
check what other implementations do here).

The reason __res_msend doesn't return errors packets is a consequence
of implementation details, specifically, that it considers erroring
slots unanswered, and reuses the buffer for them as temp space to
receive answers that might turn out to be for another query, which
clobbers them.

This is rather ugly, and I think I'd like to give __res_msend its own
512-byte receive buffer to receive into. This would give us the choice
to keep error results or not, as we see fit, rather than tying us to
the current behavior.

I almost said this would also avoid tying the receive logic to a
choice to use one socket per TCP query vs doing multiple queries over
the same TCP socket, since all reads could just take place into this
buffer. However, that ignores pathological partial reads, whereby we
might have to wait after receiving the first 1-3 bytes to get the 4th
byte and know which query the answer belongs to. So if we want to do
that, we need a 3-byte buffer for each tcp socket where we might have
received data but not yet know which query it goes with. However we
can still recv into the 512-byte receive buffer, and then only move to
a 3-byte pending buffer if it's <=3 bytes, and otherwise move to the
appropriate answer buffer.

Re: [musl] Other DNS/stub resolver changes

[Rich Felker]

On Wed, Sep 21, 2022 at 12:08:19PM -0400, Rich Felker wrote:
> In the process of working out TCP fallback support, some other
> potential/likely changes to the DNS/stub resolver behavior are
> emerging, which I'd like to document here and open for feedback.
> 
> The EAI_NODATA is already covered in an existing thread.
> 
> One weird thing I noticed is that, while lookup_name.c's name_from_dns
> is processing error RCODE values, it actually never sees them because
> __res_msend just treats errors as non-answers. This probably doesn't
> matter, but it does prevent us from ever issuing EAI_FAIL. And from
> the standpoint of the res_* API (res_query/res_send) the caller may be
> expecting to see specific errors and to be able to act on them (todo:
> check what other implementations do here).

At least glibc seems to have no code paths that can produce EAI_FAIL,
and empirically, their res_query returns -1/failure when the
nameserver gives ServFail (tested with lookup of dnssec-failed.org)
rather than making the error packet available to the caller.

> The reason __res_msend doesn't return errors packets is a consequence
> of implementation details, specifically, that it considers erroring
> slots unanswered, and reuses the buffer for them as temp space to
> receive answers that might turn out to be for another query, which
> clobbers them.
> 
> This is rather ugly, and I think I'd like to give __res_msend its own
> 512-byte receive buffer to receive into. This would give us the choice
> to keep error results or not, as we see fit, rather than tying us to
> the current behavior.

As such, I think perhaps I should just leave this alone. Leaving it
alone saves 512 bytes of stack, and doesn't really make the work of
adding TCP any harder.

One remaining motivation for having our own buffer here is that, in
the case where the caller of res_send only provides a small buffer
(smaller than 512 bytes), we would not be able to determine if a
packet equal to the buffer length had been truncated (by the recv
function on the client side) without TCP fallback. This is a mess I
don't want to get into. However, rather than spending an extra 512
bytes of stack in the __res_msend DNS query core, we can just make
"buffer must be >= 512 bytes" part of __res_msend's contract, and
res_send can be responsible for using a local buffer of its own if the
application's buffer is too small, then copying the result.

Rich