> ## Documentation Index
> Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Limits and troubleshooting

> The bounds the API enforces, and what to check when a name is not resolving the way you expect.

## Limits and behaviour

<ResponseField name="zone file import" type="1 MiB">
  Larger files are refused.
</ResponseField>

<ResponseField name="records per zone" type="quota-enforced">
  Checked on both single-record creation and import, against your
  organization's quota.
</ResponseField>

<ResponseField name="ttl" type="60–604800 seconds, default 3600">
  Omit it, or send `0`, to get the default of one hour. Any other value below
  the 60-second minimum is refused — `0` is a sentinel meaning "use the
  default", not the bottom of the range, so `30` is an error where `0` is not.

  On update that sentinel does not apply: `0` is refused there, because a PATCH
  that sends it is asking for a TTL of zero rather than declining to choose.

  The maximum is 604800 (7 days).
</ResponseField>

<ResponseField name="deleting a zone" type="202, runs in the background">
  Deletes every record it owns, plus the zone's DNSSEC key material and the DS
  at its parent — the zone row goes last, so nothing is ever left half-removed.

  The call answers `202`, not `204`: the teardown is **accepted**, not
  finished, and the zone still exists when it returns. Poll
  `GET /v1/zones/{zone_id}` until it `404`s. That matters if you mean to
  re-create the same name — until the teardown completes, creating it again
  answers `409`.
</ResponseField>

## Troubleshooting

<AccordionGroup>
  <Accordion title="The zone does not resolve at all" icon="circle-x">
    Check `ownership.verified`. A zone with no zone above it on the platform
    does not answer until ownership is proved — creating it is not claiming
    it. Set the zone's own `nameservers` at your registrar and call
    `verify-ownership`; see [proving ownership](/dns/ownership).
  </Accordion>

  <Accordion title="I set the nameservers but verify still fails" icon="circle-x">
    Two things do this.

    **You used Basaltic's bare nameserver names** rather than the ones your
    zone lists. Only the labelled names verify a zone — compare what is at your
    registrar against the `nameservers` array character for character.

    **The domain is delegated to two Basaltic zones at once.** While that is
    true neither one is served, and the verify message says so. Remove the
    nameservers your zone does not list. Expect this midway through moving a
    domain between accounts.
  </Accordion>

  <Accordion title="Re-creating a zone I just deleted returns 409" icon="clock">
    The delete is still running. `DELETE` answers `202` and the teardown
    finishes in the background, dropping the zone row last — so for a few
    seconds the name is still taken. Poll `GET /v1/zones/{zone_id}` until it
    `404`s, then create.
  </Accordion>

  <Accordion title="A name resolves for some people and SERVFAILs for others" icon="triangle-alert">
    That pattern — works for non-validating resolvers, fails for validating
    ones — is the signature of a CNAME sharing a name with another record. The
    API refuses new ones, but a zone imported or migrated in unusual ways is
    worth checking. List the records at that name and make sure the CNAME is
    alone.
  </Accordion>

  <Accordion title="DNSSEC validation fails everywhere" icon="shield-x">
    Almost always a missing or stale DS record at the registrar. Compare what
    the registrar publishes against `dnssec.ds_records` on the zone — a DS
    left over from a previous provider breaks validation exactly as
    thoroughly as none at all.
  </Accordion>

  <Accordion title="An import did not remove the records I deleted" icon="git-merge">
    Working as intended — import merges and never deletes. An RRset absent
    from the file is left alone. Delete records explicitly through the record
    endpoints.
  </Accordion>
</AccordionGroup>