Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

resolve_dns hook lacks information on IPv4/IPv6 preference and can't return more than one result #461

Open
JustAnotherArchivist opened this issue Mar 19, 2021 · 0 comments

Comments

@JustAnotherArchivist
Copy link
Contributor

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:

  1. 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.
  2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant