Jesse
On Wed, Oct 28, 2015 at 5:25 PM, Jesse Hathaway <je...@mbuki-mvuki.org> wrote:
> On Tue, Oct 27, 2015 at 8:18 PM, Baptiste <bed...@gmail.com> wrote:
>> #2 an error in the way we parse CNAME responses, leading to return an
>> error when validating a CNAME (this triggers bug #1).
>
> How does your patch for this issue change the logic? It appears
> functionally the same to me.
Good catch, forget about patch 00001, It was 2AM in the morning when I
wrote it :'(...
I wanted to apply the same code as DNS_UPD_NO_IP_FOUND, and increment
the OTHER error.
Actually, the bug was triggered because the status of the resolution
was never updated in this very particular case (first DNS response,
can't find requested name in the response), which lead the code to
resend a packet, creating a loop.
Ben, could you apply the patch below instead of 0001:
diff --git a/src/server.c b/src/server.c
index dcc5961..c92623d 100644
--- a/src/server.c
+++ b/src/server.c
@@ -2620,6 +2620,17 @@ int snr_resolution_cb(struct dns_resolution
*resolution, struct dns_nameserver *
}
goto stop_resolution;
+ case DNS_UPD_NAME_ERROR:
+ /* if this is not the last expected response,
we ignore it */
+ if (resolution->nb_responses <
nameserver->resolvers->count_nameservers)
+ return 0;
+ /* update resolution status to OTHER error type */
+ if (resolution->status != RSLV_STATUS_OTHER) {
+ resolution->status = RSLV_STATUS_OTHER;
+ resolution->last_status_change = now_ms;
+ }
+ goto stop_resolution;
+
default:
goto invalid;
I'll also test it in our amazon lab later tonight.
Then I'll ask Willy to merge them.
Jesse, thanks again for catching this!
Baptiste
