Lab notes · 2026-09-13

Who answers for apple.com: half Apple, half Packet Clearing House

apple.com has four nameservers, a to d.ns.apple.com. Two of them are Apple's own anycast network (AS714). The other two are Packet Clearing House, the non-profit that runs anycast DNS for a few hundred top-level domains, and they answer from the same servers that serve pch.net itself. icloud.com uses exactly the same four. We noticed it while checking pch.net, and it is a clean example of the pattern we keep recommending: own anycast plus one outside operator on separate infrastructure. So we measured both halves from 1,000 vantage points and compared them.

What the delegation says

Three things are visible before any probe is involved.

• Each address is its own prefix. Apple's two are a /24 each; PCH's two are a /24 and a /48 each, and the /48s carry Apple's AS number in the address (…:714::1). One prefix per customer nameserver means PCH can announce, withdraw or steer Apple's two addresses independently of every other customer.
• The zone comes from one hidden primary. All eight addresses return the same SOA, serial 2026091100, and the same MNAME, ns-ext-prod.jackfruit.apple.com, which is not in the delegation. PCH is a secondary here, not the source.
• apple.com is not signed. There is no DS record in .com and no DNSKEY at the apex. That is a matter of public record, and it is the same for icloud.com.

What NSID says about the inside of one site

Ask c.ns.apple.com from Frankfurt twenty-five times for hostname.bind and you get eleven different answers: 1.fra.pch, 2.fra.pch, 3.fra.pch … up to 16.fra.pch. Same for d, same for anyns.pch.net. The Frankfurt site is not one server behind an anycast address; it is at least sixteen, and the router spreads consecutive queries across them. Apple's own half behaves differently: a always answers as defra3-dns-001, b always as defra3-dns-002. Two addresses, two machines, one site, defra3 being Apple's third Frankfurt location. From here all eight addresses are 16 to 18 ms away, so a resolver in Germany cannot tell the two halves apart by speed.

That is the limit of one vantage point. Whether PCH's cloud reaches further than Apple's own, and by how much, is a question for a thousand.

From 1,000 vantage points

On 12 September, 16:38 to 16:43 UTC, we sent one SOA query with the NSID bit to each of the eight addresses from the same 1,000 RIPE Atlas probes, IPv4 and IPv6, about 965 answers per address. The probe set is drawn per country in proportion to population: 299 probes in Asia, 242 in Europe, 159 in North America, 155 in South America, 54 in Africa, 48 in the Middle East, 9 in Oceania.

Apple's half answered from 30 sites, PCH's from 124. Apple's site codes read like airport codes with a country prefix: eleven in the United States, defra3 and deber5 in Germany, three in France, uklon6 and gbmnc1, sesto4, dkblp1, iedub1, brsao4, sgsin8, hkhkg3, inbom5, two in Tokyo, two in Australia. That is Apple's own network: North America, Western Europe, and a handful of large Asian cities. No site in Africa, none in the Middle East, none in Eastern Europe, one that matters in South America. PCH's 124 read like a list of internet exchanges, because that is what they are: jnb, cpt, nbo, dar, los, lad, kgl, abj in Africa; ruh, tlv, ist, dxb, bah2 in the Middle East; aep, scl, lim, bog2, gru, ccs, lpb2, sjo, gua in Latin America; dac, ktm, pnh, rgn, blr, maa, ccu in South Asia and beyond.

Same probes, same five minutes, same question. Where each half has a site, the two are indistinguishable: Europe, North America, East Asia all within a few milliseconds. Where only one of them has a site, the table shows who.

• Africa is PCH. 54 probes, Apple's half answers them from London at a median of 171 ms; PCH's from Johannesburg, Lagos, Nairobi, Cape Town and Dar es Salaam at 2 ms. 47 of 54 African probes are faster on PCH. The four that are faster on Apple sit in Tunisia, Uganda and Chad, where both halves are slow and Apple is merely less so.
• The Middle East is PCH. Riyadh, Istanbul, Tel Aviv, Thessaloniki. Apple answers those probes from Frankfurt and, for thirteen of them, from São Paulo. 64 ms versus 24 on IPv4; 88 versus 49 on IPv6.
• South America is Apple. One site, brsao4, takes 207 of Apple's 310 South American answers at 27 ms. PCH has seven sites on the continent, and 123 of its 300 South American answers still arrive from Miami, at 83 ms. 81 South American probes are faster on Apple, 48 on PCH. The sites exist; the networks those probes sit behind route past them to Miami. That is their choice, not PCH's. That is what anycast catchment means: the operator decides where the servers are, everyone else's routing decides who reaches them.
• Asia is a draw with an edge for PCH. 124 probes faster on PCH, 86 on Apple, 73 within three milliseconds. Apple's Singapore, Bombay, Tokyo and Hong Kong sites are good; PCH adds Jakarta, Bangkok, Delhi, Dhaka, Kuala Lumpur, Manila, Seoul, Taipei, Kathmandu.

