¿Deben existir los subdominios intermedios?

Si tengo los hosts example.comy leaf.intermediate.example.comen los registros DNS para example.com, pero no tengo registros para intermediate.example.comsí mismo, ¿eso causa un problema en algunas situaciones o es un mal estilo o etiqueta por alguna razón? Tengo servidores web configurados así y todo parece funcionar bien, pero solo quería verificar si hay algo que me falta.

TL; DR: sí, deben existir subdominios intermedios, al menos cuando se consulta, según la definición del DNS; sin embargo, pueden no existir en el archivo de zona.

Una posible confusión para eliminar primero; Definición de "No terminal vacío"

Puede estar confundiendo dos cosas, como parece que también hay otras respuestas. Es decir, qué sucede cuando se consultan nombres en comparación con cómo configura su servidor de nombres y el contenido del archivo de zona.

El DNS es jerárquico. Para que exista cualquier nodo hoja, DEBEN existir todos los componentes que lo conducen, en el sentido de que si se consultan, el servidor de nombres autorizado responsable debe responder por ellos sin error.

Como se explica en RFC 8020 (que es solo una repetición de lo que siempre fue la regla, pero solo algunos proveedores de DNS necesitaban un recordatorio), si para cualquier consulta, un servidor de nombres autorizado responde NXDOMAIN (es decir: este registro de recursos no existe), entonces significa que cualquier etiqueta "debajo" de este recurso tampoco existe.

En su ejemplo, si una consulta de intermediate.example.comdevoluciones NXDOMAIN, entonces cualquier servidor de nombres recursivo adecuada responderá inmediatamente NXDOMAINpara leaf.intermediate.example.comporque no puede existir este disco si todas las etiquetas en que no existen como registros.

Esto ya se dijo en el pasado en el RFC 4592 sobre comodines (que no están relacionados aquí):

El espacio de nombre de dominio es una estructura de árbol. Los nodos en el árbol
poseen al menos un RRSet y / o tienen descendientes que poseen colectivamente
al menos un RRSet. Un nodo puede existir sin conjuntos de RRS solo si tiene
descendientes que lo tienen; este nodo es un no terminal vacío.

Un nodo sin descendientes es un nodo hoja. Los nodos de hoja vacíos no existen.

Un ejemplo práctico con nombres de dominio .US

Tomemos un ejemplo funcional de un TLD con muchas etiquetas históricamente, es decir .US. Escogiendo cualquier ejemplo en línea, usémoslo www.teh.k12.ca.us.

Por supuesto, si consulta este nombre, o incluso teh.k12.ca.uspuede recuperar Aregistros. Aquí no hay nada concluyente para nuestro propósito (incluso hay un CNAME en el medio, pero eso no nos importa):

$ dig www.teh.k12.ca.us A +short
CA02205882.schoolwires.net.
107.21.20.201
35.172.15.22
$ dig teh.k12.ca.us A +short
162.242.146.30
184.72.49.125
54.204.24.19
54.214.44.86

Vamos a consultar ahora k12.ca.us(no estoy consultando el servidor de nombres autorizado de él, pero eso no cambia el resultado de hecho):

$ dig k12.ca.us A

; <<>> DiG 9.11.5-P1-1ubuntu2.5-Ubuntu <<>> k12.ca.us A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59101
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1480
;; QUESTION SECTION:
;k12.ca.us.         IN  A

;; AUTHORITY SECTION:
us.         3587    IN  SOA a.cctld.us. hostmaster.neustar.biz. 2024847624 900 900 604800 86400

;; Query time: 115 msec
;; SERVER: 127.0.0.10#53(127.0.0.10)
;; WHEN: mer. juil. 03 01:13:20 EST 2019
;; MSG SIZE  rcvd: 104

¿Qué aprendemos de esta respuesta?

Primero, es un éxito porque el estado es NOERROR. Si hubiera sido otra cosa y específicamente NXDOMAINentonces teh.k12.ca.us, tampoco www.teh.k12.ca.uspodría existir.

En segundo lugar, la sección RESPUESTA está vacía. No hay Aregistros para k12.ca.us. Esto no es un error, este tipo ( A) no existe para este registro, pero tal vez existan otros tipos de registro para este registro o este registro sea un ENT, también conocido como "Empty Non Terminal": está vacío, pero no es una hoja, hay cosas "debajo" de él (véase la definición en RFC 7719 ), como ya sabemos (pero normalmente la resolución es de arriba hacia abajo, así que llegaremos a este paso antes de pasar un nivel por debajo y no al contrario, como lo estamos haciendo aquí para la demostración propósito).

