¿Existe un límite oficial para la indirección del servidor de nombres?

Los registros de pegamento generalmente no están disponibles si un dominio y su servidor de nombres no comparten un TLD, y técnicamente no son necesarios si no comparten el mismo dominio de segundo nivel, lo que podría llevar a pasos adicionales para resolver un dominio. El solucionador primero debe buscar la dirección del servidor de nombres antes de que pueda encontrar la dirección de su dominio. Pero, en teoría, podría agregar más pasos allí que solo esos dos.

La pregunta aquí es, ¿cuánto tiempo puede durar esa cadena ?

if xyz.comusa nameserver ns1.xyz.info,
y xyz.infousa nameserver ns1.xyz.co,
y xyz.cousa nameserver ns1.xyz.cc,
y xyz.ccusa nameserver ns1.xyz.co.uk, ... y así sucesivamente

... podría terminar con una cadena muy larga para que el resolutor se desenrede antes de que pueda resolver el nombre que originalmente quería.

Presumiblemente hay un límite práctico: BIND solo debería estar dispuesto a atravesar tantos enlaces, de lo contrario existe el potencial de una denegación de servicio. ¿Pero hay un límite oficial? ¿Algún número de pasos más allá de los cuales el resolutor no está oficialmente obligado a continuar?

domain-name-system rfc

— tylerl
fuente

La sección "cantidad limitada de trabajo" en tools.ietf.org/html/rfc1035#section-7.1 es lo que me viene a la mente. No es realmente específico en cuanto a cuál debería ser el límite, pero no estoy al tanto de que haya alguna regla definitiva al respecto.

— Håkan Lindqvist

Además, ¿puede dar más detalles sobre algún escenario real en el que prevea que esto sea un problema (parece muy poco probable en la práctica) o es una cuestión de naturaleza puramente académica?

— Håkan Lindqvist

@ HåkanLindqvist De hecho, estoy creando una herramienta que busca problemas en las configuraciones de DNS. Este es uno de los problemas a buscar. La pregunta es, qué tan profundo debe recurrir el sistema para buscar más problemas antes de simplemente darse por vencido.

— tylerl

@tylerl Es posible que desee echar un vistazo a github.com/dotse/dnscheck .

— Jenny D

@ JennyD sí, hay varios proyectos por ahí como ese. Pero estoy construyendo uno que con suerte da mejores detalles y es más fácil de entender. Pero gracias por señalar eso.

— tylerl

if xyz.com uses nameserver ns1.xyz.info,

En este caso, su solucionador local primero preguntará a los servidores .com(por ejemplo, a.gtld-servers.net) dónde encontrar los servidores de nombres para el dominio xyz.com. El servidor de dominio .com generalmente proporcionará registros de pegamento para las direcciones IP de los servidores de nombres para el dominio xyz.com.

p.ej:

$ dig  gmail.com @a.gtld-servers.net 

; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1.1 <<>> gmail.com @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46893
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 5
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;gmail.com.         IN  A

;; AUTHORITY SECTION:
gmail.com.      172800  IN  NS  ns2.google.com.
gmail.com.      172800  IN  NS  ns1.google.com.
gmail.com.      172800  IN  NS  ns3.google.com.
gmail.com.      172800  IN  NS  ns4.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.     172800  IN  A   216.239.34.10
ns1.google.com.     172800  IN  A   216.239.32.10
ns3.google.com.     172800  IN  A   216.239.36.10
ns4.google.com.     172800  IN  A   216.239.38.10

;; Query time: 375 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Thu Jul 10 01:10:57 EST 2014
;; MSG SIZE  rcvd: 181

En mi experiencia, su afirmación de que "los registros de Glue generalmente no están disponibles si un dominio y su servidor de nombres no comparten un TLD" simplemente no es cierto. Sin embargo, depende de los datos proporcionados por el registrador para el dominio, y sus políticas varían. Algunos requieren que se especifique la IP. Algunos lo dejan en manos del propietario del dominio. Creo que recuerdo uno en Australia que no los apoya. Si el número de registradores que se ocupan del dominio de su país es pequeño, entonces quizás esto sea cierto dentro de esa parte del espacio de dominio, pero para la red en su conjunto esto es atípico.

Ciertamente, es una buena práctica para los propietarios de dominios proporcionar registros de Glue, pero a veces la capacidad de especificar un servidor DNS por nombre sin precisar la IP se considera que proporciona flexibilidad, y muchos propietarios de dominios no entienden el problema de rendimiento que esto crea.

Si proporciona una herramienta de informes de DNS, ¿es realmente el límite absoluto de la configuración errónea que le interesa? Seguramente es más importante que informe los registros de pegamento faltantes como una advertencia si incluso uno de esos problemas de registros de pegamento faltantes se presenta. Probablemente desee rastrear al menos algunas indirectas como las que proporciona (e informar sobre sus registros de pegamento faltantes), pero debe haber algunos límites sobre qué tan lejos debe seguir esto. Estaría bastante contento si una herramienta de informes DNS advirtiera de los primeros 3 más o menos, ya que solo estaría realmente interesado en agregar los registros de pegamento a mi dominio o cambiar el proveedor de DNS para el dominio a uno que sea más competente.

Dudo de su propuesta de DOS en BIND, ya que BIND almacenará en caché la información que recopila sobre la ubicación de los servidores de nombres. Un atacante tendría que configurar muchos dominios sin pegamento y luego hacer muchas consultas sobre ellos. El costo de configurar dominios que probablemente el registrador cancelaría después de su uso probablemente haga que esto sea poco atractivo para un atacante.

— mc0e
fuente

.com y .net son ambos verisign. Ellos son la excepción. en.m.wikipedia.org/wiki/Verisign

— tylerl

Las 'excepciones' parecen cubrir la mayoría de los TLD con los que he trabajado, pero sí, ciertamente hay dominios donde los registros de pegamento no están presentes.

— mc0e