dotPH, the .ph ccTLD, decided to do something that is unwise. Specifically they decided to do a wildcard redirection of any unresolved .ph domain to a specific IP address (162.4.84.242).
That means that if you look up "thisisatotallybogusdomain.ph", the answer is not a status of NXDOMAIN (i.e. this is a bogus domain that does not exist) but a status NOERROR and the IP address 162.4.84.242, which looks to be a legitimate location. This is not normal behavior, see for example a lookup of the .pk version of the same name:
This is something that ICANN has a specific policy against for gTLDs (such as .com, .vip, .online etc.) because it breaks things.
We know it is bad because it was tried over 20 years ago by VeriSign for the .com and .net TLDs. While many of the links covering that kerfuffle have expired, some pages were archived (such as this one from The Register) and ICANN's official report is still available (PDF). From the Executive Summary (my emphasis)
The specific technical change substituted a “synthesized response” for an error message, and applications that relied on the original error code unexpectedly failed. At ICANN’s insistence and after
widespread protest from the technical community, VeriSign suspended the Site Finder
service on 4 October 2003.
This report by the Security and Stability Advisory Committee (SSAC), an advisory committee to ICANN, describes VeriSign’s actions of September-October 2003 and thetechnical community’s responses to those actions and then analyzes the sequence of actions and reactions from the perspective of security and stability of the Internet. [...] The Committee’s primary focus is not Site Finder, per se. Rather, our focus is two-fold: that core registry operations were modified, thereby changing existing services, and that the change was introduced abruptly without broad notice, testing, refinement or community agreement.
The Committee finds that VeriSign’s actions did not have network-shattering effects but
did violate fundamental architectural principles and well-established codes of conduct
and good practice intended to ensure stability.
The summary continues to explain why the idea was a bad one. The key points are findings 2 and 3
Finding (2): The changes violated fundamental Internet engineering principles by blurring the well-defined boundary between architectural layers. VeriSign targeted the Site Finder service at Web browsers, using the HTTP protocol, whereas the DNS protocol, in fact, makes no assumptions – and is neutral – regarding the protocols of the queries to it. As a consequence, VeriSign directed traffic operating under many protocols to the Site Finder service for further action, and thus, more control was moved toward the center and away from the periphery, violating the long-held end-to-end design principle.
Finding (3): The mechanisms proposed by VeriSign to ameliorate the undesirable effects of their diversion on protocols other than HTTP put VeriSign in the implementation path of every existing and future protocol that uses DNS. For every such protocol, it would be necessary to consult with VeriSign to figure out how to simulate the response of the protocol to "no such domain." This is an unacceptable invasion of clear layering.
Essentially anyone using a .com domain for any traffic other than HTTP would be liable to seeing traffic sent to typosquats of their domain being sent to VeriSign with no clear guarantee that the traffic would be discarded unread. More over people using the wrong domain by mistake would have little indication that they were connecting to the wrong place.
The same thing seems to have happened with the .ph domain and, as with VeriSign, a search of the dotPH website news page and the various policies shows no mention of the change. It is in fact worse today in that most web browsers now get upset on visiting non-TLS webpages and some browsers/users actually forbidding http as opposed to https connections. As a result, dotPH cannot easily implement their version of Site Finder and alert visitors to unregistered domains that the domain is for sale, as there is no way they can have a valid and trusted *.ph certificate. In fact, currently it looks like both http and https queries to the IP address simply fail and return an empty reply, which means that the whole thing is entirely pointless, but presumably dotPH hope to add this capability later once they figure out the certificate issue (Joke: it is possible they intended to use one of the eMudhra intermediate certificates).
In a slight improvement to VeriSign, our investigation suggests that only A record queries are wildcard redirected. Other queries return NXDOMAIN as they should. This makes the whole thing even more bizarre as one might have expected at least AAAA queries to return an answer. But on the good news front this means that fewer bits of the internet are broken because of dotPH.
However while it hasn't broken everything, it has broken a variety of security related features which make the internet safer for users. Now, anything that checks whether a hostname exists by doing a DNS lookup of it, has to add extra logic to discard the answer if it is 162.4.84.242. Other security devices will create alerts that need to be checked (or ignored, leading to potential problems later because getting into the habit of ignoring alerts is bad) and so on.
For a while collectors of passive DNS data such as DomainTools were seeing enormous jumps in apparent new domains which were actually erroneous. This affected what they provided to their customers (such as ThreatSTOP and some of our customers in turn). Specifically the Newly Observed Domains feed from DomainTools exploded to at least ten times the size it was normally. At one point we noticed that an hourly update had 833276 new domains and 805648 of them were *.ph domains (over 95%), by contrast the usual historical number of .ph domains in such an update is a dozen or less. ThreatSTOP in fact decided to stop updating our versions of the feed for a few hours until DomainTools filtered the feed because we were unclear what was genuine and what was not. DomainTools and ThreatSTOP were not by any means the only people impacted by this. At the time of this post we have seen various security and DNS vendors make changes to filter these results, but there will no doubt be more that have not. Fortunately users of ThreatSTOP will generally not see the problem because we have added the IP address to some of our core targets and thus most of our users will get the correct blocked behavior.