¿Por qué DNS sigue siendo difícil de aprender?

• DNS se usa desde la década de 1980, lleva más de 35 años en funcionamiento y su estructura es estable, pero a muchos programadores les toma mucho tiempo poder depurar con confianza incluso problemas básicos
• La dificultad no está tanto en la complejidad de DNS en sí, sino en que hay muchos componentes invisibles como la caché del resolver, las bibliotecas DNS locales y la conversación con los servidores de nombres autoritativos
• dig es poderoso, pero la estructura de su salida y su terminología resultan poco familiares, y funciones como +norecurse, aunque útiles, hacen que la interpretación de resultados no sea intuitiva
• Trampas comunes como negative caching, el historial de falta de soporte de TCP DNS en musl, resolvers que ignoran el TTL, el caché permanente de nginx y ndots de Kubernetes son difíciles de aprender hasta que alguien te las explica
• Para quienes usan DNS rara vez, una hoja de referencia puede ayudar, y problemas en los que experimentar da miedo pueden aliviarse con entornos seguros de prueba como Mess With DNS

---

DNS: una tecnología vieja que sigue siendo difícil

• DNS se ha usado durante más de 35 años desde la época de RFC 1034, se utiliza en todos los sitios web de Internet y, en muchos aspectos, funciona de forma parecida a como lo hacía hace 30 años
• Aun así, puede tomar mucho tiempo depurar problemas básicos como “configuré correctamente el dominio, pero no resuelve” o “los resultados DNS de dig y del navegador son distintos”
• Quienes tienen dificultades con DNS suelen atorarse en los siguientes puntos
  • No se sienten cómodos ni siquiera con cambios simples de DNS en un sitio web
  • Confunden el hecho de que los registros DNS no se empujan, sino que se jalan (pull)
  • Aunque entienden los conceptos básicos, se confunden con detalles de funcionamiento como negative caching o las diferencias entre las consultas DNS de dig y las del navegador

Resolvers y servidores de nombres invisibles

• El flujo básico al enviar una solicitud DNS desde una computadora parece sencillo
  • La computadora hace una solicitud a un servidor llamado resolver
  • El resolver revisa su caché y, si hace falta, vuelve a consultar al authoritative nameserver
• En la depuración real, muchos elementos importantes no se muestran de manera predeterminada
  • Es difícil saber qué hay dentro de la caché del resolver
  • No está claro qué biblioteca DNS local procesa la solicitud
    • Puede ser libc getaddrinfo, glibc, musl, la implementación de Apple, el propio código DNS del navegador o alguna implementación personalizada aparte
    • Cada implementación difiere un poco en configuración, forma de cachear y soporte de funciones
    • El DNS de musl no soportó TCP hasta inicios de 2023
  • La conversación entre el resolver y el authoritative nameserver no es visible
    • Si se pudiera rastrear a qué authoritative nameserver se consultó y qué respondió, sería mucho más fácil entender muchos problemas de DNS

Un enfoque para hacer visibles los sistemas ocultos

• Saber cuáles son los componentes ocultos ya ayuda muchísimo en el aprendizaje
  • Si no sabes que incluso dentro de una misma computadora pueden usarse varias bibliotecas DNS según la situación, puedes pasar mucho tiempo confundido
• Mess With DNS intenta hacer experimentos estilo fishbowl que muestren las partes normalmente invisibles
  • Permite ver parte de la conversación entre el resolver y el authoritative nameserver
• También existe un enfoque de incluir información de depuración en la respuesta DNS
  • Ya existe una función llamada Extended DNS Errors o EDE
  • Las herramientas están agregando soporte para EDE poco a poco

Pistas que dan los Extended DNS Errors

• Extended DNS Errors es una forma nueva de que un servidor DNS entregue información adicional de depuración en la respuesta
• Si consultas el dominio inexistente xjwudh.com con dig @8.8.8.8 xjwudh.com, puede aparecer un error adicional como este

