Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #411
Description
While chasing down an issue in the IPv6 recursive resolution, I was having a hard time understanding why we made some of the DNS lookups we did.
That led me to see this section of code in the
cachedRetryingLookup
fn that I couldn't explain why it is there or how it didn't break iterative lookups.At first glance it looks like it's trying to save a lookup for the nameservers, but it's then returning this
NS
result regardless of what the originalQuestion.Type
was. This messes up the recursion for some domains, see theTesting
section.Removing it seems to solve the issue reported in #411. It seems to have been added as a performance enhancement, but I cannot explain how it doesn't make the resolution of some domains mess up. Additionally, removing it improves performance and I don't see how it drops accuracy.
Testing
This always works:
echo "www.meteo.it" | ./zdns A --iterative
However, when trying to resolve 6k domains, with
www.meteo.it
being towards the back of that list (and therefore giving the cache plenty of time to cache entries and this code to then be called)main (repeated 3 times with same results)
There is a
SERVFAIL
. I testedv1.1.0
andv1.0.0
with the same test with similar (orITERATION_TIMEOUT
error) results asmain
, so it seems this has been there for a while.Phillip/411 (repeated 3 times)
Performance
Looking at that code, I can't think of an issue with accuracy since going to the wire should be at least as accurate as the cache, and more if the cache is being polluted or used inaccurately. But I was worried there'd be a marked downgrade in performance without this caching. Using the benchmark though, the runtime halved and the number of failed domains decreased significantly.
main
Phillip/411