Hi Kris, On a broad level, your RFC asserts that checkdnsrr() is used to determine "whether or not a hostname exists," but you don't actually define "exists." It seems to me you're glossing over the fact that "existence" is application-specific and doesn't add up to one single RR type or set of types.
For example, when setting up a web hosting account (www.example.com), or, say, an organization-wide account for a web app (sharepoint.example.com) when example.com's DNS is managed by the tenant, we may want to determine whether the hostname "exists": "Is there an A or CNAME RR in the DNS for that hostname?" [1] Of course, that A/CNAME needs to eventually point to your servers to be useful, but with this barebones, non-professional-grade check, we could at least tell the tenant they pre-created a record successfully. (Or, contrariwise, we could tell them the hostname already exists, so it may already be used by one of their other apps.) Note if checkdnsrr() did an ANY query, `true` would be meaningless in this context. It would be an instant false-positive if there were only an SOA and a coupla NSs. But when setting up a new user for a different kind of app, we may use their e-mail address (j...@example.com) as their username and we'll most certainly use it for a verification e-mail. Here, we might quick-check whether example.com "exists" in the mail context, giving a reasonable expectation that it will accept mail (maybe not ours, of course!): "Is there an MX, A, or CNAME RR in the DNS for that hostname?" [2] This is a different, perfectly valid way that a hostname may "exist." Note again if checkdnsrr() defaulted to ANY, `true` would be meaningless/misleading. And also note (I'll explore this again below) that an MX record is not required to accept mail. You can't decide that a domain is SMTP-nonexistent just because there's no MX. Users will just be angry if they are already receiving mail and you tell them their address hard-failed your preflight check: warn them, perhaps, but leave it up to the SMTP layer to make those hard decisions. For another example, if you run a purpose-built DNS management app, you may want to know if a domain is in the DNS at all: "Are there simply SOA and NS RRs in the DNS?" This is another completely valid meaning. You wouldn't want to check for CNAME, MX, or A here, since none of them are mandatory. True, you could in theory waste your resources on an ANY query for this one. But it is not a compelling reason to have ANY be the default. For yet another example, if I'm building an SPF test tool I want to check if TXT or SPF/99 records exist for the hostname. I don't care if the hostname has CNAME, MX, or A -- in fact, a hostname w/an SPF record solely to discourage Joe Jobs doesn't need to prove its existence in any other way. I mean, that's the thing about DNS. It serves tens of different purposes. It's not possible to assume what people are looking for when they build a specialized PHP app. It could very well be that an app doesn't ever test for existence of A/CNAME, but only existence of SRV records. Or only PTRs. On one note I fully agree. The defaulting to MX sucks. But as others have pointed out it's a BC break to try to manipulate the arg list at this point in time. I think it would be good, maybe, to update the docs with something like (though less clumsy): "This function's default behavior is to verify the existence of MX records for a hostname. MXs prove the domain owner's intent to receive mail. However, a result of `false` does not mean a domain *cannot* receive mail, as MXs are not mandatory." Perhaps try to condition people to be more aware of what they're looking up and why. As someone else said in the original thread, it's not too much to ask that PHP users who decide to use DNS functions know what they're looking up. Oh, and I also just caught a bug in the default behavior anyway. Gonna log that now! -- S. [1] Here and elsewhere "A" means "A or AAAA," although as of late 2014 the IPV6 variant isn't sufficient to establish "existence" on the public 'Net. [2] I'm deliberately setting aside the vario us CNAME interactions with MX records, which may result in successful mail delivery in many, but not all, permutations: it may be safer to consider such setups broken, as long as you let the user confirm "Yes, I vouch for my domain's setup/existence/operation even though you found problems." -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
