Обратный DNS (Reverse DNS)

Узнайте через обратный DNS имя хоста любого адреса IPv4 или IPv6: все PTR-записи прямо с собственных DNS-серверов обратной зоны, указывает ли каждое имя обратно на адрес (FCrDNS), кто ведёт зону и выполняет ли адрес правила Gmail, Yahoo и Microsoft для почтовых серверов.

Источники: DNS-серверы обратной зоны, найденные начиная с корневого сервера · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru

Что такое обратный DNS (rDNS)?

Обратный DNS превращает IP-адрес обратно в имя хоста — в противоположность обычному (прямому) запросу, который превращает имя в адрес. Ответ — PTR-запись, которую владелец адреса публикует в отдельной части DNS, отведённой для адресов.

Имена DNS читаются справа налево, поэтому для запроса адрес записывается задом наперёд: 8.8.8.8 становится 8.8.8.8.in-addr.arpa, а 203.0.113.7 — 7.113.0.203.in-addr.arpa. Когда часть сети стоит справа, каждый блок адресов можно передать тому, кто им владеет (RFC 1035 §3.5).

IPv6 использует ip6.arpa и все 32 шестнадцатеричные цифры (ниблы) адреса, начиная с последней: :: раскрывается до того, как цифры переворачиваются, поэтому у 2001:4860:4860::8888 имя из 32 меток (RFC 3596 §2.5). Инструмент ещё во время ввода показывает под полем имя, которое запросит, а в обратном пути рядом с результатом выписывает все 32 нибла.

Устройство обратного именипроверено 2026-10-23

Адрес IPv4OpenDNS

208.67.222.222222.222.67.208.in-addr.arpa

Его обратное имя, запрос PTRresolver1.opendns.com +3

Октеты в обратном порядке/8 идёт последним: 208.in-addr.arpa — зона ARIN, 222.67.208.in-addr.arpa — собственная зона OpenDNS.
in-addr.arpaОбратное дерево IPv4: его администрирует IANA, а обслуживают серверы от a до f.in-addr-servers.arpa.
PTRЧто содержит имя: resolver1.opendns.com и ещё три имени хоста.

Адрес IPv6, записанный полностьюGoogle

2001:4860:4860:0000:0000:0000:0000:8888

32 нибла, начиная с последней цифры

8888 в конце идёт первым, /32 Google 2001:4860 — последним, а 16 нулей, которые скрывал ::, выписаны полностью.

8.8.8.8.in-addr.arpaIPv4: четыре метки в обратном порядке
8.8.8.8.0.0.0.0…ip6.arpaIPv6: все 32 цифры в обратном порядке
8.8.8.8.0.6.8.4…ip6.arpa:: не раскрыт: другое имя и NXDOMAIN
8.8.8.8 читается одинаково в обе стороны, поэтому на рисунке взят 208.67.222.222, у которого октеты заметно меняются местами. Обратный путь в инструменте показывает такую же перестановку для каждого проверенного адреса IPv4.

Как выполнить обратный DNS-запрос

Введите адрес выше и нажмите Найти PTR. Инструмент спускается от корневого сервера к собственному DNS-серверу обратной зоны и спрашивает его напрямую, а затем сравнивает копии в кэше Google и Cloudflare. Из терминала то же самое делают dig -x 8.8.8.8 в macOS и Linux, nslookup 8.8.8.8 в Windows или host 8.8.8.8.

dig -x сам строит имя in-addr.arpa или ip6.arpa; добавьте @ и DNS-сервер зоны с +norecurse (dig -x 8.8.8.8 @ns1.google.com +norecurse), чтобы прочитать собственный ответ зоны с полным TTL, а не кэш. Для PowerShell документированная Microsoft форма передаёт перевёрнутое имя: Resolve-DnsName -Name 8.8.8.8.in-addr.arpa -Type PTR.

dig -x 8.8.8.8 +noall +answer

dig сам строит 8.8.8.8.in-addr.arpa. Число перед IN — оставшийся TTL у вашего резолвера.

Как читать ответ digGoogle Public DNS, затем собственный сервер Google · записано 2026-10-23
bash · zsh
$ dig -x 8.8.8.8 @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24160
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa.        IN   PTR

