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
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