Le 6 sept. 2015 18:53, "Conrad Hoffmann" <conrad@soundcloud.com> a écrit :
>
> Hi,
>
> I ran into the following problem: I have a server specified by hostname,
> using the new DNS feature. I initially did not specify the
"resolve-prefer"
> parameter. The initial lookup of the server succeeded and produced an IPv4
> address. Unfortunately, that address was then never updated because of the
> following situation:
>
> - In server.c:1034, resolve-prefer silently defaults to ipv6
> - The DNS server gave no records in response to ANY query
> - Resolvers check resolve-prefer, try again with AAAA query
> - Query yields no results
>
> This was a little unexpected, because the initial resolution works just
> fine. I think there are at least two possible options to improve this
> behaviour:
>
> - Document the defaulting to ipv6 and only allow ipv6 for the initial
> lookup as well (in my scenario, this would have lead to failure to
> start, leading to me adding resolve-prefer ipv4, an acceptable solution
> - Do not default to ipv6, leave as unspecified instead. If ANY query
> doesn't produce results, check current address type if no resolve-
> prefer is specified
>
> The attached patch is merely to demonstrate the latter solution. It worked
> for me, but I didn't check too hard if leaving resolver_family_priority
set
> to AF_UNSPEC might lead to other problems elsewhere.
>
> Maybe there is even other/better solutions?
>
> Regards,
> Conrad
> --
> Conrad Hoffmann
> Traffic Engineer
>
> SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany
>
> Managing Director: Alexander Ljung | Incorporated in England & Wales
> with Company No. 6343600 | Local Branch Office | AG Charlottenburg |
> HRB 110657B
Hi Conrad,
Following some recommendation provided by Jan, I sent last week a few patch
to Willy to update this behavior.
Since some servers ignore the ANY type, we failover to the family pointed
by 'resolve-prefer', if fail again, it fails over to the remaining family.
The patches also trigger a failover if the server answers a truncated
response.
I'll send you the patch by tomorrow.
I'll patch later to make haproxy send an OPT record to announce the number
of bytes it support as UDP payload.
Baptiste
>
> Hi,
>
> I ran into the following problem: I have a server specified by hostname,
> using the new DNS feature. I initially did not specify the
"resolve-prefer"
> parameter. The initial lookup of the server succeeded and produced an IPv4
> address. Unfortunately, that address was then never updated because of the
> following situation:
>
> - In server.c:1034, resolve-prefer silently defaults to ipv6
> - The DNS server gave no records in response to ANY query
> - Resolvers check resolve-prefer, try again with AAAA query
> - Query yields no results
>
> This was a little unexpected, because the initial resolution works just
> fine. I think there are at least two possible options to improve this
> behaviour:
>
> - Document the defaulting to ipv6 and only allow ipv6 for the initial
> lookup as well (in my scenario, this would have lead to failure to
> start, leading to me adding resolve-prefer ipv4, an acceptable solution
> - Do not default to ipv6, leave as unspecified instead. If ANY query
> doesn't produce results, check current address type if no resolve-
> prefer is specified
>
> The attached patch is merely to demonstrate the latter solution. It worked
> for me, but I didn't check too hard if leaving resolver_family_priority
set
> to AF_UNSPEC might lead to other problems elsewhere.
>
> Maybe there is even other/better solutions?
>
> Regards,
> Conrad
> --
> Conrad Hoffmann
> Traffic Engineer
>
> SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany
>
> Managing Director: Alexander Ljung | Incorporated in England & Wales
> with Company No. 6343600 | Local Branch Office | AG Charlottenburg |
> HRB 110657B
Hi Conrad,
Following some recommendation provided by Jan, I sent last week a few patch
to Willy to update this behavior.
Since some servers ignore the ANY type, we failover to the family pointed
by 'resolve-prefer', if fail again, it fails over to the remaining family.
The patches also trigger a failover if the server answers a truncated
response.
I'll send you the patch by tomorrow.
I'll patch later to make haproxy send an OPT record to announce the number
of bytes it support as UDP payload.
Baptiste