Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
DNS es una base de datos distribuida jerárquica y un conjunto asociado de protocolos que definen:
Un mecanismo para consultar y actualizar la base de datos
Mecanismo para replicar la información en la base de datos entre servidores
Esquema de la base de datos
Los nombres de host DNS residen en una base de datos que se puede distribuir entre varios servidores, lo que reduce la carga en cualquier servidor y proporcionan la capacidad de administrar este sistema de nomenclatura por partición. DNS admite nombres jerárquicos y permite el registro de varios tipos de datos, además de la asignación de nombre de host a dirección IP utilizada en los archivos HOSTS. La base de datos DNS se distribuye, lo que le permite escalar verticalmente y escalar horizontalmente, lo que significa que el rendimiento no se degrada cuando se agregan más servidores.
El DNS original se basaba en la solicitud de comentario (RFC) 1035 (nombres de dominio:implementación y especificación). Otros RFC describen la seguridad del DNS, la implementación, y los problemas administrativos que más adelante aumentaron las especificaciones de diseño originales.
Las RFC usadas en los sistemas operativos Windows Server son:
- Nombres de dominio: conceptos e instalaciones RFC 1034
- Nombres de dominio: implementación y especificación RFC 1035
- Extensiones DNS para admitir ip versión 6 RFC 1886
- Un mecanismo para la notificación inmediata de cambios de zona (NOTIFICACIÓN DNS) RFC 1996
- Transferencia de zona incremental en DNS RFC 1995
- Actualizaciones dinámicas en el sistema de nombres de dominio (DNS UPDATE)RFC 2136
- Almacenamiento en caché negativo de consultas DNS (DNS NCACHE) RFC 2308
- Registros de recursos para las extensiones de seguridad DNS RFC 4034
- Modificaciones de protocolo para las extensiones de seguridad dns RFC 4035
- Un RR de DNS para especificar la ubicación de los servicios (DNS SRV) RFC 2052
Nombres de dominio DNS
DNS se implementa como una base de datos jerárquica y distribuida que contiene varios tipos de datos, incluidos los nombres de host y los nombres de dominio. Los nombres de una base de datos DNS forman una estructura jerárquica de árbol denominada espacio de nombres de dominio. Los nombres de dominio constan de etiquetas individuales separadas por puntos, por ejemplo: mydomain.contoso.com.
Un nombre de dominio completo (FQDN) identifica de forma única la posición del host dentro del árbol jerárquico dns. El FQDN especifica una lista de nombres separados por puntos en el camino desde el host referenciado hasta la raíz. En la ilustración siguiente se muestra un ejemplo de un árbol DNS con un host llamado mydomain dentro del contoso.com dominio. El FQDN del host sería mydomain.contoso.com.
Descripción del espacio de nombres de dominio DNS
El espacio de nombres de dominio DNS, como se muestra en la ilustración anterior, se basa en el concepto de un árbol de dominios con nombre. Cada nivel del árbol puede representar una rama o una hoja. Una rama es un nivel en el que se usa más de un nombre para identificar una colección de recursos con nombre. Una hoja representa un único nombre usado una vez en ese nivel para indicar un recurso específico.
Jerarquía de nombres de dominio DNS
Los clientes y servidores DNS usan consultas como método para resolver nombres en el árbol a tipos específicos de información de recursos. Los servidores DNS proporcionan esta información en las respuestas de consulta a los clientes DNS que, a continuación, extraen la información y la pasan a un programa solicitante para resolver el nombre consultado. En el proceso de resolver un nombre, los servidores DNS suelen funcionar como clientes DNS, consultando a otros servidores para resolver completamente un nombre consultado.
Por ejemplo, los servidores raíz de Internet asignan a Contoso una autoridad para su propia parte del árbol de espacios de nombres de dominio DNS en Internet, es decir, contoso.com. La resolución de un nombre fuera del contoso.com espacio de nombres requiere que los servidores DNS de Contoso consulten otros servidores DNS, como los servidores raíz.
Cómo se organiza el espacio de nombres de dominio DNS
Cualquier nombre de dominio DNS usado en el árbol es técnicamente un dominio. Sin embargo, la mayoría de las discusiones de DNS identifican nombres de una de cinco maneras, en función del nivel y de la forma en que se usa un nombre. Por ejemplo, el nombre de dominio DNS registrado en Contoso (contoso.com) se conoce como un dominio de segundo nivel. El nombre tiene dos partes (conocidas como etiquetas) que indican que se encuentra dos niveles por debajo de la raíz o parte superior del árbol. La mayoría de los nombres de dominio DNS tienen dos o más etiquetas, cada una de las cuales indica un nuevo nivel en el árbol. Los puntos se usan en los nombres para separar las etiquetas.
En la tabla siguiente se describen las cinco categorías de nombres de dominio DNS por su función en el espacio de nombres, junto con un ejemplo de cada tipo de nombre.
| Tipo de nombre | Descripción | Ejemplo |
|---|---|---|
| Dominio raíz | La parte superior del árbol, que representa un nivel sin nombre; a veces se muestra como dos comillas vacías (""), que indica un valor NULL. Cuando se usa en un nombre de dominio DNS, se indica mediante un punto final (.) para designar que el nombre se encuentra en el nivel raíz o superior de la jerarquía de dominios. En este caso, el nombre de dominio DNS se considera completo y apunta a una ubicación exacta en el árbol de nombres. Los nombres indicados de esta manera son FQDN. Un único punto (.) o un punto usado al final de un nombre, como example.contoso.com. |
Un único punto (.) o un punto usado al final de un nombre, como example.contoso.com. |
| Dominio de nivel superior (TLD) | Nombre que se usa para indicar un país o región o el tipo de organización mediante un nombre. |
.com, que indica un nombre registrado en una empresa para su uso comercial en Internet. |
| Dominio de segundo nivel | Nombres de longitud variable registrados a nombre de una persona u organización para su utilización en Internet. Estos nombres siempre se basan en un dominio de nivel superior adecuado, en función del tipo de organización o ubicación geográfica donde se use un nombre. |
contoso.com. es el nombre de dominio de segundo nivel registrado en Contoso por el registrador de nombres de dominio DNS de Internet. |
| Subdominio | Otros nombres que una organización puede crear derivados del nombre de dominio registrado de segundo nivel. Los subdominios incluyen nombres agregados para aumentar el árbol DNS de nombres de una organización y dividirlos en departamentos o ubicaciones geográficas. |
example.contoso.com. es un subdominio asignado por Contoso para su uso en nombres de ejemplo de documentación. |
| Nombre de host o recurso | Nombres que representan una hoja en el árbol DNS de nombres e identifican un recurso específico. Normalmente, la etiqueta más izquierda de un nombre de dominio DNS identifica un equipo específico en la red. Por ejemplo, si se usa un nombre en este nivel en un registro de recursos de host (A), se usa para buscar la dirección IP del equipo en función de su nombre de host. |
host-a.example.contoso.com. La primera etiqueta (host-a) es el nombre de host DNS para un equipo específico de la red. |
Dominios DNS e Internet
Las autoridades de registro de Internet administran el sistema de nombres de dominio. Las autoridades de registro son responsables de mantener los dominios de nivel superior asignados por la organización y por país o región. Estos nombres de dominio siguen el Estándar Internacional para códigos de país (ISO 3166). Hay cientos de nombres de dominio de nivel superior disponibles para su uso por parte del público. En la tabla siguiente se muestran algunos TLD comunes, así como abreviaturas de dos letras usadas para países y regiones.
| Nombre de dominio DNS | Tipo de organización |
|---|---|
| .COM | Organizaciones comerciales |
| .edu | Instituciones educativas |
| .Org | Organizaciones sin ánimo de lucro |
| .net | Redes (la red troncal de Internet) |
| .Gov | Organizaciones gubernamentales nomilitaristas |
| .mil | Organizaciones gubernamentales militares |
| .arpa | Zonas DNS inversas |
| .xx | Códigos de país de dos letras (por ejemplo, .us, .au, .ca. , .fr) |
Registros de recursos DNS
Los registros de recursos DNS contienen la información que mantiene una zona sobre los recursos (como los hosts) que contiene la zona. Un registro de recursos típico consta de:
- Nombre (host) del registro de recursos.
- Información sobre cuánto tiempo puede permanecer el registro de recursos en la memoria caché.
- Tipo de registro de recursos, como un registro de recursos host (A).
- Datos específicos para el tipo de registro, como la dirección IPv4 de los hosts.
Puede agregar registros de recursos directamente o se pueden agregar automáticamente cuando los clientes habilitados para el Protocolo de configuración dinámica de host (DHCP) basados en Windows se unen a una red mediante la actualización dinámica.
Tipos de registros de recursos
Entre los registros de recursos comunes se incluyen:
| Tipo de registro de recursos | Descripción |
|---|---|
| Registros de host (A, AAAA) | Asigna un nombre de host a una dirección IP. |
| Registros de alias (CNAME) | Reenvíe un nombre de dominio o subdominio de alias a otro nombre principal o canónico. Los registros de recursos de alias (CNAME) a veces se denominan registros de recursos de nombre canónico. Con estos registros, puede usar más de un nombre DNS para apuntar a un único host. |
| Registros de intercambio de correo (MX) | Especifica el nombre de un equipo que intercambia o reenvía el correo. Las aplicaciones de correo electrónico usan el registro de recursos del intercambiador de correo (MX) para localizar un servidor de correo basado en un nombre de dominio DNS en la dirección del destinatario de un mensaje de correo electrónico. Si existen varios registros de recursos de intercambio de correo (MX), el servicio cliente DNS intenta ponerse en contacto con los servidores de correo en el orden de preferencia del valor más bajo (prioridad más alta) al valor más alto (prioridad más baja). |
| Registros de puntero (PTR) | Se usa en búsquedas de DNS inversos para asignar una dirección IP al dominio. Los registros de recursos de puntero (PTR) admiten el proceso de búsqueda inversa, en función de las zonas que se crean y tienen su raíz en el dominio in-addr.arpa. Debe tener la zona de búsqueda inversa adecuada presente en el servidor DNS para crear un registro PTR que asigne una dirección IP a un nombre de host específico. |
| Registros de ubicación de servicios (SRV) | Especifica el host, el puerto y el protocolo de un servicio. Los registros de recursos de ubicación de servicio (SRV) son necesarios cuando los clientes usan DNS para buscar servicios de ubicación como controladores de dominio de Active Directory. |
| Registros del servidor de nombres (NS) | Especifica los servidores de nombres autoritativos para un dominio. |
| Registro de texto (TXT) | Habilita la publicación de texto en un registro DNS. Los registros de texto permiten agregar información de texto que se devuelve consultando DNS. Los registros TXT se usan a menudo para autenticar la propiedad de las zonas DNS. |
| Registro de nombre de delegación (DNAME) | Proporciona un alias para un dominio, como un registro CNAME, pero incluye todos los subdominios. |
| Registro de inicio de autoridad (SOA) | Proporciona información autoritativa sobre una zona DNS. El registro SOA incluye el servidor de nombres principal, el contacto del administrador de zona DNS, la información de actualización y otra información. |
Tiempo de vida de los registros de recursos
El valor período de vida (TTL) de un registro de recursos indica un período de tiempo que usan otros servidores DNS para determinar cuánto tiempo se almacena en caché la información de un registro antes de expirar y descartarla. Por ejemplo, la mayoría de los registros de recursos creados por el servicio servidor DNS heredan el TTL mínimo (predeterminado) de una hora desde el inicio del registro de recursos de autoridad (SOA), lo que impide el almacenamiento en caché extendido por otros servidores DNS.
Un solucionador de cliente DNS almacena en caché las respuestas que recibe cuando resuelve las consultas DNS. Estas respuestas almacenadas en caché se pueden usar para responder a consultas posteriores para obtener la misma información. Sin embargo, los datos almacenados en caché tienen una duración limitada especificada en el parámetro TTL devuelto con los datos de respuesta. TTL garantiza que el servidor DNS no mantenga la información durante tanto tiempo que no esté actualizada. El TTL de la caché se puede establecer en la base de datos DNS (para cada registro de recursos individual, especificando el campo TTL del registro y por zona a través del campo TTL mínimo del registro SOA) y en el solucionador de cliente DNS especificando el TTL máximo que permite almacenar en caché los registros de recursos.
Hay dos factores de competencia que se deben tener en cuenta al establecer el TTL. La primera es la precisión de la información almacenada en caché y la segunda es el uso de los servidores DNS y la cantidad de tráfico de red. Si el TTL es corto, la probabilidad de tener información antigua se reduce considerablemente, pero aumenta el uso de servidores DNS y tráfico de red, ya que el cliente DNS debe consultar los servidores DNS para los datos expirados la próxima vez que se solicite. Si el TTL es largo, las respuestas almacenadas en caché podrían quedar obsoletas, lo que significa que el solucionador podría dar respuestas falsas a las consultas. Al mismo tiempo, un TTL largo reduce el uso de servidores DNS y reduce el tráfico de red porque el cliente DNS responde a las consultas mediante sus datos almacenados en caché.
Si una consulta se responde con una entrada de la memoria caché, el TTL de la entrada también se pasa con la respuesta. De este modo, los solucionadores que reciben la respuesta saben cuánto tiempo es válida la entrada. Los solucionadores respetan el TTL del servidor de respuesta; no lo restablecen en función de su propio TTL. Por lo tanto, las entradas realmente expiran en lugar de existir a perpetuidad, moviéndose de un servidor DNS a otro con un TTL actualizado.
Nota:
En general, nunca configure el TTL en cero. La diferencia entre una configuración de 0 o 60 es mínima para la precisión del registro, pero cuando el TTL se establece en 0, hay un impacto significativo en el rendimiento del servidor DNS porque el servidor DNS está consultando constantemente para los datos expirados.
Zonas y delegación
Una base de datos DNS se puede dividir en varias zonas. Una zona es una parte de la base de datos DNS que contiene los registros de recursos con los nombres de propietario que pertenecen a la parte contigua del espacio de nombres DNS. Los archivos de zona se mantienen en servidores DNS. Un único servidor DNS se puede configurar para hospedar cero, uno o varias zonas.
Cada zona está anclada en un nombre de dominio específico denominado dominio raíz de la zona. Una zona contiene información sobre todos los nombres que terminan con el nombre de dominio raíz de la zona. Un servidor DNS se considera autoritativo para un nombre si carga la zona que contiene ese nombre. El primer registro de cualquier archivo de zona es un registro de recursos Start of Authority (SOA). El registro de recursos SOA identifica un servidor de nombres DNS principal para la zona como el mejor origen de información para los datos de esa zona. El SOA también actúa como una entidad que procesa las actualizaciones de la zona.
Un nombre dentro de una zona también se puede delegar en una zona diferente hospedada en un servidor DNS diferente. La delegación es un proceso de asignar la responsabilidad de una parte de un espacio de nombres DNS a un servidor DNS propiedad de una entidad independiente. Esta entidad independiente puede ser otra organización, departamento o grupo de trabajo dentro de su empresa. Dicha delegación se representa mediante el registro de recursos NS que especifica la zona delegada y el nombre DNS del servidor autoritativo para esa zona. La delegación en varias zonas formaba parte del objetivo de diseño original de DNS.
Para más información sobre los tipos y la replicación de zonas DNS, consulte Zonas DNS.
Entre los motivos para delegar un espacio de nombres DNS se incluyen los siguientes:
Necesidad de delegar la administración de un dominio DNS a muchas organizaciones o departamentos dentro de una organización.
Es necesario distribuir la carga de mantener una base de datos DNS grande entre varios servidores DNS para mejorar el rendimiento de la resolución de nombres y crear un entorno tolerante a errores de DNS.
Es necesario permitir la afiliación organizativa de un host mediante la inclusión del host en dominios adecuados. Los registros de recursos del servidor de nombres (NS) facilitan la delegación mediante la identificación de los servidores DNS para cada zona y los registros de recursos de NS aparecen en todas las zonas. Siempre que un servidor DNS necesite cruzar una delegación para resolver un nombre, hace referencia a los registros de recursos de NS para los servidores DNS de la zona de destino.
En la imagen siguiente se muestra cómo se delega la administración del dominio contoso.com entre las dos zonas contoso.com y mydomain.contoso.com.
Nota:
Si existen varios registros NS para una zona delegada que identifica varios servidores DNS disponibles para realizar consultas, el servicio servidor DNS de Windows Server podrá seleccionar el servidor DNS más cercano en función de los intervalos de ida y vuelta medidos a lo largo del tiempo para cada servidor DNS.
Arquitectura del servicio DNS
En el diagrama siguiente se muestra la arquitectura del servicio cliente DNS en sus operaciones de resolución de nombres y actualización en el cliente de Windows y Windows Server. La arquitectura de resolución de nombres se muestra mediante una aplicación cliente y las actualizaciones se representan mediante el cliente DHCP.
En el diagrama siguiente se muestra la arquitectura del servicio servidor DNS con sus herramientas de administración y la interfaz de Instrumental de administración de Windows (WMI) en Windows Server.
En las secciones siguientes se describe el proceso de consulta DNS y cómo se controlan las actualizaciones de DNS.
Consultas DNS
Las consultas DNS se pueden enviar desde un cliente DNS (solucionador) a un servidor DNS o entre dos servidores DNS.
Una consulta DNS es simplemente una solicitud para los registros de recursos DNS de un tipo de registro de recursos especificado con un nombre DNS especificado. Por ejemplo, una consulta DNS puede solicitar todos los registros de recursos de tipo A (host) con un nombre DNS especificado.
Hay dos tipos de consultas DNS que se pueden enviar a un servidor DNS:
Recursivo: una consulta recursiva obliga a un servidor DNS a responder a una solicitud con un error o una respuesta correcta. Normalmente, los clientes DNS (solucionadores) realizan consultas recursivas. Con una consulta recursiva, el servidor DNS debe ponerse en contacto con cualquier otro servidor DNS que necesite para resolver la solicitud. Cuando recibe una respuesta correcta del otro servidor DNS (o servidores), envía una respuesta al cliente DNS. La consulta recursiva es el tipo de consulta típico que usa un solucionador que consulta un servidor DNS y un servidor DNS que consulta su reenviador, que es otro servidor DNS configurado para controlar las solicitudes reenviadas a él.
Cuando un servidor DNS procesa una consulta recursiva y la consulta no se puede resolver desde datos locales (archivos de zona local o caché de consultas anteriores), la consulta recursiva se debe escalar a un servidor DNS raíz. Cada implementación basada en estándares de DNS incluye un archivo de caché (o sugerencias de servidor raíz) que contiene entradas para los servidores DNS raíz de los dominios de Internet. (Si el servidor DNS está configurado con un reenviador, el reenviador se usa antes de usar un servidor raíz).
Iterativo: una consulta iterativa es una en la que se espera que el servidor DNS responda con la mejor información local que tiene, en función de lo que el servidor DNS conoce de los archivos de zona local o del almacenamiento en caché. Esta respuesta también se conoce como referencia si el servidor DNS no es autoritativo para el nombre. Si un servidor DNS no tiene ninguna información local que pueda responder a la consulta, simplemente envía una respuesta negativa. Un servidor DNS realiza este tipo de consulta, ya que intenta buscar nombres fuera de su dominio local (o dominios) (cuando no está configurado con un reenviador). Es posible que tenga que consultar servidores DNS externos en un intento de resolver el nombre.
En la ilustración siguiente se muestra un ejemplo de ambos tipos de consultas.
En el diagrama se muestra cómo se usaron varias consultas para determinar la dirección IP de www.contoso.com. La secuencia de consultas se describe de la manera siguiente:
Consulta recursiva para
www.contoso.com(registro de recursos tipo A).Consulta iterativa para
www.contoso.com(un registro de recursos).Se ha omitido la referencia al servidor de nombres
.com(registros de recursos NS para.com); por simplicidad, se han omitido las consultas iterativas tipo A realizadas por el servidor DNS para resolver las direcciones IP de los nombres de host del servidor de nombres que son devueltos por otros servidores DNS.Consulta iterativa para
www.contoso.com(un registro de recursos).Referencia al servidor de nombres
contoso.com(registro de recursos del servidor de nombres (NS), paracontoso.com).Consulta iterativa para
www.contoso.com(un registro de recursos).Respuesta a la consulta iterativa del servidor de contoso.com (la dirección IP
www.contoso.com).Respuesta a la consulta recursiva original del servidor DNS local al resolutor (la dirección IP
www.contoso.com).
Actualización de DNS
Los registros de recursos suelen cambiar a medida que los equipos, los servidores y los dispositivos se agregan o quitan de la red. La implementación de DNS en Windows Server admite actualizaciones estáticas y dinámicas de la base de datos DNS.
Los registros de recursos se pueden agregar a una zona existente mediante el comando Add-DNSServerResourceRecord de PowerShell. Algunos tipos de registro de recursos comunes tienen otros comandos de PowerShell en los que no es necesario especificar el tipo de registro de recursos. También puede agregar registros de recursos mediante la consola del Administrador de DNS. Consulte Administración de registros de recursos DNS para obtener instrucciones sobre cómo trabajar con registros de recursos, incluida la creación y modificación de registros de recursos existentes de todos los tipos.
Compatibilidad con caracteres Unicode
Cuando se introdujo DNS como parte de RFC 1035, los nombres se limitaban al uso de letras mayúsculas y minúsculas (A-Z, a-z), números (0-9) y guiones (-). Además, el primer carácter del nombre DNS puede ser un número y los nombres deben codificarse y representarse mediante caracteres basados en US-ASCII. Para el uso de DNS en la configuración internacional, este requisito crea limitaciones significativas en las que se usan conjuntos de caracteres extendidos para los estándares de nomenclatura local. El servicio DNS de Windows Server proporciona compatibilidad mejorada, más allá de la especificación RFC 1035, para caracteres UTF-8.
¿Qué es UTF-8?
UTF-8 es el juego de caracteres recomendado para los protocolos que evolucionan más allá del uso de ASCII. El protocolo UTF-8 proporciona compatibilidad con caracteres ASCII extendidos y la traducción de UCS-2, un juego de caracteres Unicode de 16 bits que abarca la mayoría de los sistemas de escritura del mundo. UTF-8 permite un intervalo mucho mayor de nombres que se puede lograr mediante la codificación ASCII o ASCII extendida para los datos de caracteres.
Los equipos que ejecutan Windows Server 2008 son compatibles con UTF-8. Lo que significa que cuando el servidor recibe o usa caracteres con codificación UTF-8, el servidor puede cargar y almacenar estos datos en sus zonas. Aunque los servidores DNS basados en Windows son compatibles con UTF-8, siguen siendo compatibles con otros servidores DNS que usan la codificación de datos tradicional US-ASCII y los estándares DNS actuales.
Cómo implementa el servicio DNS UTF-8
Para proporcionar compatibilidad e interoperabilidad de estándares con otras implementaciones de DNS, el servicio DNS usa una reducción uniforme de los datos de caracteres recibidos. En este proceso, el servicio DNS convierte todos los caracteres en mayúsculas usados en datos estándar US-ASCII a datos equivalentes en minúsculas por los siguientes motivos:
- Para mantener la compatibilidad con los estándares DNS actuales y existentes.
- Para proporcionar interoperabilidad con implementaciones de servidor DNS que no reconocen ni admiten codificación UTF-8.
Para comprender por qué se eligió la reducción uniforme, primero se deben tener en cuenta varios puntos relacionados a partir de los estándares de Internet revisados actuales para DNS. Varios puntos clave de los estándares se refieren directamente a cómo se deben controlar los datos de caracteres entre los servidores DNS y otros servidores y clientes. Entre los puntos clave se incluyen:
- Cualquier cadena binaria se puede usar en un nombre DNS. (RFC 2181)
- Los servidores DNS deben poder comparar nombres de una manera que no distingue mayúsculas de minúsculas. (RFC 1035)
- El caso original de los datos de caracteres debe conservarse siempre que sea posible, ya que los datos se introducen en el sistema. (RFC 1035)
Dado que la insensibilidad de mayúsculas y minúsculas es una parte necesaria del estándar DNS principal y la conservación de mayúsculas y minúsculas es una recomendación opcional, se eligió la reducción uniforme para proporcionar una solución eficaz compatible con los estándares. Al reducir los nombres codificados con UTF-8 antes de la transmisión, otros servidores DNS (que no son compatibles con UTF-8) pueden recibir y realizar comparaciones binarias correctas de los datos y obtener los resultados deseados.
Consideraciones para la interoperabilidad con UTF-8
El servicio servidor DNS se puede establecer para permitir o bloquear el uso de caracteres UTF-8 para cada servidor. Algunos servidores DNS que no admiten UTF-8 podrían aceptar zonas con nombres UTF-8, pero podrían tener problemas para guardar o volver a cargar esos nombres. Tenga cuidado al transferir zonas con nombres UTF-8 a servidores que no admiten UTF-8.
Algunos protocolos aplican restricciones a los caracteres permitidos en un nombre. Además, los nombres destinados a ser visibles globalmente (RFC 1958) deben contener caracteres solo ASCII, como se recomienda en RFC 1123.
El uso de UTF-8 para transformar caracteres Unicode es invisible para los usuarios. Sin embargo, puede ver caracteres codificados UTF-8 si usa Network Monitor o una herramienta similar para analizar el tráfico DNS.
Además de la compatibilidad del servidor DNS con el formato de codificación UTF-8, el solucionador de cliente usa el formato de codificación de caracteres UTF-8.
Los nombres codificados en formato UTF-8 no deben superar los límites de tamaño aclarados en RFC 2181, que especifica un máximo de 63 octetos por etiqueta y 255 octetos por nombre. El recuento de caracteres no es suficiente para determinar el tamaño porque algunos caracteres UTF-8 superan un octeto de longitud.
El protocolo de codificación UTF-8 se adapta para su uso con implementaciones de protocolo DNS existentes que esperan US-ASCII caracteres debido a que la representación de US-ASCII caracteres en UTF-8 es idéntica, byte para byte, a la representación US-ASCII. Las implementaciones de servidor o cliente DNS que no reconocen caracteres UTF-8 siempre codifican nombres en el formato US-ASCII. El servicio servidor DNS puede interpretar correctamente esos nombres.
El servicio DNS puede configurar la comprobación de nombres para permitir o restringir el uso de caracteres UTF-8 en datos DNS.
De forma predeterminada, se usa la comprobación de nombres UTF-8 multibyte, lo que permite la mayor tolerancia cuando el servicio DNS procesa caracteres. La comprobación de nombres UTF-8 multibyte es el método preferido de comprobación de nombres para la mayoría de los servidores DNS operados de forma privada que no proporcionan servicio de nombres para hosts de Internet.