; EDE: 12 (NSEC Missing): (Invalid denial of existence of xjwudh.com/a)

• Este ejemplo parece estar relacionado con DNSSEC, y lo importante es que dentro de la respuesta llega un mensaje adicional de depuración
• Para ver el ejemplo anterior, se necesitó una versión más reciente de dig

dig: poderoso, pero difícil de leer

• dig es útil para revisar el estado interno de DNS
• Si usas dig +norecurse, puedes verificar qué registros tiene en caché un resolver DNS específico
  • 8.8.8.8 parece devolver SERVFAIL si la respuesta no está en caché
  • google.com sí está en caché, así que devuelve NOERROR y un registro A
  • homestarrunner.com no está en caché y por eso devuelve SERVFAIL, pero eso no significa que no exista un registro DNS
• La salida de dig es difícil de leer si no estás familiarizado con ella
  • Encabezados como ->>HEADER<<-, flags:, OPT PSEUDOSECTION:, QUESTION SECTION: y ANSWER SECTION: resultan extraños
  • Los saltos de línea y espacios entre secciones no se sienten consistentes
  • En MSG SIZE rcvd: 47, no queda claro si hay otros campos además de rcvd
  • Hay que saber que, aunque se diga que hay 1 registro en la sección ADDITIONAL, en realidad OPT PSEUDOSECTION cumple ese papel
• La salida de dig no parece un formato diseñado deliberadamente desde el inicio, sino más bien un script que fue creciendo de forma orgánica con el tiempo

Cómo hacer más legibles las herramientas de DNS

• Sirve contar con documentación que explique la salida de dig
  • how to use dig explica la estructura de la salida de dig y cómo configurar una salida básica más corta
• También se pueden crear herramientas más amigables
  • Hay alternativas como dog, doggo y DNS lookup tool
  • Aun así, cuando necesitas funciones avanzadas como +norecurse, puede ser mejor resolverlo solo con dig
  • Reemplazar el amplio rango de funciones de dig sería un trabajo grande
• Otra opción es agregar algo como una bandera +human a la salida de dig para mostrar la misma información de manera más estructurada
  • Podrían separarse con claridad el encabezado, la consulta, la respuesta, la sección adicional, el tiempo, el servidor, el protocolo y el tamaño de la respuesta
  • No se trata de reducir la cantidad de información, sino de presentar la misma información de forma más legible
• Las versiones recientes de dig tienen un formato de salida +yaml
  • Puede sentirse más claro, pero también puede ser tan verboso que ni una respuesta DNS simple quepa completa en la pantalla

Trampas de DNS frecuentes, pero difíciles de aprender

• En DNS hay trampas relativamente comunes, pero difíciles de conocer hasta que alguien te las cuenta

• negative caching

  • Si visitas un dominio que todavía no tiene un registro DNS, el estado de “no existe” de ese registro puede quedar cacheado
  • Si ese estado se cachea durante varias horas, puede volverse muy molesto

• Diferencias en implementaciones de getaddrinfo

  • musl no soportó TCP DNS hasta inicios de 2023

• Resolvers que ignoran el TTL

  • Aunque configures el TTL de un registro DNS en 5 minutos, algunos resolvers pueden ignorarlo y cachearlo por más tiempo, como 24 horas

• Problemas de configuración de nginx

  • Si nginx se configura mal, puede cachear registros DNS para siempre

• Kubernetes ndots

  • ndots puede hacer más lento el DNS de Kubernetes

Cómo compartir y documentar las trampas

• El conocimiento sobre trampas raras es difícil de obtener, y es ineficiente que la gente tenga que redescubrir los mismos problemas una y otra vez
• Al explicar un tema, ayuda mucho señalar también las trampas comunes
  • Como ejemplo fuera de DNS, la introducción a Flexbox de Josh Comeau explica el minimum size gotcha
