DNS: poddomeny, które wymagają zarówno rekordu MX, jak i CNAME


17

Powiedzmy, że jesteśmy właścicielem strefy mywebservice.com.

Chciałbym, aby każdy z moich klientów otrzymał własną subdomenę, na przykład customer.mywebservice.com.

customer.mywebservice.com musi być nazwą CNAME dla danego serwera poza siedzibą. Ponieważ ta strona zarządza własnym sprzętem i może zmieniać adresy w dowolnym momencie, CNAME jest wymagany.

Ludzie muszą także mieć możliwość wysyłania wiadomości e-mail na adres inbox@customer.mywebservice.com, co wymagałoby zwykłego rekordu MX.

Chciałbym jednak uzyskać pewne wskazówki:

Zgodnie z 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.

Zweryfikowałem również, że mój serwer DNS odmówi serwowania czegokolwiek poza CNAME dla hostów, które ich używają.

Wygląda więc na to, że mogę stracić sytuację. Jeśli chcę użyć rekordu MX, muszę użyć A zamiast CNAME.

Czy ktoś może wymyślić jakieś obejścia? Dzięki!

Odpowiedzi:


20

Niestety, na co się natrafisz, jest ograniczenie specyfikacji DNS. Posiadanie rekordu MX dla tej samej nazwy hosta, która jest zdefiniowana jako rekord CNAME, zakończy się niepowodzeniem w większości implementacji serwera DNS. Niektóre starsze serwery DNS na to pozwolą, ale zostały one w większości wycofane na rzecz nowszych, bezpieczniejszych implementacji.

Zamiast używać rekordów CNAME, będziesz musiał użyć rekordów „A” z adresami IP witryn klientów bezpośrednio, zamiast aliasu nazw.


Tak, chyba zamierzam stawić temu czoła. Dzięki!
Michael Gorsuch,

2
Powinienem również zauważyć, dla tych, którzy czytają to w dalszej części drogi, że powodem tego ograniczenia jest to, że CNAME ma odnosić się do „nazwy kanonicznej” dla gospodarza, który jest przeglądany. Na przykład, jeśli masz hosta x2.przyklad.com, który jest rekordem CNAME wskazującym na x1.przyklad.com, to każdy resolver szukający x2 powinien zobaczyć CNAME, zastąpić wszystko, co robi dla x2, x1 i zacząć od nowa . Jeśli miałeś rekord MX dla x2 oprócz CNAME, to jeśli x1 miałby również MX, istnieje szansa, że ​​byłyby inne, co jest niepożądane, więc po prostu nie pozwalają.
Justin Scott

18

Po wielu pracach i badaniach tutaj znalazłem akceptowalne rozwiązanie. Po pierwsze, ważne jest, abyśmy wszyscy przestrzegali RFC. Połączyłem mój serwer DNS, aby naruszyć RFC, i odkryłem, że kilka innych głównych serwerów DNS nie przestrzega tej zmiany.

Właściwym posunięciem jest umieszczenie MX na hoście, na który wskazuje CNAME. Jeśli więc customer.mywebservice.com jest nazwą CNAME dla rekordu loadbalancer.mywebservice.com A, należy również utworzyć rekord MX dla loadbalancer.mywebservice.com. Sprawdziłem, że działa to ze wszystkimi głównymi programami rozstrzygającymi.

Jeśli zostanie wykonane zapytanie MX dla customer.mywebservice.com, biblioteka resolverów podąży za CNAME i otrzyma właściwe MX dla końcowego rekordu A. Hurra!


4

customer.mywebservice.com musi być nazwą CNAME dla danego serwera poza siedzibą. Ponieważ ta strona zarządza własnym sprzętem i może zmieniać adresy w dowolnym momencie, CNAME jest wymagany.

Czy ktoś może wymyślić jakieś obejścia? Dzięki!

Masz wymóg, aby klienci musieli mieć możliwość zmiany adresu, czy zastanawiałeś się nad umożliwieniem klientowi dynamicznej aktualizacji własnego rejestru? Dzięki dynamicznym dns możesz użyć rekordu A, a klient może go zmienić w razie potrzeby. Zajmie to trochę pracy, ale możesz każdą subdomenę jako osobną strefę, aby mieć pewność, że klient może dotknąć tylko własnej strefy.

Nie próbowałem tego, ale gnudip wydaje się być narzędziem typu open source, umożliwiającym dynamiczne aktualizacje bez konieczności zajmowania się uwierzytelnianiem i konfigurowaniem wielu stref na serwerze DNS.


3

Jeśli twoje rekordy MX będą takie same dla wszystkich tych rekordów, możesz spróbować użyć DNAME do przekierowania XYZ.mywebservice.com na hosting.mywebservice.com. W obszarze hosting.mywebservice.com dodaj swoje rekordy MX i A.

