I Accidentally Ranked a Porn Site for a Children's Hospital

9:47 AM on a Monday. I know the time because I'd just looked at the clock in the corner of my screen, the way you do when you're doing routine work and you're checking to see how much of the morning is left before you can justify a second cup of coffee. I was running a backlink audit. Routine stuff. The kind of work that feels like flossing - necessary, unglamorous, the thing you're supposed to do regularly and that you actually do whenever you remember, which for most consultants is less often than they'd admit.

The client was a children's hospital. I want you to hold that in your mind for the next several thousand words, because it matters. Not a dropshipping store. Not a SaaS company. Not a local plumber or a law firm or any of the other businesses where an SEO problem is a business problem. A children's hospital. A place where parents bring their sick kids. A place where the stakes of your online presence aren't "fewer leads" or "lower revenue" but "a mother Googling her child's symptoms at 3 AM and making a decision about where to seek care based on what she finds." That's the weight class we're operating in. That's the client whose backlink profile I was casually scrolling through while thinking about coffee.

I had Ahrefs open. I was pulling referring domains, sorting by domain rating, doing the mechanical scan that I've done a thousand times - scrolling past the expected stuff, the medical journal citations, the local news mentions, the hospital directory listings, the .edu references from the university affiliation - when something caught my eye. A referring domain that didn't belong. A URL structure I didn't recognize. A subdomain of the hospital's primary domain that I'd never seen in any documentation, never encountered in any technical audit, never had mentioned to me by anyone on the client's team.

I clicked on it.

I want to describe the sensation of what happened next with precision, because precision matters here and also because I'm going to be talking about this moment for the rest of this piece and I need you to understand exactly what it felt like. It was not a slow realization. It was not a gradual dawning. It was instantaneous. The page loaded and my blood went cold and my stomach dropped and my hand came off the mouse as if the mouse had become electrically charged, which it hadn't, but my body reacted as though something physical had happened because something physical did happen - adrenaline dumped into my bloodstream in the time it takes to load a web page, which on this particular web page was about 1.3 seconds, because the content was heavily optimized (for the wrong kind of traffic, but optimized nonetheless).

The subdomain was hosting pornography.

Not ambiguous content. Not something that could be interpreted charitably. Not a dating site or an adult novelty retailer or anything that existed in a gray area. Pornography. Explicit, aggressive, unmistakable pornography. On a subdomain of a children's hospital. With the hospital's domain name right there in the URL, clearly visible, clearly associated, clearly and permanently indexed by the search engine that I was being paid to optimize this hospital's presence on.

I closed the tab. I opened it again. I closed it again. I stood up from my desk and walked to my kitchen and stood there for a moment, staring at my coffee maker, processing what I'd just seen, and then I walked back to my desk and opened the tab again because I needed to confirm that this was real, that this was actually happening, that a subdomain of my client's hospital - a hospital for children, a hospital with the word "children's" in its name - was serving content that would make a reasonable adult question everything about the institution.

It was real.

The Anatomy of a Hijack

