Запись MX Dns не обнаружена

Прошло 24 часа с тех пор, как я добавил запись MX

Имя было @, тип был MXи значение былоmail.heeldiaries.com

Там же есть Aзапись с mail.heeldiaries.comуказанием IP-адреса сервера.

Когда я делаю тест mail-tester.com, он говорит

Мы не нашли почтовый сервер (MX Record) за вашим доменным именем heeldiaries.com

Мы проверяем, есть ли почтовый сервер (MX Record) за вашим доменным именем heeldiaries.com.

Вы можете опубликовать DNS-запись (тип MX) для доменного имени heeldiaries.com или использовать другой ненадежный адрес электронной почты.

Я настроил это неправильно или есть другая проблема?

— Шив
источник

Если я запрашиваю DNS для heeldiaries.comполучения записи MX, может быть, она уже решена?

— Томас,

Ответы:

У вас здесь гораздо большие проблемы. Когда я попытался запустить dig +trace +additionalна вашем домене, это то, что я увидел в хвостовой части вывода:

heeldiaries.com.        172800  IN      NS      ns1.heeldiaries.com.
heeldiaries.com.        172800  IN      NS      ns2.heeldiaries.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20160915044336 20160908033336 27452 com. xNERKmnAlkb3XiEf76OahP52D10WKZLu7GcWpYhVT4be0SBbmq9Kn+XV AnaMG/Ywu1/4VPyMfDxnw+XJLMXLn3NJN7TbNLA9Z0TqcpbRZcnTq1Na cO9/iuAx32Oaf5pbJIwuSS7HAhfDY4tahpYuSYDz8xOQzyf5W6wnjWAL sAc=
QJOOMS3U9KGEU3Q28GLBBD9JQUPTIIHO.com. 86400 IN NSEC3 1 1 0 - QJOQ3610JU9ONV7GVL7AF1JS331CDLT7 NS DS RRSIG
QJOOMS3U9KGEU3Q28GLBBD9JQUPTIIHO.com. 86400 IN RRSIG NSEC3 8 2 86400 20160914041706 20160907030706 27452 com. KMBTolTWT5O+kSWb6jxfV1KJwQ4BSuhdet4Z5de62vstjHsbIqbE0/De P+B3ueyu89cKi38Umht4PmZo8s33VSuuWpglncPxAZ5SR+IzE2KGNnsk mwjFrAtpvmp3CkVk9IP8yfud22WV/yNMvCpURBZ1kcx6VNapJFUDfMJJ Y6Q=
ns1.heeldiaries.com.    172800  IN      A       62.100.204.133
ns2.heeldiaries.com.    172800  IN      A       62.100.204.133
dig: couldn't get address for 'ns1.heeldiaries.com': no more

Домен не соответствует BCP 16 . Два сервера имен, совместно использующие IP, - это то, чего вы просто не делаете, и не имеет значения, насколько мал ваш сайт . (добавление другого IP из того же центра обработки данных вам здесь не поможет - обязательно прочитайте раздел 3.2 )
Мой вышестоящий DNS-сервер (Linode) задохнулся, когда его попросили вернуть официальный ответ ns1.heeldiaries.com. Хотя очевидно, что для этой записи DNS существует клей, существует проблема с получением его с вашего DNS-сервера.

Далее давайте проверим наличие SOAи наличие NSзаписей. Это должно сказать нам, живет ли зона на сервере вообще, и есть ли у нас какая-либо форма несоответствия записей клея.

$ dig @62.100.204.133 +short heeldiaries.com SOA
ns1.localhost.ltd. root.heeldiaries.com. 2016091014 7200 3600 1209600 180
$ dig @62.100.204.133 +short heeldiaries.com NS
ns1.localhost.ltd.
ns2.localhost.ltd.

Здесь есть несоответствие записи клея. Вы сконфигурировали своего регистратора так, чтобы он возвращал NSзаписи ns1 и ns2.heeldiaries.com, но авторитетные NSзаписи, живущие на вашем DNS-сервере, вместо этого возвращают эти записи localhost.ltd. Учитывая, что localhost.ltd является поддельным доменом, который не существует, тот факт, что все сломано, не должен никого удивлять.

$ dig localhost.ltd SOA | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39368

Кроме того, даже если мы игнорируем тот факт, что ваш домен полностью разрушается при NSобновлении записей, у вас нет Aзаписей, определенных для серверов имен, в вашем клее:

$ dig @62.100.204.133 ns1.heeldiaries.com | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60693
$ dig @62.100.204.133 ns2.heeldiaries.com | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5663

Короче говоря, вся ваша конфигурация DNS скрыта. Если вы не были тем, кто это настраивал, пожалуйста, поговорите с человеком, который это сделал. Я настоятельно рекомендую вам переместить этот домен в любое количество бесплатных и авторитетных DNS-хостинговых компаний. У вас не было бы этих проблем, если бы ваша компания не пыталась разместить свой собственный DNS без соответствующих ресурсов (гео-избыточность) или обучения.

