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 <ska-skaware_at_skarnet.org> 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
>this as ENETUNREACH.
>
>--
> Laurent
>
--
Ellenor Bjornsdottir (she)
sysadmin umbrellix.net
Received on Thu Oct 06 2022 - 18:39:41 CEST