When Every Address Lookup Failed at Once

The laptop fan was humming along when 1,264 little failures filled the screen almost at the same time.

I was in the middle of a planning job for a move involving a large collection of customer website addresses. Before we could decide how to handle the move, I needed to sort those addresses by the company that manages each one. That detail changes the available choices. It is a little like checking who holds the key to each of 1,264 storage units before deciding how to move their contents.

The first pass had already shown a useful shape: 1,120 of the 1,264 addresses belonged with the same large provider. That was about 88 percent of the list. The remaining addresses were scattered, and 73 did not give an answer at all. Knowing the split mattered because it would shape the plan for the whole move.

To get those answers, I was asking an online address book a simple question for each website address: who is in charge of it? The technical name for this service is DNS, which is just the internet’s way of looking up where a name should go. It is usually invisible. You type a website name, and the answer arrives.

Then the whole batch stopped.

I tried the usual public lookup service first. Every request failed. Not a few. Not the odd difficult address. All 1,264 failed, and they failed without any wait at all.

That speed was the clue. If a website address is genuinely hard to find, there is usually a pause. The request has to travel, ask around, and eventually come back with an answer or a timeout. It feels like calling a business and hearing the phone ring before nobody picks up. This was different. It was closer to finding that the phone has no dial tone before I had even made the call.

For a few minutes, the screen suggested that the entire address system had gone bad. That would have been the wrong story. I had not reached the address book at all.

The first route had failed because the computer would not accept the other service’s proof of identity. The technical name is a TLS certificate. Think of it as the little digital ID card a website shows before a private conversation begins. On this particular machine, that ID could not be checked properly, so the conversation never started. No address question had gone out. No address answer had a chance to come back.

I did not fully solve why that computer rejected the ID card that day. The message pointed to something missing or out of date in the machine’s list of trusted signers. I could have stopped and chased that down. But it would have stalled the migration audit I was supposed to finish. More importantly, it was not necessary to keep the work moving.

Instead, I changed one line so the same question went to a second public address book. The two services use the same basic answer format. That mattered. I did not have to rebuild the sorting process or make a second version of the program. I swapped the destination, asked again, and the answers came back normally.

The result was the same useful picture I needed for planning: 1,120 of the 1,264 addresses were with the main provider. The rest could be handled in their smaller groups. One failed security check on one computer had nearly turned a simple counting job into a lost day, even though the addresses themselves were fine.

The backup mattered again later that day. After changing where a website name pointed, the machine’s own saved copy continued to point to the old place for a full hour. That is normal behavior. Computers keep recent answers around for a while so they do not have to ask the internet the same question over and over. But a saved answer is not helpful when you are checking whether a change just took effect.

The direct public lookup showed the new destination right away. The machine’s local copy still showed the old one. Without that second check, it would have looked as though the change had failed. It had not. The wrong answer was simply sitting in the local memory, waiting for its hour to run out.

There are two lessons here, and neither requires anyone to become a technical person. First, notice the shape of a failure. When a large set of things fails instantly and in exactly the same way, the problem may be the doorway in front of the service, not the service itself. A broken connection, a rejected sign-in, or a missing digital ID can make everything behind it look broken.

Second, any important batch job that relies on one outside service has a fragile spot, even when the work itself is sound. The weak spot does not have to be a dramatic outage. It can be one computer with a trust problem. It can be an old saved answer. It can be a single provider that is unreachable on a particular day.

The count that told the whole story was 1,264 to zero: every single lookup died before it could ask anything, because one machine’s certificate check failed first, and that all-or-nothing pattern is what pointed straight at the doorway instead of the address book. Swap one destination line and the same 1,120 out of 1,264 addresses landed back with the main provider, which is the only number that actually mattered for planning the move.

dxdev LESSON · paste into your AI coding agent
LESSON: When a whole batch fails instantly and identically, suspect the doorway in front of the service, and keep a second compatible route ready
SOURCE: dxdev.com/blog/2026-05-03_every-address-lookup-failed-at-once
WHAT HAPPENED: A planning job sorted 1,264 customer website addresses by the company managing each one, using a public online address lookup (DNS over HTTPS). Every request failed, all 1,264, with no wait at all. The cause was a TLS certificate the machine could not verify, so the conversation never started and no lookup question was sent. Changing one line to send the same question to a second public service that uses the same answer format brought the answers back, showing 1,120 of the 1,264 addresses with the same large provider. Later the same day the machine's own cached copy kept pointing at the old destination for an hour after a change, while the direct public lookup showed the new one right away.
THE RULE: When a large set of requests fails instantly and in the same way, suspect the connection in front of the service before the data, keep a second compatible service configured, and check changes against a lookup that bypasses local cached answers.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any batch job that depends on a single outside service or endpoint with no configured second provider that returns the same format.
  2. Any error handling that reports thousands of instant failures as failures of the individual items instead of checking the connection or certificate first.
  3. Any verification of a recently changed DNS record that reads only the machine's local cached answer.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.