DNS: sottodomini che richiedono sia un record MX sia un CNAME

17

Diciamo che possediamo la zona mywebservice.com.

Vorrei che ciascuno dei miei clienti ottenesse il proprio sottodominio, come customer.mywebservice.com.

customer.mywebservice.com deve essere un CNAME per un determinato server fuori sede. Poiché tale sito gestisce le proprie apparecchiature e può cambiare indirizzo in qualsiasi momento, CNAME è un requisito.

Le persone devono anche essere in grado di inviare e-mail a inbox@customer.mywebservice.com, che richiederebbe un semplice record MX.

Tuttavia, ed è qui che vorrei una guida:

Secondo 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.

Ho anche verificato che il mio server DNS rifiuterà di servire qualsiasi cosa tranne un CNAME per gli host che li usano.

Quindi, sembra che potrei avere una situazione perdente. Se voglio usare il record MX, devo usare una A invece di un CNAME.

Qualcuno può pensare a soluzioni alternative? Grazie!

domain-name-system cname-record mx-record

— Michael Gorsuch
fonte

20

Sfortunatamente, quello che stai incontrando è una limitazione delle specifiche DNS. Avere un record MX per lo stesso nome host definito come record CNAME fallirà nella maggior parte delle implementazioni del server DNS. Alcuni server DNS meno recenti lo consentiranno, ma sono stati in gran parte eliminati a favore di implementazioni più recenti e più sicure.

Invece di utilizzare i record CNAME, dovrai utilizzare i record "A" con gli indirizzi IP dei siti dei clienti direttamente anziché alias dei nomi.

— Justin Scott
fonte

Sì, immagino che ho intenzione di affrontare questo. Grazie!

— Michael Gorsuch,

2

Vorrei anche notare, per coloro che leggono questo articolo, che la ragione di questa limitazione è che un CNAME dovrebbe fare riferimento al "nome canonico" per l'host che viene cercato. Ad esempio, se hai un host, x2.example.com che è un record CNAME che punta a x1.example.com, qualsiasi risolutore che cerca x2 dovrebbe vedere CNAME, sostituire tutto ciò che sta facendo per x2 con x1 e ricominciare . Se tu avessi un record MX per x2 oltre al CNAME, allora se x1 avesse anche un MX c'è una possibilità che sarebbero diversi, il che è indesiderabile, quindi semplicemente non lo permettono.

— Justin Scott,

18

Dopo tanto lavoro e ricerche qui, ho trovato una soluzione accettabile. Innanzitutto, è importante seguire tutti gli RFC. Ho corretto il mio server DNS per violare la RFC e ho scoperto che molti altri server DNS non avrebbero rispettato la modifica.

La mossa appropriata è mettere l'MX sull'host a cui punta il CNAME. Quindi, se customer.mywebservice.com è un CNAME di A record loadbalancer.mywebservice.com, è corretto creare anche un record MX per loadbalancer.mywebservice.com. Ho verificato che funziona con tutti i principali resolver.

Se viene effettuata una query MX per customer.mywebservice.com, la libreria del resolver seguirà il CNAME e otterrà il MX corretto per il record A finale. Evviva!

— Michael Gorsuch
fonte

4

customer.mywebservice.com deve essere un CNAME per un determinato server fuori sede. Poiché tale sito gestisce le proprie apparecchiature e può cambiare indirizzo in qualsiasi momento, CNAME è un requisito.

Qualcuno può pensare a qualche soluzione alternativa? Grazie!

Hai l'obbligo che i clienti debbano essere in grado di cambiare l'indirizzo, hai preso in considerazione la possibilità di consentire al cliente di aggiornare dinamicamente il proprio record? Con DNS dinamico è possibile utilizzare il record A e il cliente può modificare il record secondo necessità. Ci vorrebbe un po 'di lavoro, ma è possibile ogni singolo sottodominio come zona separata in modo da poter assicurarsi che un cliente possa toccare solo la propria zona.

Non l'ho provato ma gnudip sembra essere uno strumento open source per facilitare gli aggiornamenti dinamici senza dover gestire l'autenticazione e impostare molte zone sul server DNS.

— Zoredache
fonte

3

Se i tuoi record MX saranno gli stessi per tutti questi record, potresti provare a utilizzare un DNAME per reindirizzare XYZ.mywebservice.com a hosting.mywebservice.com. Sotto hosting.mywebservice.com aggiungi i tuoi record MX e A relavent.

