A partner reports your NAT address hitting their sinkhole at 02:14 — how do you name the internal host?

## The shape of this problem You did not find this. Somebody else did, and handed you two fields: an external address that belongs to your organisation, and a time. Everything that follows is a chain of record lookups, and the interview is testing whether you know which record carries which link and where the chain usually breaks. ## Why the resolver log does not help The instinct is to search DNS. In a multi-site campus with a central recursive resolver, that instinct fails on a structural detail: **the recursive resolver's query log records the client as whatever last spoke to it.** If sites run local forwarders, every query in the central log has the forwarder's address as its source. The record honestly confirms that the name was looked up, at what time, and how often — and it is incapable of naming the machine that wanted it. The fixes are architectural, not analytical: log queries at the *first* resolver that sees the real client, or collect DNS telemetry on the endpoint itself, where the record can carry the querying process as well as the name. Both are worth raising, but neither retroactively rescues last night's log. ## The attribution ladder Each rung is a different log, with a different owner and a different retention: 1. **Public address + port + time → inside address.** Only the NAT translation log (or firewall session log with pre- and post-translation fields) does this. Port address translation is many-to-one, so at 02:14 a busy pool may hold hundreds of concurrent sessions on the same public address. Without the public source port you are choosing between candidates; with it, the entry is unique. 2. **Inside address + time → machine.** DHCP lease logs or IPAM. Leases move, so the mapping is time-bound; an address that belongs to a laptop at 02:14 may belong to a different one by the time you look. 3. **Machine + time → account.** VPN session records, 802.1X or NAC authentication, or a host logon record. Note what this proves: that a credential was accepted on that machine, not that a particular person was sitting at it. 4. **Machine + time → process.** Endpoint network-connection telemetry is the only surface that can say which executable opened the socket. Where it exists, it is the rung that turns a network report into an investigation. ## Clocks, and why they matter more than people expect The partner's timestamp is in the partner's clock and, unless they said so, possibly not in UTC. A two-minute skew across a busy NAT pool multiplies your candidate set. Ask explicitly for the timezone and the source of their timestamp, and confirm your own exporters and firewalls are NTP-synchronised. Search a window, not an instant, and narrow it with the port rather than by guessing. ## When the chain is broken NAT translation logs are high volume and are frequently retained for days, not months. If the report is older than the retention, say so plainly rather than presenting a partial match as an identification — a wrong host named at this stage propagates into every later step of the investigation and into whatever you tell the partner. Then pivot: proxy logs may hold the client address and the authenticated user for the same period; endpoint telemetry may still hold the connection; the destination address or name may be searchable in whatever surfaces do have the retention. And record the retention gap as a finding, because the next report will land the same way. ## Stating the conclusion honestly The report told you a connection was observed from an address you own. After the ladder, the strongest defensible claim is typically: "the translation log maps that public address and port at 02:14:0x to inside host 10.x.y.z, which DHCP shows leased to laptop ABC, on which account jdoe held an active session." Each clause names its source. What you have not shown is intent, a person at the keyboard, or what crossed the connection — the sinkhole report may itself be the result of a malicious process, a browser extension, a security tool, or a research VM someone runs deliberately. Naming the host is the beginning of the investigation, not the verdict.