Lina argues that ENUM's public DNS tree was never formally decommissioned, and SIP stacks quietly kept issuing NAPTR lookups for years after the ecosystem moved on. By registering vacant subtrees she demonstrated that anyone could passively collect real-time call metadata — including calls to military bases and government offices — without touching a single audio stream.
The editorial frames each NAPTR query as effectively an announcement that 'someone on this network is about to place a call to this number, right now,' complete with timestamp, source resolver, and target E.164 number. That turns a dormant DNS tree into a live intelligence feed on sensitive callers, which is qualitatively different from a normal misconfiguration.
The HN submission and its 484-point thread became a 'small support group' for telecom engineers who had assumed the public ENUM root was defunct and nobody was still querying it. The reaction underscores that operational knowledge about which protocols are actually live has decayed faster than the deployed SIP stacks that still speak them.
Lina explicitly limited herself to counting queries, identifying vendor user agents, and confirming the traffic was genuine rather than scanner noise — she avoided doing anything with the leaked phone numbers themselves. The writeup frames this restraint as the ethical baseline for accidentally-authoritative DNS: disclose the pattern, don't weaponize the data.
Security researcher Lina wrote up a project titled *"I accidentally logged phone calls to military bases"* — and the mechanism is almost embarrassingly simple. She noticed that e164.arpa, the DNS tree that was meant to map E.164 phone numbers to SIP URIs via ENUM (RFC 6116), is largely a graveyard of unregistered or expired country-code delegations. So she registered some of the vacant subtrees, stood up an authoritative DNS server, and waited.
Within days, her logs filled with NAPTR queries for real phone numbers — including numbers belonging to U.S. military installations, government offices, and enterprise PBXes routing outbound calls. Each query effectively announced: *someone on this network is about to place a call to this number, right now.* The researcher wasn't intercepting audio or hijacking calls. She was collecting the DNS lookup — timestamp, source resolver, target E.164 number — that a SIP client or session border controller performs before it decides how to route.
The post walks through how she confirmed the traffic was genuine (not scanners), which vendors' user agents showed up in the query patterns, and how she responsibly avoided doing anything with the numbers beyond counting them. The HN thread (484 points at time of writing) turned into a small support group for telecom engineers who had assumed e164.arpa was dead infrastructure nobody still queried.
ENUM was one of those late-90s ideas that made perfect sense on paper: publish a DNS record for every phone number, let VoIP clients look up the SIP URI, and route calls over IP wherever possible. The IETF standardized it, ITU-T blessed a public root at e164.arpa, and a handful of countries (Austria was the poster child) actually delegated their country codes. Then everything else happened — carrier peering, SBCs, closed federations, WebRTC — and the public ENUM tree stopped mattering. Except nobody told the endpoints.
A surprising number of SIP stacks, PBX distributions, and enterprise dial plans still fall back to e164.arpa when a called number doesn't match a local route. Asterisk ships with ENUM lookup functions. FreePBX has an ENUM module. Cisco's older CUCM builds will happily consult it. Some SBCs use it as a "try public ENUM before you give up" heuristic. If the zone comes back NXDOMAIN, the call falls through to the PSTN — fine. But if the zone comes back with an answer, the client trusts it.
The security model here is DNS's original sin: whoever controls the delegation controls the answers. A stale country-code delegation is a permanent leak of every call metadata event from every enterprise that still has ENUM enabled. And unlike most metadata leaks, this one is *pre-call* — the query happens before the audio path is established, which means an attacker could theoretically return a poisoned NAPTR pointing at their own SIP proxy and MITM the call. The researcher explicitly did not do this, but the capability is sitting there waiting.
The uncomfortable part is that nobody who deployed these dial plans in 2008 is still on-call for them in 2026. Telecom infrastructure ages in dog years and gets patched in geological ones. The engineers who enabled `ENUMLOOKUP()` in extensions.conf have long since moved on, the runbooks don't mention it, and the config survives every migration because it "works."
If you run any SIP infrastructure — Asterisk, FreeSWITCH, Kamailio, a commercial SBC, or a hosted VoIP platform where you control the dial plan — audit for ENUM lookups now. In Asterisk, grep your dialplan for `ENUMLOOKUP`, `enum.conf`, or references to `e164.arpa`. In FreeSWITCH, check `enum.conf.xml`. On commercial SBCs, look for anything labeled "public ENUM," "ENUM fallback," or "E.164 to URI resolution." If you find it, disable it unless you have a specific, documented business reason to query the public tree — and if you do, use a private ENUM zone you control (tier-1 ENUM), not the public root.
At the network layer, consider egress-blocking DNS queries for `*.e164.arpa` at your resolver. It's a cheap defense-in-depth measure that costs nothing if you're not using ENUM and immediately surfaces which of your systems still are. Your DNS logs become your telecom inventory.
For anyone building modern VoIP or CPaaS products: this is a good reminder that DNS-based service discovery inherits every trust assumption of the DNS itself. If you're publishing NAPTR, SRV, or URI records for real-time services, assume that stale delegations will be picked up by curious researchers — or less curious adversaries — and design your fallback logic to fail closed, not open.
The IETF is unlikely to formally deprecate e164.arpa; standards bodies rarely retract a spec just because reality moved on. Which means the responsibility falls on vendors to ship secure defaults (ENUM off, not on) and on operators to audit what their PBXes are quietly asking the internet about. Expect a small wave of CVEs and vendor advisories over the next few weeks as more researchers scan the vacant subtrees. And if you've been meaning to finally decommission that 2011-vintage Asterisk box in the closet — this is your sign.
I'm mostly amazed the author didn't land in jail, which is the normally the response to reporting this kind of thing to authorities.
It is a shame they did not actually set up a SIP server and see if any of those requests turned into actual call terminations.There is another schema called TRIP [1] - telephony routing over ip that uses a number format "1234*1455" designed to be entered on a standard phone keypad. When I
I enjoyed reading this much more than anything I read here recently. In particular I like how it absolutely shows that somethings just… fall through the cracks!
It's funny how such holes can remain for years, and no one notices until someone stumbles upon them. It's interesting that no serious organization wanted to address the issue until it was discovered that the military was involved.It's a shame the author wasn't rewarded but at lea
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
> It never really took off though, and even back in its early days it saw barely any use. Over the years it just deteriorated further, and today it's basically completely dead.It's actually not completely dead... It's just (almost) completely non-public.You can subscribe to service