DNS: subdominios que requieren un registro MX y un CNAME

17

Digamos que somos dueños de la zona mywebservice.com.

Me gustaría que cada uno de mis clientes obtenga su propio subdominio, como customer.mywebservice.com.

customer.mywebservice.com debe ser un CNAME para un servidor externo. Como ese sitio administra su propio equipo y puede cambiar las direcciones en cualquier momento, el CNAME es un requisito.

Las personas también deben poder enviar un correo electrónico a [email protected], lo que requeriría un simple registro MX.

Sin embargo, y aquí es donde me gustaría un poco de orientación:

De acuerdo con RFC 1034 :

If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different.

También he verificado que mi servidor DNS se negará a servir cualquier cosa que no sea un CNAME para los hosts que los usan.

Entonces, parece que puedo tener una situación perdedora. Si quiero usar el registro MX, necesito usar una A en lugar de un CNAME.

¿Alguien puede pensar en alguna solución? ¡Gracias!

domain-name-system cname-record mx-record Michael Gorsuch
fuente

Respuestas:

20

Desafortunadamente, lo que está encontrando es una limitación de la especificación DNS. Tener un registro MX para el mismo nombre de host que se define como un registro CNAME fallará en la mayoría de las implementaciones de servidores DNS. Algunos servidores DNS más antiguos permitirán esto, pero se han eliminado en su mayoría en favor de implementaciones más nuevas y más seguras.

En lugar de usar registros CNAME, deberá usar registros 'A' con las direcciones IP de los sitios del cliente directamente en lugar de alias de los nombres.

Justin Scott
fuente
Sí, supongo que voy a enfrentarme a este. ¡Gracias!
Michael Gorsuch
2
También debo señalar, para aquellos que lean esto en el futuro, que la razón de esta limitación es que se supone que un CNAME se refiere al "nombre canónico" para el host que se busca. Por ejemplo, si tiene un host, x2.example.com que es un registro CNAME que apunta a x1.example.com, cualquier resolutor que busque x2 debería ver el CNAME, reemplazar lo que sea que esté haciendo para x2 con x1, y comenzar de nuevo . Si tenía un registro MX para x2 además del CNAME, entonces si x1 también tenía un MX, existe la posibilidad de que sean diferentes, lo que es indeseable, por lo que simplemente no lo permiten.
Justin Scott el
18

Después de mucho trabajo e investigación aquí, he encontrado una solución aceptable. Primero, es importante que todos sigamos los RFC. Parcheé mi servidor DNS para violar el RFC, y descubrí que varios otros servidores DNS importantes no respetarían el cambio.

El movimiento apropiado es colocar el MX en el host al que apunta el CNAME. Por lo tanto, si customer.mywebservice.com es un CNAME para el registro A loadbalancer.mywebservice.com, es apropiado también crear un registro MX para loadbalancer.mywebservice.com. He verificado que esto funciona con todos los principales solucionadores.

Si se realiza una consulta MX para customer.mywebservice.com, la biblioteca de resolución seguirá el CNAME y obtendrá el MX adecuado para el registro A final. ¡Hurra!

Michael Gorsuch
fuente
4

customer.mywebservice.com debe ser un CNAME para un servidor externo. Como ese sitio administra su propio equipo y puede cambiar las direcciones en cualquier momento, el CNAME es un requisito.

¿Alguien puede pensar en alguna solución? ¡Gracias!

Tiene el requisito de que los clientes deben poder cambiar la dirección, ¿ha considerado permitir que el cliente actualice dinámicamente su propio registro? Con dns dinámico, puede usar el registro A, y el cliente puede cambiar el registro según sea necesario. Tomaría un poco de trabajo, pero podría cada subdominio individual como una zona separada para asegurarse de que un cliente solo pueda tocar su propia zona.

No lo he probado, pero gnudip parece ser una herramienta de código abierto para facilitar actualizaciones dinámicas sin tener que lidiar con la autenticación y configurar muchas zonas en su servidor DNS.

Zoredache
fuente
3

Si sus registros MX serán los mismos para todos estos registros, puede intentar utilizar un DNAME para redirigir XYZ.mywebservice.com a hosting.mywebservice.com. En hosting.mywebservice.com agregue sus registros MX y A correspondientes.

Debo decir que nunca he utilizado registros DNAME en producción, pero puede leer más sobre ellos en RFC2672 .

