coilyco-flight-deck/infrastructure
Watch
2
0
Code Issues 110 Pull requests Projects Releases Packages Wiki Activity Actions

Route53 REGISTER_DOMAIN fails sub-second on this AWS account, and the same cause would silently break domain AutoRenew #971

New issue
Open
opened 2026-08-28 02:26:40 +00:00 by coilyco-ops · 4 comments
coilyco-ops commented 2026-08-28 02:26:40 +00:00
Owner
Copy link

Split out of coilysiren/inbox#475, which owns the WHOIS exposure on coilyco.ai. This issue owns the AWS-side failure, because it reaches past that one domain.

The failure

Five REGISTER_DOMAIN operations on 2026-08-27 against coilyco.com, coilyco.dev, and coilyco.me all returned:

We can't finish registering your domain. Contact AWS Support [...] for further information.

Timing is the decisive signal. The solo retry was submitted at 16:11:48.201 and failed at 16:11:48.950, rejected in 0.75 seconds, before any registry round-trip. coilyco.ai by contrast reached the registry within a minute and its record was created. This is an account-side gate.

Eliminated with evidence

  • ICANN registrant email verification - DONE for the account
  • Domain count limit - 2 registered, default ceiling 20
  • Account standing - ACTIVE
  • Partial or stuck registration - all three names remain AVAILABLE, nothing half-landed
  • Burst or velocity throttle - a solo retry an hour later failed identically
  • Contact record validity - the same contacts succeeded for .ai minutes earlier
  • TLD class - .me is a ccTLD like .ai and still failed, so gTLD-versus-ccTLD does not predict it
  • Privacy protection service - tested 2026-08-28 with an idempotent update-domain-contact-privacy on coilysiren.me, operation 301353af-a0aa-429d-ba8e-39bbb5d26fa3, status SUCCESSFUL. The service works on this account, on .me, at zero cost and with no state change. The earlier privacy-flag theory is dead.

Surviving candidates

  1. Payment instrument on the AWS account. An expired card, a declined card, or an address-verification mismatch all fail at the payment step, which runs before the registry call. This fits the sub-second uniform failure across three unrelated registries better than anything else.
  2. An AWS-side fraud or review hold on domain registration.

Neither is visible through the API. AWS returns the generic message by design.

The part that reaches past the original task

If the cause is the payment instrument, domain AutoRenew is exposed too. Both registered domains carry AutoRenew: true and would renew against the same instrument:

  • coilysiren.me - expiry 2027-07-05, and this is the live production domain
  • coilyco.ai - expiry 2028-08-27, $137 renewal

A renewal failure is quiet. It surfaces as a domain entering redemption, not as an alarm. coilysiren.me carries 88 records in its hosted zone and is the public surface, so losing it is the worst available outcome of an unchecked card.

This is why the payment check is worth doing even though the three names are being registered elsewhere. The registration path was routed around. The renewal path cannot be.

Next actions

  1. Human, console only. Billing to Payment methods. Check for an expired or declined card, and check the card's billing address against the AWS account contact address. The Route53 console also surfaces a more specific error than the API does.
  2. If billing is clean, file an AWS support case by hand. The Support API is unavailable on this account: DescribeSeverityLevels returns SubscriptionRequiredException, Premium Support required.
  3. Once the cause is known, decide whether AutoRenew on the two live domains needs a guard, such as a calendar check ahead of each expiry or an alert on renewal operations.

Not in scope

Registering coilyco.com, coilyco.dev, or coilyco.me. Kai chose an external registrar for those, so they no longer depend on this being fixed. The WHOIS exposure on coilyco.ai stays with coilysiren/inbox#475.

