> ## 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.

# Registros

> RRsets, el ápice, y los registros que la plataforma administra para usted.

<a id="records" />

## Registros

Un registro es un **RRset**: un nombre, un tipo y un array de `values`. Al actualizar un registro, se reemplaza toda la lista de valores.

<Tabs>
  <Tab title="Console">
    Abre la zona desde **DNS** y elige **Add Record**. Introduce un **Name** — un subdominio como `www`, o `@` para el ápice — elige un **Type** y añade una entrada por línea en **Values**. Esa lista es el RRset. **TTL** es opcional.
  </Tab>

  <Tab title="API">
    ```bash theme={null}
    POST /v1/zones/{zone_id}/records
    {
      "name": "www.example.com",
      "type": "A",
      "ttl": 300,
      "values": [
        { "content": "203.0.113.10" },
        { "content": "203.0.113.11" }
      ]
    }
    ```
  </Tab>

  <Tab title="CLI">
    ```bash theme={null}
    basaltic dns record create <zone-id> \
      --name www.example.com --type A --ttl 300 \
      --values '[{"content":"203.0.113.10"},{"content":"203.0.113.11"}]'
    ```

    `--values` recibe el array JSON sin cambios, por lo que el RRset usa el mismo formato que se envía por la red.
  </Tab>

  <Tab title="Go">
    ```go theme={null}
    rec, err := dns.New(cfg).CreateRecord(ctx, zoneID, &dns.RecordCreateRequest{
        Name: "www.example.com",
        Type: "A",
        TTL:  basaltic.Int(300),
        Values: []*dns.RecordValue{
            {Content: "203.0.113.10"},
            {Content: "203.0.113.11"},
        },
    })
    ```
  </Tab>
</Tabs>

<Note>
  No se puede preparar un valor sin publicarlo. Se rechaza `disabled: true` porque no hay dónde almacenar un valor que no se vaya a servir. Antes, el valor se aceptaba y después se descartaba, indicando éxito aunque se perdiera. Para quitar una dirección de un RRset, elimínala de `values`.
</Note>

<Warning>
  **Un CNAME no puede compartir un nombre con otro registro ni estar en el ápice de la zona.** La API rechaza ambos casos para evitar fallos silenciosos de resolución.

  El firmante rellena el NSEC de cada nombre con un mapa de bits de los tipos de registro presentes. Un CNAME junto a un A produce un mapa de bits que indica "CNAME y A". Un resolvedor que valida DNSSEC considera ese nombre inválido y responde SERVFAIL. La zona se carga y los registros parecen correctos en la API, pero el nombre deja de resolverse para quienes validan DNSSEC. Esto sigue la RFC 1034 §3.6.2 y la RFC 2181 §10.1.

  En el ápice el conflicto es inevitable — los conjuntos SOA y NS siempre están allí — así que apunta el ápice a direcciones con registros `A`/`AAAA`.
</Warning>

<a id="pointing-a-zone-apex-at-something" />

## Apuntar el ápice de una zona a un destino

No existe el tipo de registro `ALIAS` ni el aplanamiento de CNAME. El ápice recibe direcciones IP, por lo que debes usar una dirección estable.

En Basaltic, esa dirección ya es estable. Un balanceador de carga se alcanza a través de una [IP flotante](/es/networking/gateways) que asignas y conservas. La dirección no cambia mientras la mantengas, por lo que un registro `A` en el ápice puede apuntar a ella. Lo mismo ocurre con una instancia que tenga una IP flotante asociada.

Para un destino operado por terceros, como una CDN o un servicio de entrada alojado, normalmente recibes un nombre de host sin una dirección fija. El proveedor puede cambiar las direcciones asociadas a ese nombre, que también pueden variar según el origen de la consulta. Por eso, no es seguro fijarlas en el ápice. Coloca el `CNAME` en un subdominio como `www` y redirige el ápice hacia él por HTTP mediante un servicio que controles.

<a id="platform-managed-records" />

## Registros gestionados por la plataforma

La plataforma crea y mantiene el SOA, el conjunto NS del ápice y todos los registros DNSSEC. Tienen `managed: true` y no se pueden crear, actualizar ni eliminar mediante la API.

**La lista de registros no los incluye por defecto.** En una zona firmada, son más numerosos que tus propios registros: hay un `NSEC3` por nombre, además del conjunto `DS`, el `DNSKEY` y el `SOA`. Incluirlos por defecto obligaría a recorrer más registros de la plataforma que registros propios. La información útil de DNSSEC está en la propia zona, en `dnssec`.

Pasa `include_managed=true` para obtener la zona exactamente como se sirve:

<Tabs>
  <Tab title="Console">
    La tabla de registros los oculta e indica cuántos hay: *N conjuntos de registros gestionados por la plataforma*, con un botón **Show** al lado. **Hide** vuelve a ocultarlos.
  </Tab>

  <Tab title="API">
    ```bash theme={null}
    GET /v1/zones/{zone_id}/records?include_managed=true
    ```
  </Tab>

  <Tab title="CLI">
    ```bash theme={null}
    basaltic dns record list <zone-id> --include-managed
    ```
  </Tab>

  <Tab title="Go">
    ```go theme={null}
    page, err := dns.New(cfg).ListRecords(ctx, zoneID, &dns.ListRecordsParams{
        IncludeManaged: basaltic.Bool(true),
    })
    ```
  </Tab>
</Tabs>

Esto resulta útil para herramientas que comparan zonas. La [exportación de un archivo de zona](/es/dns/zone-files#exporting-a-zone-file) incluye el SOA y el NS del ápice, como cualquier archivo de zona, y omite los registros DNSSEC: esas claves de firma se mantienen en la plataforma y no se aplican a otros proveedores.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.