Este es el sexto de los artículos dedicados al DNS publicados en ZeppelinuX. En este artículo conoceremos los tipos de registros de recursos necesarios para definir las zonas. Si te interesa ver el artículo anterior, Resolución inversa DNS, solo tienes que pinchar aquí.
- Registros de recursos DNS.
- Notas previas.
- Formato general.
- Tipos de registros.
- Delegación de dominios y registros pegamento.
- Registros de recursos DNS (Volver al índice General)
Como hemos visto en artículos anteriores, el servicio DNS gestiona una base de datos distribuida entre múltiples servidores DNS, que almacenan los ficheros de zona que contienen la información sobre los dominios. Los ficheros de zona organizan esta información con los registros de recurso (RR, Resource Records). Estos registros de recurso son enviados en las preguntas y respuestas entre clientes DNS y servidores DNS.En este artículo hablaremos sobre los Registros de recursos DNS más utilizados. Para obtener una lista más completa de tipos de registros DNS o pseudo-registros de recursos, pincha aquí.
También decir que a partir de este momento nos referiremos a los Registros de Recursos como RR.
- Notas previas (Volver al índice General)
- El (;) se utiliza para comentar líneas o añadir comentarios a las líneas.
;Esto es una línea comentada
zeppelinux.es. IN NS ns1.zeppelinux.es. ;Esto es un comentario
- $TTL: Directiva obligatoria a partir de la versión 9 de Bind (RFC 1035/RFC 2308). Ajusta el tiempo de vida (del ingles, Time To Live) predeterminado de la información obtenida en el fichero de zona.
Es el tiempo en segundos que determina cuanto tiempo los registros de recursos de la zona serán válidos.
Un RR puede contener su propio su propio valor TTL, que tendrá prioridad sobre la directiva presente.
Por defecto se usan segundos (604800 segundos equivalen a siete días exactos), pero puede usarse también semanas ($TTL 1W), días ($TTL 7D), Horas ($TTL 168H) y minutos ($TTL 10080M).Debe declararse al comienzo del archivo de zona, antes del RR SOA.
$TTL 7D zeppelinux.es. IN SOA ns1.zeppelinux.es. super.zeppelinux.es. ( ...
- Si el primer campo de una línea de un registro de recursos se deja en blanco, toma el valor del mismo campo de la línea del registro de recursos anterior.
IN NS ns1.zeppelinux.es. ;Servidor DNS maestro
por ejemplo, si el registro anterior fue el registro SOA del ejemplo anterior, la línea anterior es igual que:
zeppelinux.es. IN NS ns1.zeppelinux.es. ;Servidor DNS maestro
- Si los nombres DNS no terminan con un punto, por defecto, se añadirá a su derecha el nombre de dominio de la zona. Por ejemplo para el dominio zeppelinux.es, las líneas siguientes son iguales:
ns1 IN A 192.168.1.20
- El símbolo @ equivale al nombre del dominio de la zona.
@ IN NS ns1.zeppelinux.es.
es igual que:
zeppelinux.es. IN NS ns1.zeppelinux.es.
- $ORIGIN: La directiva $ORIGIN (RFC 1035) define el nombre del dominio que será añadido al final de cualquier nombre que no acabe en punto (nombres relativos o no cualificados) en los RR, para así transformarlos en nombres FQDN (fully qualified domain name). Si un nombre acaba en punto, se considera un nombre FQDN y no se utilizaría $ORIGIN.
La sintaxis es la siguiente:$ORIGIN nombre-dominio
Donde
nombre-dominiose escribe en formato FQDN para evitar confusiones, pero podría no acabar en punto y funcionaría todo igual, aunque es buena costumbre escribir el dominio acabado en punto.Esta directiva puede ponerse en cualquier parte del archivo de zona y además, se pueden poner más de una, teniendo efecto cada directiva en el trozo del archivo de zona que va desde su aparición hasta la siguiente directiva $ORIGIN o el final del fichero.
... $ORIGIN zeppelinux.es. ;A partir de aquí se añade .zeppelinux.es. a los nombres relativos ... $ORIGIN viajes.zeppelinux.es. ;A partir de aquí se añade .viajes.zeppelinux.es. a los nombres relativos ...
La directiva $ORIGIN no es obligatoria, y en el caso de que no esté presente se asumirá que su valor es el del dominio descrito por el fichero de zona, que en BIND será el nombre que se encuentra en la cláusula
zonedel fichero de configuraciónnamed.conf.local. Es aconsejable usarla siempre, al menos al principio del fichero de zona, de forma que este queda así más descriptivo y portable, pues puede que algún software DNS no admita su ausencia.
es igual que:
ns1.zeppelinux.es. IN A 192.168.1.20
- El (;) se utiliza para comentar líneas o añadir comentarios a las líneas.
- Formato general (Volver al índice General)
Los RR tienen dos formas de representarse. Una es la representación textual utilizada en los ficheros de zona y la otra es la representación binaria, que es la que se emplea en los mensajes del protocolo DNS, definina en la RFC 1035. Nosotros trataremos solo la representación textual.Formato genenral de un RR:
Nombre de dominio [TTL] Clase Tipo Tipo-Dato
Ejemplo de un RR:
zion.zeppelinux.es 7200 IN A 91.199.120.62
- NombreDeDominio: Nombre de dominio con el que se asocia el RR. Por ejemplo: zion.zeppelinux.es, 62.120.199.91.in-addr.arpa
- TTL (Time To Live): Número de segundos que puede estar el RR en cache antes de ser descartado. Este valor es opcional a nivel de recurso ya que se puede establecer un tiempo global que se aplicará a todos los RR de una zona. Un TTL con valor 0 indica que el registro no tiene que ser almacenado en cache.
- Clase: Define la arquitectura de protocolos usada. Por ejemplo: IN para TCP/IP.
- Tipo: Hace referencia al tipo de registro y son diferentes en función del campo clase. Por ejemplo, para la clase IN existen tipos como: A, NS, MX, CNAME, etc.
- Tipo-Dato: Es información asociada al nombre de dominio. Varía según el tipo de registro. Por ejemplo una IP para el tipo A.
- Tipos de registros (Volver al índice General)
Como ya hemos dicho más arriba, en este artículo veremos los RR más utilizados, no obstante, en este enlace, puedes ver todos los tipos de Registros de Recursos existentes según la IANA.- Registro SOA (Volver al índice General)
El registro SOA (Start Of Authority) es el primer registro de una zona y en el cual, se definen una serie de opciones generales de la zona.
Los datos asociados con un registro SOA son los siguientes:- MNAME: es el nombre FQDN del servidor DNS maestro del dominio. Por ejemplo: ns1.zeppelinux.es.
- Contacto (contact): Correo del responsable del dominio. Se parece a una dirección de correo electrónico normal, con la excepción de que la arroba (@) se reemplaza por un punto (.). Por ejemplo: super.zeppelinux.es.
- Numero de serie (serial): Indica la versión del fichero de zona y debe ser incrementado cada vez que se modifica el fichero de zona. Los servidores DNS secundarios consultan el registro SOA para realizar transferencias de zona. Si ha cambiado, entonces se realiza la transferencia de zona. Una práctica muy común es utilizar el formato de fecha aaammdd y añadir al final dos o tres dígitos más para los cambios que puedan hacerse en un mismo día. Por ejemplo: 20190415001.
- Actualización (refresh): Tiempo que esperan los servidores DNS esclavos para preguntar al servidor DNS maestro si hay cambios en la zona. La RFC 1912 recomienda valores entre
1200 sg(20 minutos) y43200 sg(12 horas) dependiendo de la frecuencia de cambios en los ficheros de zona. Si se usan notificaciones (NOTIFY), es decir, cuando los servidores DNS envian un mensaje NOTIFY a los clientes cada vez que se ha realizado un cambio en los datos de la zona, se puede usar un valor muy alto (1 o más días). - Reintentos (retry): Si falla la transferencia de zona, esta opción indica el tiempo que espera el Servidor DNS secundario o esclavo antes de volver a intentar la transferencia. Se aconseja que el valor de esta opción sea inferior al tiempo de actualización.
- Caducidad (expire): Determina el tiempo que el servidor DNS esclavo puede estar intentando contactar con el servidor DNS maestro para ver si hay cambios de zona. Si el tiempo expira, el servidor DNS esclavo considera que algo ha pasado y se declara como no autorizado para la zona, y por lo tanto, no responderá a preguntas sobre esa zona. La RFC 1912 recomienda valores entre 2 y 4 semanas.
- TTL negativo (Time To Live): Tiempo mínimo que se almacenan las respuestas negativas sobre una zona. Este tiempo es diferente al TTL de los RR.
Ejemplo de registro SOA para zona de resolución directa:zeppelinux.es. IN SOA ns1.zeppelinux.es. super.zeppelinux.es. ( 20190425001 ; serial 604800 ; refresh (7 días) 86400 ; retry (1 día) 2419200 ; expire (28 días) 604800 ) ; TTL negativo (7 días) ...Ejemplo de registro SOA para zona de resolución inversa:
@ IN SOA 1.168.192.in-addr.arpa. super.zeppelinux.es. ( 20190425001 ; Serial 604800 ; Refresh (7 días) 86400 ; Retry (24 horas) 2419200 ; Expire (28 días) 604800 ) ; TTL negativo (7 días) ... - Registro NS (Volver al índice General)
El registro NS (Name Server) permite establecer:- El o los servidores de nombres autorizados para una zona. Cada zona debe contener al menos un registro NS y los servidores DNS pueden tener un nombre de la misma zona o de otras.
... zeppelinux.es. IN NS ns1.zeppelinux.es. ;Servidor DNS maestro zeppelinux.es. IN NS ns2.zeppelinux.es. ;Servidor DNS esclavo zeppelinux.es. IN NS dns.zeppelinux.net. ;Servidor DNS esclavo ns1.zeppelinux.es. IN A 192.168.1.20 ns2.zeppelinux.es. IN A 192.168.1.21 ...
- Cuales son los servidores de nombres autorizados para los subdominios delegados. Cada zona debe contener al menos un registro NS por cada subdominio que haya delegado.
... zeppelinux.es. IN NS ns1.zeppelinux.es. ;Servidor DNS maestro zeppelinux.es. IN NS ns2.zeppelinux.es. ;Servidor DNS esclavo zeppelinux.es. IN NS dns.zeppelinux.net. ;Servidor DNS esclavo ns1.zeppelinux.es. IN A 192.168.1.20 ns2.zeppelinux.es. IN A 192.168.1.21 ;DELEGACIÓN viajes.zeppelinux.es. IN NS ns1.viajes.zeppelinux.es. redes.zeppelinux.es. IN NS dns.zeppelinux.net. ns1.viajes.zeppelinux.es. IN A 192.168.2.20 ;GLUE Record ...
Nota: La parte derecha de un registro NS no debe ser un nombre de tipo CNAME. Se explica en el apartado sobre registros tipo CNAME.
- El o los servidores de nombres autorizados para una zona. Cada zona debe contener al menos un registro NS y los servidores DNS pueden tener un nombre de la misma zona o de otras.
- Registro A (Volver al índice General)
El registro A (Address), también conocido como registro de dirección, establece una correspondencia entre un nombre de dominio completamente cualificado (FQDN) y una dirección IP versión 4.... ns1.zeppelinux.es. IN A 192.168.1.20 ns2.zeppelinux.es. IN A 192.168.1.21 filemon.zeppelinux.es. IN A 192.168.1.22 ...
- Registro AAAA (Volver al índice General)
El registro AAAA (Address Address Address Address) establece una correspondencia entre un nombre de dominio completamente cualificado (FQDN) y una dirección IP versión 6.... ns1.zeppelinux.es. IN AAAA ::ffff:c0a8:114 ns2.zeppelinux.es. IN AAAA ::ffff:c0a8:115 filemon.zeppelinux.es. IN AAAA ::ffff:c0a8:116 ...
- Registro CNAME (Volver al índice General)
El registro CNAME (Canonical Name) permite crear alias para nombres de dominio especificados en registros A y AAAA.... filemon.zeppelinux.es. IN A 192.168.1.22 www.zeppelinux.es. IN CNAME filemon.zeppelinux.es. ftp.zeppelinux.es. IN CNAME filemon.zeppelinux.es. ...
Un registro CNAME también puede apuntar a un nombre de otro dominio.
... www.zeppelinux.es. IN CNAME www.zeppelinux.com. ...
No se deben usar registros CNAME en la parte derecha de los registros MX y NS. La parte derecha de estos recursos tiene que ser un nombre que aparezca en un registro de dirección de tipo A o AAAA.
Nota: El uso de muchos CNAME disminuye el rendimiento de los servidores DNS, ya que cuando se pregunta por un registro CNAME hay que buscar dos veces en el fichero de zona. En servidores con poco tráfico su impacto en el rendimiento es insignificante, pero en servidores con zonas muy grandes y mucho tráfico hay que tenerlo en cuenta.
- Registro MX (Volver al índice General)
El registro MX (Mail Exchange) permite definir los servidores encargados de la entrega de correo en el dominio y la prioridad entre ellos. Su sintáxis es la siguiente:Nombre_de_dominio [TTL] Clase MX prioridad Tipo-Dato
Es posible definir varios registros MX para un mismo dominio. En cada registro MX se especifica un número positivo entre
0y65535, que determina la preferencia. El registro MX con un número de preferencia más pequeño tiene la mayor prioridad y será el primero en ser probado. El cliente remoto continuará recorriendo, de mayor a menor prioridad, la lista de servidores hasta que logre entregar con éxito el mensaje, o éste sea permanentemente rechazado debido a un mensaje de servidor inalcanzable o a que la cuenta de correo no existe en ese servidor. Si hay más de una sola entrada con el mismo número de preferencia, todos ellos deben ser probados antes de desplazarse a una entrada con menor prioridad.Estos equipos son consultados por los agentes de transporte de correo SMTP (MTA, Mail Transport Agent).
... zeppelinux.es. IN MX 10 mail1.zeppelinux.es. zeppelinux.es. IN MX 20 mail2.zeppelinux.es. mail1.zeppelinux.es. IN A 192.168.1.100 mail2.zeppelinux.es. IN A 192.168.1.101 ...
Nota: La parte derecha de un registro MX no debe ser un nombre de tipo CNAME. Se explica en el apartado sobre registros tipo CNAME.
- Registro SOA (Volver al índice General)
- Registro SRV (Volver al índice General)
El registro SRV (Services Record) define la ubicación, es decir, el nombre de host y el número de puerto, de servidores para servicios específicos. Se define en la RFC 2782 y cuyo código de tipo DNS es33. Algunos protocolos de Internet como el Protocolo de inicio de sesión (SIP) y el Protocolo de presencia y mensajería extensible (XMPP) a menudo requieren el soporte de SRV por parte de los elementos de la red.La sintáxis para este tipo de registro es la siguiente:
_servicio._protocolo.nombre. TTL clase SRV prioridad peso puerto objetivo
- servicio: El nombre simbólico del servicio deseado.
- protocolo: El protocolo de transporte del servicio deseado; Esto suele ser TCP o UDP.
- nombre: El nombre de dominio para el cual este registro es válido, terminando en un punto.
- TTL: Tiempo de vida del registro.
- clase: Campo de clase DNS estándar (esto siempre está IN).
- prioridad: La prioridad del host de destino, menor valor significa mayor prioridad.
- peso: Un peso relativo para registros con la misma prioridad, mayor valor significa más preferido.
- puerto: El puerto TCP o UDP en el que se encuentra el servicio.
- objetivo: El nombre de host canónico de la máquina que proporciona el servicio, terminado en un punto.
Ejemplos:
Un ejemplo de registro SRV en forma de texto que podría encontrarse en un archivo de zona podría ser el siguiente:_sip._tcp.ejemplo.com. 86400 IN SRV 0 5 5060 sipserver.ejemplo.com.
Esto apunta a un servidor llamado sipserver.ejemplo.com que escucha en el puerto
TCP 5060para los servicios de protocolo del Protocolo de inicio de sesión (SIP). La prioridad dada aquí es0, y el peso es5.Otro ejemplo:
... _http._tcp.zeppelinux.es. IN SRV 0 5 80 filemon.zeppelinux.es _ftp._tcp.zeppelinux.es. IN SRV 0 5 21 filemon.zeppelinux.es ...
Otro ejemplo más complejo:
# _servicio._protocolo.nombre. TTL clase SRV prioridad peso puerto objetivo. _sip._tcp.ejemplo.com. 86400 IN SRV 10 60 5060 bigbox.ejemplo.com. _sip._tcp.ejemplo.com. 86400 IN SRV 10 20 5060 smallbox1.ejemplo.com. _sip._tcp.ejemplo.com. 86400 IN SRV 10 20 5060 smallbox2.ejemplo.com. _sip._tcp.ejemplo.com. 86400 IN SRV 20 0 5060 backupbox.ejemplo.com.
Los primeros tres registros comparten una prioridad de
10, por lo que los clientes utilizarán el valor del campo peso para determinar qué servidor (host y combinación de puertos) contactar. La suma de los tres valores es100, por lo que bigbox.ejemplo.com se usará el60%de las veces. Los dos hosts, smallbox1 y smallbox2 se utilizarán para el40%del total de solicitudes, la mitad de ellas se enviarán a smallbox1 y la otra mitad a smallbox2. Si bigbox no está disponible, estas dos máquinas restantes compartirán la carga por igual, ya que cada una será seleccionada el50%de las veces.Si los tres servidores con prioridad
10no están disponibles, se elegirá el registro con el siguiente valor de prioridad más bajo, que es backupbox.ejemplo.com. Esto podría ser una máquina en otra ubicación física, presumiblemente no vulnerable a cualquier cosa que haga que los primeros tres hosts no estén disponibles.El balanceo de carga proporcionado por los registros SRV es inherentemente limitado, ya que la información es esencialmente estática. La carga actual de los servidores no se tiene en cuenta, a menos que los valores TTL sean lo suficientemente bajos (alrededor de un minuto o menos) para que los valores de prioridad o peso puedan actualizarse rápidamente.
Nota: Al igual que en los registros MX, el objetivo en los registros SRV debe apuntar al nombre de host con un registro de dirección A o AAAA. Señalar un nombre de host con un registro CNAME no es una configuración válida.
En este artículo no se explica en detalle los campos de este tipo de registro. Para más información, consultar la RFC 2782.
- Registro PTR (Volver al índice General)
El registro PTR (Pointer Record) establece una correspondencia entre direcciones IPv4 e IPv6 y nombres de dominio. Se utilizan en las zonas de resolución inversa.Nota: En una misma zona no puede haber registros PTR IPv4 y registros PTR IPv6. Existen por lo tanto zonas de resolución inversa IPv4 y zonas de resolución inversa IPv6.
Ejemplos para zona IPv4:
En el caso de un bloque IPv4 de prefijo /24, por ejemplo el 192.168.1.0/24, los registros PTR serían los siguientes:... 20.1.168.192.in-addr.arpa. IN PTR ns1.zeppelinux.es. 21.1.168.192.in-addr.arpa. IN PTR ns2.zeppelinux.es. 22.1.168.192.in-addr.arpa. IN PTR filemon.zeppelinux.es. ...
o lo que es lo mismo:
... 20 IN PTR ns1.zeppelinux.es. 21 IN PTR ns2.zeppelinux.es. 22 IN PTR filemon.zeppelinux.es. ...
Ejemplos para zona IPv6:
Antes veremos la correspondencia de las IPv4 del ejemplo anterior con las IPv6:192.168.1.20 = 0000:0000:0000:0000:0000:ffff:c0a8:0114 192.168.1.21 = 0000:0000:0000:0000:0000:ffff:c0a8:0115 192.168.1.22 = 0000:0000:0000:0000:0000:ffff:c0a8:0116
En el caso de un bloque IPv6 de prefijo /112, por ejemplo el ::ffff:c0a8:0/112 o lo que es lo mismo, 0000:0000:0000:0000:0000:ffff:c0a8:0000/112, los registros PTR serían los siguientes:
... $ORIGIN 8.a.0.c.f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 4.1.1.0 IN PTR ns1.zeppelinux.es. 5.1.1.0 IN PTR ns2.zeppelinux.es. 6.1.1.0 IN PTR filemon.zeppelinux.es. ...
o lo que es lo mismo:
... 4.1.1.0.8.a.0.c.f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. IN PTR ns1.zeppelinux.es. 5.1.1.0.8.a.0.c.f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. IN PTR ns2.zeppelinux.es. 6.1.1.0.8.a.0.c.f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. IN PTR filemon.zeppelinux.es. ...
- Registro HINFO (Volver al índice General)
El registro HINFO (Host INFOrmation) es opcional, describe el hardware y el sistema operativo sobre el que se ejecuta un servidor DNS.... @ IN HINFO "AMD Opteron" "Debian GNU/Linux" ...
- Registro TXT (Volver al índice General)
El registro TXT (plaint text) permite asociar información adicional a un dominio mediante múltiples cadenas de texto, con una longitud máxima de 255 caracteres cada una de ellas. Por ejemplo, utilizado para almacenar claves de cifrado.... @ IN TXT "Servidor maestro de ZeppelinuX" @ IN TXT "Servidor maestro de ZeppelinuX" ...
- Registro SPF (Volver al índice General)
SPF son las siglas de Sender Policy Framework, una protección contra las falsificaciones de correos electrónicos. Esta protección se basa en un registro TXT que debemos añadir en nuestros servidores DNS, para identificar a los servidores de correo SMTP de nuestro dominio. Muchos servidores de correo no permitenrecibir emails enviados desde dominios que no tienen configurada esta entrada.
Ejemplo de registro SPF:
El propietario del nombre de dominio, debe añadir en la configuración de la zona DNS del dominio las direcciones IP de las máquinas utilizadas para enviar correo. Esto se consigue utilizando registros TXT. Un ejemplo de registro SPF sería:... @ IN TXT "v=spf1 mx ptr ~all" ...
En el ejemplo anterior se indica en un registro de texto TXT para el dominio zeppelinux.es con la siguiente descripción SPF:
- v=: Define la versión usada de SPF (versión 1).
- mx: Autoriza a las máquinas con la IP de los registros MX.
- ptr: Autoriza a las máquinas bajo el dominio zeppelinux.es.
- ~all: Sugiere desautorizar a las máquinas que no encajen en lo autorizado explícitamente.
El ejemplo anterior debería servir de plantilla para la mayoría de los dominios.
- Registro ANY (*) (Volver al índice General)
El registro ANY (*) es un pseudo-registro de recurso, se utiliza solo en los mensajes DNS, nunca en las bases de datos de zonas o ficheros de zona. Hace referencia a todos los registros. - Registro AXFR (Volver al índice General)
El registro AXFR es un pseudo-registro de recurso, se utiliza solo en los mensajes DNS, nunca en las bases de datos de zonas o ficheros de zona. Utilizado para solicitar una transferencia de zona completa, desde el servidor DNS maestro al servidores DNS esclavo. - Registro IXFR (Volver al índice General)
El registro IXFR es un pseudo-registro de recurso, se utiliza solo en los mensajes DNS, nunca en las bases de datos de zonas o ficheros de zona. Utilizado para solicitar una transferencia de zona incremental de la zona dada pero solo las diferencias desde un número de serie anterior. - Delegación de dominios y registros pegamento (Volver al índice General)
La organización que administra un servidor DNS, y por lo tanto, sus zonas, puede decidir delegar o no en otros servidores DNS alguno de sus subdominios. Pueden darse dos casos:- Que el servidor DNS autorizado del subdominio en el que se delega, se encuentre dentro del propio subdominio.
... zeppelinux.es. IN NS ns1.zeppelinux.es. ;Servidor DNS maestro zeppelinux.es. IN NS ns2.zeppelinux.es. ;Servidor DNS esclavo zeppelinux.es. IN NS dns.zeppelinux.net. ;Servidor DNS esclavo ns1.zeppelinux.es. IN A 192.168.1.20 ns2.zeppelinux.es. IN A 192.168.1.21 ;DELEGACIÓN viajes.zeppelinux.es. IN NS ns1.viajes.zeppelinux.es. ;Delegación ns1.viajes.zeppelinux.es. IN A 192.168.2.20 ;GLUE Record ...
En cuyo caso:
- Hay que añadir un registro NS en la zona del padre que define el servidor DNS autorizado para la zona delegada.
- Y hay que añadir un registro A para indicar la dirección IP del servidor DNS autorizado para la zona delegada.
A este tipo de registros se les denomina glue record o registro pegamento porque unen la zona hija con la zona padre.Si no se define este registro, el cliente DNS que realiza una pregunta iterativa (por ejemplo pc1.viajes.zeppelinux.es) y obtiene una referencia al siguiente servidor DNS al que preguntar (ns1.viajes.zeppelinux.es) no podría obtener la dirección IP del nuevo servidor DNS hasta que no acceda a él (ns1 es un nombre del dominio viajes.zeppelinux.es). Es decir, no puede preguntarle si no conoce su dirección IP.
Si se omiten o se añaden registros pegamento incorrectos, parte del espacio de nombres quedará inaccesible.
Por lo tanto los servidores DNS padres deben conocer la direcció IP de los servidores DNS de todos sus subdominios.
- Que el servidor DNS autorizado del subdominio en el que se delega, no se encuentre dentro del subdominio.
... zeppelinux.es. IN NS ns1.zeppelinux.es. ;Servidor DNS maestro zeppelinux.es. IN NS ns2.zeppelinux.es. ;Servidor DNS esclavo zeppelinux.es. IN NS dns.zeppelinux.es. ;Servidor DNS esclavo ns1.zeppelinux.es. IN A 192.168.1.20 ns2.zeppelinux.es. IN A 192.168.1.21 ;DELEGACIÓN redes.zeppelinux.es. IN NS dns.zeppelinux.net. ...
En cuyo caso:
- Hay que añadir un registro NS en la zona del padre que define el servidor DNS autorizado para la zona delegada.
- No hace falta añadir un registro A para indicar la dirección IP del servidor DNS autorizado para la zona delegada.
En este caso, el cliente DNS que realiza una pregunta iterativa (por ejemplo, pc1.redes.zeppelinux.es) y obtiene una referencia al siguiente servidor DNS al que preguntar (dns.zeppelinux.net) podrá resolver el nombre dns.zeppelinux.net normalmente.Es un error incluir registros pegamento para anombres de host que no los necesitan. La regla general es que se deben incluir registro A únicamente para los host que están dentro del dominio o cualquiera de sus subdominios.
- Que el servidor DNS autorizado del subdominio en el que se delega, se encuentre dentro del propio subdominio.
Aquí termina el sexto de los artículos dedicado al Sistema de Nombres de Dominio (DNS). En breve, continuaremos publicando más sobre DNS, en concreto sobre Transferencias de zona.
Configuración de privacidad y de cookies.
Publicaciones Relacionadas
Transferencias de Zona DNS (0)- Sistema de nombres de dominio (DNS) (2)
- DNS dinámico DDNS (Dynamic DNS) (0)
- Clientes DNS, Proceso de resolución, Caché, TTL y Recursividad (0)
- Formato de un mensaje DNS (0)
- Instalación y configuración de BIND9 en Debian (14)
- Resolución inversa DNS (2)
- Servidores de nombres, sus tipos y zonas (0)
Deja una respuesta