[squid-users] Recent Squid 4 versions show ERR_CANNOT_FORWARD instead of ERR_DNS_FAIL

[Alex Rousskov]

On 8/9/23 08:14, Tommy Brunn wrote:

> It's been 5 years since this was originally posted, but I am currently
> in the process of upgrading from Squid 4.13 to 5.8,

FWIW, you should be upgrading to v6 instead. Squid v5 maintainer does 
not expect making regular bug-fixing v5 releases:
https://github.com/squid-cache/squid/pull/1346#issuecomment-1668901339


> and have
> encountered the same scenario when running our integration tests to
> validate the existing behavior. To summarize, given the exact same
> configuration in both versions, making a CONNECT request for a domain
> that doesn't exist used to result in a 503 response with an
> ERR_DNS_FAIL error. In Squid 5.8 this instead results in a 500
> response with an ERR_CANNOT_FORWARD error.

Mishandling/misreporting ERR_DNS_FAIL is a known problem. Or two. IIRC, 
at least two different scenarios suffer from that problem, one ends up 
with ERR_CANNOT_FORWARD and one with ERR_READ_ERROR.

FWIW, the Squid Project is improving CI tests to detect such unexpected 
changes in the future.


> For reference, I am using the version of Squid that is packaged in the
> most recent version of Amazon Linux 2023.
> I have attached verbose debug logs from > squid, as well as the squid configuration file, the full output of
> `squid -v` and finally the output of `dig` on the non-existent domain
> from the same context as squid is running in:
> https://gist.github.com/Nevon/ee4d379877b9570cccb4f21df7382a63

Thank you for sharing those details. When developers start working on a 
fix, they may find them very useful (if they can find them at that 
time). You may also want to post a bug report on Squid Bugzilla.


> Does anyone know if this is an intentional change or a bug?

The change was not intentional. In most cases, it is a bug: A catch-all 
ERR_CANNOT_FORWARD should not be used when a more specific ERR_X applies.


## Current 503 vs old 500 status code

Please note that not all ERR_DNS_FAIL should result in HTTP 503 (Service 
Unavailable) responses AFAICT.

For example, RFC 9209 section 2.3.2 recommends that DNS NXDOMAIN 
responses result in HTTP 502 (Bad Gateway) responses:
https://www.rfc-editor.org/rfc/rfc9209.html#section-2.3.2

However, the above recommendation does not quite match RFC 9110 
description of HTTP 502 (Bad Gateway) status code because NXDOMAIN is 
not an "invalid response" (it is a valid error response):
https://www.rfc-editor.org/rfc/rfc9110#section-15.6.3

The presence of multiple errors during forwarding attempts complicates 
the situation further.

Given all these uncertainties, if your infrastructure relies on a very 
specific HTTP status response code, it may be a good idea to redesign.


HTH,

Alex.