HN Debrief

I accidentally logged hundreds of thousands of phone calls to military bases

  • Security
  • Infrastructure
  • Telecom
  • Networking

The post walks through how the author bought a neglected domain tied to ENUM, an old standard that maps phone numbers into DNS so voice systems can route calls over the internet, and then started receiving live lookup traffic that should never have reached a public domain they controlled. The surprising part was not just that ENUM still existed, but that the queries exposed called numbers and timing data for destinations including Diego Garcia and Ascension Island, places strongly associated with UK and US military activity. The writeup lands as a supply-chain failure in telecom plumbing, not a clever app bug. A forgotten namespace was still wired into real call-routing paths.

If your systems depend on obscure DNS or telecom routing layers, audit who controls every domain and namespace they touch. “Unused” infrastructure can still be live enough to leak operational data, especially when private telco plumbing spills onto the public internet.

Discussion mood

Strongly positive about the writeup and the author’s curiosity, with a nervous undercurrent about how risky it is to touch military or telecom systems at all. The main reaction was that this is exactly the kind of forgotten infrastructure failure that persists for years because no one checks ownership boundaries until something sensitive leaks.

Key insights

  1. 01

    Private ENUM never really went away

    Public ENUM fizzled, but carriers kept the pattern alive for internal routing and number portability. That changes the story from a weird historical artifact into a live operational leak. The queries likely came from systems that assumed this namespace was private or at least trusted, then accidentally spilled onto the public network.

    Do not treat abandoned public-facing protocol infrastructure as harmless just because the public version failed. If you run telecom, messaging, or identity systems, verify that any private lookup path cannot silently fall back to public DNS.

      Attribution:
    • toast0 #1
    • wolrah #1
    • srejk #1
    • trollbridge #1
  2. 02

    Why phone systems were querying DNS at all

    ENUM existed to turn a phone number into an internet destination so SIP endpoints could connect directly instead of bouncing through traditional telephony intermediaries. Framed that way, DNS was being used as a distributed phone book for call routing. The bug is less exotic than it sounds. It is a normal consequence of voice systems reusing internet naming layers.

    If your team does not work in telecom, read this as another example of application logic hiding inside DNS. Security reviews need to cover DNS-dependent behavior outside classic web use cases.

      Attribution:
    • somat #1
    • brcmthrowaway #1
  3. 03

    The direct-call path was probably real

    One person wished the author had gone further and stood up a SIP server to see whether any lookups turned into call attempts. That is a sharp way to frame the severity. If the lookups were not just metadata leaks but active routing decisions, the issue moves from passive exposure into possible call interception or misdelivery.

    When you assess a namespace takeover or routing leak, test whether the affected system only reveals metadata or will actually hand over traffic. That distinction should drive incident response priority and disclosure urgency.

      Attribution:
    • pknopf #1
    • chaz6 #1
  4. 04

    The military inference was probably justified

    Skepticism about jumping from source IPs to military calls did not hold up once people focused on the called numbers and locations. Diego Garcia in particular has no normal civilian telecom footprint in the usual sense. That makes the post’s headline implication feel less like sensationalism and more like a fair reading of the destinations involved.

    When judging leak sensitivity, destination metadata can be enough. Even without audio content, called numbers, timestamps, and geography may already reveal operationally sensitive patterns.

      Attribution:
    • tosti #1
    • matteason #1
    • alasdair_ #1
    • RugnirViking #1
    • duskwuff #1

Against the grain

  1. 01

    The exact software source stayed unclear

    A gap in the story is that nobody pinned down which products or operators were still making these lookups. That leaves some ambiguity about scope. The leak is real, but without identifying the software path you cannot tell whether this was one stale deployment, a carrier default, or a wider class of systems.

    If you encounter a similar issue, spend effort isolating the implementation chain before going public. Vendors and operators will move faster when you can name the component and the fallback behavior.

      Attribution:
    • seri4l #1
    • cryptolobster #1
  2. 02

    The legal danger may be overstated here

    The fear of immediate prosecution was palpable, but a few people noted the practical facts. The author reported a UK-linked issue from Germany, and the activity described looked more like receiving stray traffic than actively breaking in. That does not make it safe, but it does make the “surely jail” reaction less inevitable than the mood suggested.

    Do not assume either safety or doom from anecdotes about disclosure. Check the jurisdiction, the actions you actually took, and whether you merely observed traffic or altered service behavior.

      Attribution:
    • dmd #1
    • jakzurr #1
    • edelbitter #1
    • lukan #1

In plain english

DNS ↩
Domain Name System, the internet service that translates website names into network addresses.
ENUM ↩
Telephone Number Mapping, a standard that converts phone numbers into Domain Name System records so internet-based voice systems can route calls.
SIP ↩
Session Initiation Protocol, a common protocol used to set up and manage internet voice and video calls.
VoIP ↩
Voice over Internet Protocol, phone service delivered over the internet instead of a traditional phone network.

Reference links

Protocol and telecom background

Books and reading