[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220921221949.GX9709@brightrain.aerifal.cx>
Date: Wed, 21 Sep 2022 18:19:49 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Other DNS/stub resolver changes
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