Before I tell you about the phone call (and there was a phone call, and it was exactly as uncomfortable as you're imagining, possibly more so), I need to explain how this happened. Because it didn't happen the way you might think. Nobody at the hospital uploaded anything. No employee went rogue. No disgruntled IT worker decided to sabotage the institution's reputation. The explanation is at once more mundane and more terrifying than any of those scenarios, because it reveals something fundamental about how the internet works that most organizations - including organizations that should know better, including organizations whose entire mission depends on public trust - do not understand.

Here's what happened, as best I could reconstruct it after two weeks of forensic investigation that involved me, the hospital's IT director (a man named Greg who aged visibly during those two weeks), and a DNS specialist I brought in because I needed someone who understood this at a level I didn't and wasn't too proud to admit it.

Three years before I was retained as the hospital's SEO consultant, the hospital's web development team had created a staging environment for a website redesign project. This is standard practice. You don't build a new website on top of the live one. You create a staging site, build there, test there, and when everything's ready, you push it live. Every competent development team does this. The hospital's team did this. They set up the staging environment on a subdomain - let's call it staging.childrenshospital.org (not the real URL, obviously, because I'm not going to print the real URL on the internet, because I still work with this client and also because I'm not a monster).

The staging subdomain pointed to a server. The DNS record - the little piece of internet infrastructure that tells browsers "when someone types this address, send them to this server" - pointed staging.childrenshospital.org to a specific IP address at a hosting provider. The redesign project was completed. The new site went live on the primary domain. The staging environment was no longer needed.

And here's where it went wrong. Here's the moment of failure. Here's the gap in the fence.

The development team decommissioned the staging server. They cancelled the hosting account. They deleted the files. They did everything you're supposed to do when you're done with a staging environment. Everything except one thing.

They didn't delete the DNS record.

The DNS record for staging.childrenshospital.org was still pointing to an IP address at the hosting provider. But the hosting account at that IP address had been cancelled. The server was no longer theirs. The IP address was released back into the hosting provider's pool of available addresses, sitting there, unoccupied, like a vacant lot in a city where vacant lots don't stay vacant for long.

Someone else registered a hosting account and was assigned that IP address. I don't know who. I never found out. It doesn't matter who, because the who is less important than the what, and the what is this: someone, somewhere, now controlled a server at an IP address that the DNS record for staging.childrenshospital.org was still pointing to. Which means that when anyone typed staging.childrenshospital.org into a browser, they were sent to this person's server. Which means this person could put anything they wanted on that server and it would appear to be hosted on the hospital's domain.

This is called a dangling DNS record, or a subdomain takeover, and if you've never heard of it, I need you to understand that it is one of the most common and least understood vulnerabilities on the internet. It's not a hack in the dramatic, movie sense. Nobody broke through a firewall. Nobody guessed a password. Nobody exploited a zero-day vulnerability in some obscure piece of software. All that happened was: an organization created a DNS record, forgot to delete it, and someone else took advantage of the orphaned pointer.

That's it. That's the whole exploit. A forgotten line in a DNS configuration file. A digital Post-it note that nobody remembered to throw away. And the result was pornography on a children's hospital's domain.

The Phone Call

I have made a lot of uncomfortable phone calls in my career. I've called clients to tell them their traffic dropped fifty percent overnight. I've called clients to tell them their developer accidentally noindexed their entire site. I've called a client to tell them that the SEO agency they used before me had built links from a network of websites that were, upon closer inspection, fronts for online gambling operations, and that I was going to have to disavow approximately four thousand of their backlinks, which is the SEO equivalent of calling someone to tell them their house has termites and also the termites have been there for years and also the house is mostly termites now.

None of those calls were as uncomfortable as this one.

The hospital's marketing director was named Sarah. Sarah was a competent, serious person who had hired me specifically because the hospital's online reputation was important to her, who had impressed upon me during our initial meeting that the hospital served a vulnerable population and that the digital presence needed to reflect the trust that parents placed in the institution. Sarah had said the word "trust" four times in our first meeting. I counted.

I called Sarah on a Monday afternoon. I remember the exact phrasing I used because I rehearsed it eleven times before dialing. I said: "Sarah, I've found something during the backlink audit that requires your immediate attention. A subdomain of the hospital's domain has been compromised and is hosting inappropriate content. I need to walk you through what's happening and what we need to do about it, and I need to be direct with you about the nature of the content, because you're going to need to involve your IT team and possibly your legal team and possibly your communications team."

There was a pause. The kind of pause that happens when someone on the other end of the phone is recalibrating their expectations for the rest of their day. When someone realizes that the call they thought was going to be a routine update is actually going to be the worst call they receive this month.

"What kind of inappropriate content?" Sarah asked.

I told her.

The silence that followed was the loudest silence I've ever heard. Five seconds of nothing. Five seconds during which I could hear Sarah processing, in real time, the implications of what I'd just said. The reputation risk. The media risk. The risk to the parents who might find this. The risk to the children whose hospital this was. The risk to the donors. The risk to the board. All of it, cascading through her mind in five seconds of silence that felt like five minutes.

"How long has this been up?" she asked. Her voice was very controlled. The specific kind of controlled that means someone is working very hard to sound calm.

I told her I didn't know yet, but that based on the cached versions I'd found, it appeared to have been at least four months. Possibly longer. Four months during which this content existed on a subdomain that bore the hospital's name, was indexed by Google, was accumulating backlinks (from other sites in the same genre, which is how I'd found it in the first place - it was showing up in the referring domains report because these sites were linking to it, because in that ecosystem links are traded the way business cards are traded at conferences, automatically and without discrimination), and was, in theory, discoverable by anyone who knew how to use a search engine, which is to say: anyone.

Sarah said she needed to make some calls. I said I understood. She asked me to prepare a full briefing document. I said I would. She asked me how this happened. I told her about the DNS record, and the decommissioned server, and the IP address reuse, and I tried to explain it in terms that a marketing director would understand, which meant stripping out the technical jargon and replacing it with an analogy that I came up with in real time and that I've used ever since because it works.

