go to bug id or search bugs for
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 non-existant-domain-name.com 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 https://bugs.php.net/bug.php?id=8264
Two test scripts:
php -r 'var_dump(checkdnsrr("non-existant-domain-name.com"));'
php -r 'var_dump(getmxrr("non-existant-domain-name.com",$mxhosts));var_dump($mxhosts);'
I would expect checkdnsrr("non-existant-domain-name.com") and getmxrr("non-existant-domain-name.com",$a) to return false.
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
Add a Pull Request
The return value is incorrect, not the return type.
I can't reproduce this issue, see <http://3v4l.org/P0nsE>.
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 claims even stranger behavior,
which I couldn't reproduce either: <http://3v4l.org/Tf5sT>.
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.