• También es útil que la comunidad reúna las trampas comunes en un solo lugar
  • En Bash, shellcheck es muy útil como recopilación de trampas frecuentes
• Documentar las trampas de DNS también es difícil porque los problemas que encuentra cada usuario son distintos
  • Quien configura el DNS de un dominio personal una vez cada 3 años y quien opera el DNS de un dominio con mucho tráfico pueden toparse con trampas diferentes

Uso poco frecuente y dificultad para experimentar

• Mucha gente toca DNS muy rara vez
  • Si solo manipulas DNS una vez cada 3 años, es natural que sea difícil aprenderlo
  • Una hoja de referencia para cosas como el “procedimiento para cambiar nameservers” puede ayudar
• DNS también da miedo para experimentar porque existe la presión de que puedes romper tu propio dominio
  • Mess With DNS se creó para reducir esa carga al experimentar

[GN⁺]

Opiniones de Hacker News

• No estoy de acuerdo con este artículo. Creo que DNS no es realmente difícil de aprender; simplemente poca gente se toma el tiempo de aprenderlo.
  Lo bueno de DNS es que el sistema informa su propio estado interno ante las consultas. Es fácil examinar un servidor DNS para una zona conocida y entender cómo funciona, y también hay herramientas gratuitas como dig ampliamente disponibles.
  Siempre me sorprendió que, a lo largo de mi carrera, la gente con la que trabajé recordara sobre todo mis conocimientos de DNS, porque no creo saber nada misterioso ni especial. DNS está muy bien estandarizado, las implementaciones comunes de servidores y clientes siguen el estándar con rigor, y es fácil observarlo con herramientas gratuitas. Requiere esfuerzo y tiempo, pero no es realmente difícil.

  • Como autor del artículo, quiero decir algunas cosas sobre la postura de que DNS en realidad no es difícil. Me tomó varios años sentirme completamente cómodo depurando problemas de DNS, y escribí el artículo para explicar por qué me resultó difícil.
    Antes pensaba que “¡no, en realidad es fácil!” era una forma de alentar a alguien cuando decía “es difícil de aprender”. Me gusta DNS y también creo que, en muchos aspectos, es sorprendentemente simple. Por ejemplo, en https://implement-dns.wizardzines.com se muestra cómo implementar desde cero un resolvedor DNS de juguete con código Python sencillo.
    Pero con el tiempo aprendí que “¡no, es fácil de aprender!” muchas veces se recibe más como “no es difícil, es que eres tonto” que como un “¡sí puedes!”. Cuando llevas años confundido con un tema, escuchar “en realidad es fácil” no ayuda mucho.
    Por eso ahora ya no lo digo así, y dedico mucho esfuerzo a entender por qué a la gente le resulta difícil algo en particular y a reducir esas barreras.
  • Creo que es difícil de aprender si lo vemos desde el punto de vista de las herramientas para aprender DNS.
    BIND cumple muy bien su función, pero sus archivos de configuración no son muy buenos, y el manual es largo, seco y a veces innecesariamente complejo. dig es potente, pero abrevia todo como si siguiéramos en la época de las terminales de 80 columnas. Al depurar problemas de DNS, más de una vez Wireshark me resultó mejor herramienta que dig.
    Creo que si se usara PowerDNS u otro servidor DNS moderno, sería mucho más fácil configurar un servidor DNS funcional. No conozco un buen cliente DNS moderno, así que terminé acostumbrándome a dig. Como alguien que usa la bandera --color del comando ip, me gustaría que herramientas como dig también ofrecieran una salida más moderna. Las banderas de línea de comandos ya las pondré en alias; solo quisiera que agregaran la funcionalidad.
    En serio, no hacía falta abreviar MSG SIZE rcvd: 71. flags: qr rd ra también podría haberse escrito completo. Tampoco sé qué intentan comunicar los puntos y coma al inicio de las líneas; más bien confunden.
    No es raro que la gente se confunda al aprender DNS con los materiales disponibles.
  • Dijiste “no estoy de acuerdo con este artículo”, pero parece que casi no respondes a los argumentos del texto y solo te opones al título. Además, parece que mezclas DNS es difícil con DNS es difícil de aprender.
    Si “solo requiere un poco de esfuerzo y tiempo”, ¿cuánto esfuerzo y tiempo exactamente? Varias personas en este hilo dicen que lo aprendieron implementando un servidor, que tardaron meses en entenderlo, y luego repiten “una vez que lo entiendes, es bastante fácil”. Entonces, para algo tan común y conceptualmente simple, ¿no podríamos estar de acuerdo en que en la práctica sí es difícil de aprender?
  • Si lees el artículo, ahí se explica por qué es difícil de aprender. El concepto es fácil, pero al enseñar el concepto no se incluyen todos los detalles del internet moderno.
    Por ejemplo, ¿cuáles son las reglas por las que un navegador cachea y expira entradas DNS? ¿Esas reglas son consistentes entre navegadores?
  • Creo que DNS es una de esas tecnologías de las que puedes ir recogiendo fragmentos aquí y allá durante toda tu carrera sin enfrentarlas de lleno. Si más gente hubiera tenido que tratarla directamente, parecería menos compleja de lo que parece; en la industria, ese tipo de cosas termina adquiriendo una especie de aura de misterio.