"Think of it like a mailbox," I said. "You moved out of a house, but you left your mailbox at the curb with your name on it. Someone else moved into the house. They're receiving mail addressed to you. Except instead of mail, it's web traffic. And instead of your name on a mailbox, it's your hospital's name on a URL."

Sarah understood. Sarah was not happy.

The Cleanup

The fix itself was simple. Absurdly simple. Insultingly simple, given the severity of the problem. Greg, the IT director, deleted the DNS record. That was it. One line in a configuration file, removed. The subdomain stopped resolving. The content disappeared. The crisis, at the technical level, was resolved in about forty-five seconds.

Everything else took months.

Google had indexed the pages on the subdomain. Those pages needed to be removed from the index. We submitted removal requests through Search Console, but Google's removal tool is designed for individual URLs and we were dealing with hundreds of pages (whoever had taken over the server had been industrious). We also needed to ensure that the hospital's domain wasn't penalized for the content that had been hosted on its subdomain, which meant filing a reconsideration request, which meant explaining to Google's webspam team what had happened, which meant writing a document that essentially said "we had pornography on our children's hospital website because someone forgot to delete a DNS record" and hoping that Google's algorithms would distinguish between a site that had been compromised and a site that had intentionally hosted this content.

The backlinks were another problem. The subdomain had accumulated its own backlink profile - links from other adult sites, links from spam networks, links from the kind of corners of the internet that you don't want associated with a children's hospital. Those links were pointing to a subdomain of the hospital's domain, which meant they were, in Google's eyes, part of the hospital's backlink profile. We disavowed them. All of them. But disavowing links is like filing a police report - it's necessary, it creates a record, and there's no guarantee anyone reads it.

The communications team had to prepare a statement in case the media picked up the story. They didn't, as it turned out, because nobody noticed, which is its own kind of horror - the idea that this content could exist on a children's hospital's domain for four months without anyone noticing, without any parent or journalist or competitor stumbling across it, is not reassuring. It's terrifying. It means there are things happening on your domain, right now, that you don't know about. It means the internet is a place where terrible things can hide in plain sight for months because nobody thought to look.

The legal team had to evaluate whether the hospital had any liability. Whether the hosting of this content, even unknowingly, even through a mechanism as passive as a forgotten DNS record, exposed the institution to legal risk. I'm not a lawyer and I won't pretend to understand the nuances of their analysis, but I can tell you that the conversations were long and the faces in the conference room were grim and the word "liability" was spoken more times than anyone wanted to hear it.

How Common This Is

Here's the part that should keep you up at night if you manage any kind of digital property for any kind of organization. This is not rare. This is not a freak occurrence. This is not the kind of thing that happens once and becomes an amusing conference talk. Subdomain takeovers happen constantly, to organizations of every size, in every industry, and the vast majority of them go undetected for months or years because nobody is looking.

A 2021 study by researchers at TU Wien analyzed over 6,000 organizations and found that approximately 0.5% of them had at least one vulnerable subdomain - a dangling DNS record pointing to an IP address or service that the organization no longer controlled. Half a percent sounds small until you realize that the study looked at major organizations - corporations, universities, government agencies - and that 0.5% of major organizations means thousands of vulnerable subdomains across the internet, each one an open door that anyone can walk through.

And those are just the ones that were detectable through automated scanning. The real number is higher, because some dangling records point to infrastructure that's harder to detect - internal services, cloud instances that have been terminated but whose DNS records persist, development environments that were created for a project that ended two years ago and that nobody remembers existed.

I've seen it at law firms (a subdomain pointing to a decommissioned marketing platform, taken over and used for phishing). I've seen it at e-commerce companies (a subdomain pointing to a shut-down CDN, taken over and used for SEO spam). I've seen it at a university (a subdomain pointing to a student project server that was decommissioned after graduation, taken over and used for - you guessed it - pornography, because the internet's default use for unattended digital space is apparently pornography, in the same way that nature's default use for unattended physical space is weeds).

And here's the thing that ties this back to SEO, the thing that makes this not just an IT problem but a marketing problem and a reputation problem and a business problem: Google doesn't know the difference. Google sees a subdomain of your domain hosting content and Google treats that content as part of your domain's presence on the web. If someone takes over your subdomain and fills it with spam, Google may associate that spam with your domain. If someone takes over your subdomain and fills it with malicious content, Google may flag your domain as compromised. If someone takes over your subdomain and builds a network of backlinks to it from the worst corners of the internet, those backlinks become part of your domain's link profile.