Doug Luxem
fuente
Quería intentar usar DNAME con algunos de nuestros dominios SSL, pero escuché que todavía hay problemas con servidores DNS antiguos, etc. ¿Es esto relevante? ¿O es seguro usar DNAME en servidores de producción?
drybjed
Si tuviera que adivinar, muchas aplicaciones no esperan registros de DNAME y probablemente se rompen cuando se usan. ¿Todos los servidores de correo siguen DNAME para buscar registros MX? No lo sé, pero deberían. Para su problema SSL, los servidores DNS que no entienden DNAME deberían recibir una referencia CNAME. Lo probaría a fondo antes de implementarlo.
Doug Luxem
¡La aplicación ciertamente NO tiene que procesar registros DNAME! Se realiza solo en servidores de nombres.
bortzmeyer
3

¿El RHS del Customer.mywebservice.com CNAME tiene una entrada MX?

Si es así, el servidor de correo usará ese MX para encontrar el servidor de correo que usará. Espero que puedas controlar eso.

MikeyB
fuente
1

La respuesta de Michael Gorsuch es en gran medida correcta, la cadena CNAME -> A + MX funciona ... principalmente . Sin embargo, desencadena un mal comportamiento en ciertos MTA. Lo que encontré al ejecutar esta solución a una escala decente:

  • algunos MTA simplemente se negarán a encontrar el registro.
  • otros reemplazarán incorrectamente el registro A donde debería estar el CNAME: es decir, envié un correo a "[email protected]", que CNAMES a web.example.com, que tiene un MX de mail.example.com, y el MTA reescribe el encabezado del sobre como "Para: [email protected]".

Todavía no está claro cuán generalizados son estos problemas (google / hotmail / yahoo / etc.todos parecen tratar esto correctamente), pero ciertamente nos tienen buscando mejores soluciones.

osheroff
fuente
2
Esto es correcto; El comportamiento documentado para los servidores SMTP compatibles con RFC5321 es verificar primero la existencia de un registro MX para el dominio, y si eso falla, verificar la existencia de un registro A. Este comportamiento es la verdadera razón técnica por la cual el MX no debería ser un CNAME: dejará de resolverse después de la primera respuesta utilizable.
Adaptr
0

Una solución posible y válida sería crear un nombre de host básico para todos sus clientes y establecerlo en el registro ayaaa del servidor web externo y su mx, luego CNAME todos los dominios de sus clientes a ese único nombre de host. De esa manera, solo tendrá que cambiar un registro cuando cambie la dirección IP fuera del sitio.

Es la única forma posible y valiosa, ya que CNAME es un alias para un conjunto completo de registros, no solo un.

Bachsau
fuente
-4

MX y CNAME son registros completamente separados: el primero determina el servidor de correo para un dominio dado, el segundo proporciona la dirección de un dominio. Esto debería funcionar:

@ IN SOA ns1.mywebservice.com. root.mywebservice.com. (
                        2009060201
                        12h
                        1h
                        1w
                        8h
)

                        NS ns1.mywebservice.com.
                        NS ns2.mywebservice.com.

cliente CNAME offsite.host.
cliente MX 10 mail.server.
Drybjed
fuente
44
Eso puede funcionar, pero viola RFC1034 y RFC1219 que establecen que ningún otro registro de recursos puede tener el mismo nombre que un CNAME.
Doug Luxem
Mi demonio DNS es estricto con RFC, que simplemente se niega a enviar la respuesta para el MX. Creo que hay algunos posibles problemas de almacenamiento en caché en el lado del cliente si tuviéramos que implementar esto.
Michael Gorsuch
¿Qué demonio DNS? Estoy usando BIND9 que debería funcionar con esa configuración sin ningún problema. Tal vez es hora de actualizar? ¿Gran infraestructura, supongo?
drybjed
Estoy usando MyDNS. Es una configuración bastante grande, y este pequeño demonio ha sido una bendición hasta este momento. Estoy considerando repararlo, pero no estoy muy interesado en tratar los efectos secundarios que dan a luz. Si va en contra del RFC, parece una mala idea.
Michael Gorsuch
@Maciej: claro, su servidor autorizado podría ser capaz de alojar estos registros. Sin embargo, confundirán muchísimo a cualquier servidor recursivo que los interrogue.
Alnitak