• Creo que el artículo da en el clavo. DNS en sí no es difícil, pero aprender el DNS del mundo real sí lo es. Porque gran parte de lo que ocurre entre hacer una consulta y obtener el resultado esperado está oculto.
  Antes, la forma básica de conectarse a internet era una interfaz, una puerta de enlace y un proveedor de servidores DNS. Ahora podemos estar conectados simultáneamente a varias WAN, como LTE y WiFi, y al usuario le resulta difícil saber qué ruta de resolución se usó realmente. No queda claro si fue el navegador, la interfaz estándar de la biblioteca C del sistema, un resolvedor local intermedio o un resolvedor recursivo, si hay una caché local, o si se agregan opciones especiales por defecto.
  Incluso cuando todo funciona, no puedes confiar ciegamente en que la consulta y la respuesta de una aplicación hayan seguido la misma ruta que las de otra aplicación. Tres navegadores pueden usar cada uno un método distinto, el sistema operativo comportarse de otra manera, y mDNS puede sumar una quinta opción.

• Hay un chiste que dice que en ciencias de la computación solo hay tres problemas difíciles: invalidación de caché y nombrar cosas.
  Y DNS es un sistema de caché para los nombres de las cosas.
  https://reddit.com/comments/15c2ul2/comment/jtty9dy

  • Para ser justos, DNS es uno de los casos en que nombrar cosas se hizo bien.
    Está administrado globalmente (IANA), es jerárquico, federado y fácil de modificar.