Your domain is your digital property. And digital property is like physical property in one crucial respect: if you own land and don't maintain the fence, things move in.

The Open Door Problem

I've thought about this a lot since the hospital incident, and I've come to a conclusion that I think most people in SEO haven't fully reckoned with: digital asset management is a security problem masquerading as a marketing problem.

When I say "digital asset management," I don't mean the trendy enterprise software category. I mean the basic, fundamental act of knowing what you own on the internet and making sure that what you own is under your control. Your domains. Your subdomains. Your DNS records. Your hosting accounts. Your cloud instances. Your third-party integrations. Your staging environments. Your development servers. Your old marketing sites. Your abandoned microsites. Your legacy platforms. All of it.

Most organizations don't know what they own. I mean this literally. I've done digital asset audits for companies that discovered domains they'd registered for campaigns ten years ago and forgotten about. Subdomains created by employees who've since left. Hosting accounts paid for by credit cards that have expired. DNS records pointing to servers that don't exist anymore. Cloud instances running in regions that nobody monitors. A sprawling, unmapped, ungoverned landscape (third and final use) of digital property that nobody is responsible for because it doesn't fit neatly into any department's mandate.

IT thinks marketing owns the subdomains because marketing requested them. Marketing thinks IT owns the subdomains because IT set up the DNS. Legal doesn't know the subdomains exist. The C-suite doesn't know what a subdomain is. And the SEO consultant finds out about them at 9:47 on a Monday morning when something appears in a backlink report that shouldn't be there.

This is a governance problem. And governance problems don't get fixed by technology. They get fixed by someone - a human being with authority and accountability - deciding that digital asset management is important enough to own. That there should be an inventory. That the inventory should be maintained. That every domain, subdomain, DNS record, and hosting account should be documented, monitored, and regularly audited.

In twenty-plus years of doing this work, I have encountered exactly three organizations that had a comprehensive digital asset inventory. Three. One was a bank (regulated industry, compliance requirements). One was a defense contractor (same). One was a startup whose CTO happened to be paranoid about security in a way that bordered on pathological but that, in this instance, served him well.

Everyone else was flying blind. Everyone else had subdomains they didn't know about, DNS records they'd forgotten, hosting accounts they'd lost track of. Everyone else was one forgotten configuration file away from the kind of morning I had at 9:47 on that Monday.

The Audit That Should Exist But Doesn't

After the hospital incident, I developed what I now call a digital property audit. It's not complicated. It's not revolutionary. It's the kind of thing that should be standard practice and isn't, because it falls in the gap between IT and marketing, because nobody's KPIs include "make sure our subdomains aren't hosting porn," because organizations don't prioritize things that haven't gone wrong yet.

The audit has five components. I'm going to describe them here, not because this is a how-to article (it's not, it's a cautionary tale dressed up as a how-to article, which is the best kind of how-to article) but because after what I found on that Monday morning, I feel a professional obligation to make sure other people know what to look for.

First: DNS record inventory. Pull every DNS record for every domain you own. Not just the primary domain. Every domain. The legacy domain you registered in 2014 for a product launch that never happened. The vanity domain your CEO bought because it had his name in it. The typo domain you registered to prevent squatting. All of them. For each domain, enumerate every subdomain that has a DNS record pointing somewhere. Then, for each of those records, verify that the destination is a server or service that you control. If it's not - if the record points to an IP address at a hosting provider where you no longer have an account, or to a cloud service you've decommissioned, or to a third-party platform you've stopped using - delete the record. Immediately. Do not wait. Do not add it to a backlog. Delete it now, because every minute that record exists is a minute during which someone can take over that subdomain.

Second: hosting account audit. Document every hosting account, cloud instance, and server that your organization pays for. Cross-reference with the DNS records. If you have DNS records pointing to infrastructure that isn't in your hosting inventory, you have a problem. If you have hosting accounts that aren't referenced by any DNS record, you might be paying for infrastructure you don't need (which is wasteful but not dangerous). If you have DNS records pointing to infrastructure that was decommissioned, you have the specific problem I've been describing for the last three thousand words.

Third: third-party service audit. Many subdomain takeover vulnerabilities come not from self-hosted infrastructure but from third-party services. You set up a subdomain to point to a GitHub Pages site, or a Heroku app, or an Azure instance, or a Shopify store, and then you stop using that service but you don't delete the DNS record. The third-party service releases the hostname. Someone else claims it. Your subdomain now points to their content. This is well-documented, well-known, and still catches organizations by surprise on a regular basis because knowing about a vulnerability and actually checking for it are two different things that feel the same but aren't.