Split out of `coilysiren/inbox#475`, which owns the WHOIS exposure on `coilyco.ai`. This issue owns the AWS-side failure, because it reaches past that one domain. ## The failure Five `REGISTER_DOMAIN` operations on 2026-08-27 against `coilyco.com`, `coilyco.dev`, and `coilyco.me` all returned: > We can't finish registering your domain. Contact AWS Support [...] for further information. Timing is the decisive signal. The solo retry was submitted at `16:11:48.201` and failed at `16:11:48.950`, **rejected in 0.75 seconds**, before any registry round-trip. `coilyco.ai` by contrast reached the registry within a minute and its record was created. This is an account-side gate. ## Eliminated with evidence * ICANN registrant email verification - `DONE` for the account * Domain count limit - 2 registered, default ceiling 20 * Account standing - `ACTIVE` * Partial or stuck registration - all three names remain `AVAILABLE`, nothing half-landed * Burst or velocity throttle - a solo retry an hour later failed identically * Contact record validity - the same contacts succeeded for `.ai` minutes earlier * TLD class - `.me` is a ccTLD like `.ai` and still failed, so gTLD-versus-ccTLD does not predict it * **Privacy protection service** - tested 2026-08-28 with an idempotent `update-domain-contact-privacy` on `coilysiren.me`, operation `301353af-a0aa-429d-ba8e-39bbb5d26fa3`, status `SUCCESSFUL`. The service works on this account, on `.me`, at zero cost and with no state change. The earlier privacy-flag theory is dead. ## Surviving candidates 1. **Payment instrument on the AWS account.** An expired card, a declined card, or an address-verification mismatch all fail at the payment step, which runs before the registry call. This fits the sub-second uniform failure across three unrelated registries better than anything else. 2. **An AWS-side fraud or review hold on domain registration.** Neither is visible through the API. AWS returns the generic message by design. ## The part that reaches past the original task **If the cause is the payment instrument, domain AutoRenew is exposed too.** Both registered domains carry `AutoRenew: true` and would renew against the same instrument: * `coilysiren.me` - expiry 2027-07-05, and this is the live production domain * `coilyco.ai` - expiry 2028-08-27, $137 renewal A renewal failure is quiet. It surfaces as a domain entering redemption, not as an alarm. `coilysiren.me` carries 88 records in its hosted zone and is the public surface, so losing it is the worst available outcome of an unchecked card. This is why the payment check is worth doing even though the three names are being registered elsewhere. The registration path was routed around. The renewal path cannot be. ## Next actions 1. **Human, console only.** Billing to Payment methods. Check for an expired or declined card, and check the card's billing address against the AWS account contact address. The Route53 console also surfaces a more specific error than the API does. 2. If billing is clean, file an AWS support case by hand. The Support API is unavailable on this account: `DescribeSeverityLevels` returns `SubscriptionRequiredException`, Premium Support required. 3. Once the cause is known, decide whether AutoRenew on the two live domains needs a guard, such as a calendar check ahead of each expiry or an alert on renewal operations. ## Not in scope Registering `coilyco.com`, `coilyco.dev`, or `coilyco.me`. Kai chose an external registrar for those, so they no longer depend on this being fixed. The WHOIS exposure on `coilyco.ai` stays with `coilysiren/inbox#475`.
coilyco-ops commented 2026-08-28 02:37:53 +00:00
Author
Owner
Copy link

Correction - the payment-instrument hypothesis in the issue body is wrong, and so is the AutoRenew alarm

Kai checked Billing on 2026-08-28 and reported it clean. Pushing on why the hypothesis was raised at all surfaced that the issue body over-weighted it against evidence already collected.

The evidence that was in hand and not reconciled

coilyco.ai registered successfully at 15:01:48 for $274, the largest of the four charges. The .com failures begin at 16:10:46, roughly one hour later, on the same account and the same payment instrument.

AWS does not complete a domain registration without collecting payment, and that registration completed: the registry record exists, Gandi holds it, and it appears in list-domains with a 2028 expiry.

The payment theory therefore requires an instrument that clears $274 to decline $16 an hour later. Nothing supports that, and Kai's Billing check independently contradicts it.

The reasoning flaw, named so it is not repeated

Sub-second rejection establishes that AWS refused the request internally, before any registry round-trip. It does not establish which internal check fired. Payment verification, fraud and risk scoring, and account eligibility all sit inside that window and all fail fast.

The issue body picked one of the three and described it as fitting the timing better. The timing is equally consistent with all three, and the successful $274 charge actively argues against the one chosen. That was inference presented as a ranked diagnosis.

Revised candidate ordering

  1. AWS-side risk or review hold on domain registration. The generic message plus a pointer to a registration-issue support case is the characteristic shape of an internal risk refusal. A first-time $274 domain purchase an hour earlier is a plausible trigger. This is now the leading candidate.
  2. Account eligibility condition on new registrations, not visible through the API.
  3. Payment instrument. Demoted to unlikely. Contradicted by the cleared $274 charge and by Kai's Billing check.

Still eliminated with evidence, unchanged: registrant email verification, domain count limit, account standing, partial registration, velocity throttle, contact validity, TLD class, and the privacy protection service.

Retracting the AutoRenew risk

The issue body argued that coilysiren.me (expiry 2027-07-05, 88 records, the public surface) and coilyco.ai (expiry 2028-08-27) were exposed because AutoRenew runs against the same instrument.

That concern was entirely downstream of the payment hypothesis and does not survive it. Billing is clean and the instrument demonstrably processed $274. Renewals charge that same working instrument. There is no silent-renewal-failure risk here, and no renewal guard is needed on the strength of this issue.

Retracting it explicitly rather than leaving it in the body, because an unretracted alarm about losing the production domain would keep drawing attention it does not deserve.

Recommended disposition

Close as not worth pursuing. The three names are being registered at Porkbun, so nothing depends on this. The only remaining path is a hand-filed support case (Premium Support is not on this account, so the Support API returns SubscriptionRequiredException), and the payoff is an explanation for a path already routed around.

Reopen if a future Route53 registration is actually wanted, or if a renewal ever fails, which would revive the payment question with real evidence behind it.

