ICANN Is Adding 1,600 New Domains — Who's Monitoring the Ones You Already Own?

ICANN has opened the next round of generic top-level domain applications — the first major expansion since 2012, when 1,241 new gTLDs went live. This round could add as many as 1,600 more. Adidas, Adobe, and Airbnb have applied for their own names. Crypto and AI companies are lining up too. Somewhere in that pile is a domain that will eventually host your company's next marketing site, client portal, or product microsite.

If you run infrastructure for a living, that news should trigger an uncomfortable question: do you actually know every domain your organization owns — and is every one of them monitored? In most shops the honest answer is no. Marketing registers a campaign domain on a cloud VM. A vendor spins up a portal on a hostname you have never seen. A Let's Encrypt renewal task keeps firing on a server that was decommissioned two months ago. None of it lands in the monitoring platform, because monitoring platforms only watch what someone remembered to add. So the first person to notice the new domain is down is a user — with a ticket, forty minutes after it broke.

That is a monitoring problem, not a domain problem. And it is fixable.

The Problem: Your Monitoring Ends Where the Network Ends

Walk through how a typical new-domain incident actually unfolds:

1. Marketing registers a new domain for a product launch. IT is looped in — maybe — for a DNS record. Nobody adds it to monitoring, because the RMM, the uptime checker, and the helpdesk are three different systems, and the domain "belongs" to marketing.
2. The site launches and works for weeks or months. It is invisible: no alerts, no dashboard, no owner in IT.
3. Something breaks. The TLS certificate expires because the renewal scheduled task died with a decommissioned VM. Or the hosting server's disk hits 100% and IIS stops serving. Or a DNS record gets mangled during a "quick" migration.
4. Users report it first. A ticket appears: "The new site is down." The tech burns 40 minutes working out which host, which certificate, which record — before the actual fix even starts.

That last step is the killer. When monitoring catches an issue, the alert includes the host, the check, the severity, and a timestamp. When a user catches it, the ticket includes none of that. The first 30–45 minutes of every user-reported incident is discovery, not repair — and your MTTR numbers quietly absorb it.

Why the gaps exist — this is architecture, not negligence:

• Agent-based RMM tools (NinjaOne, ConnectWise Automate, Datto RMM) look inward. They are excellent at what is installed and running on endpoints and servers. They have no idea that a public URL stopped resolving, or that a certificate issued by Let's Encrypt expired overnight.
• Standalone uptime tools (UptimeRobot, StatusCake, PRTG HTTP sensors) can check external URLs — but every check must be added manually, and nobody adds what they do not know exists. When a check does fail, the alert lands in an email inbox, not your on-call rotation.
• The helpdesk becomes the de facto monitoring system. Zendesk, Freshservice, or HaloPSA will happily collect user reports of an outage — the slowest and most demoralizing detection mechanism available.
• There is no shared inventory. Domains live in the registrar account, checks live in the uptime tool, servers live in the RMM, tickets live in the helpdesk. Nothing correlates them.

And it is not just public URLs. Those 1,600 new gTLDs will mostly resolve through infrastructure you do own: the Windows Server DNS role on your domain controllers. When a forwarder breaks, a conditional zone goes stale, or scavenging deletes a record it should not, your DCs will still show "healthy" in endpoint monitoring — the DNS service is technically Running — while half the office gets "site can't be reached" and the helpdesk queue explodes.

What it costs, concretely:

• Detection time for external services is measured in user tolerance, not seconds.
• MTTR inflates because discovery consumes the opening minutes of every incident.
• SLA reporting is fiction when the alert timestamp lives in one tool and the ticket timestamp lives in another.
• For MSPs, multiply all of the above across 20–50 clients, each with unmonitored domains tracked in a spreadsheet nobody trusts.
• Technicians burn out on incidents they hear about from angry users instead of from their own tools.

How AlertMonitor Closes the Gap

The core problem is not that any single tool is bad. It is that the checks that matter — URL availability, DNS resolution, certificate expiry, and the disk, services, and event logs on the servers behind it all — sit in four disconnected systems with four escalation paths. AlertMonitor collapses that into one platform. Concretely:

1. External checks live next to infrastructure checks, in one alert stream. Every domain in your inventory gets a URL uptime check, a DNS resolution check, and a certificate expiry threshold in the same platform that watches the hosting VM's disk, CPU, and Windows services. One alert stream. One escalation policy. One on-call view.

2. Certificate expiry becomes a managed alert, not a surprise. Set a warning at 21 days out and critical at 7. The renewal task that silently died on a decommissioned VM stops mattering, because AlertMonitor pages you three weeks before the certificate expires — not when the first user hits a browser warning.

3. Alerts become tickets automatically. When the marketing site check fails, AlertMonitor opens the ticket in the integrated helpdesk with the check, host, and detection timestamp attached. SLA reporting finally uses real detection times instead of reconstructed guesses from three systems.