;; ANSWER SECTION:
8.8.8.8.in-addr.arpa.  14003  IN   PTR   dns.google.

;; SERVER: 8.8.8.8#53(8.8.8.8)

$ dig -x 8.8.8.8 @ns1.google.com +norecurse
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
8.8.8.8.in-addr.arpa.  86400  IN   PTR   dns.google.
;; SERVER: 216.239.32.10#53(216.239.32.10)
  1. Статус. NOERROR с одним ответом. NXDOMAIN означал бы, что PTR не задан; SERVFAIL — что обратная зона неисправна.
  2. Вопрос. dig построил 8.8.8.8.in-addr.arpa из адреса и запросил его PTR.
  3. TTL. В кэше Google осталось 14 003 с. Собственный сервер зоны отдаёт полные 86 400 с — сутки.
  4. Имя хоста. Значение PTR. Точка в конце завершает имя.
  5. Кто ответил. 8.8.8.8 — это кэш. Во втором ответе флаг aa отмечает собственный сервер зоны.
Один PTR, запрошенный дважды: Google Public DNS отвечает из кэша с обратным отсчётом; ns1.google.com, запрошенный с +norecurse, отвечает за зону с полным TTL.

Как читать результат

Заголовок одной фразой говорит, какое PTR-имя у адреса и указывает ли оно обратно, с TTL зоны и ответившим сервером. Цветные заметки под ним говорят, кто может изменить имя и что в нём необычного.

Раздел PTR перечисляет все имена с TTL и прямой проверкой; «Почта» оценивает их по правилам получателей; «Делегирование» показывает каждый опрошенный сервер; «Копии» сравнивает ответы в кэше Google и Cloudflare; «Команды» дают тот же запрос для терминала. Справа обратный путь рисует весь спуск.

Обратный DNS для 8.8.8.8: PTR-запись dns.google с DNS-сервера Google, её прямая проверка и путь делегированияОбратный DNS для 8.8.8.8: PTR-запись dns.google с DNS-сервера Google, её прямая проверка и путь делегированияВердиктPTR-имя адреса, указывает ли оно обратно и кто его задал, с TTL и ответившим сервером.PTR-записиВсе имена, которые зона хранит для адреса, с TTL и адресами, которые возвращает их прямой запрос.РазделыПочтовые правила, делегирование шаг за шагом, копии в кэше с обратным отсчётом и команды.Обратный путьАдрес, превращённый в DNS-имя, затем корень, IANA, регистратор и зона, которая ответила.
Проверка обратного DNS для 8.8.8.8: вердикт, PTR-запись с TTL и прямой проверкой и обратный путь от корня до зоны Google. Выберите номер, чтобы узнать, что показывает каждая часть.

Что такое PTR-запись?

PTR-запись (pointer, указатель), тип DNS 12, содержит одно имя хоста для адреса, под которым она стоит: 8.8.8.8.in-addr.arpa. 86400 IN PTR dns.google. Это просто данные: в отличие от CNAME, она никуда не перенаправляет (RFC 1035 §3.3.12).

Её пишет владелец адреса, а не владелец имени внутри неё: обратная зона Google говорит, что 8.8.8.8 — это dns.google, а обратное утверждает только запись A в зоне dns.google. У одного адреса может быть несколько PTR-записей (RFC 2181 §10.2): у 208.67.222.222 их четыре. Имя должно быть настоящим именем хоста, а не псевдонимом.

PTR содержит имя и больше ничего: ни владельца, ни страны, ни города. Место, показанное рядом с результатом, берётся из слов, которые оператор вписал в имя, или из отдельной базы данных.

Одно имя, две зоны8.8.8.8 и dns.google, проверено 2026-10-23
Прямая зоназона домена: dns.google
dns.google. A 8.8.8.8dns.google. A 8.8.4.4dns.google. AAAA 2001:4860:4860::8888dns.google. AAAA 2001:4860:4860::8844

Обслуживает ns1.zdns.google для владельца dns.google

две зоны, два набора серверов
Обратная зоназона блока адресов: 8.8.8.0/24
8.8.8.8.in-addr.arpa. PTR dns.google.

