|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #66877 Invalid return value checkdnsrr / getmxrr
Submitted: 2014-03-10 11:35 UTC Modified: 2020-08-10 19:48 UTC
Avg. Score:4.5 ± 0.9
Reproduced:4 of 4 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (25.0%)
From: nschoenmaker at hostnet dot nl Assigned: nikic (profile)
Status: Closed Package: URL related
PHP Version: 5.5.10 OS: Ubuntu 13.10
Private report: No CVE-ID: None
 [2014-03-10 11:35 UTC] nschoenmaker at hostnet dot nl
The return type of checkdnsrr and getmxrr are described as: Returns TRUE if any records are found; returns FALSE if no records were found or if an error occurred.

So if we check for a non-existant domain name, the result should be false.

The following command gives the expected result on my system, empty:
dig +short MX

Bug found using Zend server 6.3, which is released with PHP 5.5.7. Also confirmed for current master.

Related to (closed) bug

Test script:
Two test scripts:

php -r 'var_dump(checkdnsrr(""));'

php -r 'var_dump(getmxrr("",$mxhosts));var_dump($mxhosts);'
  array(0) {

Expected result:
I would expect checkdnsrr("") and getmxrr("",$a) to return false.

Actual result:
They return true.

The case of getmxrr() is even stranger, this is the description of the meaning of the second parameter:
    A list of the MX records found is placed into the array mxhosts.

This list is empty! So the return type indicates there are records, but the second in/out argument indicates there are no records...


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2014-03-10 11:41 UTC] nschoenmaker at hostnet dot nl
-Summary: Invalid return type checkdnsrr / getmxrr +Summary: Invalid return value checkdnsrr / getmxrr
 [2014-03-10 11:41 UTC] nschoenmaker at hostnet dot nl
The return value is incorrect, not the return type.
 [2015-06-10 12:55 UTC]
I can't reproduce this issue, see <>.

Interestingly, on Windows 7 (PHP 5.5.25 and 5.6.9) I get:

That is, however, another (albeit minor) issue, and should be
handled in a separate ticket.

However, a user contributed note[1] claims even stranger behavior,
which I couldn't reproduce either: <>.

[1] <>
 [2020-08-10 19:48 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: nikic
 [2020-08-10 19:48 UTC]
I expect that this issue has been resolved by the fixes for bug #78008 and bug #79944. Those are for Alpine, but the basic issue can occur on other OSes depending on the used DNS resolution library.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Jun 14 06:01:33 2024 UTC