Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77496
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.195 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKOpQSyiCDEUDGhn50RuLL7ox_TJCCjD=4=qZ68OqbA5krXWkA@mail.gmail.com>
References: <CAKOpQSyiCDEUDGhn50RuLL7ox_TJCCjD=4=qZ68OqbA5krXWkA@mail.gmail.com>
Date: Mon, 22 Sep 2014 23:09:04 -0400
Message-ID: <CAA8DMBsjORWTDKDncgbrWZKHmrn-=VQaRgxSpwhKoRC-RmE=4w@mail.gmail.com>
To: Kris Craig <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
From: figureonecpr@gmail.com (Sanford Whiteman)

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 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."