Doc #73149 [Com]: dns_get_record(): A temporary server error occurred
[email protected] ("josh dot t dot richards at gmail dot com") Mon, 10 Jul 2023 02:47:37 +0000
| Newsgroups | php.doc.bugs |
|---|---|
| Message-ID | <[email protected]> |
Edit report at https://bugs.php.net/bug.php?id=73149&edit=1 ID: 73149 Comment by: josh dot t dot richards at gmail dot com Reported by: walter at oradio dot be Summary: dns_get_record(): A temporary server error occurred Status: Open Type: Documentation Problem Package: Network related Operating System: Linux Mint 17 Qiana and Centos 7 PHP Version: 5.6.26 Block user comment: N Private report: N New Comment: 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". Previous Comments: ------------------------------------------------------------------------ [2023-04-20 08:33:11] 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. ------------------------------------------------------------------------ [2021-11-08 11:06:11] 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. ------------------------------------------------------------------------ [2021-07-15 10:42:30] [email protected] Okay, changing to doc bug then. Thanks! ------------------------------------------------------------------------ [2021-07-15 10:30:53] 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-06-06 04:22:08] 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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=73149 -- Edit this bug report at https://bugs.php.net/bug.php?id=73149&edit=1