Devo dire che non ho mai utilizzato i record DNAME in produzione, ma puoi leggere di più su di essi in RFC2672 .

— Doug Luxem
fonte

Volevo provare a utilizzare DNAME con alcuni dei nostri domini SSL, ma ho sentito che ci sono ancora problemi con i server DNS più vecchi, ecc. È rilevante? O DNAME è sicuro da usare sui server di produzione?

— drybjed

Se dovessi indovinare, molte applicazioni non si aspettano record DNAME e probabilmente si rompono quando li usano. Tutti i server di posta seguono i DNAME per cercare i record MX? Non lo so, ma dovrebbero. Per il tuo problema SSL, i server DNS che non comprendono DNAME dovrebbero invece ricevere un riferimento CNAME. Lo testerei accuratamente prima di implementarlo.

— Doug Luxem,

L'applicazione NON deve certo elaborare i record DNAME! Viene eseguito solo nei server dei nomi.

— Bortzmeyer,

3

L'RHS di customer.mywebservice.com CNAME ha una voce MX?

In tal caso, il server di posta utilizzerà tale MX per trovare il server di posta da utilizzare. Spero che tu possa controllarlo.

— MikeyB
fonte

1

La risposta di Michael Gorsuch è ampiamente corretta, la catena CNAME -> A + MX funziona ... principalmente . Tuttavia, in alcuni MTA provoca comportamenti scorretti. Cosa ho trovato eseguendo questa soluzione su una discreta quantità di scala:

alcuni MTA rifiuteranno semplicemente di trovare il record.
altri sostituiranno erroneamente il record A dove dovrebbe essere il CNAME: cioè ho inviato la posta a "joe@foo.example.com", che CNAMES a web.example.com, che ha un MX di mail.example.com, e il MTA riscrive l'intestazione della busta come "A: joe@web.example.com".

Non è ancora chiaro quanto siano pervasivi questi problemi (google / hotmail / yahoo / ecc. Tutti sembrano affrontarli correttamente), ma sicuramente ci stanno cercando soluzioni migliori.

— Osheroff
fonte

2

Questo è corretto; il comportamento documentato per i server SMTP conformi a RFC5321 è innanzitutto verificare l'esistenza di un record MX per il dominio e, in caso contrario, verificare l'esistenza di un record A. Questo comportamento è il vero motivo tecnico per cui MX non dovrebbe essere un CNAME: smetterà di risolversi dopo la prima risposta utilizzabile.

— adattamento

0

Una soluzione possibile e valida sarebbe quella di creare un nome host di base per tutti i tuoi clienti e impostarlo sul record a e aaaa del server web off-site e del tuo mx, quindi CNAME tutto il dominio dei tuoi clienti su quel singolo nome host. In questo modo dovrai solo cambiare un record quando cambia l'indirizzo IP del sito esterno.

È l'unico modo di valutare e possibile, poiché CNAME è un alias per un set completo di record, non solo a.

— Bachsau
fonte

-4

MX e CNAME sono record completamente separati: il primo determina il server di posta per un determinato dominio, il secondo fornisce l'indirizzo per un dominio. Questo dovrebbe funzionare:

@ 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.
mail server MX 10 cliente.

— drybjed
fonte

4

Potrebbe funzionare, ma viola RFC1034 e RFC1219, in cui si afferma che nessun altro record di risorse può avere lo stesso nome di un CNAME.

— Doug Luxem,

Il mio demone DNS è rigoroso RFC, che semplicemente rifiuta di inviare la risposta per MX. Credo che ci siano alcuni potenziali problemi di memorizzazione nella cache sul lato client se dovessimo metterlo in atto.

— Michael Gorsuch,

Quale demone DNS? Sto usando BIND9 che dovrebbe funzionare con quella configurazione senza problemi. Forse è il momento di aggiornare? Grande infrastruttura, presumo?

— drybjed

Sto usando MyDNS. È una configurazione abbastanza grande, e questo piccolo demone è stato una benedizione fino a questo punto. Sto pensando di rattopparlo, ma non sono molto interessato a gestire gli effetti collaterali che danno alla luce. Se va contro la RFC, sembra una cattiva idea.

— Michael Gorsuch,

@Maciej - certo, il tuo server autorevole potrebbe essere in grado di ospitare questi record. Confonderanno la maggior parte dei server ricorsivi che li interrogano.

— Alnitak,