Summary
After a Gateway is programmed and publishes status.addresses[0] (an <id>.datumproxy.net name), the address takes ~65–85s to become answerable from the authoritative nameserver. That's above the 60s reasonable-expectation threshold for a gateway/managed-DNS record to program (datum-cloud/infra#3692). A customer's gateway is "programmed" but its address doesn't resolve — and therefore doesn't serve — for over a minute.
Evidence
Measured from construct e2e runs on prod that used a generous 5-minute resolve budget, so slow resolves passed and the poll count reveals the true time (each poll = 5s, querying the authoritative NS directly, no negative cache):
| run |
slowest datumproxy resolve |
| A |
~85s (17 polls) |
| B |
~80s (16 polls) |
| C |
~65s (13 polls) |
| D |
~10s (2 polls) |
So it routinely sits in the 65–85s band, occasionally fast. This is chronic, not a regression — it only surfaced now because the e2e budget was tightened to the 60s SLO; the old multi-minute budget masked it. Once tightened, prod e2e failed on this path every run.
Where to look
The address is published quickly on the Gateway status, but the DNS record for it (programmed via the gateway DNS path → DNSRecordSet → downstream DNS/PowerDNS) lags. Likely the same propagation-latency family as datum-cloud/enhancements#291 (custom-hostname DNSRecordProgrammed Pending), but a different record (gateway address vs custom hostname CNAME). Worth confirming whether the delay is in record creation/requeue here or in downstream propagation, and fixing at the slow layer.
Threshold reference
enhancements#828 — "Gateway programs (address assigned) 30s" / "Managed DNS record programs 60s". Per that contract the gap is a defect to fix, not headroom to grant. Related: datum-cloud/enhancements#291.
Summary
After a Gateway is programmed and publishes
status.addresses[0](an<id>.datumproxy.netname), the address takes ~65–85s to become answerable from the authoritative nameserver. That's above the 60s reasonable-expectation threshold for a gateway/managed-DNS record to program (datum-cloud/infra#3692). A customer's gateway is "programmed" but its address doesn't resolve — and therefore doesn't serve — for over a minute.Evidence
Measured from construct e2e runs on prod that used a generous 5-minute resolve budget, so slow resolves passed and the poll count reveals the true time (each poll = 5s, querying the authoritative NS directly, no negative cache):
So it routinely sits in the 65–85s band, occasionally fast. This is chronic, not a regression — it only surfaced now because the e2e budget was tightened to the 60s SLO; the old multi-minute budget masked it. Once tightened, prod e2e failed on this path every run.
Where to look
The address is published quickly on the Gateway status, but the DNS record for it (programmed via the gateway DNS path → DNSRecordSet → downstream DNS/PowerDNS) lags. Likely the same propagation-latency family as datum-cloud/enhancements#291 (custom-hostname
DNSRecordProgrammedPending), but a different record (gateway address vs custom hostname CNAME). Worth confirming whether the delay is in record creation/requeue here or in downstream propagation, and fixing at the slow layer.Threshold reference
enhancements#828 — "Gateway programs (address assigned) 30s" / "Managed DNS record programs 60s". Per that contract the gap is a defect to fix, not headroom to grant. Related: datum-cloud/enhancements#291.