Esta es la razón por la cual, como acceso directo, decimos que el código de estado es NODATA: este no es un código de estado real, solo significa NOERROR+ sección de RESPUESTA vacía, lo que significa que no hay datos para este tipo de registro específico, pero puede haber otros.

Puede repetir el mismo experimento para obtener el mismo resultado si consulta con la siguiente etiqueta "arriba", ese es el nombre ca.us.

Resultados de las consultas frente al contenido del archivo de zona

¿Ahora de dónde puede venir la confusión? Creo que puede provenir de una falsa idea de que cualquier punto en un nombre DNS significa que hay una delegación. Esto es falso Dicho de otra manera, su example.comarchivo de zona puede ser así, y es totalmente válido y funciona:

example.com. IN SOA ....
example.com. IN NS ....
example.com. IN NS ....

leaf.intermediate.example.com IN A 192.0.2.37

Con dicho archivo de zona, al consultar este servidor de nombres obtendrá exactamente el comportamiento observado anteriormente: una consulta para intermediate.example.comregresará NOERRORcon una respuesta vacía. No necesita crearlo específicamente en el archivo de zona (si no lo necesita por otras razones), el servidor de nombres autorizado se encargará de sintetizar las respuestas "intermedias", porque ve que necesita este no terminal vacío (y cualquier otros "intermedios" si hubiera habido otras etiquetas) como se ve el nombre de la hoja leaf.intermediate.example.com.

Tenga en cuenta que este es un caso generalizado en algunas áreas, pero es posible que no lo vea porque apunta a más registros de "infraestructura" a los que las personas no están expuestas:

• en zonas inversas como in-addr.arpo ip6.arpa, y específicamente la última. Tendrá registros como 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.1.d.e.1.6.8.0.0.0.0.0.0.2.6.2.ip6.arpa. 1h IN PTR text-lb.eqiad.wikimedia.org.y obviamente no hay una delegación en cada punto, ni registros de recursos adjuntos en cada etiqueta
• en los SRVregistros, como _nicname._tcp.fr. 12h IN SRV 0 0 43 whois.nic.fr., un dominio puede tener muchos _proto._tcp.example.comy _proto._udp.example.com SRVregistros porque, por diseño, deben tener este formulario, pero al mismo tiempo _tcp.example.comy _udp.example.compermanecerán vacíos sin terminales porque nunca se usaron como registros
• De hecho, tiene muchos otros casos de construcción específica de nombres basados ​​en "etiquetas de subrayado" para varios protocolos como DKIM. DKIM le ordena que tenga registros DNS como whatever._domainkey.example.com, pero obviamente _domainkey.example.compor sí solo nunca se usará, por lo que seguirá siendo un no terminal vacío. Esto es lo mismo para TLSAregistros en DANE (ej .:) _25._tcp.somehost.example.com. TLSA 3 1 1 BASE64==o URIregistros (ej . _ftp._tcp IN URI 10 1 "ftp://ftp1.example.com/public":)

Comportamiento del servidor de nombres y generación de respuestas intermedias

¿Por qué el servidor de nombres sintetiza automáticamente tales respuestas intermedias? El algoritmo de resolución central para el DNS, como se detalla en la sección 4.3.2 del RFC 1034, es la razón de esto, permítanos tomarlo y resumirlo en nuestro caso al consultar el nombre del servidor de nombres autorizado intermediate.example.com(este es el QNAMEsiguiente protocolo):

2. Busque en las zonas disponibles la zona que es el ancestro más cercano a QNAME. Si se encuentra dicha zona, vaya al paso 3, de lo contrario, el paso 4.

El servidor de nombres encuentra la zona example.comcomo el ancestro más cercano de QNAME, por lo que podemos ir al paso 3.

Ahora tenemos esto:

3. Comience a emparejar, etiqueta por etiqueta, en la zona. [..]

a. Si todo QNAME coincide, hemos encontrado el nodo. [..]

si. Si una coincidencia nos sacara de los datos autorizados, tenemos una referencia. Esto sucede cuando nos encontramos con un nodo con NS RR marcando cortes a lo largo de la parte inferior de una zona. [..]

do. Si en alguna etiqueta, una coincidencia es imposible (es decir, la etiqueta correspondiente no existe), observe si existe la etiqueta "*". [..]

Podemos eliminar los casos byc, porque nuestro archivo de zona no tiene delegación (por lo tanto, nunca habrá una referencia a otros servidores de nombres, ningún caso b), ni comodines (por lo que no hay caso c).

Aquí solo tenemos que tratar el caso a.

Comenzamos a emparejar, etiqueta por etiqueta, en la zona. Entonces, incluso si teníamos un sub.sub.sub.sub.sub.sub.sub.sub.example.comnombre largo , en algún momento, llegamos al caso a: no encontramos una referencia, ni un comodín, pero terminamos con el nombre final para el que queríamos un resultado.

