☰

Opción de servidor unbound.conf "dominio privado": ¿nombre de dominio que termina en un punto o no?

tag-icon • tag-icon domain-name-system debian-stretch syntax unbound
Opción de servidor unbound.conf "dominio privado": ¿nombre de dominio que termina en un punto o no?

unbound.confse utiliza para configurarSin consolidar, un solucionador de DNS de almacenamiento en caché. Eldocumentaciónde la versión 1.6.8 dice:

Server Options
    private-domain: <domain name>
        Allow this domain, and all its subdomains to contain private
        addresses. Give multiple times to allow multiple domain names
        to contain private addresses. Default is none.

Ejecutamos la versión 1.6.0 independiente con Debian Stretch (la página de manual y la documentación citada no difieren aquí).

Hemos probado las siguientes tres variantes separadas por

  • edición/etc/unbound/unbound.conf
  • comprobaciónunbound-checkconf
  • reiniciandosystemctl restart unbound.service
  • monitorear el archivo de registro independiente.

Variante 1 (termina en punto):

private-domain: domain.example.

Variante 2 (sin terminar en punto):

private-domain: domain.example

Variante 3 (en orden indicado):

private-domain: "domain.example. domain.example"

Para las tres variantes unbound-checkconfdevuelve:

unbound-checkconf: no errors in /etc/unbound/unbound.conf

En la variante 3 encontramos en el archivo de registro:

debug: ignoring duplicate private-domain: domain.example.

Tiene sentido, porque una entrada para el mismo nombre de dominio tiene que ser suficiente y parece verificar que unbound tiene un manejo idéntico para ambas formas de escribir los nombres de dominio (con/sin punto).

Ambas formas funcionan, pero ¿cuál es la sintaxis correcta para definir nombres de dominio privados sin consolidar? ¿Los nombres de dominio deberían terminar en un punto o no? ¿El punto al final es útil o no tiene sentido? ¿Qué implicaciones podría tener un punto innecesario o faltante?

Respuesta1

Esta pregunta es antigua, pero todavía me surgió como la primera entrada en una búsqueda, por lo que, en mi opinión, vale la pena intentar responderla.

En pocas palabras: en este contexto, y en la mayoría de los demás, no existe una diferencia práctica entre domain.example(sin seguimiento .) y domain.example.(con capacitación .). Por tanto, ambas son correctas.

Ahora la respuesta larga. :) Esta respuesta, y el único otro comentario aquí ahora, de 2018, procede de lo que dice la especificación, como también lo hace el comentario de 2018 al OP. Si bien puede haber diferencias semánticas entre el RFC y la forma en que Unbound usa los nombres de dominio, esto sería una desviación de la especificación y probablemente se consideraría un error.

RFC 1034 Sección 3.1define la sintaxis central de los nombres de dominio de la siguiente manera:

Cuando un usuario necesita escribir un nombre de dominio, se omite la longitud de cada etiqueta y las etiquetas están separadas por puntos (""."). Dado que un nombre de dominio completo termina con la etiqueta raíz, esto lleva a un formulario impreso que termina en un punto. Usamos esta propiedad para distinguir entre:

  • una cadena de caracteres que representa un nombre de dominio completo (a menudo llamado "absoluto"). Por ejemplo, "poneria.ISI.EDU".

  • una cadena de caracteres que representa las etiquetas iniciales de un nombre de dominio que está incompleta y debe ser completada por el software local utilizando el conocimiento del dominio local(a menudo llamado "pariente"). Por ejemplo, "poneria" usado en el dominio ISI.EDU.

Los nombres relativos se toman en relación con un origen conocido o con una lista de dominios utilizada como lista de búsqueda.

Tenga en cuenta la última frase: a menos que se defina una "lista de dominios utilizados como lista de búsqueda", los nombres sin un punto final se consideran relativos a un "origen bien conocido", es decir, la raíz de la jerarquía de nombres. Para DNS público, la raíz DNS corresponde alzona raíz; las jerarquías de nombres privados rara vez se desvían de esta convención.

A efectos prácticos, esto significa que un nombre de dominio completo (FQDN) sin final .casi siempre debe considerarse en relación con la raíz de la jerarquía de nombres, que equivale al mismo dominio "absoluto". Por lo tanto, domain.example== " domain.examplerelativo a la raíz" == domain.example..

¿Cuándo podrían tener implicaciones las diferentes representaciones? Cuando estás tratando confragmentosde un nombre de dominio en lugar de un FQDN. En ese caso, debe omitir el punto y considerar utilizar el punto en los FQDN. Si ejecuta example.com.(tenga en cuenta el punto; el servidor raíz *.example.comle envía tráfico) y desea configurarlo east.example.com.como un subdominio, eastes el subdominio; east.es el dominio de nivel superior (TLD) .east.

Nuevamente: esto es lo que dice la especificación. Consulte los documentos de la herramienta que está configurando, como siempre. También hay otras áreas de la especificación, en particular la compresión DNS, donde se introduce alguna semántica adicional. Puede ignorarlos si no está literalmente analizando o generando mensajes en el protocolo de conexión DNS.

Con suerte, eso responde completamente a la pregunta. Espero que esto sea útil para alguien.

información relacionada