Muszę powiedzieć, że nigdy nie korzystałem z rekordów DNAME w produkcji, ale możesz przeczytać o nich więcej w RFC2672 .


Chciałem spróbować użyć DNAME z niektórymi naszymi domenami SSL, ale słyszałem, że nadal występują problemy ze starszymi serwerami DNS itp. Czy to ma znaczenie? Czy korzystanie z DNAME jest bezpieczne na serwerach produkcyjnych?
drybjed

Gdybym musiał zgadywać, wiele aplikacji nie oczekuje rekordów DNAME i prawdopodobnie psuje się podczas ich używania. Czy wszystkie serwery pocztowe śledzą nazwy DNAME w celu wyszukiwania rekordów MX? Nie wiem, ale powinni. W przypadku problemu z SSL serwery DNS, które nie rozumieją nazwy DNAME, powinny zamiast tego otrzymać odniesienie do CNAME. Dokładnie przetestowałbym to przed wdrożeniem.
Doug Luxem

Aplikacja z pewnością NIE musi przetwarzać rekordów DNAME! Odbywa się to tylko na serwerach nazw.
bortzmeyer

3

Czy RHS klienta.mywebservice.com CNAME ma wpis MX?

Jeśli tak, to serwer poczty użyje tego MX do znalezienia serwera poczty do użycia. Mam nadzieję, że możesz to kontrolować.


1

Odpowiedź Michaela Gorsucha jest w dużej mierze poprawna, łańcuch CNAME -> A + MX działa ... głównie . Jednak powoduje pewne złe zachowanie w niektórych MTA. Co znalazłem, uruchamiając to rozwiązanie na przyzwoitą skalę:

  • niektóre MTA po prostu odmówią znalezienia rekordu.
  • inni niepoprawnie podmienią rekord A, w którym powinna być CNAME: tj. wysłałem pocztę na adres „jan@foo.example.com”, który CNAMES na web.example.com, który ma MX mail.example.com, oraz MTA przepisuje nagłówek koperty jako „Do: jan@web.example.com”.

Nie jest jeszcze jasne, jak wszechobecne są te problemy (Google / Hotmail / Yahoo / etc wydaje się, że radzą sobie z tym poprawnie), ale z pewnością każą nam szukać lepszych rozwiązań.


2
To jest poprawne; udokumentowanym zachowaniem dla serwerów SMTP zgodnych z RFC5321 jest najpierw sprawdzenie istnienia rekordu MX dla domeny, a jeśli to się nie powiedzie, sprawdzenie istnienia rekordu A. To zachowanie jest prawdziwym technicznym powodem, dla którego MX nie powinien być CNAME: przestanie działać po pierwszej użytecznej odpowiedzi.
adapttr

0

Możliwym i prawidłowym rozwiązaniem byłoby utworzenie podstawowej nazwy hosta dla wszystkich klientów i ustawienie jej na rekord aaaa zewnętrznego serwera WWW i twojego mx, a następnie CNAME wszystkich domen klientów na tę pojedynczą nazwę hosta. W ten sposób będziesz musiał zmienić tylko jeden rekord, gdy zmieni się adres IP zewnętrznej strony.

Jest to jedyny możliwy sposób sprawdzania wartości, ponieważ CNAME jest aliasem pełnego zestawu rekordów, a nie tylko.


-4

MX i CNAME są całkowicie oddzielnymi rekordami - pierwszy określa serwer pocztowy dla danej domeny, drugi podaje adres domeny. To powinno działać:

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

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

klient CNAME offsite.host.
klient MX 10 serwer poczty.

4
To może działać, ale narusza RFC1034 i RFC1219, które stwierdzają, że żadne inne rekordy zasobów nie mogą mieć takiej samej nazwy jak CNAME.
Doug Luxem

Mój demon DNS jest ściśle zgodny z RFC, co po prostu odmawia wysłania odpowiedzi dla MX. Uważam, że istnieją pewne potencjalne problemy z buforowaniem po stronie klienta, jeśli mamy to wprowadzić.
Michael Gorsuch,

Który demon DNS? Używam BIND9, który powinien działać z tą konfiguracją bez problemu. Może czas na aktualizację? Duża infrastruktura, jak sądzę?
drybjed

Używam MyDNS. To dość duża konfiguracja, a ten mały demon był do tej pory błogosławieństwem. Rozważam załatanie go, ale nie jestem bardzo zainteresowany radzeniem sobie z efektami ubocznymi, które go rodzą. Jeśli jest to sprzeczne z RFC, brzmi to jak zły pomysł.
Michael Gorsuch,

@Maciej - pewnie, twój autorytatywny serwer może być w stanie obsługiwać te rekordy. Wprawią w zakłopotanie większość serwerów rekurencyjnych, które ich pytają.
Alnitak,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.