When the operator decides not to create a DNS record for a load balancer hostname, the reason never reaches the load balancer's status. It works the reason out, for example "update your registrar's NS records", and uses it only to count failures on the gateway. The gateway then says "see per-hostname conditions for details" and there aren't any. In the portal this shows up as a DNS badge that spins forever, and on production today it took a live investigation to find out why.
How it fails
- A user adds a custom hostname to a load balancer on a domain that's verified and has a zone on Datum.
- The operator finds a reason it can't create the record, such as the domain's nameservers not matching the zone's.
- It builds a per-hostname status with that reason and a useful message, then only counts it for the gateway's summary.
- The per-hostname status the load balancer publishes is built from DNS records that already exist. No record was created, so the hostname gets no DNS status at all.
This happens for every reason that stops a record before it's created: no zone, a zone that isn't ready, an unverified domain, mismatched nameservers, or a clash with a record the user made. The user only ever sees problems that happen after a record exists.
What we saw
On production, a hostname on a verified domain with a ready zone had:
- a gateway condition reading "0/1 hostnames have DNS records programmed; see per-hostname conditions for details"
- per-hostname status on the load balancer showing the hostname was claimed and its certificate was ready, and nothing about DNS
The real cause (stale nameservers on the domain) was only found by reading operator code and logs.
What success looks like
- Every hostname that needs a Datum-managed record has a DNS status on the load balancer, whether or not a record exists.
- A hostname blocked before a record is created shows the operator's reason and message.
- The gateway condition doesn't point at details that don't exist.
- Hostnames that don't need a Datum-managed record stay out of the count, as they do now.
Related
When the operator decides not to create a DNS record for a load balancer hostname, the reason never reaches the load balancer's status. It works the reason out, for example "update your registrar's NS records", and uses it only to count failures on the gateway. The gateway then says "see per-hostname conditions for details" and there aren't any. In the portal this shows up as a DNS badge that spins forever, and on production today it took a live investigation to find out why.
How it fails
This happens for every reason that stops a record before it's created: no zone, a zone that isn't ready, an unverified domain, mismatched nameservers, or a clash with a record the user made. The user only ever sees problems that happen after a record exists.
What we saw
On production, a hostname on a verified domain with a ready zone had:
The real cause (stale nameservers on the domain) was only found by reading operator code and logs.
What success looks like
Related