[RFC] Change checkdnsrr() $type argument behavior

From what I can tell, there are valid arguments to be made for both, so
I
would love to see some discussion/debate here regarding which solution
should be implemented, as I'm currently undecided. Also please feel
free
to point out any areas of improvement for the RFC itself.

Functions don't throw E_ERROR on missing argument.

And ANY is about as bad as MX.

I can fix that. What would be the customary one to throw for a missing arg?

--Kris

hi Kris,

Per discussion in an earlier thread. Here's the RFC:

https://wiki.php.net/rfc/checkdnsrr-default-type

Basically, this RFC seeks to make it so that PHP's checkdnsrr()
function,
which is most commonly used to see whether or not a hostname exists, no
longer restricts itself to only MX records by default.

Though the RFC itself is a no-brainer, the more difficult question is
which
solution should be implemented. The two options currently presented are
changing default from "MX" to "ANY", which would cause it to check all
records and not just MX; and getting rid of the default altogether and
making it so that the argument is required.

From what I can tell, there are valid arguments to be made for both, so
I
would love to see some discussion/debate here regarding which solution
should be implemented, as I'm currently undecided. Also please feel
free
to point out any areas of improvement for the RFC itself.

I am not sure which problem this RFC tries to solve, do you have any
example showing the issues please?

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

It's not a bug or anything. The problem is that the current behavior is
very counter-intuitive, not to mention unnecessary because there's already
another function dedicated to MX lookups.

At my job, we wasted a good deal of time troubleshooting what appeared to
be a weird DNS issue that turned out to just be a checkdnsrr() lookup that
was looking only for MX records because a second argument wasn't passed. I
cannot think of any use case served by this behavior.

--Kris

On Mon, Sep 22, 2014 at 8:09 PM, Sanford Whiteman figureonecpr@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 (john@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."