DNS acaba de comenzar a resolver mis direcciones server.prod a 127.0.53.53

Tengo servidores nombrados como server.prod.example.com, y regularmente inicio sesión en ellos como server.prod. Recientemente, estos nombres de host comenzaron a resolverse a 127.0.53.53.

Resulta que ICANN recientemente habilitó el .prodTLD. Además, cada solicitud que se dirige a los .prodservidores de nombres se resuelve en 127.0.53.53 en lugar de regresar como NXDOMAIN, lo que permitiría que la resolución continúe funcionando correctamente. (Supongo que el punto detrás de esto es hacer que las personas sepan que sus cosas empeorarán antes de que comiencen a resolver algo real).

¿Cómo puedo evitar tener que escribir mi nombre de dominio para cada host como este?

¿Esto todavía te muerde ocasionalmente? No pude encontrar una lista de nuevos TLD y cuando se agregaron, así que configuré uno yo mismo: https://twitter.com/newgtldannounce

domain-name-system tld

— wfaulk
fuente

Este cambio de ICANN también sirve como un buen recordatorio de que dejar que sus aplicaciones usen rutas de búsqueda es malo. Si bien esta pregunta definitivamente tiene mérito para cuando la entrada de un usuario da como resultado este comportamiento, es mejor que sus aplicaciones usen entradas de archivos host o FQDN con sufijo de punto. Pocos se dan cuenta de que glibc no pasará al siguiente servidor hasta que se haya agotado el tiempo de intentar cada sufijo de búsqueda definido.

— Andrew B

¿Puedo tomarme un momento para recordarles a todos que .prodes un TLD estúpido ? :(

— Lightness compite con Monica el

Su pregunta respondió la pregunta que iba a hacer, diciendo "ICANN recientemente habilitó el <whatever> TLD". Resulta que estaba usando .haus para mi LAN y comencé a obtener estos: D Gracias por preguntar / responder :)

— Arno Teigseth

@LightnessRacesinOrbit .prod es uno de los muchos TLD nuevos de Google. Culpalos a ellos.

— Michael Hampton

@LightnessRacesinOrbit puede ser estúpido si lo miras de esa manera, pero al mismo tiempo no es bueno depender de listas de búsqueda o usar nombres no registrados globalmente, ya que llegarás a colisiones.

— Patrick Mevzek

Respuestas:

Cuando vea que los dominios internos de repente se resuelven 127.0.53.53, tiene una colisión de nombres e ICANN está tratando de decirle que necesita urgentemente corregir su configuración de DNS.
Si devuelve NXDOMAIN como sugirió, está en lo cierto, continuaría funcionando, por ahora .

También filtraría su consulta DNS internamente intencionada a terceros.

Peor aún, en el futuro alguien podría registrarse server.prody causarle muchos más problemas.

Consulte aquí para obtener más información https://icann.org/namecollision o ejecute:

$ dig -t TXT server.prod +short
"Your DNS configuration needs immediate attention see https://icann.org/namecollision"

En cuanto a cómo resolver esto: Depende del caso de uso, probablemente solo los agregaría .ssh/configcon los nombres cortos. O comience a usar los FQDN realmente.

— falsificador
fuente

@MichaelHampton no realmente, recomiendo el capítulo 5.3:; Train users and system administrators in using FQDNs)

— falso el

Sí, porque realmente quiero, 20 veces al día, escribir en ssh db.myreallylongdomainnamethatsomeassholefrommarketingpicked.comlugar de ssh db.

— wfaulk

@wfaulk: ¿Por qué sería una "broma"? Si no le gusta la escritura excesiva, ¿por qué está evitando obsesivamente el mejor mecanismo para permitir la interacción con una computadora que evita la escritura excesiva? Algunos de ustedes, nerds de Unix, son simplemente chiflados.

— Lightness compite con Mónica el

@Ligereza Generalmente porque tendemos a gravitar hacia los anfitriones del bastión. Nuestros señores corporativos son cada vez menos propensos a permitir que sus trabajadores ejecuten un Unix en sus dispositivos emitidos por la empresa a medida que pasan los años, y las horas de trabajo ahorradas al tener acceso a los scripts de shell desde nuestro punto de acceso superan fácilmente cualquier cosa que una GUI tenga para ofrecer. . Las consolas GUI y de texto tienen su parte de malos hábitos asociados con ellas. : P

