Add SRV DNS record support to HTTP Operator

[gtxu]

This pull request allows an HTTP connection resolve its target host and port from a DNS SRV record instead of a fixed host/port, so it can talk to services published via SRV-based service discovery(ie. AWS Service Discovery for ECS).

This changes introduces dnspython as an optional dependency to keep the core HTTP provider lightweight. To prevent DNS query flooding, a TTL cache mechanism is implemented.

• Implemented soft dependency via the srv extra.

• Built RFC 2782 compliant failover (lowest priority tier filtering and random target selection).

• Added concurrency-safe TTL caching (srv_cache_ttl) using asyncio.Lock to prevent cache stampedes in asynchronous contexts.

• Exposed srv_lookup and srv_cache_ttl configuration directly in the Airflow Connection UI via custom form widgets.

closes: #9186

---

Was generative AI tooling used to co-author this PR?

• Yes - Claude Sonnet 5

Generated-by: Claude Sonnet 5 following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[aaron-y-chen]

Thanks for the PR 🙂

[omkar-foss]

PR looks good to me overall. Newly added tests are looking well-covered, would be nice if someone could initiate the ci checks in this PR so we can see them run and pass.

PS: I'm not a maintainer, my review is non-binding. Just trying to help out :)

[gtxu]

Found out the root cause CI failures (3/3 runs) targeting TestHttpAsyncHookSrvLookup::test_run_resolves_srv_record.
The test was failing with a real network query (dns.resolver.NoAnswer), bypassing the mock, yet consistently passing in local environments.

In Python 3.10(CI Env), mock.patch uses _dot_lookup (which calls getattr), meaning it successfully patched the stale attribute on the dns package. When the hook subsequently executed import dns.asyncresolver, it found no entry in sys.modules, loaded a fresh real module, and bypassed the mock entirely.

Python 3.12 uses pkgutil.resolve_name, which performs a real import and self-heals, explaining why the test failure is not identified in my local test.

Added a stable_dns_import fixture for both SRV test classes.

This fixture re-registers the submodules:

importlib.import_module("dns.resolver")
importlib.import_module("dns.asyncresolver")

---

Drafted-by: Claude Code (Sonnet 5); reviewed by @gtxu

[ashb]

I can understand your reasoning, but I don't think this is right for two reasons.

1. DNS caching is a notoriously complex thing to deal with (do you cache poisitve, or NX/negative answers too)
2. The practical benefit of caching is very limited, because this caching will apply to exactly one connection, which in all likely hood will just resolve one host then make connections to it.

[gtxu]

Hi @ashb , I agree with your feedback that we should drop the DNS caching.

One thing worth noting for callers using the multi-call async session pattern (HttpAsyncHook.session()) with SRV lookup enabled: without a cache, resolving the SRV record fresh on every request means the target host/port can change between calls. That effectively defeats aiohttp's pooled TCPConnector (which keys connections on (scheme, host, port)), so TCP keep-alive won't be as effective across those dynamic routes. Given the short-lived HttpHook/HttpAsyncHook instances in Airflow tasks, this trade-off is minor.

Removed cache from hooks and tests. Thank you for reviewing this PR!