Re: [RFC] Change checkdnsrr() $type argument behavior
| From: | Kris Craig | Date: | Mon, 22 Sep 2014 07:07:04 +0000 |
| Subject: | Re: [RFC] Change checkdnsrr() $type argument behavior | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-77425@lists.php.net to get a copy of this message | ||
On Sep 21, 2014 11:52 PM, "Pierre Joye" <pierre.php@gmail.com> wrote:
>
> hi Kris,
>
> On Sat, Sep 20, 2014 at 4:15 AM, Kris Craig <kris.craig@gmail.com> wrote:
> > 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