Делегирована ARIN компании Google, обслуживает ns1.google.com

8.8.8.8.in-addr.arpa.Обратное имя86400TTL · суткиINКлассPTRТипdns.google.Имя хоста
1 адрес, 4 имени208.67.222.222: resolver1.opendns.com и ещё три
1 адрес, 48 имён17.253.144.10, адрес apple.com, у каждого имени TTL 5 минут
1 имя, 4 адресаdns.google: 8.8.8.8, 8.8.4.4 и два IPv6
PTR говорит, как называется 8.8.8.8; записи A — куда указывает dns.google. Так совпало, что обе зоны ведёт Google, на разных серверах.

Что такое обратный DNS с прямым подтверждением (FCrDNS)?

Обратный DNS с прямым подтверждением означает, что имя из PTR разрешается обратно в тот же адрес: 8.8.8.8 → dns.google → 8.8.8.8. Почтовые серверы называют эту проверку iprev (RFC 8601 §3): запросить PTR-имена адреса, запросить записи A или AAAA каждого имени и считать проверку пройденной, если адрес есть среди них.

Второй шаг важен, потому что владелец адреса может вписать в PTR любое имя, хоть google.com. Имя что-то доказывает, только когда владелец домена направляет его обратно. Инструмент проверяет каждое PTR-имя, до десяти, и рисует петлю справа: зелёную, когда она замыкается, жёлтую, когда имя указывает в другое место.

Если PTR-записей несколько, достаточно одной, которая указывает обратно. Имя, у которого в записи A есть и другие адреса, всё равно проходит, если этот адрес среди них.

Три адреса — три петлипроверено 2026-10-23
Прямое подтверждениеGoogle
8.8.8.8dns.google8.8.8.8: тот же адрес
Указывает обратноdns.google возвращает ещё и 8.8.4.4
Указывает в другое местоAdGuard
94.140.14.14dns.adguard-dns.com185.113.30.30: другой адрес
Не подтвержденоего запись A — 185.113.30.30
Нет PTRCloudflare
104.18.0.1NXDOMAIN: имени нет
Нечего подтверждатьNXDOMAIN из зоны Cloudflare
Та же петля проходит по правому краю каждого результата: зелёная, когда имя ведёт обратно, жёлтая, когда оно ведёт в другое место.

Проверка обратного DNS для почтовых серверов: что требуют Gmail, Yahoo и Outlook.com

Все трое требуют PTR-запись для каждого IP, с которого идёт отправка. Gmail также требует, чтобы имя разрешалось обратно в тот же IP, а Yahoo — «действительную прямую и обратную DNS-запись»; оба — для всех отправителей с февраля 2024 года. Политика Outlook.com требует действительный обратный DNS и ничего не говорит о прямом шаге.

Шаблонное имя вроде ec2-3-80-0-1.compute-1.amazonaws.com не нарушает ни одного правила: Yahoo лишь рекомендует осмысленное, не шаблонное имя, отражающее ваш домен. Outlook.com предупреждает, что подключения из динамических диапазонов IP могут не приниматься, — это касается пуловых имён интернет-провайдеров, а не статического имени облачного сервера по умолчанию. Раздел «Почта» показывает их как предупреждения, а требования — как «пройдено» или «не пройдено»; незавершённая проверка — ни то ни другое.

Две вещи никогда не считаются ошибкой: несколько PTR-записей, которые разрешает RFC 2181, и PTR, отличающийся от имени HELO сервера: RFC 5321 §4.1.4 запрещает отклонять почту из-за этого. Gmail ограничивает скорость кодами 421 4.7.0 или 451 4.7.23 и блокирует кодом 550 5.7.25, когда PTR нет или он не указывает обратно.