## Correction - the payment-instrument hypothesis in the issue body is wrong, and so is the AutoRenew alarm Kai checked Billing on 2026-08-28 and reported it clean. Pushing on why the hypothesis was raised at all surfaced that the issue body over-weighted it against evidence already collected. ### The evidence that was in hand and not reconciled `coilyco.ai` registered **successfully** at `15:01:48` for **$274**, the largest of the four charges. The `.com` failures begin at `16:10:46`, roughly one hour later, on the same account and the same payment instrument. AWS does not complete a domain registration without collecting payment, and that registration completed: the registry record exists, Gandi holds it, and it appears in `list-domains` with a 2028 expiry. **The payment theory therefore requires an instrument that clears $274 to decline $16 an hour later.** Nothing supports that, and Kai's Billing check independently contradicts it. ### The reasoning flaw, named so it is not repeated Sub-second rejection establishes that **AWS refused the request internally, before any registry round-trip**. It does not establish **which** internal check fired. Payment verification, fraud and risk scoring, and account eligibility all sit inside that window and all fail fast. The issue body picked one of the three and described it as fitting the timing better. The timing is equally consistent with all three, and the successful $274 charge actively argues against the one chosen. That was inference presented as a ranked diagnosis. ### Revised candidate ordering 1. **AWS-side risk or review hold on domain registration.** The generic message plus a pointer to a `registration-issue` support case is the characteristic shape of an internal risk refusal. A first-time $274 domain purchase an hour earlier is a plausible trigger. **This is now the leading candidate.** 2. **Account eligibility condition on new registrations**, not visible through the API. 3. **Payment instrument.** Demoted to unlikely. Contradicted by the cleared $274 charge and by Kai's Billing check. Still eliminated with evidence, unchanged: registrant email verification, domain count limit, account standing, partial registration, velocity throttle, contact validity, TLD class, and the privacy protection service. ### Retracting the AutoRenew risk The issue body argued that `coilysiren.me` (expiry 2027-07-05, 88 records, the public surface) and `coilyco.ai` (expiry 2028-08-27) were exposed because AutoRenew runs against the same instrument. **That concern was entirely downstream of the payment hypothesis and does not survive it.** Billing is clean and the instrument demonstrably processed $274. Renewals charge that same working instrument. There is no silent-renewal-failure risk here, and no renewal guard is needed on the strength of this issue. Retracting it explicitly rather than leaving it in the body, because an unretracted alarm about losing the production domain would keep drawing attention it does not deserve. ### Recommended disposition **Close as not worth pursuing.** The three names are being registered at Porkbun, so nothing depends on this. The only remaining path is a hand-filed support case (Premium Support is not on this account, so the Support API returns `SubscriptionRequiredException`), and the payoff is an explanation for a path already routed around. Reopen if a future Route53 registration is actually wanted, or if a renewal ever fails, which would revive the payment question with real evidence behind it.
coilyco-ops commented 2026-08-28 06:17:20 +00:00
Author
Owner
Copy link

Reopening the privacy hypothesis - my earlier probe tested the wrong code path

New attempt on 2026-08-28 at 23:16:16, coilysiren.com, privacy on, using the corrected Oakland contact record.

  • Submitted 23:16:16.137, FAILED 23:16:16.969
  • 0.832 seconds, identical generic message, identical shape to all five failures on 2026-08-27
  • Nothing charged, domain still AVAILABLE

Two conclusions from this

The account contact address was not the cause. The AWS account contact was updated from the six-year-old Brooklyn record to the current Oakland address earlier the same session, which was the strongest remaining form of the payment and address-verification theory. Registration still fails identically. That theory is now weak on evidence rather than merely unproven.

My earlier "privacy hypothesis is dead" conclusion was wrong, and I am retracting it.

An earlier comment declared the privacy theory dead because an idempotent update-domain-contact-privacy on coilysiren.me returned SUCCESSFUL. That test was not decisive, and I presented it as though it were.

Updating privacy on an already-registered domain and registering a new domain with the privacy flag set are different code paths. The probe proved Route53 can toggle privacy on an existing registration. It established nothing about whether the privacy service can be provisioned as part of REGISTER_DOMAIN. I collapsed the two and reported a settled result from an unrelated success.

The correlation, now six attempts with perfect separation

  • coilyco.ai - privacy off - SUCCEEDED
  • coilyco.com - privacy on - FAILED
  • coilyco.dev - privacy on - FAILED
  • coilyco.me - privacy on - FAILED
  • coilyco.com retry - privacy on - FAILED
  • coilysiren.com - privacy on - FAILED

Six for six on a single variable, across two registrant names, four TLDs, both gTLD and ccTLD, two different days, and two different contact addresses. Every other variable has now moved at least once while the privacy flag stayed perfectly predictive.

This is the strongest candidate by a wide margin and it should not have been dismissed.

The decisive test, and why it is now cheap

Register coilysiren.com with PrivacyProtect*: false, then immediately call update-domain-contact-privacy to enable it.

When this was first proposed on coilysiren/inbox#475 it was correctly refused, because the target was .ai, where no redaction exists at Route53 and a failed follow-up would strand a permanently public personal record. That risk is much smaller now:

  • .com is a gTLD, so ICANN's registration data policy redacts contact data in RDAP and WHOIS at the registry level by default, independent of the registrar's privacy product
  • the registrant address is now a CMRA in Oakland rather than a residence
  • update-domain-contact-privacy is proven working on this account, which is exactly what the earlier probe did establish, correctly scoped