• DNS es el tipo de tecnología en la que hay una discrepancia entre lo fácil que parece y la dificultad que realmente revela
  Usamos DNS todos los días y parece muy sencillo. El lenguaje cotidiano de DNS es nombres de dominio, consultas y direcciones IP. Ese lenguaje está expuesto tal cual en el navegador, y a partir de esa exposición construimos un modelo mental de cómo funciona
  Pero por dentro hay un lenguaje completamente distinto: zonas, resolvers, autoridad delegada y ese punto raro al final de los dominios de nivel superior

  • Ese punto raro se llama raíz. Sin el punto, el nombre no está completo; con el punto, el nombre queda definido por completo. Es decir, el contexto lo es todo. Si no hay punto, el resolver puede añadir repetidamente su propio dominio o partes de él
    Por ejemplo, ambos sabemos qué significa host.example.co.uk, pero si no tiene el punto al final, el resolver podría intentar consultar host.example.co.uk.example.co.uk
    Con la configuración predeterminada de Windows, en un caso así podría intentar host.example.co.uk.example.co, host.example.co.uk.example, otra vez host.example.co.uk.example y luego host.example.co.uk., y quizá obtener un resultado. Aunque nunca he visto a Windows hacer realmente el primer intento, y este comportamiento parece diseñado para lidiar con entornos de grandes empresas donde DNS tiene un Active Directory federado y monstruoso
    Hoy en día, es bastante probable que los navegadores se escabullan hacia servidores de DNS over HTTPS(DoH) sin consentimiento del usuario y se junten con todo tipo de actores sospechosos. Las consultas DNS son datos básicos, así que a los ISP les gustaba ver a dónde iba el usuario. Los proveedores de sistemas operativos, por supuesto, también pueden enviar “telemetría”. Google no es dueño del escritorio, pero sí del navegador, así que les conviene hacer que el usuario use servidores DNS “seguros” en lugar del DNS que configuró. Gracias a estas artimañas, resolver problemas de IT se volvió mucho más emocionante que antes
    No hay que preocuparse demasiado por el punto final. Total, casi seguro que no estás usando el servidor DNS que crees estar usando. Entiendo por qué se creó DoH, y algunos usuarios comunes sí tienen motivos para usarlo. Por ejemplo, si alguien que no es profesional de IT usa un hotspot WiFi malicioso, que el navegador vuelva de forma segura a casa para hacer las consultas DNS le da cierta protección. Pero otra cuestión es si el proveedor del navegador debería poder pasar por encima de las decisiones de seguridad del endpoint del usuario
    DNS es mucho más complejo que simplemente consultar direcciones. Hoy es un asunto de dinero y, de hecho, más o menos desde el año 2000 siempre lo fue. Ahora hay muchas megacorporaciones muy tercas que quieren decidir quién se beneficia a través del usuario
  • Creo que lo difícil es la parte distribuida. Por encima del nivel atómico de cada nodo individual ocurre una enorme cantidad de magia negra, y eso genera la mayor parte de la complejidad y de la opacidad
    DNS en sí es fácil. Distribuir información sin depender de una organización es realmente complicado

• Hace unos años me di cuenta de que entendía DNS solo por fragmentos. Conocía dig(1), BIND y el concepto de nivel CS101 de cómo funciona la resolución DNS recursiva, pero me faltaba el conocimiento práctico necesario para diseñar e implementar un sistema no trivial, o para depurar uno que no funcionara
  Así que leí “DNS and BIND” casi de principio a fin, y también configuré servidores BIND reales para algunos sitios web personales de poca importancia. No fue difícil, pero sí requirió una inversión considerable de tiempo. BIND no es la respuesta correcta para muchos casos de uso, pero fue muy valioso porque muchos conceptos y términos de DNS todavía vienen de BIND
  Creo que los libros están subestimados para aprender estas cosas. Los materiales que se encuentran en la web suelen ser teoría de alto nivel, como diagramas de bloques de consultas recursivas; materiales orientados a tareas, como cómo hacer una consulta recursiva con dig; o materiales de bajo nivel, como leer el código fuente para entender la política de reintentos del cliente DNS local. Para entender cada pieza y cómo encajan, desde qué intentan lograr hasta detalles de implementación como dónde están las cachés, casi no hay reemplazo para el enfoque integral que se suele encontrar en un libro. En la web no es que no exista, pero es raro

• Conviene que toda persona de IT tenga conocimientos prácticos sobre depuración de problemas de DNS
  Históricamente, DNS ha sido una vía para vulnerabilidades de seguridad importantes, y es muy probable que lo siga siendo. Estas vulnerabilidades abren rutas de ataque hacia casi todos los demás protocolos, como SMTP. Incluso el sistema de autoridades certificadoras usado por HTTPS depende en gran medida de un protocolo que, en esencia, no es seguro. Si un banco comprara un certificado DV en lugar de OV, ¿lo notarías? Probablemente no
  Por eso, que DNS parezca difícil de aprender para quienes no tienen suficiente interés no necesariamente es algo malo. Todavía se ve gente construyendo funciones relacionadas con DNS sin dedicar tiempo a entender bien la historia de cosas como la aleatorización de puertos, el envenenamiento de caché o AXFR

  • Cualquier cosa que difunda o afirme una decisión de enrutamiento en cualquier capa de la red me parece más simple de lo que realmente es, pero potencialmente peligrosa

