Both machines are AMD64, so endianness should not be a problem. The
truss tool may be displaying them incorrectly.
Anyway. Pre-update `/package/web/s6-dns/command/s6-dnsip[46]
perihelion.ultradian.club` returns the correct response on both
machines, even if run after doing the SRV and MX lookups. Linked below
is truss output for all four invokations.
<
https://umbrellix.net./~ellenor/omnios.dnsip4.txt>
<
https://umbrellix.net./~ellenor/omnios.dnsip6.txt>
<
https://umbrellix.net./~ellenor/fbsd.dnsip4.txt>
<
https://umbrellix.net./~ellenor/fbsd.dnsip6.txt>
(side note: I'm realizing that my program makes duplicate queries. This
shouldn't impact the accuracy of the responses, but it does mean the
caches could be blocking me or something, but not blocking me when I use
/package/web/s6-dns/command/s6-dnsip[46].)
On 10/10/22 11:12, Laurent Bercot wrote:
>
>> On OmniOS, all the DNS queries (apparently 58) received a response. On
>> HardenedBSD, only the first 4 queries received a response, the next 18
>> timed out. They were retried 4 additional times, as expected, again
>> timing out without receiving a response.
>
> The fd of the async pipe to the client isn't the same in both outputs:
> it's 9 on OmniOS and 10 on HardenedBSD, which means the client uses one
> more fd on HardenedBSD for some reason. (Does OmniOS support signalfd()?
> That would explain it.)
>
> On HardenedBSD, 4 queries received responses, that were properly
> reported to the client. The others were pending and retried with longer
> timeouts, but only 6 of them reported a full timeout to the client.
> The client exited while 12 queries were technically still in flight.
>
> On OmniOS, I can't even make sense of some of the strings, typically
> in the async responses to the client. What is the endianness of this
> machine? A network byte order 32-bit number equal to 3 seems to be
> encoded as { 0, 0, 3, 0 }, which doesn't look right. (I did check my
> uint32_bswap() primitive.) If the client isn't complaining very loudly
> when it receives such strings, it means the strings are correct and the
> truss tool displays them incorrectly, which doesn't help me diagnose
> what's going on.
>
> In any case the problems look unrelated to skadnsd and come from the
> interaction between the s6-dns library and the caches: either the
> packets are correct and the caches are not sending the responses they
> should, and that's not an s6-dns problem, or the packets are malformed
> and that's why the servers are ignoring them, and I need to fix that.
> Amelia, could you do some tests (with the same caches) from s6-dns
> command-line clients such as s6-dnsip4? That will bypass the skadns
> layer, and will be easier to trace and understand. Thanks :)
>
> --
> Laurent
>
--
Amelia Bjornsdottir (she, they)
sysadmin umbrellix.net, deputy sysadmin chatspeed.net
jabber: eamon.aka.amy.malik ~on~ umbrellix.net
Received on Mon Oct 10 2022 - 19:11:54 CEST