Residual risk is a brief window before the follow-up call, against a gTLD that redacts by default, carrying a mailbox address.

Status

Awaiting Kai's decision on running the privacy-off registration. Not attempting it unasked, since it is a deliberate choice to register without the privacy flag and the same experiment was explicitly deferred once already.

## Reopening the privacy hypothesis - my earlier probe tested the wrong code path New attempt on 2026-08-28 at `23:16:16`, `coilysiren.com`, privacy on, using the corrected Oakland contact record. * Submitted `23:16:16.137`, FAILED `23:16:16.969` * **0.832 seconds**, identical generic message, identical shape to all five failures on 2026-08-27 * Nothing charged, domain still `AVAILABLE` ### Two conclusions from this **The account contact address was not the cause.** The AWS account contact was updated from the six-year-old Brooklyn record to the current Oakland address earlier the same session, which was the strongest remaining form of the payment and address-verification theory. Registration still fails identically. That theory is now weak on evidence rather than merely unproven. **My earlier "privacy hypothesis is dead" conclusion was wrong, and I am retracting it.** An earlier comment declared the privacy theory dead because an idempotent `update-domain-contact-privacy` on `coilysiren.me` returned `SUCCESSFUL`. That test was not decisive, and I presented it as though it were. **Updating privacy on an already-registered domain and registering a new domain with the privacy flag set are different code paths.** The probe proved Route53 can toggle privacy on an existing registration. It established nothing about whether the privacy service can be provisioned as part of `REGISTER_DOMAIN`. I collapsed the two and reported a settled result from an unrelated success. ### The correlation, now six attempts with perfect separation * `coilyco.ai` - privacy **off** - **SUCCEEDED** * `coilyco.com` - privacy **on** - FAILED * `coilyco.dev` - privacy **on** - FAILED * `coilyco.me` - privacy **on** - FAILED * `coilyco.com` retry - privacy **on** - FAILED * `coilysiren.com` - privacy **on** - FAILED Six for six on a single variable, across two registrant names, four TLDs, both gTLD and ccTLD, two different days, and two different contact addresses. Every other variable has now moved at least once while the privacy flag stayed perfectly predictive. This is the strongest candidate by a wide margin and it should not have been dismissed. ### The decisive test, and why it is now cheap Register `coilysiren.com` with `PrivacyProtect*: false`, then immediately call `update-domain-contact-privacy` to enable it. When this was first proposed on `coilysiren/inbox#475` it was correctly refused, because the target was `.ai`, where no redaction exists at Route53 and a failed follow-up would strand a permanently public personal record. **That risk is much smaller now:** * `.com` is a gTLD, so ICANN's registration data policy redacts contact data in RDAP and WHOIS at the registry level by default, independent of the registrar's privacy product * the registrant address is now a CMRA in Oakland rather than a residence * `update-domain-contact-privacy` is **proven working on this account**, which is exactly what the earlier probe did establish, correctly scoped Residual risk is a brief window before the follow-up call, against a gTLD that redacts by default, carrying a mailbox address. ### Status Awaiting Kai's decision on running the privacy-off registration. Not attempting it unasked, since it is a deliberate choice to register without the privacy flag and the same experiment was explicitly deferred once already.
coilyco-ops commented 2026-08-28 06:25:38 +00:00
Author
Owner
Copy link

Privacy hypothesis killed on the correct code path. I was wrong to revive it.

coilysiren.com, privacy off, Oakland contact, 2026-08-28:

  • Submitted 23:24:21.433, FAILED 23:24:22.364. 0.931 seconds.
  • Identical generic message
  • Nothing charged, nothing half-landed, domain still AVAILABLE

The previous comment argued the privacy flag was six-for-six predictive and called it the strongest candidate by a wide margin. It registered with the flag off and still failed. The correlation was coincidence produced by ordering, exactly as the first probe suggested before I talked myself out of it.

I have now been wrong twice on this issue: first the payment instrument, then the privacy flag, each time promoting a correlation to a diagnosis on timing evidence that could not distinguish between candidates. Recording that plainly because the pattern matters more than either wrong answer.

What seven attempts actually establish

One success, six failures, on this account:

  • coilyco.ai - 2026-08-27 15:01 - SUCCEEDED
  • coilyco.com, coilyco.dev, coilyco.me, coilyco.com retry - 2026-08-27 16:10 to 16:20 - FAILED, two-year durations
  • coilysiren.com privacy on - 2026-08-28 23:16 - FAILED, one-year duration
  • coilysiren.com privacy off - 2026-08-28 23:24 - FAILED, one-year duration

Eliminated with direct evidence: registrant email verification, domain count limit, account standing, partial registration, velocity throttle, contact validity, TLD class (gTLD and ccTLD both fail), payment instrument (Kai confirmed billing clean, and a $274 charge cleared an hour before the first failure), contact address (failures both before and after the Brooklyn to Oakland correction), privacy flag (failures with it both on and off), and registration duration (failures at both one and two years).

Every failure is sub-second, 0.75 to 0.95 seconds, well before any registry round-trip. Nothing ever half-lands. Every attempted domain remains available.

What is left

The only surviving pattern is that the single success was .ai and every failure was .com, .dev, or .me. That is one data point against six and is not a diagnosis.

I have no further cheap test. Every variable reachable through the API has been moved. AWS returns a deliberately generic message and points at a support case, and the Support API is unavailable on this account (DescribeSeverityLevels returns SubscriptionRequiredException), so the case must be filed by hand in the web console.

Status

REGISTER_DOMAIN is effectively non-functional on this account for .com, .dev, and .me, cause unknown, not diagnosable from the API surface. Keeping this issue open as the record. An external registrar is the working path for any domain Kai actually wants.

## Privacy hypothesis killed on the correct code path. I was wrong to revive it. `coilysiren.com`, privacy **off**, Oakland contact, 2026-08-28: * Submitted `23:24:21.433`, FAILED `23:24:22.364`. **0.931 seconds.** * Identical generic message * Nothing charged, nothing half-landed, domain still `AVAILABLE` The previous comment argued the privacy flag was six-for-six predictive and called it the strongest candidate by a wide margin. **It registered with the flag off and still failed.** The correlation was coincidence produced by ordering, exactly as the first probe suggested before I talked myself out of it. I have now been wrong twice on this issue: first the payment instrument, then the privacy flag, each time promoting a correlation to a diagnosis on timing evidence that could not distinguish between candidates. Recording that plainly because the pattern matters more than either wrong answer. ### What seven attempts actually establish One success, six failures, on this account: * `coilyco.ai` - 2026-08-27 15:01 - **SUCCEEDED** * `coilyco.com`, `coilyco.dev`, `coilyco.me`, `coilyco.com` retry - 2026-08-27 16:10 to 16:20 - FAILED, two-year durations * `coilysiren.com` privacy on - 2026-08-28 23:16 - FAILED, one-year duration * `coilysiren.com` privacy off - 2026-08-28 23:24 - FAILED, one-year duration **Eliminated with direct evidence:** registrant email verification, domain count limit, account standing, partial registration, velocity throttle, contact validity, TLD class (gTLD and ccTLD both fail), payment instrument (Kai confirmed billing clean, and a $274 charge cleared an hour before the first failure), contact address (failures both before and after the Brooklyn to Oakland correction), **privacy flag** (failures with it both on and off), and **registration duration** (failures at both one and two years). **Every failure is sub-second**, 0.75 to 0.95 seconds, well before any registry round-trip. **Nothing ever half-lands.** Every attempted domain remains available. ### What is left The only surviving pattern is that the single success was `.ai` and every failure was `.com`, `.dev`, or `.me`. That is one data point against six and is not a diagnosis. **I have no further cheap test.** Every variable reachable through the API has been moved. AWS returns a deliberately generic message and points at a support case, and the Support API is unavailable on this account (`DescribeSeverityLevels` returns `SubscriptionRequiredException`), so the case must be filed by hand in the web console. ### Status `REGISTER_DOMAIN` is effectively non-functional on this account for `.com`, `.dev`, and `.me`, cause unknown, not diagnosable from the API surface. Keeping this issue open as the record. An external registrar is the working path for any domain Kai actually wants.
coilyco-ops commented 2026-08-28 06:33:22 +00:00
Author
Owner
Copy link

Console fails too, .ai now fails too, and the shape is temporal

Kai attempted registration through the Route 53 console on 2026-08-27 at 23:30 Pacific. Three operations landed in the log and all failed:

  • 5fab008f-05b9-43e9-b4d1-202a653a5d19 - coilysiren.ai - FAILED
  • 29bbc549-0943-4c14-8e03-24f2991a628f - coilysiren.com - FAILED
  • ccf22e49-27a5-43d5-ac5f-491e56868d60 - coilysiren.dev - FAILED

Two findings.

The console fails identically to the CLI. That eliminates every client-side explanation at once: request shape, SDK version, contact struct serialization, CLI flag handling. Two independent code paths, same refusal.

.ai now fails. It was the only TLD with a success on this account and the last surviving pattern in the previous comment. It is gone. coilysiren.ai was refused exactly like the gTLDs.

The actual shape: temporal, not categorical

Eleven REGISTER_DOMAIN operations, one success, and the success is the first one:

  • 93696e2f-3ec0-4a89-93a3-9fb655a12ca9 - coilyco.ai - submitted 15:01:48, completed 15:12:47 - the only success
  • Ten failures from 16:10:46 onward, spanning .com, .dev, .me, and .ai, across two days, two clients, both privacy states, both durations, and two contact addresses

Every attempt after 15:12:47 has failed. Nothing has succeeded since. The categorical hypotheses were all chasing structure inside the failure set when the real discriminator is that a gate went up on this account between 15:12:47 and 16:10:46 Pacific on 2026-08-27, a 58-minute window.

That is the question for AWS, and it is answerable only by them.

Support case, ready to file

Premium Support is not on this account, confirmed again: support describe-severity-levels returns SubscriptionRequiredException. Account and billing cases are still filable through the console on Basic support, which is where the error message's own link points.

Link: https://console.aws.amazon.com/support/home?region=us-east-1#/case/create?issueType=customer-service&serviceCode=service-domains&categoryCode=registration-issue

Subject: Route 53 REGISTER_DOMAIN fails for every domain since 2026-08-27, sub-second generic error

Body:

Account: 226734851276
Service: Route 53 domain registration
Region: us-east-1

SUMMARY
Every REGISTER_DOMAIN operation on this account has failed since
2026-08-27 16:10 Pacific. One registration succeeded 58 minutes
earlier. All 10 attempts since have failed with the same generic
message in under one second, before any registry round-trip.

LAST SUCCESSFUL REGISTRATION
93696e2f-3ec0-4a89-93a3-9fb655a12ca9  coilyco.ai
  submitted 2026-08-27 15:01:48 PT, completed 15:12:47 PT

ALL SUBSEQUENT ATTEMPTS, ALL FAILED
6975be1b-eaad-46b5-ac8f-f47241b46a81  coilyco.com     16:10:46 PT
e7f9ac15-cf7e-48df-b97c-2c0050620ae6  coilyco.dev     16:10:47 PT
bebcbb66-64a4-4d69-aaf0-fb2e714f0652  coilyco.me      16:10:48 PT
7ad7009d-0290-4518-939d-94c46eed541a  coilyco.com     16:11:48 PT
d0e30a25-b6f6-4e08-b1c4-7ab0bf4c6176  coilyco.com     16:20:41 PT
06911854-4a52-4b75-b2a8-11a12e3fb4fe  coilysiren.com  23:16:16 PT
ae8499fa-8375-4249-a85e-b658e6c8f19e  coilysiren.com  23:24:21 PT
5fab008f-05b9-43e9-b4d1-202a653a5d19  coilysiren.ai   23:30:55 PT
29bbc549-0943-4c14-8e03-24f2991a628f  coilysiren.com  23:30:56 PT
ccf22e49-27a5-43d5-ac5f-491e56868d60  coilysiren.dev  23:30:57 PT

Each returns: "We can't finish registering your domain. Contact AWS
Support at [...] for further information."

OBSERVED PATTERN
- Every failure completes in 0.75 to 0.95 seconds
- No domain is ever partially registered; all remain AVAILABLE
- No charge appears for any failed attempt
- Fails identically from the AWS CLI and from the Route 53 console

VARIABLES TESTED AND ELIMINATED
- TLD: .com, .dev, .me, .ai all fail. .ai succeeded once and now fails.
- Privacy protection: fails with PrivacyProtect* both true and false
- Duration: fails at both 1 year and 2 years
- Registrant contact: fails with two different contact records
- Payment: billing verified current. The $274 charge for coilyco.ai
  cleared 58 minutes before the first failure.
- GetContactReachabilityStatus: DONE
- Domain count: 2 registered, default limit 20
- Account status: ACTIVE
- Client: CLI and console both fail

REQUEST
Please identify what account-level condition was applied to account
226734851276 between 2026-08-27 15:12:47 PT and 16:10:46 PT that
causes REGISTER_DOMAIN to be refused, and what is required to clear
it. The generic error text gives no actionable detail and the
condition is not visible through any API surface available to me.

Status

Blocked on AWS. Every API-reachable variable has been eliminated. Domains remain available and unregistered.

## Console fails too, `.ai` now fails too, and the shape is temporal Kai attempted registration through the Route 53 console on 2026-08-27 at 23:30 Pacific. Three operations landed in the log and all failed: * `5fab008f-05b9-43e9-b4d1-202a653a5d19` - `coilysiren.ai` - FAILED * `29bbc549-0943-4c14-8e03-24f2991a628f` - `coilysiren.com` - FAILED * `ccf22e49-27a5-43d5-ac5f-491e56868d60` - `coilysiren.dev` - FAILED **Two findings.** **The console fails identically to the CLI.** That eliminates every client-side explanation at once: request shape, SDK version, contact struct serialization, CLI flag handling. Two independent code paths, same refusal. **`.ai` now fails.** It was the only TLD with a success on this account and the last surviving pattern in the previous comment. It is gone. `coilysiren.ai` was refused exactly like the gTLDs. ### The actual shape: temporal, not categorical Eleven `REGISTER_DOMAIN` operations, one success, and the success is the **first** one: * `93696e2f-3ec0-4a89-93a3-9fb655a12ca9` - `coilyco.ai` - submitted 15:01:48, **completed 15:12:47** - the only success * Ten failures from 16:10:46 onward, spanning `.com`, `.dev`, `.me`, and `.ai`, across two days, two clients, both privacy states, both durations, and two contact addresses **Every attempt after 15:12:47 has failed. Nothing has succeeded since.** The categorical hypotheses were all chasing structure inside the failure set when the real discriminator is that a gate went up on this account between `15:12:47` and `16:10:46` Pacific on 2026-08-27, a 58-minute window. That is the question for AWS, and it is answerable only by them. ### Support case, ready to file Premium Support is not on this account, confirmed again: `support describe-severity-levels` returns `SubscriptionRequiredException`. Account and billing cases are still filable through the console on Basic support, which is where the error message's own link points. **Link:** `https://console.aws.amazon.com/support/home?region=us-east-1#/case/create?issueType=customer-service&serviceCode=service-domains&categoryCode=registration-issue` **Subject:** Route 53 REGISTER_DOMAIN fails for every domain since 2026-08-27, sub-second generic error **Body:** ``` Account: 226734851276 Service: Route 53 domain registration Region: us-east-1 SUMMARY Every REGISTER_DOMAIN operation on this account has failed since 2026-08-27 16:10 Pacific. One registration succeeded 58 minutes earlier. All 10 attempts since have failed with the same generic message in under one second, before any registry round-trip. LAST SUCCESSFUL REGISTRATION 93696e2f-3ec0-4a89-93a3-9fb655a12ca9 coilyco.ai submitted 2026-08-27 15:01:48 PT, completed 15:12:47 PT ALL SUBSEQUENT ATTEMPTS, ALL FAILED 6975be1b-eaad-46b5-ac8f-f47241b46a81 coilyco.com 16:10:46 PT e7f9ac15-cf7e-48df-b97c-2c0050620ae6 coilyco.dev 16:10:47 PT bebcbb66-64a4-4d69-aaf0-fb2e714f0652 coilyco.me 16:10:48 PT 7ad7009d-0290-4518-939d-94c46eed541a coilyco.com 16:11:48 PT d0e30a25-b6f6-4e08-b1c4-7ab0bf4c6176 coilyco.com 16:20:41 PT 06911854-4a52-4b75-b2a8-11a12e3fb4fe coilysiren.com 23:16:16 PT ae8499fa-8375-4249-a85e-b658e6c8f19e coilysiren.com 23:24:21 PT 5fab008f-05b9-43e9-b4d1-202a653a5d19 coilysiren.ai 23:30:55 PT 29bbc549-0943-4c14-8e03-24f2991a628f coilysiren.com 23:30:56 PT ccf22e49-27a5-43d5-ac5f-491e56868d60 coilysiren.dev 23:30:57 PT Each returns: "We can't finish registering your domain. Contact AWS Support at [...] for further information." OBSERVED PATTERN - Every failure completes in 0.75 to 0.95 seconds - No domain is ever partially registered; all remain AVAILABLE - No charge appears for any failed attempt - Fails identically from the AWS CLI and from the Route 53 console VARIABLES TESTED AND ELIMINATED - TLD: .com, .dev, .me, .ai all fail. .ai succeeded once and now fails. - Privacy protection: fails with PrivacyProtect* both true and false - Duration: fails at both 1 year and 2 years - Registrant contact: fails with two different contact records - Payment: billing verified current. The $274 charge for coilyco.ai cleared 58 minutes before the first failure. - GetContactReachabilityStatus: DONE - Domain count: 2 registered, default limit 20 - Account status: ACTIVE - Client: CLI and console both fail REQUEST Please identify what account-level condition was applied to account 226734851276 between 2026-08-27 15:12:47 PT and 16:10:46 PT that causes REGISTER_DOMAIN to be refused, and what is required to clear it. The generic error text gives no actionable detail and the condition is not visible through any API surface available to me. ``` ### Status Blocked on AWS. Every API-reachable variable has been eliminated. Domains remain available and unregistered.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
aos/claude/uv47-state-ambient-taxonomy
eval/ansible-slug-tidy
eval/label-advocate
aos/claude/mt75-kubectl-context-callsites
eval/slug-pass-labels
aos/claude/mt75-coredns-hairpin
eval/label-devrel-relations
eval/label-platform-engineer
eval/label-descriptions-retitle
eval/label-descriptions-roster
aos/claude/wz68-mirror-push
aos/claude/wz68-mirror-watch
aos/claude/wz68-bot-identity
aos/claude/wz68-bot-handle
aos/claude/wz68
aos/claude/ff54-retire-coilyco-ai-hook
aos/claude/ff54-retire-issue-refs
aos/claude/ue86
aos/claude/yq86
aos/claude/ser8-image-build-929
ops/zombie-retire-secret-strays
ops/917-alert-unit-name
ops/917-restic-failure-alert
ops/914-drop-comfyui-cname
ops/914-drop-stale-dns-instruction
ops/retire-coilysiren-me-mail
ops/911-dns-mail-auth
aos/claude/fj88
ops/393-aos-pin-rollout
ops/708-o11y-telegram-per-host-cache
chore/claude-permissions-allow-all
fix/comfyui-preflight-whatif
fix/comfyui-supervisor-job-object
fix/forgejo-creds-windows-ssm
fix/comfyui-orphan-on-refused-restart
fix/windows-projects-root
fix/comfyui-restart-race
windows-tasks-s4u
windows-attribution-bash-shim-python
fix/comfyui-whatif-verification
windows-terminal-kai-tower-3026
fix/setup-git-lfs-windows-path
chore/drop-ward-yaml
fix/terraform-docs-action-arg
fix/mint-key-orphan
feat/public-asset-host
aos/claude/ka54-failclosed
aos/claude/ka54-cleanup
aos/claude/ka54
aos/claude/uq98-unattended-forgejo
aos/claude/uq98-disk-domains
aos/claude/xk58
aos/claude/aw85-bands
aos/claude/ym96-docs-band
aos/claude/wt57-alerts-to-mapper
aos/claude/xu59-role-trailer
aos/claude/ym96-verb-convert
aos/claude/ym96-token-cleanup
aos/claude/ym96-label-sync
aos/claude/wt57-atlas-cleanup
fix/mirror-unskip-sirens-echo
aos/claude/uz86-session-name
retire-code-fleet-watch-830
codex/alacritty-link-rollout
chore/mcp-beaver-fleet-watch
aos/claude/attribution-interpreter
aos/claude/mg96-fm
aos/claude/js44
coilyco-ops/deprovision-tangled-knot
aos/claude/mg96
aos/claude/zv96
outdated-branch-815
aos/claude/agent-proxy-publisher-runner
aos/claude/git-attribution-pin-interpreter
aos/claude/restore-tag-quarantine
aos/claude/mirror-workflows-permission
aos/claude/forgejo-16
aos/claude/dind-mtu
aos/claude/precommit-egress-proxy
aos/claude/qa57-branch-protection
chore/egress-proxy-open
chore/egress-allow-code-forgejo
aos/claude/qa57
chore/aos-precommit-v0.18-bump
aos/claude/ck67
infra/claude/ser8-runner-force-pull
aos/claude/runner-scratch-10gi
aos/claude/runner-recycle-selector
aos/claude/xk86
aos/codex/20260806t002312z-7943-00371332
codex/sirens-echo-deepseek-tailnet-20260805
codex/daily-aos-sync
issue-756-remove-role-provider-symlink
aos/codex/sirens-echo-runner-rename
aos/codex/20260731t171534z-9817-e7959fba
issue-697-aos-check-config
issue-694-aos-convergence
ops/remove-mac-models-launchd-20260729
ops/remove-mac-models-20260729
tailscale-proxy-converge-self-heal
issue-587
backup/issue-785-first-person
issue-785-first-person
ops/galaxy-gen-registry-rotate
ops/website-deploy-runner
codex/history-derived-skill-20260728
ops/k3s-pod-capacity-config
ops/publisher-runners
codex/code-fleet-watch-v2
codex/code-fleet-watch
recovery/2026-07-28-triaged-branch-archive
recovery/2026-07-27-local-work
recovery/machine-exit-20260727
issue-653-registry-retirement
issue-593
fix/aws-iam-ssm-import
feat/warded-ssm-identity
issue-500
No results found.
Labels
Clear labels   
burndown-2026-06
Backlog burndown June 2026

  
burndown-2026-08
Closed in the 2026-08-26 backlog burn-down. Reopen freely: state:closed label:burndown-2026-08 recovers the whole set.

  
autonomy
async-consult
 A human needs to consult on the issue to upgrade it to headless

  
autonomy
epic
 This issue has many units of sub work - its size makes it meaningfully exclusive with other autonomy types

  
autonomy
headless
 The agent can perform the work on its own

  
autonomy
live-collab
 The agent and the human need to work together in realtime

  
coherence-core
Core review set for the warded control plane coherence milestone. These issues form the release spine; adjacent milestone issues are stretch or supporting work.

  
priority
P0
 priority tier

  
priority
P1
 priority tier

  
priority
P2
 priority tier

  
priority
P3
 priority tier

  
priority
P4
 priority tier

  
qa-fixture
Disposable issue admitted to the bounded Ward QA verification lane.

  
role/advocate
requires work from the Developer Advocate seat

  
role/director
requires work from the Portfolio Director seat

  
role/exec
requires work from the exec role

  
role/frontend
requires work from the Frontend Engineer seat

  
role/gamedev
requires work from the Game Developer seat

  
role/human
requires a person, and specifically not an agent seat

  
role/platform
requires work from the Platform Engineer seat

  
role/qa
requires work from the QA role

  
role/science
requires work from the Applied Scientist seat

  
role/sysadmin
requires work from the Systems Administrator seat

  
state
ambient
 ambient and ephemeral work, held as a maintained document rather than a queue

No labels
burndown-2026-06
burndown-2026-08
autonomy
async-consult
autonomy
epic
autonomy
headless
autonomy
live-collab
coherence-core
priority
P0
priority
P1
priority
P2
priority
P3
priority
P4
qa-fixture
role/advocate
role/director
role/exec
role/frontend
role/gamedev
role/human
role/platform
role/qa
role/science
role/sysadmin
state
ambient
Milestone
Clear milestone
No items
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-flight-deck/infrastructure#971
No description provided.