Luego aplicamos el resto del contenido del caso a:

Si los datos en el nodo son un CNAME

No es nuestro caso, nos saltamos eso.

De lo contrario, copie todos los RR que coincidan con QTYPE en la sección de respuesta y vaya al paso 6.

Cualquiera que sea QTYPE elegimos ( A, AAAA, NS, etc.) no tenemos RR para intermediate.example.com, ya que no aparece en el fichero de zona. Entonces la copia aquí está vacía. Ahora terminamos en el paso 6:

Usando solo datos locales, intente agregar otros RR que puedan ser útiles para la sección adicional de la consulta. Salida.

No es relevante para nosotros aquí, por lo tanto, terminamos con éxito.

Esto explica exactamente el comportamiento observado: tales consultas volverán NOERRORpero tampoco datos.

Ahora, puede preguntarse a sí mismo: "pero si uso cualquier nombre, como another.example.comentonces con el algoritmo anterior, debería obtener la misma respuesta (sin error)", pero las observaciones en su lugar informarían NXDOMAINen ese caso.

¿Por qué?

Debido a que todo el algoritmo como se explicó, comienza con esto:

El siguiente algoritmo asume que los RR están organizados en varias estructuras de árbol, una para cada zona y otra para el caché

Esto significa que el archivo de zona anterior se transforma en este árbol:

+-----+
| com |  (just to show the delegation, does not exist in this nameserver)
+-----+
   |
   |
   |
+---------+
| example | SOA, NS records
+---------+
   |
   |
   |
+--------------+
| intermediate | no records
+--------------+
   |
   |
   |
+------+
| leaf | A record
+------+

Entonces, al seguir el algoritmo, desde arriba, puede encontrar una ruta: com > example > intermediate(porque la ruta com > example > intermediate > leafexiste) Pero another.example.com, después de com > exampleno encontrar la anotheretiqueta en el árbol, como nodo secundario de example. Por lo tanto, caemos en parte de la opción c desde arriba:

Si la etiqueta "*" no existe, verifique si el nombre que estamos buscando es el QNAME original en la consulta o un nombre que hemos seguido debido a un CNAME. Si el nombre es original, configure un error de nombre autorizado en la respuesta y salga. De lo contrario, solo salga.

La etiqueta *no existe, y no seguimos a CNAME, por lo tanto estamos en el caso: set an authoritative name error in the response and exitaka NXDOMAIN.

Tenga en cuenta que todo lo anterior creó confusión en el pasado. Esto se recoge en algunos RFC. Vea, por ejemplo, este lugar inesperado (la alegría de que las especificaciones DNS sean tan impenetrables) que definen comodines: RFC 4592 "El papel de los comodines en el sistema de nombres de dominio" y, en particular, su sección 2.2 "Reglas de existencia", también citada en parte al comienzo de mi respuesta pero aquí está más completa:

Los no terminales vacíos [RFC2136, sección 7.16] son ​​nombres de dominio que no poseen registros de recursos pero tienen subdominios que sí. En la sección 2.2.1,
"_tcp.host1.example". es un ejemplo de un nombre no terminal vacío.
Este texto introduce los no terminales vacíos en la sección 3.1 de RFC 1034:

# The domain name space is a tree structure.  Each node and leaf on
# the tree corresponds to a resource set (which may be empty).  The
# domain system makes no distinctions between the uses of the
# interior nodes and leaves, and this memo uses the term "node" to
# refer to both.

El paréntesis "que puede estar vacío" especifica que los no
terminales vacíos se reconocen explícitamente y que los "no terminales vacíos
" existen ".

La lectura pendiente del párrafo anterior puede conducir a una
interpretación de que existen todos los dominios posibles, hasta el
límite sugerido de 255 octetos para un nombre de dominio [RFC1035]. Por ejemplo,
www.example. puede tener un RR A, y en lo que
concierne prácticamente , es una hoja del árbol de dominio. Pero la definición se puede
tomar para significar ese sub.www.ejemplo. También existe, aunque sin datos. Por extensión, existen todos los dominios posibles, desde la raíz hacia abajo.

Como RFC 1034 también define "un error de nombre autorizado que indica que el nombre no existe" en la sección 4.3.1, aparentemente esta no es la intención de la definición original, justificando la necesidad de una definición actualizada en la siguiente sección.

Y luego la definición en la siguiente sección es el párrafo que cité al principio.

