The resolve_dns hook is useful to override DNS to retrieve content from a server that used to be pointed at by a domain name. However, this is limited primarily by two factors:
Information on the preference of IPv4 or IPv6 is not passed to the hook, hence it can't return results accordingly.
The return value is always a str, so it's not possible to return multiple IP addresses and have wpull rotate through them with --rotate-dns. Instead, such rotation has to be handled in the hook.
The obvious resolution for the latter is to add support for a sequence (list/tuple/set/etc.) return value. While alternate hostnames could perhaps be useful sometimes in this context, this is a very rare use case and adds significant complexity, so I'd propose that all entries must be IP addresses in such a sequence. --rotate-dns could be implemented by random selection.
I see two possible ways of implementing the IPv4/IPv6 preference:
Pass the preference as an argument to the hook. The hook would have to check the value and only return IP addresses of the corresponding type.
Keep the preference out of the hook. The hook simply returns one sequence containing both IPv4 and IPv6 addresses, and the Resolver filters the results based on the preference.
I'm slightly leaning towards the latter as it keeps the hook interface simpler, and I can't think of a use case where actually knowing the preference in the hook would be important.
On a related note, it appears that the code always makes the round trip to dnspython or the system resolver, even if the hook already returned an IP address. This seems unnecessary. Instead, dns.inet.is_address could be used to check that and return directly.
The
resolve_dnshook is useful to override DNS to retrieve content from a server that used to be pointed at by a domain name. However, this is limited primarily by two factors:str, so it's not possible to return multiple IP addresses and have wpull rotate through them with--rotate-dns. Instead, such rotation has to be handled in the hook.The obvious resolution for the latter is to add support for a sequence (list/tuple/set/etc.) return value. While alternate hostnames could perhaps be useful sometimes in this context, this is a very rare use case and adds significant complexity, so I'd propose that all entries must be IP addresses in such a sequence.
--rotate-dnscould be implemented by random selection.I see two possible ways of implementing the IPv4/IPv6 preference:
Resolverfilters the results based on the preference.I'm slightly leaning towards the latter as it keeps the hook interface simpler, and I can't think of a use case where actually knowing the preference in the hook would be important.
On a related note, it appears that the code always makes the round trip to dnspython or the system resolver, even if the hook already returned an IP address. This seems unnecessary. Instead,
dns.inet.is_addresscould be used to check that and return directly.