[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220921160819.GU9709@brightrain.aerifal.cx>
Date: Wed, 21 Sep 2022 12:08:19 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Other DNS/stub resolver changes
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.
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.
