Map: the target placed and named¶

A first pass over Ankh-Morpork, pulled from certificate transparency and DNS and attributed with the fingerprints, comes out roughly like this:

ankh-morpork.example
  www         public   Seneca Smartsite CMS   (Smartsite markers in the page)
  mijn        public   Exxellence PIP portal  (/persoonlijke-internet-pagina route)
  formulieren public   Open Formulieren       (openforms-root div, API at /api/v1/)
  inloggen    identity DigiD                  (SAML AuthnRequest to DigiD, ACS on this host)
  zaken       plumbing Open Zaak, ZGW         (/zaken/api/v1/ and /catalogi/api/v1/ answer)
  koppel      plumbing legacy StUF SOAP       (SOAP koppelvlak still live)
  kaart       geo      Vicrea                 (WMS and WFS, proxied to PDOK)

Most of these are front doors, built to be visited. Two are not. zaken answering on the ZGW paths at all is worth a second look for a back-office API: either it is exposed on purpose or it is reachable when it is not meant to be. formulieren resolves by CNAME onto a supplier-hosted domain, so the form a resident sees and the estate that serves it sit on different infrastructure. The core never appears on the apex at all; Centric and PinkRoccade surface only as the supplier named in the inloggen assertion.

The interesting questions are in how these hosts connect. inloggen hands a DigiD assertion to formulieren, which on prefill pulls BRP data into the fields, so the authorisation boundary between login and form sits right there. A form submitted on formulieren opens a case through the ZGW API on zaken, so a logic flaw on the form reaches the case store behind it. zaken speaking REST while koppel still speaks StUF is the half-migrated seam, old and new plumbing live at once.

Every row is a passive inference, not a confirmed hit. The map is provisional by definition: the next pass promotes a guess to a fact or drops it.