Tenga en cuenta que el RFC 8020 (en NXDOMAINrealidad se quiere decir NXDOMAIN, que es si responde NXDOMAINpara intermediate.example.com, a continuación, leaf.intermediate.example.comno puede existir) fue impuesto en parte debido a que varios proveedores de DNS no siguieron esta interpretación y que el caos creado, o no eran más que errores, véase por ejemplo éste corregido en 2013 en un código de servidor de nombres autorizado de código abierto: https://github.com/PowerDNS/pdns/issues/127

Las personas necesitaban poner contramedidas específicas solo para ellos: eso no es un almacenamiento en caché agresivo NXDOMAINporque para esos proveedores si llega NXDOMAINa algún nodo, aún puede significar que obtiene algo más que NXDOMAINotro nodo debajo de él.

Y esto hacía que la minimización de QNAME (RFC 7816) fuera imposible de obtener (consulte https://indico.dns-oarc.net/event/21/contributions/298/attachments/267/487/qname-min.pdf para obtener más detalles) , mientras se quería aumentar la privacidad. La existencia de no terminales vacíos en el caso de DNSSEC también creó problemas en el pasado, en torno al manejo de la no existencia (ver https://indico.dns-oarc.net/event/25/contributions/403/attachments/378/647 /AFNIC_OARC_Dallas.pdf si está interesado, pero realmente necesita una buena comprensión de DNSSEC antes).

Los siguientes dos mensajes dan un ejemplo de problemas que un proveedor tuvo que hacer cumplir adecuadamente esta regla en los no terminales vacíos, da una perspectiva de los problemas y por qué estamos allí:

• https://mailarchive.ietf.org/arch/msg/dnsop/XIX16DCe2ln3ZnZai723v32ZIjE
• https://lists.dns-oarc.net/pipermail/dns-operations/2019-April/018640.html

Es posible que no entienda la respuesta de Khaled, pero la falta de registros intermedios no debería ser un problema con la resolución del nombre subzonificado. Tenga en cuenta que esta salida de excavación no proviene ni está dirigida a un servidor DNS autorizado para teaparty.netninguna de sus subzonas:

[me@nand ~]$ dig very.deep.host.with.no.immediate.parents.teaparty.net
[...]
;; ANSWER SECTION:
very.deep.host.with.no.immediate.parents.teaparty.net. 3600 IN A 198.51.100.200

De hecho, deberías poder hacerlo digtú mismo y obtener esa respuesta: teaparty.netes un dominio real, bajo mi control, y realmente contiene ese Aregistro. Puede verificar que no hay registros para ninguna de esas zonas entre veryy teaparty.net, y que no tiene ningún impacto en su resolución del nombre de host anterior.

Si está consultando directamente el servidor DNS autorizado, obtendrá respuestas sin problemas.

Sin embargo, no obtendrá una respuesta válida si realiza una consulta a través de otro servidor DNS que no tiene una memoria caché válida. La consulta intermediate.example.comdará como resultado un NXDOMAINerror.

Para responder directamente a la pregunta, no, no necesita agregar registros para nombres intermedios que realmente no está utilizando, sin embargo, eso no significa que esos nombres no existan.

En cuanto a si estos nombres existen o no, esa es en realidad una pregunta completamente diferente para la que espero proporcionar una respuesta breve y bastante intuitiva.

Todo se reduce a que DNS es una estructura de árbol, donde cada etiqueta en un nombre de dominio es un nodo de árbol. Ej www.example.com.tiene las etiquetas www, example, comy `` (nodo raíz), que son los nodos del árbol que forman la trayectoria de todo el camino a la raíz.

Lo que quizás hace que esta naturaleza fundamental de DNS no sea obvia es que casi siempre cuando se administran datos de DNS no se ve ningún árbol y generalmente no trabajamos directamente con los propios nodos del árbol, en su lugar, generalmente tenemos una lista aplanada de qué registro datos que deberían existir en diferentes nombres de dominio (de hecho, rutas de árbol, como se indicó anteriormente).

Lo que sucede cuando se usa esta lista aplanada es que el software del servidor DNS construye el árbol en función de los registros existentes, y si hay espacios entre los nodos que tienen registros (por ejemplo, hay registros para foo.bar.example.com.y example.com.no bar.example.com.), estos simplemente se consideran árbol vacío. nodos Es decir, estos son nombres de dominio / nodos que de hecho existen, el árbol no está roto, estos nodos simplemente no tienen datos asociados.

En consecuencia, si consulta uno de estos nodos vacíos, recibirá una NODATArespuesta ( NOERRORestado + SOAen la sección de autoridad), diciendo que el tipo de registro solicitado no existía en este nodo. Si, en cambio, consulta algún nombre que en realidad no existe, recibirá una NXDOMAINrespuesta que dice que el nombre de dominio solicitado no existe en el árbol.

Ahora, si quieres los detalles esenciales, lee la respuesta muy detallada de Patrick Mevzek.