— Andrew B

Este no es el lugar para tener una discusión de GUI vs CLI. Propuse una solución, puede que no sea la mejor para todos y eso es todo lo que hay que decir.

— falsificador

Si escribe un nombre de host sin puntos, los solucionadores de DNS intentan buscar ese nombre de host agregando primero los dominios de búsqueda configurados.

Para la mayoría de los solucionadores, si usa un nombre de host con al menos un punto, el solucionador primero prueba el nombre de host por sí mismo y vuelve a agregar los dominios de búsqueda configurados.

Muchos resolutores tienen la capacidad de cambiar su comportamiento para que agreguen los dominios de búsqueda de nombres de host con puntos. Esto a menudo es a través de una opción llamada " ndots" que le dice al resolutor cuántos puntos debe tener el nombre de host antes de intentar buscar el nombre de host por sí solo primero. Para hacer el server.prodtrabajo, agregue esta línea a su resolv.conf:

options ndots:2

Si desea también poder resolver server.subzone.prod, deberá establecer la opción en 3, etc.

Si alguien sabe cómo hacer que esto funcione en MacOS X, hágamelo saber; el cambio /etc/resolv.confestá documentado para no funcionar (y no funciona) y no puedo entender los scutilencantamientos correctos .

(Nota: estoy cubriendo mis apuestas aquí más de lo que probablemente esté garantizado. Creo que la ndotsopción funcionará en el 99% de los sistemas Unix (no MacOSX)).

— wfaulk
fuente

Estás confundiendo la biblioteca de resolución del sistema operativo con BIND. /etc/resolv.confes propiedad del sistema operativo. :)

— Andrew B

La mayoría, si no todos, los solucionadores del sistema operativo Unix se extraen directamente de las bibliotecas de resolución de BIND, si no se usan directamente. Mi punto al llamar a BIND es que es posible que exista algún sistema operativo que use algo diferente que no responda a la opción "ndots".

— wfaulk

Es más probable que una declaración de este tipo induzca a error a la gente a pensar que el solucionador implementado por la biblioteca estándar C tiene una dependencia de las bibliotecas proporcionadas por ISC. En el caso de glibc, ciertamente no lo hace .

— Andrew B

Lo suficientemente justo. Se corrigió para intentar incorporar que puede no funcionar mientras no se hace referencia a BIND.

— wfaulk

Otras respuestas le dieron la solución técnica para el problema. Pero nadie respondió a tu:

No pude encontrar una lista de nuevos TLD y cuándo se agregaron

Asi que aqui esta.

Tienes varias formas.

Visite el sitio web de la IANA en: https://www.iana.org/domains/root/db ; verá la lista actual de TLD delegados, que son los que resuelven y están en la zona raíz. Si hace clic en cualquiera de ellos, en la parte inferior obtendrá una fecha que le indicará cuándo aparecieron
Esa misma información exacta está disponible whois, por ejemplo, en su caso whois -h whois.iana.org prod | grep createdle darácreated: 2014-08-23
Hay varios bots en Twitter / Mastodon que publican cuando el contenido de la IANA cambia, consulte, por ejemplo, https://twitter.com/ianawhois o https://twitter.com/rootchanges
Los datos de la IANA pueden estar un poco atrasados en la actualización, por lo que la base de datos canónica para gTLD y para ver en qué etapa se encuentran (ahora es un poco discutible ya que la ronda 2012 de ICANN de introducción de nuevos gTLD está casi terminada, pero las nuevas rondas lo harán llegar), está aquí: https://gtldresult.icann.org/application-result/applicationstatus ; Puedes buscar por TLD. Todos los gTLD también tienen un período de inicio específico, por lo que encontrará datos aquí: https://newgtlds.icann.org/en/program-status/sunrise-claims-periods puede exportar todos los datos.
También puede usar los datos de ICANN en JSON: https://www.icann.org/resources/registries/gtlds/v2/gtlds.json

— Patrick Mevzek
fuente