<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "type::bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary Duo Agent Platform requires the host machine to be able to resolve public hostnames when in a proxy environment. This can cause instances with a proxy configured, but no native method of resolving hostnames to lost Duo functionality. This mainly impacts: - Duo Health Check (returns blank results) - GitLab Credits dashboard (fails to load entirely) - Various DAP functionality, including fetching available models and starting workflows with the Cloud AI Gateway GitLab team members can view the [initial internal RFH](https://gitlab.com/gitlab-com/request-for-help/-/work_items/4858). ### Steps to reproduce 1. Configure a VM with a proxy (such as Squid) and purposefully malform your `/etc/resolv.conf`. 2. Install GitLab 3. Add a licence with Duo Core add-on 4. Try to run the health check, view GitLab Credits page or use DAP functionality. ### Example Project N/A ### What is the current *bug* behavior? When a host has a proxy configured for GitLab, but is unable to resolve DNS/hostnames with `/etc/resolv.conf` (i.e. only able to resolve through the proxy), Duo functionality does not work. The Duo Health Check for instance fails with the below, when trying to use `getaddress` to determine whether to use `https_proxy` or `no_proxy` when ```json { "exception.class": "Rack::Timeout::RequestTimeoutException", "exception.message": "Request ran for longer than 60000ms", "exception.backtrace": [ "uri (1.1.1) lib/uri/generic.rb:1557:in `getaddress'", "uri (1.1.1) lib/uri/generic.rb:1557:in `find_proxy'", "net-http (0.6.0) lib/net/http.rb:1874:in `proxy_uri'", "net-http (0.6.0) lib/net/http.rb:1859:in `proxy?'", "gems/gitlab-http/lib/net_http/connect_patch.rb:41:in `connect'", "gems/gitlab-http/lib/gitlab/http_v2/net_http_adapter.rb:24:in `connect'" ] } ``` ### What is the expected *correct* behavior? This should be documented as a prerequisite for using Duo on a self-managed instance, or the logic improved to work around these scenarios. ### Relevant logs and/or screenshots ```json { "exception.class": "Rack::Timeout::RequestTimeoutException", "exception.message": "Request ran for longer than 60000ms", "exception.backtrace": [ "uri (1.1.1) lib/uri/generic.rb:1557:in `getaddress'", "uri (1.1.1) lib/uri/generic.rb:1557:in `find_proxy'", "net-http (0.6.0) lib/net/http.rb:1874:in `proxy_uri'", "net-http (0.6.0) lib/net/http.rb:1859:in `proxy?'", "gems/gitlab-http/lib/net_http/connect_patch.rb:41:in `connect'", "gems/gitlab-http/lib/gitlab/http_v2/net_http_adapter.rb:24:in `connect'" ] } ``` ### Output of checks <!-- If you are reporting a bug on GitLab.com, uncomment below --> <!-- This bug happens on GitLab.com --> <!-- and uncomment below if you have /label privileges --> <!-- /label ~"reproduced on GitLab.com" --> <!-- or follow up with an issue comment of `@gitlab-bot label ~"reproduced on GitLab.com"` if you do not --> #### Results of GitLab environment info <!-- Input any relevant GitLab environment information if needed. --> <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`) </pre> </details> #### Results of GitLab application Check <!-- Input any relevant GitLab application check information if needed. --> <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:check SANITIZE=true`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`) (we will only investigate if the tests are passing) </pre> </details> ### Possible fixes <!-- If you can, link to the line of code that might be responsible for the problem. --> ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status. #### High-severity bug remediation To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads). <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->