On Mon, Sep 22, 2014 at 8:09 PM, Sanford Whiteman <figureone...@gmail.com> wrote:
> 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 agree that it would be a BC, but I believe it would be a very minor one, as I doubt very many people are relying on the current default behavior. This minor level of BC would not be inappropriate for a major version increment, as it's expected that there will be at least some BC there. Based on your comments relating to DNS in general, it sounds like defaulting to "ANY" wouldn't be much better than the current default. I'm beginning to lean heavily towards removing the second voting option and limiting the scope of the RFC to just making the second argument required for this reason. What would happen is it'd throw an E_DEPRECATED for at least the remainder of 5.x, then throw the usual E_WARNING for a missing argument starting in 7.x with no default. It has been my observation that a number of good ideas (and fixes to bad ideas) have been set aside over fears of BC breakage. While I agree there's certainly a place for such caution, refusing to ever allow any BC for such improvements even in major version increments essentially ties our hands together and prevents the language from evolving past some of its negative aspects. BC is, by its very nature, a short-term concern. I doubt anybody is experiencing any problems caused by any BC that occurred between PHP 3 and PHP 4, for example. That's why I think major version increments are the ideal time to implement more long-term objectives that may carry a marginal short-term BC cost. Given that just about everyone here agrees that the current behavior is more or less ridiculous that doesn't serve any use cases not better served elsewhere, that alone should be sufficient reason to vote yes on this. I'll update the RFC later to reflect the feedback people have given here thus far. I'll most likely be removing the second voting option and instead just make it a required argument-- if anybody objects to this part, please say so now and we'll discuss further. I'll also change E_ERROR to E_WARNING to make it consistent with how other functions deal with missing args. Am I missing anything? --Kris > 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 > >