Обязательно, рекомендуется, не указанособственные страницы каждого получателя, проверено 2026-10-23
ПроверкаGmailправила для отправителейYahoo Mailрекомендации для отправителейOutlook.comполитика postmaster
Есть PTR-записьобязательнообязательнообязательно
Имя указывает обратнообязательнообязательноне указано
Не шаблонное и не динамическоене указанорекомендуетможет отклонять динамические IP
Четыре реальных отправителя, проверены вживую
mail-sor-f41.google.com209.85.220.41 · исходящий сервер самого Gmailпройденопройденопройдено
ec2-3-80-0-1.compute-1.amazonaws.com3.80.0.1 · имя AWS по умолчаниюпройденопройденопредупреждениепройденопредупреждение
dns.adguard-dns.com94.140.14.14 · указывает на 185.113.30.30не пройденоне пройденопройдено
Нет PTR104.18.0.1 · NXDOMAINне пройденоне пройденоне пройдено

Ответы Gmail

421 4.7.0 · 451 4.7.23Ограничение скорости: нет PTR или его прямая запись не совпадает с IP отправителя
550 5.7.25Блокировка: нет PTR или прямая запись не ссылается на IP отправителя
550-5.7.1По IPv6: письмо не соответствует правилам отправки по IPv6 для PTR-записей и аутентификации
Не проходят только требования. Рекомендация Yahoo и предупреждение Outlook.com о динамических IP показаны как предупреждения. Коды Gmail взяты из его справочника ошибок SMTP.

Кто управляет обратным DNS и как задать PTR-запись

Владелец блока адресов, а не владелец домена. IANA делегирует обратную зону каждого блока его региональному интернет-регистратору, а регистратор — сети, которой принадлежат адреса; она ведёт зону сама или передаёт дальше (RFC 3172). Владение example.com не позволяет дать имя адресу: это должен сделать ваш хостинг или интернет-провайдер.

Облака позволяют клиентам задать его самим, у каждого своё правило: AWS требует сначала прямую запись A, Azure задаёт только IPv4 и не в портале, DigitalOcean строит PTR из имени Droplet, Google Cloud просит подтвердить домен. На домашней линии собственный PTR обычно бывает только на бизнес-тарифе со статическим IP: спросите провайдера. Блоки меньше /24 часто передаются через CNAME (RFC 2317), и инструмент следует за ними, куда бы они ни вели.

Изменение доходит до всех, когда кэши сбрасывают старый ответ: решает TTL старой записи или время кэширования «нет PTR», если записи не было (RFC 2308), а не фиксированные 24–48 часов. Vultr сообщает, что его изменения занимают от 6 до 12 часов.

Кто передаёт зону вниззаписанные спуски, 2026-10-23
  1. in-addr.arpaАдминистрирует IANA, обслуживают серверы от a до f.in-addr-servers.arpa
  2. 8.in-addr.arpa · 208.in-addr.arpaРегиональный регистратор блока: ARIN для 8.0.0.0/8 и 208.0.0.0/8ARINRIPE NCCAPNICLACNICAFRINIC
  3. 8.8.8.in-addr.arpaВладелец 8.8.8.0/24: PTR пишет Google, на серверах ns1–ns4.google.com
