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 <[email protected]> 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