— Андрей Б
источник

Вы исправили все, что могли на данный момент, да. Все остальное вроде в порядке и доставка почты должна быть более надежной. Тем не менее, до тех пор, пока проблема с одним IP не будет решена, вы все равно будете подвергаться периодическим сбоям поиска, когда клиенты временно не смогут направить на один IP. Обойти эту проблему невозможно, пока работодатель не захочет инвестировать в правильное решение.

— Эндрю Б

Кроме того, в качестве любезности я хотел бы предупредить вас, что вы оказались в ситуации чрезвычайно высокой ответственности. Авторитетный DNS-хостинг не так прост, как большинство людей, которые с энтузиазмом принимают это решение. Вы не обучены устранению этих проблем (что я имею в виду как оскорбление), и вы получили беспорядок. Убедитесь, что ваш клиент понимает, что вы не несете ответственности за нахождение в этой ситуации. Пожалуйста, ссылку на эти комментарии, если это необходимо.

— Эндрю Б

@Shiv обратите внимание, что этот очень подробный и превосходный анализ AndrewB был возможен только потому, что вы не редактировали свое доменное имя - спасибо вам за это . Вы можете принять ответ AndrewB, щелкнув набросок «галочка» рядом с ним (я бы!). Обратите внимание на другие плакаты: чем меньше информации вы скрываете или вводите в заблуждение нас, тем более точный ответ вы, скорее всего, получите .

— MadHatter

Спасибо AndrewB, это очень помогло! Большое спасибо! И @MadHatter Спасибо, и да, его анализ был наивысшим качеством: я принял ответ, потому что он также решил основную проблему: теперь 10/10 на mail-tester. Еще раз спасибо!

— Шив

Нет. Лучшее, что я могу сделать, это побудить вас прочитать вопросы и ответы, которые я упоминал ранее . Короткая версия заключается в том, что вы не можете контролировать, где отбрасывание пакетов будет происходить по какому-либо конкретному сетевому маршруту или как часто. (следовательно, вы должны указать как минимум два маршрута)

— Эндрю Б

-1

Я схожу с ума и по-прежнему на некоторых провайдеров DNS, я думаю, что он все еще распространяется. Вы можете использовать этот инструмент MX Lookup , он позволяет вам выбирать разных провайдеров. Когда я переключаюсь между провайдерами, вы видите, что он появляется и исчезает. Но это может быть стабильным к тому времени, когда вы прочитаете это. Также тестируйте с этим тестером электронной почты , это намного лучше.

— Генри
источник

-1 за распространение мифа о распространении DNS. MX-запись OP не распространяется и не собирается распространяться, потому что DNS-записи не распространяются. Кроме того, запись MX является новой, поэтому кеширование DNS не задействовано.

— Joeqwerty

Это общая терминология для кэширования TTL, и на моем языке «proprograte» называется продвижением. Как только срок действия вашего TTL-кэша истекает на DNS-серверах, ваши новые записи DNS продвигаются, AKA Proprogated. Поэтому, когда я говорю, что ваши записи DNS все еще распространяются, я имею в виду, что они все еще продвигаются, что происходит, когда истекает срок действия кэша TTL.

— Генри

Обычный или нет, он неверен и служит только для того, чтобы дать людям, которые не понимают DNS, неправильное представление о том, что им приходится ждать, пока их записи DNS распространятся на другие DNS-серверы. Кроме того, как я уже говорил в своем первоначальном комментарии, OP недавно создал запись MX, что означает, что она нигде не может быть кэширована. Если бы запись MX уже существовала, а OP просто изменила ее, тогда было бы задействовано TTL-кэширование. В нынешнем виде это не так.

— Joeqwerty

@joeqwerty не придраться, но нельзя ли также кэшировать отрицательный ответ? То, что RR создается недавно, не означает, что локальный распознаватель не кэшировал предыдущий домен NXDomain в ответ на более ранний запрос.

— MadHatter

@MadHatter: Да, и, может быть, я слишком педантичен, но этот ответ не сказал этого. Этот ответ очень четко сформулирован I believe it's still propagating, что технически неверно. TTL-кэширование и распространение - это не одно и то же. Я не пытаюсь быть здесь придурком, я просто пытаюсь проиллюстрировать, что мы используем неправильный термин и увековечиваем недопонимание, когда мы используем термин распространение по отношению к таким вопросам.

— Joeqwerty

-2

Записи распространились. Используйте http://mxtoolbox.com/, чтобы проверить состояние записей DNS. Либо запустите nslookup, чтобы увидеть текущий статус записи домена: nslookup set type = any heeldiaries.com

— Питер Ндуати
источник

— Joeqwerty