In working on #12778 I found there is not an easy way to test more uncommon DNS scenarios where tight control of responses and errors is needed.
For the pure Go stub resolver consider restructuring things to make this easier, such as with the ability to swap out real TCP/UDP connections for a stub so tight control is possible while still exercising the bulk of code.
@mdempsky mentioned considering possibly related restructuring for #13281.
The text was updated successfully, but these errors were encountered:
With certain names and search domain configurations the
returned error would be one encountered while querying a
generated name instead of the original name. This caused
confusion when a manual check of the same name produced
different results.
Now prefer errors encountered for the original name.
Also makes the low-level DNS connection plumbing swappable
in tests enabling tighter control over responses without
relying on the network.
Fixes#12712
Updates #13295
Change-Id: I780d628a762006bb11899caf20b5f97b462a717f
Reviewed-on: https://go-review.googlesource.com/16953
Reviewed-by: Russ Cox <rsc@golang.org>
In working on #12778 I found there is not an easy way to test more uncommon DNS scenarios where tight control of responses and errors is needed.
For the pure Go stub resolver consider restructuring things to make this easier, such as with the ability to swap out real TCP/UDP connections for a stub so tight control is possible while still exercising the bulk of code.
@mdempsky mentioned considering possibly related restructuring for #13281.
The text was updated successfully, but these errors were encountered: