Проблемы с доставкой DNS
Обновлено: 01.07.2024
>Я сделал это - перезапустил транспорт - это, кажется, устранило ошибку DNS-запроса. Теперь, пожалуйста, установите флажок «Использовать настройки внешнего поиска DNS на транспортном сервере» на вкладке «Сеть» в соединителе отправки, чтобы проверить эту проблему. Если проблема не устранена, обратитесь к обходному пути в аналогичной теме, предоставленной Хари
>мой сервер обмена не имеет внутренних имен почты, поэтому я думаю, что это должно быть заполнено. Не уверен, однако, что он пуст, и я ожидаю, что возникнут дополнительные проблемы, если это потребуется, не так ли?
это запись A и не совпадает с их записью MX. Внутренний DNS разрешается правильно.
Ты меня здесь теряешь.
SOA – мировая
MX-запись mylogic
Есть какие-либо обновления по вашей проблеме?
С уважением!
Гэвин Пожалуйста, не забудьте нажать «Отметить как ответ» на посте, который вам поможет, и нажать «Снять отметку как ответ», если помеченный пост на самом деле не отвечает на ваш вопрос. Это может быть полезно другим участникам сообщества, читающим ветку.
Единственная моя проблема с внутренней проблемой DNS заключается в том, что проблема связана с двумя разными доменами. У нас есть 500 исходящих писем на разные домены, в которых нет этой проблемы.
>Моя единственная проблема с внутренней проблемой DNS заключается в том, что проблема связана с двумя разными доменами. У нас есть 500 исходящих писем на разные домены, в которых нет этой проблемы.
На машине есть два сетевых адаптера. Поскольку мы используем DAG, у нас есть сетевой адаптер для карты и репликации. Я убедился, что порядок привязки правильный. И сеть MS Windows является вершиной порядка провайдера. Сетевая карта указывает на два внутренних DNS-сервера. Опять же, это единственный домен, с которым у нас возникли проблемы. И дело даже не в домене. Обычные почтовые сообщения отправляются без проблем. Два сообщения, которые продолжают зависать, являются принятыми приглашениями на собрание.
Я бы предпочел не публиковать это, так как это частная компания. Могу ли я отправить его вам по электронной почте?
>Опять же, это единственный домен, с которым у нас возникли проблемы. И дело даже не в домене. Обычные почтовые сообщения отправляются без проблем. Два сообщения, которые продолжают зависать, являются принятыми приглашениями на собрание.
Не забудьте нажать «Пометить как ответ» на сообщении, которое вам поможет, и нажать «Снять пометку как ответ», если помеченное сообщение на самом деле не отвечает на ваш вопрос. Это может быть полезно другим участникам сообщества, читающим ветку.
Отклонение исходящей электронной почты из-за проблем с конфигурацией системы доменных имен — распространенная проблема, с которой сталкиваются администраторы серверов электронной почты в Интернете. Есть восемь вещей, которые вы можете проверить, чтобы убедиться, что ваш DNS настроен для оптимальной доставки. Каждый день этой серии я буду освещать разные темы.
Отправляете ли вы электронную почту из своего домена с сервера, авторизованного в DNS-записях SPF вашего домена?
Структура политик отправителей, также известная как SPF, определена в Internet RFC 4408. Экспериментальный протокол при правильном применении отправителем и получателем может помочь предотвратить подделку адресов электронной почты и путей электронной почты.
К сожалению, неправильная реализация может препятствовать даже законному обмену сообщениями по электронной почте.
Хотя я не буду вдаваться в подробности того, как настроить запись SPF, в этой статье я помогу вам определить, есть ли у вас запись SPF для вашего домена и может ли она быть неправильно настроена.
Для начала я рекомендую использовать мастер записи SPF от Microsoft. Просто введите свое доменное имя на первой странице и нажмите кнопку «Старт». Это поможет вам определить текущую запись SPF вашего домена и определить, какое значение записи SPF DNS должно быть основано на ваших ответах на вопросы о том, какой почтовый сервер отправляет электронную почту для вашего домена.
Не забывайте, что запись SPF — это новый тип записи ресурсов DNS, однако ее также можно реализовать с помощью записи TXT в зоне DNS вашего домена. Убедитесь, что вы ищете записи обоих типов, если вы не используете описанный выше мастер.
Домен, используемый в адресе электронной почты отправителя
Запись SPF для вашего домена будет содержать список серверов электронной почты, которым разрешено отправлять электронную почту, где имя вашего домена находится в адресе электронной почты отправителя, как указано в командной части MAIL FROM сеанса SMTP. Это не то же самое, что адрес электронной почты, указанный в заголовке «От». Адрес MAIL FROM обычно вообще не указывается в заголовках сообщения электронной почты, но иногда указывается в заголовке «Return-Path».
Домен, используемый в HELO
Одна из наиболее распространенных проблем с записями SPF заключается в том, что люди не понимают, что они также используются для проверки доменного имени, используемого вашим компьютером в приветствии HELO/EHLO. Например, вы можете отправлять сообщение электронной почты с адреса john@example.com, но ваш почтовый сервер называется mail.example.com. У вас может быть запись SPF для example.com, в которой указан ваш почтовый сервер как авторизованный для отправки электронной почты для вашего домена example.com, а также запись SPF для mail.example.com, в котором нет этого почтового сервера. Обычно у вас должна быть запись SPF для имени хоста вашего почтового сервера, которая просто является определением записи SPF типа "a". Например:
example.com. TXT "v=spf1 a:smtp.example.com -all"
smtp.example.com. TXT "v=spf1 a -все"
Электронная почта, отправленная с вашего веб-сервера и службы списка рассылки
Самая распространенная причина сбоя SPF связана с тем, что ваш веб-сайт генерирует электронную почту из веб-формы или веб-приложения, но вы забыли указать свой веб-сервер в своей записи SPF как авторизованный для отправки электронной почты. из вашего домена.
Вторая наиболее распространенная причина сбоя SPF связана с аутсорсингом вашего списка рассылки и массовых рассылок, но при этом вы забыли обновить запись SPF вашего домена, чтобы перечислить почтовые серверы сторонних почтовых программ как авторизованные для отправки электронной почты. из вашего домена.
Не существует документа RFC, требующего записи SPF для домена. Однако, если записи SPF настроены, требуется планирование и идеальная реализация, чтобы избежать проблем с доставкой электронной почты. Кроме того, наличие записей SPF может помочь вашему электронному письму получить более высокий балл при прохождении взвешенного эвристического спам-фильтра. Я рекомендую настроить записи SPF для вашего домена, если у вас есть навыки для их правильной реализации, но я не рекомендую использовать проверки SPF для фильтрации электронной почты. Вместо этого я рекомендую просто помечать сообщения, не прошедшие проверку SPF, чем-то вроде [Поддельный отправитель]. Это даст вам соответствующее предупреждение о том, что сообщение могло быть отправлено поддельным отправителем.
< /p>
DNS-серверы — важная часть инфраструктуры, необходимая каждой компании или организации. Они участвуют в преобразовании доменных имен в IP-адреса, которые могут быть прочитаны машинами. Однако не многие организации понимают необходимость его обслуживания до тех пор, пока не начнут возникать проблемы. Большинство из этих проблем обычно мешают нормальным рабочим процессам, что в конечном итоге может повлиять на производительность. Некоторые ошибки могут представлять серьезные проблемы с безопасностью, которые могут нанести значительный ущерб бренду компании.
Большинство экспертов по DNS согласны с тем, что не так уж много разработчиков и ИТ-специалистов имеют правильное представление об управлении DNS-серверами. Даже ИТ-фирмы, которые предоставляют такие услуги, обычно оказываются на стороне получателя, когда сталкиваются с проблемами, выходящими за рамки их компетенции.
Учитывая, что существует два разных типа DNS, проблемы также различаются. Общедоступный DNS, который обычно используется для подключения к Интернету, имеет ряд проблем, связанных со злонамеренным поведением, инициированным хакерами. Внутренний DNS, используемый на предприятиях, имеет проблемы, связанные с ошибками конфигурации и ошибками, которые может оказаться трудно решить, если вы не знаете, на что обращать внимание.
Вот некоторые из наиболее распространенных проблем с DNS и их решения.
![]()
Неправильно настроенные записи DNS
В большинстве случаев проблемы с DNS обычно связаны с неправильной настройкой записей DNS. Если вы не введете правильные значения и IP-адреса своих записей, существует высокая вероятность того, что вы увязнете в проблемах с разрешением DNS.
Некоторые записи, такие как MX, SPF и DKIM, необходимы для доставки электронной почты. Неправильно настроенный сервер не сможет получать или доставлять почту.
Решение. Сократите ошибку DNS до конкретной проблемы. Например, если у вас возникли проблемы с доставкой почты, вам следует сначала проверить, правильно ли настроены ваши записи SPF, DKIM и MX.
Высокие значения TTL
TTL означает время жизни. Всякий раз, когда у вас есть высокие значения TTL в ваших записях, существует высокая вероятность того, что это приведет к большому времени ожидания распространения. Это также может привести к простоям при перемещении трафика между серверами.
Решение. Вы можете изменить свои записи, чтобы они имели низкие значения TTL. Единственная проблема с низкими значениями TTL заключается в том, что вам придется иметь дело с высокой нагрузкой запросов. Однако, если ваш сервер может справиться с дополнительной нагрузкой, то с этим проблем нет.
Примечание. Резолверы DNS некоторых интернет-провайдеров обычно игнорируют настройки TTL и переопределяют их своими собственными.
DDOS-атаки![]()
< бр />
< бр />Для этого необходимо, чтобы у вас были установлены лучшие функции безопасности. Иногда проблемы с DNS возникают в результате злонамеренных атак хакеров. Они делают это, привлекая высокий трафик на ваш сайт, пока он в конечном итоге не выйдет из строя. Отсюда необходимость вкладывать средства в альтернативные функции безопасности.
Решение. Используйте высокопроизводительное устройство защиты от атак DDOS.
Сбои оборудования/сети
В некоторых случаях проблемы с DNS вызваны аппаратными сбоями на хост-компьютере или сбоями в сети, которые могут находиться вне вашего контроля (если только хост-сервер не присутствует в вашей рабочей среде).
Решение. Устраните неполадки в настройках конфигурации сети/оборудования. Это поможет вам определить непосредственный источник той конкретной проблемы, которая. В большинстве случаев проблема обычно связана с конфигурацией.
![]()
Высокая задержка DNS
Большая задержка DNS означает большое время загрузки. Высокая задержка DNS может быть связана с тем, что серверы DNS-имен не находятся в непосредственной географической близости от большого процента пользователей, посещающих ваш сайт. Другой причиной может быть перегрузка сети.
Решение. Решение проблемы с высокой задержкой варьируется в зависимости от места возникновения проблемы. Однако, как показывает опыт, смена DNS-серверов на серверы, близкие к местоположениям ваших пользователей, доказала свою эффективность. В противном случае вам придется повторить все настройки, которые вы сделали до появления высокой задержки.
Заключение
При решении проблем с DNS всегда сначала проверяйте, возвращает ли ваш DNS-сервер один и тот же ответ при запросах из разных мест. Вы также должны убедиться, что ваше доменное имя активно и что у вас есть стабильный и надежный интернет-провайдер.
Однако для таких важных дел, как инфраструктура DNS, лучше иметь под рукой специалистов по DNS, которые смогут решить любую возникающую проблему как можно быстрее. Ознакомьтесь с полным списком серверов, которые вы можете использовать, здесь.
Поиск
О нас
< /p>
Мы — группа увлеченных технических энтузиастов, которые всегда находятся в авангарде предоставления новейшего контента, связанного с серверами. Мы обнаружили, что не хватает информации, которую можно использовать, когда дело доходит до управления DNS-сервером. Вот почему мы решили предоставить информацию людям, которые хотят узнать о них больше.
Если ваш браузер не может найти сервер dns.google или не отвечает, проверьте, можете ли вы получить доступ к общедоступным DNS-серверам Google с помощью диагностики из командной строки.
Устранение неполадок Google Public DNS
Существует много возможных проблем с разрешением DNS; следуйте указаниям под заголовком, который наиболее точно соответствует вашей проблеме. Если вам нужно сообщить о проблеме и получить помощь, включите в отчет вывод любых команд или текст со страниц диагностики.
Проблемы с доменом
Если у Google Public DNS возникают проблемы с разрешением определенного доменного имени, введите его на странице сведений dns.google. Если проблема связана с определенным типом записи ресурса DNS (RR), введите его в текстовое поле «Тип RR» (можно также ввести число). Нажмите Enter или щелкните Разрешить, чтобы увидеть результаты.
В подробных результатах может быть строка с «Комментарием»: внизу с диагностикой вашего DNS-запроса. Например, вы можете увидеть
"Ошибка проверки DNSSEC. Проверьте http://dnsviz.net/d/dnssec-failed.org/dnssec/ и http://dnssec-debugger.verisignlabs.com/dnssec-failed. .org на наличие ошибок"
Посетите все URL-адреса комментариев (это не ссылки, скопируйте и вставьте их в браузер), чтобы просмотреть подробную диагностику, которая может определить причину проблем с разрешением.
Если есть строка комментария, соответствующая одной из следующих записей, щелкните соответствующую ссылку, чтобы перейти непосредственно к определенному шагу диагностики, или просто начните с первого шага устранения неполадок домена.
Ошибка проверки DNSSEC Если вы видите это, отключите проверку, щелкнув переключатель DNSSEC, и нажмите Разрешить, чтобы повторить запрос. Если это удается ("Status": 0), возникает проблема с DNSSEC; см. раздел «Устранение неполадок DNSSEC». В противном случае см. раздел Устранение неполадок сервера имен. Серверы имен См. Устранение неполадок сервера имен. Ошибка разрешения или делегирование Lame См. раздел Устранение неполадок делегирования.
Если у вас возникают проблемы с большими записями (обычно с ключами DNSSEC или записями TXT), прочитайте об устранении неполадок с большими ответами.
Возврат неправильных ответов для домена
Существует множество причин, по которым Google Public DNS может возвращать неверные ответы. попробуйте любое из следующих действий, которые кажутся возможными, учитывая ваше знание предметной области.
Если серверы для домена недавно изменились
Особенно если в домене есть новые DNS-серверы или новый регистратор DNS, Google Public DNS может возвращать старые (но не просроченные) кэшированные ответы. Используйте Flush Cache (документация), чтобы очистить зарегистрированный домен и конкретное доменное имя, возвращающее устаревший ответ.
Если вы по-прежнему получаете устаревшие ответы после очистки, запросите тип SOA RR для зарегистрированного домена на странице сведений dns.google. и проверьте порядковый номер зоны (первый номер в «Ответе» «данные»). Если вы иногда получаете разные серийные номера, возможно, некоторые авторитетные серверы имен обслуживают устаревшие данные, и оператор DNS для домена должен решить эту проблему.
Если адреса домена сети доставки контента (CDN) находятся далеко
Если есть более близкий адрес, который должен был быть возвращен, возможно, авторитетные серверы имен неправильно реализуют клиентскую подсеть EDNS (ECS). Операторы DNS домена должны подтвердить, что они соблюдают все рекомендации на этой странице.
Если ваши приложения видят адреса, отличные от веб-результатов dns.google
Если веб-сайт dns.google заблокирован или показывает очень разные результаты, сначала убедитесь, что вы используете Google Public DNS. Если это так, разные ответы могут быть связаны с перехватом DNS авторизованным порталом Wi-Fi, вредоносным ПО на вашем маршрутизаторе, вашим интернет-провайдером или его сетями. См. инструкции по устранению неполадок при блокировке и взломе.
Разрешение доменов выполняется слишком медленно
Хотя такие инструменты, как traceroute и ping, сообщают о сетевых задержках, они не измеряют скорость разрешения DNS и помогают только при попытке найти место задержек или подтвердить доступность сети. Google не блокирует ICMP или случайный UDP для общедоступных IP-адресов DNS Google, но существуют ограничения на скорость ответов ICMP об ошибках, и трафик ICMP может быть лишен приоритета в сетях Google.
Определить метро, обслуживающее ваши запросы
Сетевое расстояние между вашим устройством и распознавателем Google Public DNS напрямую влияет на скорость разрешения. Мы реализуем опцию идентификатора сервера имен, чтобы сообщать код аэропорта метро, где обрабатывается DNS-запрос. Если метро находится далеко от вашего местоположения, задержка запроса будет выше. Это может быть вызвано различными причинами, в том числе неоптимальной маршрутизацией между вашей сетью и Google или отсутствием пропускной способности в ближайшем городе.
Чтобы найти код аэропорта, вы можете сделать запрос к нашим преобразователям DNS с установленным идентификатором сервера имен (NSID) опции EDNS. Ответ будет в формате gpdns-. Выполните следующую команду, чтобы узнать, из какого метро исходит ваш ответ:
macOS или Linux
Разрешение по IPv6 медленнее
Если задержки разрешения для IPv6 значительно больше, чем для IPv4, подключение IPv6 между вашим интернет-провайдером и Google может быть неоптимальным. Интернет-провайдеры, взаимодействующие с Google, должны проверять гораздо большее количество переходов в выходных данных трассировки IPv6 (см. доступ к общедоступным DNS-серверам Google) или другие проблемы с маршрутизацией BGP, отображаемые на их панели управления интернет-провайдером, и отправлять электронное письмо в NOC Google, если их маршрутизация IPv6 оказывается другое метро, чем IPv4.
Нет ответа на (некоторые) мои DNS-запросы
Отбрасывание очень небольшой доли UDP-запросов к DNS является нормальным явлением, но если вы видите отбрасывание одного процента или более ваших запросов, используйте инструмент тестирования DNS, аналогичный описанному в предыдущем разделе.
Если инструмент тестирования DNS показывает большое количество запросов без ответа (и особенно если ping и traceroute не показывают сравнимую частоту отбрасывания), проверьте, генерирует ли ваш IP-адрес более 1000 запросов в секунду, что может привести к ограничению скорости. Если это так, вы можете запросить увеличение лимита скорости в нашем трекере ошибок.
Блокировка и перехват DNS
Если вы не получаете никаких ответов на DNS-запросы (но страница dns.google работает), возможно, UDP- и TCP-запросы заблокированы или перехвачены. Выполните эти команды, чтобы проверить, достигают ли запросы UDP и TCP общедоступного DNS Google:
Окна
macOS или Linux
Если вывод первой команды показывает "Спасибо за использование Google Public DNS". ваши UDP-запросы достигают Google Public DNS; если вывод второй команды включает в себя location.publicdns.goog. ваши TCP-запросы также достигают Google.
Если в выходных данных отображается NXDOMAIN, значит, вы обращаетесь к другому преобразователю DNS. Если выходные данные показывают тайм-аут, DNS-запросы к Google Public DNS блокируются. Используйте команды UDP или DNS traceroute в следующем разделе, чтобы увидеть, где может происходить перехват или блокировка.
Убедитесь, что вы подключаетесь к общедоступным DNS-серверам Google
Если вы не можете открыть домашнюю страницу dns.google, возможно, возникла проблема с сетью или блокировка, из-за которой вы не можете получить доступ к Google Public DNS.
Если ваша система настроена на использование Google Public DNS в качестве преобразователя DNS, вам может потребоваться заменить имя dns.google в следующих командах на IP-адреса Google Public DNS.Попробуйте сначала использовать имя, а если не получится, используйте 8.8.8.8 или другой адрес.
Откройте окно терминала с помощью командной строки и выполните следующие команды traceroute:
Окна
Отслеживание маршрутизации с помощью эхо-запроса ICMP:
Чтобы проверить подключение IPv6:
macOS или Linux
Отслеживание маршрутизации с UDP-пакетами, отличными от DNS:
Чтобы проверить подключение IPv6:
Если ваша система говорит, что у вас нет разрешения на запуск traceroute, используйте команду sudo для ее запуска:
Если в последней строке вывода не указан общедоступный IP-адрес Google DNS (8.8.8.8, 8.8.4.4 или IPv6-адрес, начинающийся с 2001:4860:4860), может проблема с сетью, которая не позволяет вам связаться с Google.
В системах, отличных от Windows, повторите приведенные выше команды с параметром -I или -U, чтобы использовать пакеты ICMP или UDP-пакеты, отличные от DNS, отправляемые на порт DNS (53). Если параметр -I не распознается, попробуйте выполнить команду ping для отправки ICMP:
macOS или Linux
Команду dnstraceroute инструментов тестирования DNS farrokhi/dnsdiag, описанную в разделе Слишком медленное разрешение доменов, можно использовать для отслеживания маршрута реальных запросов DNS (даже в Windows).
Если некоторые из этих команд работают, а другие возвращают сетевые ошибки или тайм-ауты, сетевая фильтрация может препятствовать доступу к Google Public DNS. Обратитесь к сетевому администратору или в службу поддержки интернет-провайдера, чтобы подтвердить это.
Если ни одна из этих команд не выполнена успешно, обратитесь к своему (вышестоящему) интернет-провайдеру или, если вы являетесь интернет-провайдером, который связан с Google, свяжитесь с Google NOC. Последняя строка вывода traceroute, в которой нет трех звездочек * * * (показывая одинаковые тайм-ауты), может указывать на то, где возникает проблема.
Если не указано иное, содержимое этой страницы предоставляется по лицензии Creative Commons Attribution 4.0, а образцы кода — по лицензии Apache 2.0. Подробнее см. в Правилах сайта Google Developers. Java является зарегистрированным товарным знаком Oracle и/или ее дочерних компаний.
Читайте также: