run_af11e4cc574a74a3

input

{
  "request": "Triage Jira ticket SREIN-1685: Re-add api.commonvoice.allizom.org DNS record and decide what to do about original security report",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/SREIN-1685"
  ],
  "sourceContext": {
    "issue": "SREIN-1685"
  }
}

summary

SREIN-1685 (status: Backlog) asks the team to (1) restore the DNS record for api.commonvoice.allizom.org, which was removed and has broken the managed TLS certificate provisioning for the common-voice stage chart and several stage routes (/auth, /text, /audio), and (2) decide how to handle the underlying issue from an earlier security report — a 404 response from the root "/" route of the commonvoice api subdomain — which is now confirmed to also affect the Sandbox and Prod environments, not just Stage where it was previously "fixed." A prior comment from Graham Beckley notes that someone assessed the 404 behavior as low risk, suggesting the security concern itself may not need remediation, only the DNS re-add is clearly actionable.

findings

• none

proposed actions

Triage notes:

1) DNS re-add (actionable, low risk): Restoring the api.commonvoice.allizom.org DNS record should resolve the FailedNotVisible cert domain status and unblock cert provisioning + the /auth, /text, /audio routes in stage. Recommend prioritizing this as a quick, low-risk fix.

2) Root '/' 404 security question (needs a decision, not just a fix): The same 404-on-root-route behavior that was previously reported and 'fixed' for Stage is confirmed present in both Sandbox and Prod (load-balancer-level 404 on '/', while /auth and /text return 200 and /audio 404s at the application layer). Given the earlier assessment that this issue 'doesn't pose high risk on the app,' we should explicitly confirm that assessment still holds for Sandbox/Prod (same reasoning may not automatically transfer across environments) and then either: (a) formally close the security concern as accepted/low-risk with a documented rationale, or (b) apply the same stage fix to Sandbox/Prod for consistency, even if not strictly required for security reasons (e.g., for uniform behavior/monitoring hygiene).

3) Housekeeping: The ticket description links to the original DNS-removal ticket and the prior stage security-remediation ticket, but those links didn't render in this view — please confirm/attach those ticket keys here so the risk decision is traceable and can be closed with proper justification.

Suggest splitting into: (a) immediate DNS restoration sub-task, and (b) a decision/record entry on the security report disposition for Sandbox/Prod, referencing the prior risk assessment.

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "SREIN-1685"
    },
    "result": {
      "key": "SREIN-1685",
      "summary": "Re-add api.commonvoice.allizom.org DNS record and decide what to do about original security report",
      "status": "Backlog",
      "description_text": "In    , we removed a DNS record for  api.commonvoice.allizom.org . This has broken a few things:   -  the managed certificate in the common-voice stage chart status:\n  certificateName: mcrt-3ff9acaa-7600-4ba3-b40f-b87dc988699d\n  certificateStatus: Provisioning\n  domainStatus:\n    - domain: api.commonvoice.allizom.org\n      status: FailedNotVisible\n    - domain: commonvoice.allizom.org\n      status: Active\n    - domain: stage.common-voice.nonprod.webservices.mozgcp.net\n      status: Active\n    - domain: voice.allizom.org\n      status: Active (probably related to    ) - routes under that subdomain \u2013  /auth ,  /text ,  /audio  all aren\u2019t reachable Further, though we addressed the security report for the stage environment specifically in   , the same problem exists today Common Voice\u2019s Sandbox and Prod environment. Sandbox https://api.sandbox.commonvoice.allizom.org/ -> 404 (from load balancer)\nhttps://api.sandbox.commonvoice.allizom.org/auth -> 200\nhttps://api.sandbox.commonvoice.allizom.org/text -> 200\nhttps://api.sandbox.commonvoice.allizom.org/audio -> 404 (from application) Prod https://api.commonvoice.mozilla.org/ -> 404 (from load balancer)\nhttps://api.commonvoice.mozilla.org/auth -> 200\nhttps://api.commonvoice.mozilla.org/text -> 200\nhttps://api.commonvoice.mozilla.org/audio -> 404 (from application)  For this ticket, we should put the  api.commonvoice.allizom.org  DNS record back and decide how to address the 404 from the root  /  route of this common voice  api.  subdomain.",
      "comment_count": 1,
      "comments": [
        {
          "author": "Graham Beckley",
          "body": "Of note,    said in   , \u201cI don\u2019t think the issue poses high risk on the app\u201d, so maybe there\u2019s nothing to fix here as far as the 404 is concerned."
        }
      ]
    }
  }
]

log