• Haciendo una promoción descarada de mi proyecto paralelo, el artículo decía que sería bueno que la resolución DNS tuviera un modo “debug”, y la interfaz web de ComfyDNS tiene esa función :3
  https://comfydns.com/
  La imagen de arriba que dice TRACE google.com A IN muestra esa función
  ComfyDNS también es un proyecto para rascarme una comezón personal. Me cansé de editar a mano archivos de zona de bind9 y me daba curiosidad cómo funcionaba DNS. Conocía lo superficial, pero no los detalles, así que implementé los RFC “desde cero”. Usé netty, pero no usé ninguna biblioteca DNS. Fue bastante divertido
  Si el sitio no aguanta el tráfico y se cae, disculpen. Es una app Rails que corre en el nivel gratuito de Oracle Cloud

• El chiste de siempre era que DNS combina dos de los problemas más difíciles de la informática: nombrar cosas e invalidar cachés

  • DNS tiene un contador de validez en segundos, y se puede ser bastante laxo al contar esos segundos
    No es el tipo difícil de invalidación de caché. De hecho, casi nunca hace falta “invalidar” nada
    Del lado del servidor, también está completamente permitido servir una mezcla de la versión anterior y la nueva durante un tiempo
  • No es un chiste; es cierto

• Me da la sensación de que salió otro artículo de este tipo. En los años 90, Internet era más chico y las computadoras eran mucho más lentas y menos potentes, pero aprendíamos con mucha facilidad.
  En esa época, para un ISP cosas como DNS, LDAP, SMTP, IMAP eran lo más básico de lo básico, y la gente de verdad leía documentación oficial como los RFC. Si querías operar un servidor en Internet, tenías que aprender, y con invertir algo de tiempo —es decir, tiempo pagado en el trabajo— podías hacerlo.
  La generación actual de desarrolladores y DevOps no tiene paciencia ni iniciativa, espera que le den todo masticado y copia y pega cualquier cosa de StackOverflow y blogs de poco valor. En vez de aprender los fundamentos sobre los que se construyó Internet, agarran la herramienta wrapper de moda de la semana y siguen instrucciones pésimas de un blog; luego, cuando todo se cae y le hacen perder mucho dinero a la empresa, se quejan de que es injusto. Todo porque no se tomaron el tiempo de aprender las bases de cómo funcionan realmente las cosas en Internet.
  He visto esto una y otra vez. En realidad no es tan difícil. Hay que hacer la tarea.