17.in-addr.arpaУнаследованный /8, делегированный из in-addr.arpa прямо на собственные серверы Apple
129.2.0.192.in-addr.arpa CNAME 129.128/26.2.0.192.in-addr.arpaСобственный пример RFC 2317: для блока меньше 256 адресов родительская зона хранит CNAME в зону, которую ведёт владелец блока. Имя дочерней зоны — лишь соглашение.
Каждый шаг — отсылка, записанная 2026-10-23, кроме шага RFC 2317: это собственный пример RFC на блоке для документации.
Где каждый провайдер задаёт PTRсобственная документация каждого провайдера, проверено 2026-10-23
ПровайдерКак задатьОграничения
AWSДокументацияТолько Elastic IP. Опубликуйте для своего имени запись A, указывающую на Elastic IP, затем EC2 console › Elastic IPs › адрес › Actions › Update reverse DNS или aws ec2 modify-address-attribute --allocation-id … --domain-name mail.example.com.Прямая запись A должна существовать заранее. Пока у Elastic IP есть обратная запись, он закреплён за вашим аккаунтом. В GovCloud (US) задать её может только поддержка AWS. Ограничения порта 25 снимаются отдельным запросом.
Microsoft AzureДокументацияЗадайте ReverseFqdn публичного IP: az network public-ip update --resource-group RG --name PublicIp --reverse-fqdn mail.example.com. (имя оканчивается точкой) или Set-AzPublicIpAddress в PowerShell.Только IPv4: адреса IPv6, принадлежащие Azure, PTR не получают. Не в портале Azure. Имя должно разрешаться в этот IP или принадлежать вашей подписке. Один PTR на адрес, по умолчанию его нет, и нет для App Service и Application Gateway.
Google CloudДокументацияСначала подтвердите домен (Search Console или запись A на внешний IP ВМ). Затем VM instances › экземпляр › Edit › основной сетевой интерфейс › Public DNS PTR record или gcloud compute instances update-access-config INSTANCE --public-ptr --public-ptr-domain mail.example.com.Только основной сетевой интерфейс; нет PTR для балансировщиков нагрузки и Cloud NAT. PTR для IPv6 требуют подсеть dual-stack или только IPv6 с внешним IPv6. Имя по умолчанию — <reversed-ip>.bc.googleusercontent.com.
HetznerДокументацияCloud: Hetzner Console › сервер (или Primary IP, Floating IP) › Networking › edit rDNS рядом с IP; для IPv6 введите только часть интерфейса, например ::1. Dedicated: Robot › сервер › IPs, поле рядом с каждым IP.Обратную зону ведёт Hetzner. Запись rDNS считается действительной, только если она разрешается в обе стороны (FCrDNS). По умолчанию — static.<reversed-ip>.clients.your-server.de.
DigitalOceanДокументацияРедактора PTR нет: назовите или переименуйте Droplet полным нужным именем, например mail.example.com, и DigitalOcean создаст PTR из него.Имя должно быть корректным FQDN (my-droplet не даёт PTR). PTR получает только первый адрес IPv6 Droplet. Создать PTR вручную нельзя.
OVHcloudДокументацияСначала направьте на IP запись A или AAAA. Затем Control Panel › Network › Public IP Addresses › кнопка действий в строке IP › Configure the reverse DNS (Public Cloud: ваш проект › Public IPs).OVHcloud сразу проверяет, что имя указывает обратно на тот же IP, поэтому запись уже должна работать. Имя должно быть в нижнем регистре и оканчиваться точкой.
VultrДокументацияProducts › Compute › экземпляр › Settings › IPv4 или IPv6 › Public Network: нажмите на имя в столбце Reverse DNS, введите полное имя и сохраните.Vultr просит, чтобы имя разрешалось обратно в тот же IP, и сообщает, что изменения появляются через 6–12 часов. По умолчанию — <ip>.vultrusercontent.com.
Akamai Cloud (Linode)ДокументацияСначала добавьте запись A (и AAAA). Затем Cloud Manager › Linodes › Linode › Network › меню с многоточием у IP › Edit RDNS и введите полное имя; пустое поле возвращает имя по умолчанию.Выдаёт ошибку, пока запись A не совпадёт с IP. Диапазоны IPv6: Edit rDNS для диапазона, затем для каждого адреса. По умолчанию: <ip-with-dashes>.ip.linodeusercontent.com, у старых — li<n>-<n>.members.linode.com.
Oracle CloudДокументацияСначала создайте запись A или AAAA, затем откройте запрос в поддержку с IP, нужным именем для PTR и именем прямой записи; Oracle проверит его и создаст PTR.Один PTR на IP, только по запросу в поддержку; прямая запись должна разрешаться в этот IP.
Ваш интернет-провайдерRFC 8501Обратитесь к своему интернет-провайдеру: задать PTR может только провайдер, которому принадлежит адрес. На практике для этого нужен статический IP на бизнес-тарифе.Домашние линии сохраняют пуловое имя провайдера, а получатели вроде Comcast считают такие имена динамическими и отклоняют прямую почту с них.
Сколько длится изменение: пока кэши не сбросят старый PTR (его TTL) или закэшированный ответ «нет PTR» (RFC 2308). Реальные TTL: сутки у 8.8.8.8, 7 дней у resolver1.opendns.com, 5 минут у имени EC2 по умолчанию.

Почему у большинства адресов IPv6 нет PTR-записи

