Got PHP 7.2.34-13+ubuntu18.04.1+deb.sury.org+1 (cli) and same problem here, even @ doesn't help..

Is this still an issue with any of the actively supported PHP
versions[1]?

[1] <https://www.php.net/supported-versions.php>

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.

This error is due to the fact that the default value for the $type argument is DNS_ANY, which is ignored by most DNS servers.

dns_get_record('radioantwerpen.be') doesn't work, but dns_get_record('radioantwerpen.be', DNS_A) does.


Source: https://dustri.org/b/a-short-tale-on-phps-dns_get_record.html

Okay, changing to doc bug then.  Thanks!

We ran into this when querying for 'DNS_A', 'DNS_AAAA' or 'DNS_CNAME' records.

Code in question is here: https://github.com/nextcloud/server/blob/master/lib/private/Http/Client/DnsPinMiddleware.php#L83

It looks like this is independent of the type - just that 'DNS_ANY' requests are mor likely to cause a server failure.

However even with a server failure there should be a way to handle the situation - either by returning false or by throwing a well defined error that can be caught.

Still experiencing same as what "max at nextcloud dot com" stated but with DNS_NS and with PHP 8. This cannot be a doc bug. It must be when the records cannot be found, ie the given domain does not exist etc.

It's returning `false` for me just fine though (even with the error message) which can be checked more easily with var_dump, but it does appear that dns_get_record() is more noise-y than, say, dns_check_record() because it tries to translate the errno output if the dns lookup fails.

The second issue is that sometimes it translates to TRY_AGAIN and other times to - presumably - either NO_DATA or HOST_NOT_FOUND here:

https://github.com/php/php-src/blob/15bdc85e005e4e750428b8a9f7d6460dc126c4ff/ext/standard/dns.c#L958-L981

This is in contrast to, say, dns_check_record(), which doesn't bother: https://github.com/php/php-src/blob/15bdc85e005e4e750428b8a9f7d6460dc126c4ff/ext/standard/dns.c#L426-L431

So that accounts for the noisiness.

How I'm able to consistently reproduce the behavior: The "A temporary server error occurred" message goes away when I do an nslookup in between on the same non-existent domain. If I don't, it continues. (P.S. To repeat the same behavior (i.e. the noisy output) you have to pick a *new* non-existent domain once you've gone through the dns_get_record/nslookup/dns_get_record sequence).

Also, my gut is telling me the the inconsistent errno may be a red herring in the end, but I haven't dug into what would account for the errno changing in between calls. Possibly some DNS resolver caching/etc. where in one case it isn't certain it's more than a temporary failure and in another situation it's able to conclude "nah this really doesn't exist".

I get this error when asking duckdns dor dynamic lookup that fails
Warning:"A temporary server error occurred"

if php has flag show all this will show as an error with E_WARNING status
this is my workaround:
function NoWarnings($errno, $errstr, $errfile, $errline){ return true; }
   
$oldhandler = set_error_handler('NoWarnings', E_WARNING );  
$dns = dns_get_record( $dnsname );
set_error_handler( $oldhandler, E_WARNING );  
@ does not supress the Warning

I was looking into this and I don't think we can treat this as a bug but it's also not a doc bug (it's already documented that this function can fail with `false`). Instead we should treat this as a feature request.

I created a feature request with proposed solution in https://github.com/php/php-src/issues/17919 (comments can be added there as they are closed for anonymous users in this bug tracker).