• No es difícil. DNS es una de las pocas tecnologías que no ha cambiado mucho, y su funcionamiento es bastante intuitivo.
  dig puede ser un poco confuso. Tiene más funciones que el viejo nslookup, pero es menos intuitivo. Por cierto, nslookup todavía funciona bien.
  Creo que una de las razones por las que la gente más joven de la industria se confunde con DNS y los protocolos centrales es que ahora demasiadas cosas “simplemente funcionan”.
  Por ejemplo, los routers WiFi de hoy “simplemente funcionan” apenas los sacas de la caja. A principios de los 2000, para configurar algo así necesitabas un ingeniero de redes que supiera de DNS, IP, Ethernet, RFC1918, protocolos reales de ruteo y muchas otras cosas, y que probablemente entendiera bien por qué lo configuraba así.
  Si crees que el DNS visto desde el cliente es confuso, prueba configurar BIND ;-)
  /queja de viejo barbón

  • A los 14 años administré de forma bastante improvisada el entorno de Active Directory de un restaurante, incluyendo correo, web y CIFS, sin entender DNS ni DHCP.
    Tendría que haber hecho que el servidor DHCP del WRT54G entregara la IP fija del controlador de dominio como servidor DNS para una resolución de nombres correcta, pero hice que todo funcionara simplemente con direcciones IP y entradas en archivos hosts. También configuré el registro MX del dominio a la IP WAN del router, y no había registro PTR. Mirando hacia atrás, es un milagro que la entrega de correo haya funcionado tan bien.
    Unos años después aprendí cómo funcionaba realmente DNS, y a mis veintipocos heredé una intranet corporativa que usaba BIND como servidor de nombres para todas las zonas de dominios externos de la empresa. Al mover esa configuración a un VPS para mejorar la confiabilidad, aprendí muchísimo sobre transferencias de zona, SOA y demás. Agradezco esa experiencia, pero hoy casi todo eso se maneja por ti, así que se volvió una actividad de bajo valor. Para bien o para mal, “IT” no se valora de la misma manera que la “ingeniería de software”.
  • Es cierto que su funcionamiento es relativamente intuitivo, pero eso es si ignoras toda clase de comportamientos raros posibles, como servidores que ignoran el TTL.
    No puedo olvidar cuando Firefox lanzó una actualización que activaba DNS-over-HTTPS por defecto. Nosotros entregábamos servidores DNS internos a las estaciones de trabajo por DHCP, y de pronto empezaron a llegar montones de “¡desapareció el correo! ¡todo está roto!”. El webmail interno y el servidor web de la intranet parecían simplemente haber desaparecido.
    Nos tomó más tiempo del necesario entender qué estaba pasando. En parte fue por la idea de “es DNS, ¿por qué se rompería de repente?”. Pero está bastante claro que Mozilla no anticipó este problema tan fácilmente previsible.
  • Lo que se mencionó aquí es apenas una pequeña parte de DNS.
    Por ejemplo, consultas thing.behind.cdn.it y yo recibo una respuesta, mientras que otra persona recibe otra respuesta distinta para el mismo nombre. Eso por sí solo es bastante evidente, pero se complica cuando alguien pregunta razonablemente: “¿pueden abrir un hueco en el firewall para thing.behind.cdn.it?”.
    Algunos servidores reenvían solicitudes, otros delegan; algunos hacen la consulta por ti y otros no. También está la magia de los dominios de búsqueda del cliente, y no hay certeza de que el cliente o la biblioteca interna de resolución respeten el TTL.
    Hay innumerables tipos de registros, y a veces un servidor te pide que vuelvas a conectarte por TCP en lugar de UDP.
    Por eso DNS es bastante complejo. Da la ilusión de ser simple porque funciona muy bien y porque la mayoría de las partes complicadas están abstraídas en cosas que “por lo general simplemente funcionan”.
  • Sobre conocer protocolos antiguos, en las últimas semanas leí Networking for System Administrators e hice y repasé muchas notas en tarjetas de Anki.
    Me sorprende cuánto más seguro me siento entendiendo redes a alto nivel, incluyendo DNS y lo que hay debajo, como ethtool y las tramas Ethernet.
    Me gusta entender las cosas desde la base; por eso en la universidad elegí ingeniería eléctrica en vez de ciencias de la computación, así que quizá no debería sorprenderme.
  • Sí, configurar BIND es difícil. Unbound/nsd son mucho más fáciles de manejar. Dicho eso, el proceso de encontrar la documentación correcta ya es en sí mismo un ejercicio molesto.
    El principio de DNS no es tan difícil si entiendes que es recursivo. Pero si quieres configurarlo pensando en seguridad, tener la infraestructura correcta y ajustar hasta el último detalle, hay mucho que aprender. Si dejamos BIND fuera de la conversación, no es tan difícil.