Registro de dirección que especifica una dirección IP que se debe asignar a un nombre, como en el siguiente ejemplo:

              <host> IN A <IP-address>
            

Si el valor <host> es omitido, el registro A apunta a una dirección IP por defecto para la parte superior del espacio de nombres. Este sistema es el objetivo para todas las peticiones no FQDN.

Considere el siguiente ejemplo de registro A para el archivo de zona example.com:

              server1 IN A 10.0.1.3 IN A 10.0.1.5
            

Las peticiones para example.com apuntan a 10.0.1.3 o 10.0.1.5.

Se refiere al Registro del nombre canónico, el cual enlaza un nombre con otro. Esta clase de registros es también conocido como un alias record.

El próximo ejemplo indica a named que cualquier petición enviada a <alias-name> apuntará al host, <real-name>. Los registros CNAME son usados normalmente para apuntar a servicios que usan un esquema de nombres común, tal como www para servidores Web.

              <alias-name> IN CNAME <real-name>
            

En el ejemplo siguiente, un registro A vincula un nombre de host a una dirección IP, mientras que un registro CNAME apunta al nombre host www comúnmente utilizado para éste.

              server1 IN A 10.0.1.5 www IN CNAME server1
            

Registro de Mail eXchange, el cual indica dónde debería ir el correo enviado a un espacio de nombres particular controlado por esta zona.

               IN MX <preference-value><email-server-name>
            

En este ejemplo, <preference-value> permite una clasificación numérica de los servidores de correo para un espacio de nombres, dando preferencia a algunos sistemas de correo sobre otros. El registro de recursos MX con el valor más bajo <preference-value> es preferido sobre los otros. Sin embargo, múltiples servidores de correo pueden tener el mismo valor para distribuir el tráfico de forma pareja entre ellos.

El <email-server-name> puede ser un nombre de servidor o FQDN.

               IN MX 10 mail.example.com. IN MX 20 mail2.example.com.
            

En este ejemplo, el primer servidor de correo mail.example.com es preferido al servidor de correo mail2.example.com cuando se recibe correo destinado para el dominio example.com.

Se refiere al Registro NameServer, el cual anuncia los nombres de servidores con autoridad para una zona particular.

El siguiente ejemplo es un ejemplo de un registro NS:

               IN NS <nameserver-name>
            

Aquí, el <nameserver-name> debería ser un FQDN.

Luego, dos nombres de servidores son listados como servidores con autoridad para el dominio. No es importante si estos nombres de servidores son esclavos o maestros; ambos son todavía considerados como servidores con autoridad.

               IN NS dns1.example.com. IN NS dns2.example.com.
            

Registro PoinTeR (puntero), diseñado para apuntar a otra parte del espacio de nombres.

Los registros PTR son usados principalmente para la resolución inversa de nombres, pues ellos apuntan direcciones IP de vuelta a un nombre particular. Consulte la Sección 4.3.4, “Archivos de zona de resolución de nombres inversa” para más ejemplos de registros PTR en uso.

Registro de recursos Start Of Authority, que declara información importante de autoridad relacionada con espacios de nombres al servidor de nombres.

Está situado detrás de las directivas, un registro SOA es el primer registro en un archivo de zona.

El ejemplo siguiente muestra la estructura básica de un registro de recursos SOA:

              @ IN SOA <primary-name-server><hostmaster-email> ( <serial-number><time-to-refresh><time-to-retry><time-to-expire><minimum-TTL> )
            

El símbolo @ coloca la directiva $ORIGIN (o el nombre de la zona, si la directiva $ORIGIN no está configurada) como el espacio de nombres que esta siendo definido por este registro de recursos SOA. El nombre del host del servidor de nombres que tiene autoridad para este dominio es la directiva <primary-name-server> y el correo electrónico de la persona a contactar sobre este espacio de nombres es la directiva <hostmaster-email>.

La directiva <serial-number> es un valor numérico que es incrementado cada vez que se cambia el archivo de zona para así indicar a named que debería recargar esta zona. La directiva <time-to-refresh> es el valor numérico que los servidores esclavos utilizan para determinar cuánto tiempo debe esperar antes de preguntar al servidor de nombres maestro si se han realizado cambios a la zona. El valor <serial-number> es usado por los servidores esclavos para determinar si esta usando datos de la zona desactualizados y si debería refrescarlos.

La directiva <time-to-retry> es un valor numérico usado por los servidores esclavos para determinar el intervalo de tiempo que tiene que esperar antes de emitir una petición de actualización de datos en caso de que el servidor de nombres maestro no responda. Si el servidor maestro no ha respondido a una petición de actualización de datos antes de que se acabe el intervalo de tiempo <time-to-expire>, los servidores esclavos paran de responder como una autoridad por peticiones relacionadas a ese espacio de nombres.

La directiva <minimum-TTL> es la cantidad de tiempo que otros servidores de nombres guardan en caché la información de zona.

Cuando se configura BIND, todos los tiempos son siempre referenciados en segundos. Sin embargo, es posible usar abreviaciones cuando se especifiquen unidades de tiempo además de segundos, tales como minutos (M), horas (H), días (D) y semanas (W). La Tabla 4.1, “Segundos comparados a otras unidades de tiempo” le muestra la cantidad de tiempo en segundos y el tiempo equivalente en otro formato.

El ejemplo siguiente ilustra la forma que un registro de recursos SOA puede tomar cuando es configurado con valores reales.

              @ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day