Re: [s6-dns] is there a particular reason skadns_packet would return NULL errno ENETUNREACH?

From: Ellenor Bjornsdottir <>
Date: Thu, 06 Oct 2022 16:39:41 +0000

Neither of those conditions actually apply - my network is up and my resolver is responding (albeit slowly - it takes about a second). I get the expected response on the first batch of queries I fire off, but then the second batch gets ENETUNREACH. This happens every time I run my program (albeit on special snowflake illumos; I have not tried on other OSes).

On 6 October 2022 11:23:20 UTC, Laurent Bercot <> wrote:
>> i source spelunked and the story is that, if the error is coming from s6dns_engine_prepare, dt->protostate exceeds or equals 4. I chased that struct member around a few times and I couldn't figure out what it means to s6dns.
> dt->protostate is used for two things:
> - in UDP mode, to track how many times the query has been sent to the
>whole list of caches and all of them have failed to answer within a
>given timeout. The timeout increases for each round.
> - in TCP mode, to track how many bytes of the query have been written
>and how many bytes of the answer have been received (a congested
>network may result in short writes or reads).
> The error you got indeed happens when you're in UDP mode (the starting
>default for every query), dt->protostate has reached 4 and
>s6dns_engine_prepare() returns 0 ENETUNREACH, which
>s6dns_engine_timeout() stores into dt->status and skadnsd then sends
>back to your client.
> What it means is that your query was sent in succession to every
>cache listed in dt->servers (most likely, the list of "nameserver"
>entries in your /etc/resolv.conf, unless you overrode it with the
>DNSCACHEIP environment variable), and every one of them failed to
>answer within 1 second, then within 3 seconds, then within 11
>seconds, then within 45 seconds. That sounds like either your
>nameserver list is bad, or your own network is down; and s6-dns reports
> Laurent

Ellenor Bjornsdottir (she)
Received on Thu Oct 06 2022 - 18:39:41 CEST

This archive was generated by hypermail 2.4.0 : Thu Oct 06 2022 - 18:40:34 CEST