Fourth: certificate transparency monitoring. This is the technical one, the one that requires some infrastructure, but it's also the one that catches things the others miss. Certificate transparency logs are public records of every SSL/TLS certificate issued for your domain. If someone manages to obtain a certificate for a subdomain of your domain - which they can do, for free, in minutes, if they control the server that the subdomain points to - it will appear in the certificate transparency logs. Monitoring those logs tells you when someone is setting up HTTPS on a subdomain you didn't know about, which is a strong signal that something has gone wrong.

Fifth: regular backlink monitoring. This is the one I was doing when I found the problem, and it's the one that most SEO consultants already do, but for the wrong reasons. Most of us monitor backlinks to track link building performance and identify negative SEO attacks. We should also be monitoring backlinks to detect subdomain compromise. If your backlink report shows links to subdomains you don't recognize, that's not a link spam issue. That's a security issue. Treat it accordingly.

That's the audit. Five things. None of them are hard. All of them are obvious in retrospect. None of them were being done by the children's hospital before I found pornography on their staging subdomain. And none of them, I'm willing to bet, are being done by your organization right now.

The Empty Room

There's a principle in urban planning called the "broken windows theory" that says visible signs of disorder in an environment - a broken window, graffiti, litter - invite further disorder. The theory is debated in criminology, but in digital security, it's less a theory than an observable law of nature. An abandoned subdomain is a broken window. An orphaned DNS record is an unlocked door. A decommissioned server with an active pointer is an empty room with a sign on the door that says "come in, nobody's watching."

The internet does not leave empty rooms empty. This is something that people who've only ever interacted with the internet as users - as people who visit websites and send emails and watch videos - don't fully appreciate. The internet is an active environment. It's not a library where things sit on shelves until someone retrieves them. It's a city, and in this city, there are people constantly scanning for open doors, unattended property, abandoned space. They're not (mostly) doing it manually. They're using automated tools that scan millions of domains, checking for exactly the kind of vulnerabilities I've been describing. Dangling DNS records. Unclaimed subdomains. Expired hosting accounts. They find them, they claim them, they use them. Quickly. Automatically. At scale.

The people who took over the hospital's subdomain probably didn't know it was a children's hospital. They probably didn't know it was a hospital at all. They were running an automated process that identified an available IP address, registered a hosting account, and set up a site. The fact that a children's hospital's subdomain happened to point to that IP address was, from their perspective, a happy accident - they got a subdomain on a high-authority domain, which meant their content would benefit from the domain's existing authority in Google's eyes. They didn't target the hospital. They didn't even know the hospital existed. They just found an empty room and moved in.

That's almost worse, isn't it? That it wasn't malicious. That it wasn't targeted. That the specific nightmare of pornography on a children's hospital's domain happened not because someone wanted to harm the hospital but because someone was running a script and the hospital happened to be in the way. The randomness of it. The impersonality. The sheer, brute, mechanical indifference of the process that turned a forgotten DNS record into a reputation crisis.

What SEO Actually Is

I started doing SEO in the early 2000s, and for most of that time, I understood my job as being about visibility. Making things findable. Getting pages to rank. Optimizing content and building links and improving site speed and doing all the things that SEO consultants do to make websites more visible to search engines.

The hospital incident changed how I think about what I do.

SEO isn't just about making things visible. It's about controlling what's visible. It's about ensuring that when someone searches for your brand, for your institution, for the hospital where their child is being treated, they find what you want them to find and nothing else. It's about the integrity of your digital presence. The whole presence. Not just the pages you published intentionally, but the pages that might exist on your domain without your knowledge. Not just the content you created, but the content that might be associated with your domain through mechanisms you didn't know existed.

This is a bigger job than most SEO consultants realize. It's certainly a bigger job than most clients realize. When I pitch digital property audits to new clients, I get the same reaction roughly seventy percent of the time: a polite nod followed by "we don't think we have that kind of problem." They don't think they have that kind of problem because they've never looked. They don't think they have that kind of problem because nobody has ever told them to look. They don't think they have that kind of problem because the problem is invisible until it isn't, and by the time it isn't invisible, it's on a subdomain of their website where it has no business being and an SEO consultant is calling them on a Monday afternoon to ruin their week.

