Cuando registro un nuevo dominio, lo envío a mi proveedor de alojamiento asignándole sus servidores de nombres de dominio en la configuración del registro. Por ejemplo, con Digital Ocean, ingreso lo siguiente:
ns1.digitalocean.com
ns2.digitalocean.com
ns3.digitalocean.com
Luego agrego la configuración de dominio en el registro A de mi servidor. Se me ocurrió que cualquier otra persona en el mismo proveedor de alojamiento puede agregar un registro A con un dominio que poseo.
¿Hay algo que impida que esto ocurra? si 2 servidores diferentes que usan el mismo servidor de nombres de dominio intentan asignarse un dominio a sí mismos a través de los registros A, ¿dónde se resolvería realmente el dominio cuando lo ingrese en el navegador? ¿Qué evita las colisiones de nombres de dominio en el mismo servidor DNS?
domain-name-system
domain-name
dns-hosting
dns-zone
a-record
Eran Galperin
fuente
fuente
Respuestas:
No importa la sección de comentarios a continuación, y tampoco le importan las respuestas anteriores en el historial de edición. Después de aproximadamente una hora de conversación con amigos (gracias @joeQwerty, @Iain y @JourneymanGeek), y algunas bromas joviales llegamos al fondo de su pregunta y de la situación en general. Perdón por la brusquedad y la incomprensión de la situación por completo al principio.
Pasemos por el proceso:
wesleyisaderp.comen, digamos, NameCheap.com.ns1.digitalocean.comyns2.digitalocean.com.wesleyisaderp.comawesleyisbetterthanyou.com.Algunos amigos y yo acabamos de jugar este escenario exacto, y sí, funciona. Si @JoeQwerty compra un dominio y lo señala a los servidores de nombres de Digital Ocean, pero ya tenía esa zona agregada a mi cuenta, entonces soy el maestro de la zona y puedo hacer con él lo que quiera.
Sin embargo, considere que alguien tendría que agregar primero la zona a su cuenta DNS, y luego tendría que apuntar sus registros NS a los servidores de nombres de ese mismo host para que ocurra cualquier cosa nefasta. Además, como propietario del dominio, puede cambiar los registros NS en cualquier momento que desee y alejar la resolución del host de la zona defectuosa.
La probabilidad de que esto suceda es un poco baja, por decir lo menos. Se dice que, estadísticamente, puedes barajar un mazo de 52 cartas y obtener un pedido que ningún otro humano ha recibido, y ningún otro humano lo hará. Creo que el mismo razonamiento existe aquí. La probabilidad de que alguien explote esto es muy baja, y existen mejores atajos, que probablemente no sucederá en la naturaleza por accidente.
Además, si posee un dominio en un registrador y resulta que alguien ha hecho una zona en un proveedor como Digital Ocean con el que colisiona, estoy seguro de que si proporciona una prueba de propiedad, le preguntarán a la persona que hizo el zona en su cuenta para eliminarlo ya que no hay razón para que exista ya que no son el propietario del nombre de dominio.
¿Pero qué hay de los registros A
La primera persona en tener una zona, por ejemplo, Digital Ocean, será la que la controle. No puede tener varias zonas idénticas en la misma infraestructura DNS. Entonces, por ejemplo, usando los nombres tontos anteriores, si tengo wesleyisaderp.com como zona en Digital Ocean, nadie más en la infraestructura DNS de Digital Ocean puede agregarlo a su cuenta.
Aquí está la parte divertida: ¡realmente he agregado wesleyisaderp.com a mi cuenta de Digital Ocean! Continúa e intenta agregarlo al tuyo. No dolerá nada.
Como resultado, no puede agregar un registro A a wesleyisaderp.com. Es todo mio.
Pero que pasa...
Como @Iain señaló a continuación, mi punto # 4 anterior es en realidad demasiado detallado. No tengo que esperar ni trazar ni planear en absoluto. Puedo crear miles de zonas en una cuenta y luego sentarme y esperar. Técnicamente. Si hago miles de dominios, y luego espero a que se registren, y luego espero que usen los hosts DNS en los que he configurado mis zonas ... ¿tal vez pueda hacer algo un poco malo? ¿Tal vez? Pero probablemente no?
Disculpas al Océano Digital y NameCheap
Tenga en cuenta que Digital Ocean y NameCheap no son únicos y no tienen nada que ver con este escenario. Este es un comportamiento normal. Son irreprensibles en todos los frentes. Los acabo de usar ya que ese fue el ejemplo dado, y son marcas muy conocidas.
fuente
Ay unMXRR con TTL muy largos, apuntando a un host que controle, y martillar servidores DNS públicos comunes (¿como el de Google, tal vez?). Una variante del envenenamiento de caché ...Además de la excelente respuesta de Wesley, me gustaría agregar que ya existe una solución para evitar esto. Se llama DNSSEC.
Los conceptos básicos son los siguientes:
wesleyisaderp.comaquí, solo porque)..com). Nuevamente, carga esto cuando inicia sesión con su propio nombre de usuario / contraseña combo, por lo que está conectado a sus dominios y no a los de otra persona.wesleyisbetterthanyou.com, sus servidores de dominio raíz .com no aceptarán sus registros porque no están firmados con la clave correcta. Si su proveedor de alojamiento de DNS es inteligente, lo comprobarán de inmediato y ni siquiera le permitirán intentar agregar registros a ese dominio a menos que tenga la clave privada correcta.(En el caso original, el que describe Wesley, el error principal sería que Digital Ocean no verificó la propiedad de un dominio antes de permitir que alguien configurara registros DNS para él. Desafortunadamente, no están solos en esto; lo sé de al menos un registrador sueco con los mismos problemas).
fuente
Estará bien siempre que reclame la propiedad del dominio en DigitalOcean (es decir, lo asocie con su cuenta) antes de decirle al registrador que use sus servidores de nombres.
Si alguien ya ha asociado su dominio con su cuenta, lo descubrirá antes de que los servidores de nombres de DigitalOcean tengan autoridad. Y si eso sucede, hable con DigitalOcean acerca de sacar a esa persona de su cuenta.
En línea con las mejores prácticas, {ns1, ns2, ns3} .DigitalOcean.com no actúan como solucionadores recursivos para dominios alojados en otros lugares. Si lo hicieran, y si los servidores alojados por DigitalOcean usaran esos servidores como solucionadores de propósito general, entonces habría un problema mucho mayor. Por todo lo que se sabe que es una mala práctica, probablemente no sea tan difícil encontrar proveedores de alojamiento que se equivoquen, lo que abre posibilidades de abuso.
fuente
Creo que este problema significa que nadie debería usar servidores de nombres (como Digital Ocean's) como sus solucionadores, ya que cualquiera puede crear un servidor de nombres para un dominio existente en ellos. La batalla por el control del dominio es irrelevante, ya que la propiedad del dominio se puede probar fácilmente, pero el hecho de que alguien pueda, por ejemplo, dirigir cualquier dominio existente que NO esté alojado en Digital Ocean, a cualquier lugar que desee.
En pocas palabras: no confíe en los servidores DNS de ningún servicio de alojamiento que no requiera una prueba de propiedad del dominio (de manera fácil y rápida, por ejemplo, mediante el método sugerido anteriormente: primero agregue un registro TXT con un cierto valor en el dominio) , esto es lo que hacen Microsoft O365 y Google, por ejemplo).
fuente