Я немного запутался в том, что случилось с одним из почтовых ящиков моего клиента.
Мой клиент зарегистрировал домен на dotster.com. Она хотела начать использовать электронную почту для этого домена до того, как у нас появится ее веб-сайт, поэтому я настроил ее через почту Google Apps и добавил соответствующие записи MX в ее учетную запись dotster.
Когда ее веб-сайт был готов, я разместил его на Dreamhost и указал на серверы имен Dreamhost для домена в учетной записи dotster. (например, домен, размещенный на dotster, указывает на серверы имен Dreamhost для веб-хостинга). Записи MX остались такими же, как и раньше, и какое-то время все работало нормально.
Сегодня она сказала мне, что ее электронное письмо начало отскакивать. " ошибка, возвращенная другим сервером: 554 554 5.7.1: адрес получателя отклонен: доступ запрещен (состояние 14)". Когда я выполнял трассировку, записи MX не отображались, но отображались текстовые записи (также установленные в точке).
Итак, я перешел на Dreamhost и добавил туда записи MX. Теперь ее электронная почта снова работает.
Мои вопросы:
1) Должны ли записи MX быть установлены в том месте, где указаны серверы имен? Я думал, что они независимы.
2) Я также почти уверен, что ее электронная почта работала достаточно долго после того, как я указал серверы имен на Dreamhost. Так почему бы ему внезапно перестать работать?
Я интерфейсный веб-дизайнер / разработчик, так что имейте это в виду с точки зрения того, сколько, как вы думаете, я уже знаю. :) (Связанные с сервером вещи обычно ставят меня в тупик больше всего на свете).
Каждый домен имеет то, что называется Запись SOA. Он определяет, среди прочего, как долго другие серверы должны кэшировать информацию о где запросить записи для указанного домена.
Например:
@ IN SOA nameserver.place.dom. postmaster.place.dom. (
1 ; serial number
3600 ; refresh [1h]
600 ; retry [10m]
86400 ; expire [1d]
3600 ) ; min TTL [1h]
После того, как на сайте place.dom выполняется запрос к чему-либо (MX, TXT и т. Д.), Местоположение, куда будут отправляться все будущие запросы, кэшируется максимум на 1 день. В вашем случае это было намного дольше, поэтому вы не заметили, потому что SOA была кэширована.
Чтобы получить дополнительную информацию о записи SOA для домена, попробуйте это из командной строки:
~$ nslookup
> set type=soa
> set debug
> zaplabs.com
Server: 192.168.1.1
Address: 192.168.1.1#53
------------
QUESTIONS:
zaplabs.com, type = SOA, class = IN
ANSWERS:
-> zaplabs.com
origin = dns1.name-services.com
mail addr = info.name-services.com
serial = 2002050701
refresh = 10001
retry = 1801
expire = 604801
minimum = 181
AUTHORITY RECORDS:
ADDITIONAL RECORDS:
------------
Non-authoritative answer:
zaplabs.com
origin = dns1.name-services.com
mail addr = info.name-services.com
serial = 2002050701
refresh = 10001
retry = 1801
expire = 604801
minimum = 181
Authoritative answers can be found from:
>
1) Совершенно верно. Когда поиск в DNS завершен (в данном случае, чтобы узнать, куда отправлять почту), этот поиск выполняется с серверов имен. Поэтому, если на ваших серверах имен нет записи MX в списке, поиск ни к чему не приведет.
Это то же самое, что и телефонная книга, за исключением того, что вы можете указать свой номер телефона только в один телефонная книга за раз. Итак, вы говорите своим друзьям: «Поищите меня в телефонной книге Acme». Поэтому, когда они хотят с вами связаться, они ищут ваш номер телефона в телефонной книге Acme, находят ваше объявление и звонят вам. Но затем, если вы переместите свою запись в «Телефонную книгу OtherGuys», но не сообщите OtherGuys свой номер телефона, когда ваши друзья найдут вас в OtherGuys, они не увидят ваш номер телефона - потому что он указан в книгу Acme вместо этого.
2) Это связано с тем, что записи серверов имен для ваших клиентских доменов какое-то время кэшировались (обычно на несколько часов, возможно, до нескольких дней - тайм-аут настраивается). Это означает (примерно), что любой, кто выполнял поиск в MX до того, как вы переключили серверы имен, некоторое время сохранял старую информацию в памяти, чтобы им не пришлось искать ее снова. Но в конце концов эта информация истекла, поэтому, когда они попытались найти информацию снова - на этот раз с нового сервера - они не получили «ничего», поэтому почта начала возвращаться.