Потому что их слишком много, чтобы давать имена по одному. Интернет-провайдер может заранее задать PTR для каждого выдаваемого адреса IPv4, но в одном /48 — 2⁸⁰ адресов, а устройства выбирают себе адреса сами, часто недолговечные (RFC 8501).

RFC 8501 перечисляет варианты для провайдера: отвечать NXDOMAIN (нет PTR, самый точный вариант), wildcard-PTR на префикс каждого клиента, динамический DNS, делегирование зоны клиенту или генерация согласованных PTR и AAAA на лету. Прямую проверку ломает только wildcard; для домашних пользователей чистый NXDOMAIN — нормально, тайм-аут — нет.

Серверам, отправляющим почту по IPv6, всё равно нужен PTR с прямым подтверждением: Gmail отклоняет почту по IPv6 без него с ответом 550-5.7.1 Message does not meet IPv6 sending guidelines regarding PTR records and authentication. Azure вообще не даёт своим адресам IPv6 PTR.

Один PTR на адрес: масштаб IPv4 и IPv6RFC 8501
/24один блок IPv428 = 256
/64одна подсеть IPv6264 = 18 446 744 073 709 551 616
/48одна площадка IPv6280 = 1 208 925 819 614 629 174 706 176

Длина полосы: биты адресного пространства. Каждый бит удваивает количество.

Даже при 1000 PTR-записей в секунду /48 не был бы заполнен и через 38 триллионов лет (RFC 8501).

Варианты RFC 8501 для провайдера

NXDOMAINнет имениНикакого PTR: самый точный ответ, но почтовые серверы, скорее всего, отклонят таких отправителей.
Wildcardне совпадаетОдно имя на весь префикс: его прямой запрос не может вести обратно к каждому адресу.
Динамический DNSсовпадаетКаждый хост сам отправляет обновления AAAA и PTR, как только получит адрес.
Делегировать зонуна усмотрение клиентаКлиенты со своими DNS-серверами получают обратную зону своего префикса; большинству домашних это недоступно.
На летусовпадаетСервер создаёт PTR по запросу вместе с соответствующей AAAA.

Почтовому серверу всё равно нужен собственный PTR с прямым подтверждением:2001:4860:4860::8888 → dns.google → 2001:4860:4860::8888

Как проверить Googlebot и других поисковых роботов

Запросите PTR адреса посетителя, убедитесь, что имя оканчивается на документированный домен краулера, затем выполните прямой запрос этого имени и проверьте, что он возвращает тот же адрес: 66.249.66.1 → crawl-66-249-66-1.googlebot.com → 66.249.66.1. Или сверьте адрес с опубликованным списком оператора (метод Google).

Документированные домены: googlebot.com и google.com у Google, search.msn.com у Bingbot, applebot.apple.com у Applebot, yandex.ru, yandex.net и yandex.com у Яндекса. DuckDuckBot публикует только список адресов.

googleusercontent.com сам по себе ничего не доказывает: каждая ВМ Google Compute Engine по умолчанию получает имя в этом домене, поэтому инструмент считает его Google, только если адрес есть в опубликованных списках Google. Имя с правильным окончанием, которое не указывает обратно, — подделка, и инструмент так и пишет.

Решают два запроса66.249.66.1, проверено 2026-10-23
  1. Обратный запросPTR адреса посетителя.66.249.66.1 → crawl-66-249-66-1.googlebot.com
  2. Домен Google?Оканчивается на googlebot.com. Имени в googleusercontent.com понадобился бы ещё адрес в списках Google.
  3. Прямой запросcrawl-66-249-66-1.googlebot.com → 66.249.66.1Тот же адрес: настоящий Googlebot.
Подделка: «Googlebot» в user agent, с адреса 203.0.113.9Его обратный запрос отвечает NXDOMAIN, поэтому проверка останавливается на шаге 1. (Адрес для документации, RFC 5737.)
КраулерPTR-имя оканчивается наОпубликованный список IP
GooglebotPTR и прямой запрос или списокgooglebot.comcommon-crawlers.json
Особые краулеры GooglePTR и прямой запрос или списокrate-limited-proxy-….google.comspecial-crawlers.json
Сборщики Google по запросу пользователейPTR и прямой запрос или списокgoogle-proxy-….google.com….gae.googleusercontent.comтолько со спискомuser-triggered-fetchers-google.jsonuser-triggered-fetchers.jsonuser-triggered-agents.json
BingbotPTR и прямой запрос или списокsearch.msn.combingbot.json
ApplebotPTR и прямой запрос или списокapplebot.apple.comapplebot.json
YandexBotPTR и прямой запросyandex.ruyandex.netyandex.comнет
DuckDuckBotтолько список IPнетduckduckbot.json

