Publish DNS-AID (_agents.aspire.dev) SVCB/HTTPS records + DNSSEC

Nobody has claimed this yet.

# Publish DNS-AID (`_agents.aspire.dev`) SVCB/HTTPS records + DNSSEC

The [`isitagentready.com`](https://isitagentready.com) scanner currently reports `checks.discoverability.dnsAid.status = "fail"` for `aspire.dev` because no DNS for AI Discovery (DNS-AID) records are published in our zone. This issue tracks the DNS-operator work needed to flip that to `"pass"`.

## What needs to happen (DNS zone change, not a code change)

This is **out of scope for the `aspire.dev` source tree** — the repo contains no zone files or DNS IaC. Whoever administers DNS for `aspire.dev` (Azure DNS in the dnceng tenant, per current understanding) needs to:

1. Publish [SVCB / HTTPS service-binding records](https://www.rfc-editor.org/rfc/rfc9460) under the `_agents.aspire.dev` namespace following the [DNS-AID draft](https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/).
2. Sign the public discovery zone with DNSSEC so validating resolvers return authenticated answers.

### Draft record set

The DNS operator should finalize the targets, `alpn` values, ports, and any DNS-AID-specific experimental `keyNNNNN` SvcParamKeys (the draft is not yet RFC, so registered keys are not assigned). Starting point:

```dns
; Top-level discovery anchor for aspire.dev (HTTPS web endpoint)
_index._agents.aspire.dev. 3600 IN HTTPS 1 aspire.dev. alpn="h2,http/1.1" port=443

; Add per-protocol records once aspire.dev publishes an A2A or agent endpoint, e.g.:
; _a2a._agents.aspire.dev. 3600 IN SVCB 1 agent.aspire.dev. alpn="a2a" port=443 mandatory=alpn,port
```

> Per the DNS-AID skill: *Use numeric `keyNNNNN` SvcParamKey names for experimental DNS-AID custom parameters until they are registered.*

### DNSSEC

Enable DNSSEC on the `aspire.dev` zone (or the subordinate zone that owns `_agents.aspire.dev`) so DNS-AID consumers can rely on authenticated data. In Azure DNS this is the [`dnssec-config`](https://learn.microsoft.com/azure/dns/dnssec-how-to) feature.

## Validation

After the records are live and the zone is signed:

```http
POST https://isitagentready.com/api/scan
Content-Type: application/json

{"url": "https://aspire.dev"}
```

Expect `checks.discoverability.dnsAid.status == "pass"`.

Spot-check from any host:

```bash
dig +dnssec HTTPS _index._agents.aspire.dev
```

## Why not just fix this in the repo?

`aspire.dev` deploys via `AddAzureFrontDoor(...)` in `src/apphost/Aspire.Dev.AppHost/AppHost.cs`, but the repo holds no Bicep / Terraform / zone files for the public DNS zone — only the Front Door wiring. DNS-AID records and DNSSEC have to be applied by whoever owns the authoritative zone.

## Related: API Catalog (RFC 9727) — intentionally NOT shipping

The same scanner also flags `checks.discovery.apiCatalog.status` as fail. We **deliberately** opted out of publishing `/.well-known/api-catalog` in [#807](https://github.com/microsoft/aspire.dev/pull/807) — see the pinned assertion in `tests/StaticHost.Tests/LinkHeaderTests.cs`:

```csharp
// Confirm we are NOT advertising api-catalog (out of scope per RFC 9727).
Assert.DoesNotContain("api-catalog", link);
```

RFC 9727 is "for HTTPS servers that publish APIs." `aspire.dev` is a documentation site whose only HTTP endpoints are `/healthz` and the install-script redirects (`/install.ps1`, `/install.sh`). The scanner-vs-RFC mismatch is on the scanner, not on us — no action wanted here.

## References

- [DNS-AID draft (`draft-mozleywilliams-dnsop-dnsaid`)](https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/)
- [RFC 9460 — SVCB / HTTPS records](https://www.rfc-editor.org/rfc/rfc9460)
- [`isitagentready.com` DNS-AID skill](https://isitagentready.com/.well-known/agent-skills/dns-aid/SKILL.md)
- [Azure DNS DNSSEC how-to](https://learn.microsoft.com/azure/dns/dnssec-how-to)

Confirm who administers the authoritative aspire.dev zone and review the Azure DNS DNSSEC configuration and DNS-AID draft requirements. Publish the finalized records and validate with `dig +dnssec HTTPS _index._agents.aspire.dev`, then POST the scan request and confirm `checks.discoverability.dnsAid.status` is `pass`.

Written by the indexing model from the issue text.