The row that matters is the third one. A resolver does not pick a nameserver at random; it keeps a running estimate of each one's response time and prefers the fastest. So the latency a user sees for apple.com is not the average of the four but, after a few queries, the best of them. Best of four, IPv4: world median 12 ms, 3 % of probes above 100 ms, and 603 of 968 probes, 62 %, under 20 ms. Neither half alone gets there: Apple alone is 25 ms and 12 % above 100, PCH alone 17 ms and 14 %. Akamai, serving apple.news from six addresses for the same probes, lands at 18 ms and 5 %.

The probes that land far away

278 of PCH's 1,839 IPv4 answers took longer than 100 ms, and most of them are one story: South American probes answered from Miami or Washington (97). The rest is Chinese probes at China Telecom and Unicom answered from Amsterdam and Frankfurt at 170 to 245 ms, and on IPv6, Russian probes in seventeen different networks answered from Jakarta at 200 to 260 ms. PCH has sites in Hong Kong, Taipei, Seoul and Tokyo, and has arn, rix, tll and waw near Russia's western border; the networks in question route around them. Apple's 228 slow answers are the mirror image: African probes answered from London (76), then Middle Eastern and European probes answered from São Paulo (26). Both halves have a corner of the world they reach the long way round, and they are different corners. That is the practical case for the split.

PCH's own zone, for comparison

pch.net is served by anyns.pch.net on the same anycast cloud (122 sites in our sample), plus two unicast servers in the United States: ns2.pch.net is puck.nether.net in AS267, ns3.pch.net sits in AS715. From the whole world those two are 140 and 178 ms away at the median; 75 % and 83 % of probes see them above 100 ms. Best of three is 17 ms, because best of three is anyns. It is a different design choice: one anycast leg for reach, two plain machines on other people's networks for the day the anycast cloud itself is what breaks. On that day pch.net resolves in 140 ms instead of 17. It still resolves.

Method, so you can check it

Delegation, addresses, origin AS and country from plain DNS (tools/delegation/inventory.py, see the TLD note). Then one DNS SOA query with the NSID bit per nameserver address, UDP, no retry, from the same 1,000 RIPE Atlas probes for every address and both families (measurements 210820572 to 210820599, public). The probe set is drawn per country in proportion to population, only from probes whose IPv4 and IPv6 both work, capped by how many such probes a country has; India, China and Nigeria are under-represented because Atlas has few probes there, and Oceania has nine, which is why it is in the table and not in the text. "Site" is the NSID string with the instance number stripped: 3.fra.pch → fra, sesto4-rdc-dns-002 → sesto4. "Best of" is, per probe, the fastest answering address of the group; it also counts probes that only one half answered, which is why the Middle East best-of-four median sits a few milliseconds above the PCH half. Between 3 and 4 % of probes answered nothing on any address, and that number is the same for Apple, PCH and Akamai, so it is Atlas, not them. Interception was not filtered; it would show up as an answer without NSID and a wrong serial, and we found none of the latter. Everything here is a snapshot of five minutes on a Saturday afternoon.

All of this is in the public DNS. We asked nobody for permission to measure their nameservers because a SOA query is what every resolver on earth sends them all day; 26,000 queries from us are noise. Nothing in this note is a fault at Apple or PCH. The long paths are decisions made by the transit providers of the probes in question, and the same measurement from the same probes will show them on any anycast network.

What comes next

139 German zones, same probes, same method, all at once: which of them are hybrid like apple.com, which are one operator, which are one machine, and what each choice costs in milliseconds where the users are. That note is out: What the delegation costs.

Wording, 14 September 2026

The South America paragraph used to say that PCH "sends" 123 of its 300 South American answers to Miami. PCH sends nothing anywhere: the networks behind those probes choose the path to Miami over seven closer sites, and PCH would rather they did not. Bill Woodcock of PCH pointed this out the same day. The sentence now says whose choice it is. No number changed.