Работают сегодня, каждый указывает обратно:crawl-66-249-66-1.googlebot.commsnbot-157-55-39-1.search.msn.com17-58-101-179.applebot.apple.com

Домены и списки — с собственной страницы каждого оператора, проверено 2026-10-23. Bing просит обновлять его список ежедневно.

Ошибки обратного DNS

NXDOMAIN означает, что обратного имени не существует: для адреса никто не задал PTR. NOERROR без ответа (NODATA) означает, что имя существует, но PTR в нём нет. Резолверы хранят любой из этих ответов в течение времени негативного кэширования из SOA зоны (RFC 2308), поэтому новый PTR может появиться только по его истечении.

SERVFAIL означает, что зона неисправна, чаще всего из-за неработающего делегирования: серверы, указанные для зоны, её не обслуживают, и все резолверы сдаются. REFUSED приходит от сервера, который вообще отказывается отвечать за зону. Частные адреса и адреса для документации никогда не получают публичного PTR: инструмент отвечает на них по реестру IANA, никого не спрашивая.

Каждый ответ — на реальном примерепроверено 2026-10-23
NOERROR8.8.8.8Имя задано: PTR возвращается со своим TTL.PTR dns.google. · TTL 86400ns1.google.com · aa
NXDOMAIN104.18.0.1Такого имени нет: в зоне Cloudflare нет PTR для этого адреса, и она так и отвечает.SOA 18.104.in-addr.arpacruz.ns.cloudflare.com … 3600
NODATANOERROR, 0 answers2001:4860:4860::/48Имя есть, PTR нет: имя /48 Google, под которым есть другие имена.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpaSOA ns1.google.com … 60
SERVFAIL203.0.113.50выдуманный пример, адрес для документацииНеработающее делегирование: регистратор указывает два сервера, которые не обслуживают зону, и резолверы сдаются.APNIC → ns1, ns2.example.net: lameEDE 22: No Reachable Authority
NXDOMAINAS112192.168.1.1Частный адрес: публичное дерево передаёт 168.192.in-addr.arpa серверам AS112 от IANA, которые отвечают NXDOMAIN.blackhole-1.iana.orgSOA prisoner.iana.org … 604800
«Нет» кэшируется на негативное время из SOA (RFC 2308): 1 час у Cloudflare, 60 секунд у Google, 7 дней от AS112.

Обратный DNS: частые вопросы

Что такое обратный DNS-запрос?

Обратный DNS-запрос находит имя хоста по IP-адресу, читая его PTR-запись, — в противоположность обычному запросу, который превращает имя в адрес. Адрес переворачивается в особое имя, например 8.8.8.8.in-addr.arpa, и запрашивается у DNS-серверов, которые его хранят. Для 8.8.8.8 ответ — dns.google. Этот инструмент также проверяет, что имя указывает обратно.

Как проверить PTR-запись через dig или nslookup?

Выполните dig -x 8.8.8.8 в macOS или Linux: dig сам переворачивает адрес, и PTR появляется в секции ответа. В Windows nslookup 8.8.8.8 печатает его в строке Name:. Чтобы обойти все кэши, спросите собственный DNS-сервер зоны: dig -x 8.8.8.8 @ns1.google.com +norecurse. Раздел «Команды» здесь подставляет в каждую команду ваш адрес и сервер его зоны.

Почему у моего IP-адреса нет обратного DNS?

Потому что для него никто не задал PTR-запись. Сделать это может только владелец блока адресов, поэтому ответ — NXDOMAIN, пока ваш хостинг или интернет-провайдер её не добавит. У большинства домашних подключений и большинства адресов IPv6 её нет. Если вместо этого проверка показывает SERVFAIL, неисправна сама обратная зона — обычно из-за неработающего делегирования, которое должен исправить провайдер.

