php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #68081 checkdnsrr( 'example.com' ) returns `true` when no MX, only CNAME
Submitted: 2014-09-23 03:52 UTC Modified: 2022-05-11 15:04 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:0 of 1 (0.0%)
From: figureonecpr at gmail dot com Assigned:
Status: Open Package: Network related
PHP Version: master-Git-2014-09-23 (snap) OS: Linux Phoenix 2.6.32
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
4 + 33 = ?
Subscribe to this entry?

 
 [2014-09-23 03:52 UTC] figureonecpr at gmail dot com
Description:
------------
Per http://php.net/manual/en/function.checkdnsrr.php, checkdnsrr() defaults to an MX record query when the second argument is not supplied.  Regardless of SMTP's implicit MX logic, this function is supposed to return `false` if $host does not have at least one *explicit* MX in the DNS.

However, if the supplied hostname simply has a CNAME record (a good CNAME, one that can be dereferenced to an extant canonical hostname) the function returns `true`.  

The bug is seen regardless of whether the canonical hostname itself has an MX record.   For example, if you have somehost.example.com CNAME --> example.com A and do checkdnsrr( 'somehost.example.com' ) you will get `true`.  But if you go straight to the canonical A record and do checkdnsrr( 'example.com' ) you will get `false`.


Test script:
---------------
// where cname.example.com exists is a CNAME in the DNS pointing to an extant canonical hostname

var_dump( checkdnsrr( 'cname.example.com' ) );


Expected result:
----------------
boolean(false)

Actual result:
--------------
boolean(true)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-09-23 04:54 UTC] kriscraig@php.net
-Assigned To: +Assigned To: kriscraig
 [2014-09-23 04:56 UTC] kriscraig@php.net
Could you include the actual hostname you used?  That'll make it easier for me to repro.

Thanks!

--Kris
 [2014-09-23 07:19 UTC] figureonecpr at gmail dot com
You can use

    phpbug68081.trueklyn.com

at present.
 [2014-09-23 18:44 UTC] figureonecpr at gmail dot com
Note the dn does the same thing with other RRtypes: treats the existence of a CNAME as a positive result.  This bug cripples the function into unusability.  
The example I also posted to the mailing list is that checkdnsrr( 'www.php.net', 'SRV' ) returns `true`.  And you do not have an SRV record (as a Windows guy I would've been surprised if you did!).
 [2017-10-24 08:12 UTC] kalle@php.net
-Status: Assigned +Status: Open -Assigned To: kriscraig +Assigned To:
 [2022-05-11 00:25 UTC] jeff at systasis dot co
Hi - I think this can be resolved by checking the actual answer instead of the count of returned answers.
I'm assuming that `rectype` gets properly initialized when NULL by the parameter processing logic.
If you agree, I'll fork 7.4 based on 
3v4l.org/BoGri/rfc#output
 [2022-05-11 14:29 UTC] cschneid@php.net
If I understand correctly you want to fix it for 7.4 but AFAIK such fixes should be done on master and then backported by the release managers.

Please correct me if I'm wrong :-)
 [2022-05-11 15:04 UTC] cmb@php.net
Bug fixes should target the lowest branch which is actively
supported (currently PHP-8.0).  If there are BC concerns, then
master should be targeted.

See also <https://github.com/php/php-src/blob/master/CONTRIBUTING.md>.
 [2023-06-18 07:48 UTC] aushikshiv2 at gmail dot com
Daily Fitness Post are sharing latest news about about daily health, daily fitness, treatment, daily weight loss, diet, exercise, azima etc. More info to visit:(https://dailyfitnesspost.com)github.com
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 17:01:30 2024 UTC