>> Baptiste, whats the current behavior when an empty response with
>> NOERROR is received?
>>
>> Regards,
>>
>> Lukas
>
>
> Hi,
>
> This is already handled when I detect response without NX code and no
> response records (DNS_RESP_ANCOUNT_ZERO) or no response record
> corresponding to the query
On Wed, Oct 21, 2015 at 1:24 PM, Lukas Tribus wrote:
> Hi Robin,
>
>
>> Hey guys,
>>
>> Actually when you get an NXDOMAIN reply you can just stop resolving that
>> domain. Basically there are 2 types of "negative" replies in DNS:
>>
>> NODATA: basically this is when you don't
Hey guys,
Actually when you get an NXDOMAIN reply you can just stop resolving that
domain. Basically there are 2 types of "negative" replies in DNS:
NODATA: basically this is when you don't get an error (NOERROR in dig),
but not the actual data you are looking for. You might have gotten some
Hi Robin,
> Hey guys,
>
> Actually when you get an NXDOMAIN reply you can just stop resolving that
> domain. Basically there are 2 types of "negative" replies in DNS:
>
> NODATA: basically this is when you don't get an error (NOERROR in dig),
> but not the actual data you are looking for. You
Hey Willy,
Recursors are not required to recurse when serving an ANY query. ANY
query means that you ask a server (either recursor or auth) for
everything it has on label x. If it has a CNAME on that label just
returning that is a valid response (just like would happen if you
queried for the
Hi Robin,
[merging your reply and Lukas']
On Tue, Oct 20, 2015 at 08:59:27AM +0200, Robin Geuze wrote:
> Hey Willy,
>
> Recursors are not required to recurse when serving an ANY query. ANY
> query means that you ask a server (either recursor or auth) for
> everything it has on label x. If it has
Hi Andrew,
There is a bug repeated twice in your code.
In both dns_reset_resolution() and trigger_resolution(), you use
"resolution->resolver_family_priority" before it is positioned. This
may lead to using the last resolution->resolver_family_priority, which
may be different than the server one.
Hi Andrew,
On Mon, Oct 19, 2015 at 05:39:58PM -0500, Andrew Hayworth wrote:
> The ANY query type is weird, and some resolvers don't 'do the legwork'
> of resolving useful things like CNAMEs. Given that upstream resolver
> behavior is not always under the control of the HAProxy administrator,
> we
> Hi Andrew,
>
> On Mon, Oct 19, 2015 at 05:39:58PM -0500, Andrew Hayworth wrote:
>> The ANY query type is weird, and some resolvers don't 'do the legwork'
>> of resolving useful things like CNAMEs. Given that upstream resolver
>> behavior is not always under the control of the HAProxy
On Tue, Oct 20, 2015 at 07:36:20PM +0200, Lukas Tribus wrote:
> Hi,
>
>
> >> A simple option in the resolvers section to instruct HAPoxy to not
> >> forgive on NX and failover to next family:
> >> option on-nx-try-next-family
> >
> > I personally find this confusing from the user's point of
> I don't know. I'm always only focused on the combination of user-visible
> changes and risks of bugs (which are user-visible changes btw). So if we
> can do it without breaking too much code, then it can be backported. What
> we have now is something which is apparently insufficient to some
Hi,
>> A simple option in the resolvers section to instruct HAPoxy to not
>> forgive on NX and failover to next family:
>> option on-nx-try-next-family
>
> I personally find this confusing from the user's point of view.
Agreed, we should have good and safe defaults, and address corner
cases
On Tue, Oct 20, 2015 at 06:26:38PM +0200, Baptiste wrote:
> > Also, we will have to address the issue that a server may just use
> > a single address-family, therefor we have to fallback between A
> > and , because a NX on a query doesn't mean there are no
> > A records.
>
> Hi Lukas,
>
> Also, we will have to address the issue that a server may just use
> a single address-family, therefor we have to fallback between A
> and , because a NX on a query doesn't mean there are no
> A records.
Hi Lukas,
I do agree on this point.
A simple option in the resolvers section to
On Tue, Oct 20, 2015 at 9:09 PM, Lukas Tribus wrote:
>> I don't know. I'm always only focused on the combination of user-visible
>> changes and risks of bugs (which are user-visible changes btw). So if we
>> can do it without breaking too much code, then it can be backported.
Hi Andrew,
I've updated your patch quickly so Willy can integrate it.
I've also updated the commit message to follow Lukas recommendations.
Baptiste
On Tue, Oct 20, 2015 at 2:26 PM, Baptiste wrote:
> Hi Andrew,
>
> There is a bug repeated twice in your code.
> In both
On Tue, Oct 20, 2015 at 10:07:16PM +0200, Baptiste wrote:
> Hi Andrew,
>
> I've updated your patch quickly so Willy can integrate it.
> I've also updated the commit message to follow Lukas recommendations.
Thanks Baptiste, I've merged it and backported it to 1.6.
I'm tempted to issue 1.6.1 right
On Tue, Oct 20, 2015 at 10:20:50PM +0200, Baptiste wrote:
> On Tue, Oct 20, 2015 at 9:09 PM, Lukas Tribus wrote:
> >> I don't know. I'm always only focused on the combination of user-visible
> >> changes and risks of bugs (which are user-visible changes btw). So if we
> >>
Oh wonderful - something's come up that would have blocked me from
working on this until next week, so thank you very much for updating
it for me!
On Tue, Oct 20, 2015 at 3:07 PM, Baptiste wrote:
> Hi Andrew,
>
> I've updated your patch quickly so Willy can integrate it.
> I've
19 matches
Mail list logo