Как настроить или изменить PTR-запись?

У того, кто выдал вам адрес. В AWS сначала опубликуйте прямую запись A, затем обновите обратный DNS Elastic IP. Azure задаёт ReverseFqdn у публичного IP, DigitalOcean берёт имя Droplet, у Hetzner, OVHcloud, Vultr и Linode есть поле rDNS рядом с каждым адресом. Для домашней или офисной линии обратитесь к провайдеру: обычно это доступно только на бизнес-тарифах со статическим IP.

Сколько времени применяется изменение PTR-записи?

Столько, сколько кэши хранят старый ответ. Каждый резолвер может отдавать старый PTR, пока не истечёт его TTL, — часто от часа до суток, — или закэшированный ответ «нет PTR» в течение времени негативного кэширования зоны. Фиксированных 24–48 часов нет. Раздел «Копии» показывает, сколько времени осталось у копий Google и Cloudflare.

Может ли у IP-адреса быть несколько PTR-записей?

Да. DNS допускает несколько PTR-записей для одного адреса, и RFC 2181 говорит, что не следует предполагать никакого предела: у 208.67.222.222 их четыре. Почтовые проверки проходят, если обратно указывает любая из них. Некоторые инструменты читают только первое имя, поэтому имя, которое вы используете для почты, должно иметь прямое подтверждение. Один PTR — самая простая настройка, а не требование.

Что такое FCrDNS?

Обратный DNS с прямым подтверждением: имя из PTR при прямом запросе возвращает тот же адрес. 8.8.8.8 разрешается обратно в dns.google, а dns.google — в 8.8.8.8, поэтому проверка пройдена. Почтовые серверы называют её iprev. Она важна, потому что владелец адреса может вписать в PTR любое имя; только прямой запрос показывает, что владелец домена согласен.

Нужен ли обратный DNS для отправки почты?

Да, для любого сервера, который отправляет почту напрямую. Gmail требует, чтобы у каждого IP отправителя был PTR, разрешающийся обратно в этот IP, Yahoo требует действительные прямую и обратную DNS-записи, а Outlook.com — действительный обратный DNS. Без него почта ограничивается или отклоняется, например с кодом Gmail 550 5.7.25. Шаблонное имя провайдера проходит правила, но вызывает предупреждения.

Что значит «reverse DNS is not a valid hostname»?

Так пишут тесты почтовых серверов, когда PTR-имя IP отправителя не работает как имя хоста для этого IP: чаще всего PTR нет вовсе или у имени нет записи A, указывающей обратно на тот же адрес. Проверьте здесь IP отправителя: раздел PTR покажет имя и его прямую проверку, а раздел «Почта» — какое правило нарушено.

Обратный DNS — то же самое, что reverse IP lookup?

Нет. Обратный DNS читает имя или имена, которые владелец адреса опубликовал в PTR-записях. Reverse IP lookup пытается перечислить все сайты на адресе, а для этого нужны данные пассивного DNS, собранные со многих резолверов за долгое время. Многие сайты смешивают эти термины. На нашей странице «Имя хоста по IP» объяснено, что может найти каждый метод.

Работает ли обратный DNS с IPv6?

Да. Адреса IPv6 запрашиваются в ip6.arpa со всеми 32 шестнадцатеричными цифрами в обратном порядке, поэтому 2001:4860:4860::8888 даёт имя из 32 меток, которое инструмент строит и запрашивает за вас. У большинства адресов IPv6 PTR нет, потому что провайдеры не могут заранее задать имена для такого количества адресов, но серверам, отправляющим почту по IPv6, он нужен.

Почему у частного IP-адреса нет PTR?

Частные адреса, такие как 192.168.1.1 или 10.0.0.1, используются одновременно внутри множества сетей, поэтому публичный DNS не может дать им имена. Их обратные запросы — дело резолвера вашей собственной сети; просочившиеся наружу доходят до серверов AS112, которые отвечают, что такого имени нет. Инструмент объясняет каждый диапазон специального назначения с его RFC, никого не спрашивая.