Using drill from "develop" branch with -D -T. The manpage says mentions an -a switch for fallback and ldns_resolver_new() sets fallback to true anyways (for -D -T).
In resolve.c, the ldns_resolver_send_pkt() code does not do the fallbacks when status is not LDNS_STATUS_OK. Some auth servers failed with 20 "Could not send or receive, because of network error" due to time out when it encountered too large buffer size with DO (it returns a TC truncation with small buffer size).
I propose if the first UDP query using 4096 buffer size fails due to a "timeout", it should retry again with TCP.
(Of course 4096 is probably too large.)
ldns doesn't appear to have a separate error code for "timeout" condition but gets included in LDNS_STATUS_NETWORK_ERR, There is code for timeout handling, but the results are lost. Please consider offering a LDNS_STATUS_NETWORK_TIMEOUT status and allow the resolver to fallback based on that.
Using drill from "develop" branch with -D -T. The manpage says mentions an -a switch for fallback and ldns_resolver_new() sets fallback to true anyways (for -D -T).
In resolve.c, the ldns_resolver_send_pkt() code does not do the fallbacks when status is not LDNS_STATUS_OK. Some auth servers failed with 20 "Could not send or receive, because of network error" due to time out when it encountered too large buffer size with DO (it returns a TC truncation with small buffer size).
I propose if the first UDP query using 4096 buffer size fails due to a "timeout", it should retry again with TCP. (Of course 4096 is probably too large.)
ldns doesn't appear to have a separate error code for "timeout" condition but gets included in LDNS_STATUS_NETWORK_ERR, There is code for timeout handling, but the results are lost. Please consider offering a LDNS_STATUS_NETWORK_TIMEOUT status and allow the resolver to fallback based on that.