The thirty percent who take the audit seriously invariably find something. Not always pornography. Sometimes it's SEO spam - thousands of pages of keyword-stuffed content in languages the organization doesn't operate in, hosted on forgotten subdomains, built by automated systems that specialize in parasiting off abandoned digital property. Sometimes it's phishing pages - convincing replicas of login forms, hosted on subdomains of legitimate organizations, designed to capture credentials from users who see the trusted domain name in the URL and assume they're safe. Sometimes it's cryptocurrency mining scripts, or malware distribution, or just plain old link farms.

The specifics vary. The mechanism is always the same. An organization created digital infrastructure, stopped using it, and forgot about it. Someone else moved in. The organization didn't know until someone thought to look.

Digital Property Is Physical Property

I keep coming back to the physical property analogy because I think it's the most useful way to understand this problem, especially for the non-technical people who need to understand it most - the CMOs, the board members, the hospital administrators who need to approve the budget for digital asset management without fully understanding what digital asset management means.

If you own a building and you leave it empty, bad things happen. Squatters move in. The roof leaks. The pipes freeze. The windows break. And when bad things happen in a building you own, you're responsible, even if you weren't there, even if you didn't cause it, even if you didn't know. Because you own it. Because ownership comes with responsibility. Because "I forgot I owned a building" is not a defense against liability when someone gets hurt in that building.

Digital property works the same way. If you own a domain and you leave subdomains unmonitored, bad things happen. Spam moves in. Malware moves in. Pornography moves in. And when bad things happen on a domain you own, you're responsible. Your reputation is affected. Your search rankings are affected. Your users are affected. "I forgot I had a subdomain" is not a defense against the parent who finds inappropriate content on what appears to be your children's hospital's website.

The difference is that most organizations have a facilities team for their physical property. Someone whose job it is to check the buildings, fix the leaks, replace the locks, make sure squatters haven't moved in. Physical property management is a recognized function. It has a budget. It has staff. It has processes.

Almost no organization has the equivalent for digital property. The domains, the subdomains, the DNS records, the hosting accounts, the cloud instances - all of it exists in an administrative no-man's-land between IT and marketing and legal, owned by everyone and therefore owned by no one, maintained as long as it's actively needed and forgotten the moment it's not.

That's the gap. That's the vulnerability. That's the reason I was staring at pornography on a children's hospital's domain on a Monday morning when I should have been thinking about coffee.

The Aftermath

The hospital's subdomain was cleaned up. The DNS record was deleted. The indexed pages were eventually removed from Google. The backlinks were disavowed. The communications team's prepared statement was never needed. The legal team's analysis concluded that the liability risk was low but not zero, and recommended implementing the kind of monitoring I'd already suggested, which is the way these things always go - the consultant recommends something, the organization declines, the thing the consultant warned about happens, and then the organization implements the recommendation as if it were their idea.

Greg, the IT director, implemented a quarterly DNS audit. I helped him set up automated monitoring for certificate transparency logs and unexpected subdomain activity. We documented every domain the hospital owned, every subdomain that had ever been created, every DNS record that pointed anywhere. It took two weeks. They found three other orphaned DNS records, pointing to servers that had been decommissioned years ago. None of them had been compromised. Yet.

Sarah, the marketing director, now includes "digital property integrity" as a line item in her quarterly report to the hospital's board. She told me, during a call several months after the incident, that the board hadn't initially understood why this was a marketing issue and not an IT issue. She'd had to explain it, more than once, using the mailbox analogy I'd given her. She'd had to connect the dots between an orphaned DNS record and the trust that parents place in the hospital's brand. She'd had to make the case that digital reputation management isn't a nice-to-have but a core responsibility.

She shouldn't have had to make that case. In 2025, it should be obvious. But it's not obvious, because the people who run organizations still think of the internet as a thing they use rather than a place they exist, and in a place you exist, you have to maintain your property, and maintaining your property means knowing what your property is, and most organizations don't know what their property is because nobody ever told them they needed to know.

I'm telling you now.

Go run a DNS enumeration on every domain you own. Do it today. Do it before your second cup of coffee. Because the internet doesn't leave empty rooms empty, and you might not like what's moved into yours.

I found pornography on a children's hospital. You might find something worse. Or you might find nothing, and you'll have spent thirty minutes on a Monday morning for the privilege of sleeping better on Monday night.

Either way, you'll know what you own. And knowing what you own is the first step toward making sure nobody else is using it.

The coffee, by the way, was cold by the time I got back to it. It usually is, on the mornings that matter.