4. Correlated context shortens root-cause time. Old way: the URL check fails in UptimeRobot (one email), a disk alert fires in PRTG (a different email), and a user ticket lands in Zendesk (a third system). New way: the failed URL check, the 96% disk warning on the hosting VM, and the auto-created ticket appear on one timeline in one console. The technician sees the cause, not just the symptom.

5. MSPs get this per client, without spreadsheets. Client A's brand domains, client B's client portals, client C's marketing sites — all monitored, tagged, and escalating to the right SLA policy from the same NOC dashboard.

The measurable shift: an issue that used to surface as a 9:47 AM user ticket gets caught by a platform check within seconds of failing, with the context needed to fix it already attached.

Practical Steps You Can Take This Week

Step 1: Build the domain inventory you do not have. Ask marketing for every registered domain. Check the corporate registrar account. Pull hostnames from web server logs. The list will be longer than you expect — write it to a plain domains.txt, one domain per line.

Step 2: Sweep certificate expiry across everything. This finds the certs that are about to burn you:

# Sweep TLS certificate expiry for every domain in domains.txt
$domains = Get-Content .\domains.txt
$today = Get-Date
foreach ($domain in $domains) {
    try {
        $tcp = [System.Net.Sockets.TcpClient]::new($domain, 443)
        $ssl = [System.Net.Security.SslStream]::new($tcp.GetStream(), $false, { $true })
        $ssl.AuthenticateAsClient($domain)
        $cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]$ssl.RemoteCertificate
        [PSCustomObject]@{
            Domain = $domain
            Issuer = ($cert.Issuer -split ',')[0]
            Expires = $cert.NotAfter
            DaysLeft = ($cert.NotAfter - $today).Days
        }
        $ssl.Dispose(); $tcp.Dispose()
    }
    catch {
        [PSCustomObject]@{ Domain = $domain; Issuer = 'UNREACHABLE'; Expires = $null; DaysLeft = $null }
    }
}

Anything under 30 days goes on your action list. Anything unreachable goes on it faster.

Step 3: Verify DNS resolution from inside and outside your network. Compare what your internal resolvers return against public resolvers so a forwarder problem cannot hide behind a running service:

# Compare A-record answers across internal and public resolvers
$resolvers = @('192.168.10.5', '192.168.10.6', '8.8.8.8', '1.1.1.1')
$names = Get-Content .\domains.txt
foreach ($resolver in $resolvers) {
    foreach ($name in $names) {
        $answer = Resolve-DnsName -Name $name -Server $resolver -Type A -ErrorAction SilentlyContinue
        [PSCustomObject]@{
            Resolver = $resolver
            Name = $name
            Resolves = [bool]$answer
            Address = ($answer | Where-Object IPAddress | Select-Object -First 1).IPAddress
        }
    }
}

Step 4: Check the real health of the DNS Server role on every domain controller. Service status alone lies. Zone counts and scavenging state tell the truth:

# Verify the DNS Server role is healthy on every domain controller
Get-ADDomainController -Filter * | ForEach-Object {
    Invoke-Command -ComputerName $_.HostName -ScriptBlock {
        [PSCustomObject]@{
            Server = $env:COMPUTERNAME
            ServiceOK = (Get-Service DNS).Status -eq 'Running'
            Zones = (Get-DnsServerZone | Where-Object { -not $_.IsAutoCreated }).Count
            Scavenging = (Get-DnsServerScavenging).ScavengingState
        }
    }
}

Step 5: For Linux-hosted endpoints, run the same sweep from an external box:

# Quick external sweep: HTTP status + certificate expiry per domain
while read -r domain; do
  code=$(curl -s -o /dev/null -w "%{http_code}" --max-time 5 "https://${domain}")
  exp=$(echo | openssl s_client -servername "${domain}" -connect "${domain}:443" 2>/dev/null \
        | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
  printf "%-40s HTTP:%s  CertExpires: %s\n" "${domain}" "${code:-TIMEOUT}" "${exp:-N/A}"
done < domains.txt

Step 6: Turn the one-time sweep into continuous monitoring. Load the domain list into AlertMonitor as URL uptime checks, DNS resolution checks, and certificate expiry alerts (warn at 21 days, critical at 7). Attach disk, service, and event log monitoring for the hosting servers to the same environment. Set the escalation policy once. When marketing registers the next new gTLD next quarter, covering it is one check away — not one user ticket away.

The internet is about to get 1,600 more domains. Your job is not to register them. It is to make sure that whatever domains touch your organization — today or next quarter — a machine notices when they break before a user does.

Related Resources

AlertMonitor Infrastructure & Server Monitoring AlertMonitor Platform Overview Book a Demo Infrastructure & Server Monitoring Resources