Home Original page

A temporary server error occurred

Request #73149 dns_get_record(): A temporary server error occurred
Submitted: 2016-09-23 14:36 UTC Modified: 2025-02-24 19:22 UTC
Votes:142
Avg. Score:4.1 ± 1.0
Reproduced:138 of 138 (100.0%)
Same Version:23 (16.7%)
Same OS:25 (18.1%)
From: walter at oradio dot be Assigned: bukka (profile)
Status: Assigned Package: Network related
PHP Version: 5.6.26 OS: Linux Mint 17 Qiana and Centos 7
Private report: No CVE-ID: None

 [2016-09-23 14:36 UTC] walter at oradio dot be

Description:
------------
[regression] dns_get_record does not return false on dns server failure

When doing a nslookup for this domain: radioantwerpen.be the response is:

;; Got SERVFAIL reply from 83.149.80.123, trying next server
Server:		83.149.80.123
Address:	83.149.80.123#53

** server can't find radioantwerpen.be: NXDOMAIN

Note:
-----
This worked on PHP version 5.5x, but when I upgraded to 5.6.26 this error occurred. The same error occurs on the production server, which is a different machine with a different OS, but same PHP version.

This is a regression from bug: #53092  ( https://bugs.php.net/bug.php?id=53092 ) . It was closed in 2014.



Test script:
---------------
$url = "radioantwerpen.be";
$result = dns_get_record($url);
print_r($result);

Expected result:
----------------
return empty array

Actual result:
--------------
throws "Warning: dns_get_record(): A temporary server error occurred. in ..."
and returns nothing (no array)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

 [2021-02-24 15:30 UTC] idem84 at me dot com

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

 [2021-05-28 11:24 UTC] cmb@php.net

-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb

 [2021-06-06 04:22 UTC] php-bugs at lists dot php dot net

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.

 [2021-07-15 10:30 UTC] e6990620 at gmail dot com

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

 [2021-07-15 10:42 UTC] cmb@php.net

-Status: No Feedback +Status: Open -Type: Bug +Type: Documentation Problem -Assigned To: cmb +Assigned To:

 [2021-07-15 10:42 UTC] cmb@php.net

Okay, changing to doc bug then.  Thanks!

 [2021-11-08 11:06 UTC] max at nextcloud dot com

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.

 [2023-04-20 08:33 UTC] dewald at appturelab dot com

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.

 [2023-07-10 02:47 UTC] josh dot t dot richards at gmail dot com

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".

 [2024-03-16 10:36 UTC] tummen at jgd dot se

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

 [2025-02-24 19:22 UTC] bukka@php.net

-Type: Documentation Problem +Type: Feature/Change Request -Assigned To: +Assigned To: bukka

 [2025-02-24 19:22 UTC] bukka@php.net

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).