A user is puzzled by how their subdomain, used for internal documentation and not linked anywhere publicly, was discovered and accessed by an external user. They're concerned about potential security vulnerabilities and are seeking explanations for how this could have happened, considering they haven't shared the subdomain's address. The user is ruling out DNS brute-forcing due to the subdomain's unique and unguessable name. They're particularly perplexed because the subdomain isn't indexed by search engines and hasn't been exposed through any known channels.
ICANN's blog post details the transition from the legacy WHOIS protocol to the Registration Data Access Protocol (RDAP). RDAP offers several advantages over WHOIS, including standardized data formats, internationalized data, extensibility, and improved data access control through different access levels. This transition is necessary for WHOIS to comply with data privacy regulations like GDPR. ICANN encourages everyone using WHOIS to transition to RDAP and provides resources to aid in this process. The blog post highlights the key differences between the two protocols and reassures users that RDAP offers a more robust and secure method for accessing registration data.
Several Hacker News commenters discuss the shift from WHOIS to RDAP. Some express frustration with the complexity and inconsistency of RDAP implementations, noting varying data formats and access methods across different registries. One commenter points out the lack of a simple, unified tool for RDAP lookups compared to WHOIS. Others highlight RDAP's benefits, such as improved data accuracy, internationalization support, and standardized access controls, suggesting the transition is ultimately positive but messy in practice. The thread also touches upon the privacy implications of both systems and the challenges of balancing data accessibility with protecting personal information. Some users mention specific RDAP clients they find useful, while others express skepticism about the overall value proposition of the new protocol given its added complexity.
A misconfigured DNS record for Mastercard went unnoticed for an estimated two to five years, routing traffic intended for a Mastercard authentication service to a server controlled by a third-party vendor. This misdirected traffic included sensitive authentication data, potentially impacting cardholders globally. While Mastercard claims no evidence of malicious activity or misuse of the data, the incident highlights the risk of silent failures in critical infrastructure and the importance of robust monitoring and validation. The misconfiguration involved an incorrect CNAME record, effectively masking the error and making it difficult to detect through standard monitoring practices. This situation persisted until a concerned individual noticed the discrepancy and alerted Mastercard.
HN commenters discuss the surprising longevity of Mastercard's DNS misconfiguration, with several expressing disbelief that such a basic error could persist undetected for so long, particularly within a major financial institution. Some speculate about the potential causes, including insufficient monitoring, complex internal DNS setups, and the possibility that the affected subdomain wasn't actively used or monitored. Others highlight the importance of robust monitoring and testing, suggesting that Mastercard's internal processes likely had gaps. The possibility of the subdomain being used for internal purposes and therefore less scrutinized is also raised. Some commenters criticize the article's author for lacking technical depth, while others defend the reporting, focusing on the broader issue of oversight within a critical financial infrastructure.
Summary of Comments ( 188 )
https://news.ycombinator.com/item?id=43285725
The Hacker News comments discuss various ways a subdomain might be discovered, focusing on the likelihood of accidental discovery rather than malicious intent. Several commenters suggest DNS brute-forcing, where automated tools guess subdomains, is a common occurrence. Others highlight the possibility of the subdomain being included in publicly accessible configurations or code repositories like GitHub, or being discovered through certificate transparency logs. Some commenters suggest checking the server logs for clues, and emphasize that finding a subdomain doesn't necessarily imply anything nefarious is happening. The general consensus leans toward the discovery being unintentional and automated.
The Hacker News post "Ask HN: How did the internet discover my subdomain?" generated several comments offering various explanations and suggestions to the original poster (OP).
Several commenters focused on the likelihood of DNS propagation. They explained that even though the OP believed they hadn't publicly exposed their subdomain, the very act of configuring it within their DNS settings likely triggered its propagation across DNS servers. This means the subdomain became visible to parts of the internet, potentially through DNS queries made by various entities, including search engine crawlers, security scanners, or even malicious bots actively scanning for new domains.
Another popular theory revolved around misconfigured services or exposed APIs. Commenters suggested the possibility of a service running on the subdomain being inadvertently accessible from the public internet, perhaps due to a firewall misconfiguration or overly permissive access rules. They also suggested checking for publicly accessible APIs that might have revealed the subdomain's existence.
Some comments touched upon the possibility of certificate transparency logs. These logs publicly record SSL/TLS certificates issued for websites, and if the OP had obtained a certificate for their subdomain, it would be logged and thus discoverable.
A few commenters mentioned the potential role of link rot analysis tools and web crawlers. These tools constantly scan the web for broken links, and if a link to the OP's subdomain existed somewhere, even if obscure or unintended, it could have been discovered this way. Likewise, generic web crawlers might have stumbled upon the subdomain through various means and indexed it.
Several users offered practical advice to the OP, recommending using tools like
digto trace DNS records and identify potential points of exposure. Others advised checking server logs for any unusual activity that might indicate how the subdomain was discovered.A more speculative, but still plausible suggestion, involved the possibility of the subdomain being guessed or brute-forced. While less likely for a complex or randomly generated subdomain name, it is not impossible, particularly if the name is based on common patterns or easily guessable words.
Finally, some comments highlighted the inherent difficulty of fully controlling information propagation on the internet. Once something is even briefly exposed, it can be difficult to completely erase its trace. They emphasized the importance of proactive security measures and careful configuration to minimize unintended exposure.