Dns обратный – Опасный резолв. Разбираем на пальцах три мощных вектора атак через DNS — «Хакер»

Содержание

Что такое обратный DNS? Основные инструменты для выполнения обратного поиска DNS

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

Мы все знаем, что такое DNS и как он работает. Но даже некоторые IT-ботаники иногда забывают о rDNS, а третьи, которые только что присоединились к клубу, никогда даже не слышали о нем.

На простом языке обратный DNS или rDNS делает противоположное традиционному DNS. То есть, вместо преобразования доменного имени на IP, он преобразует IP к имени хоста.

Разрешение rDNS – это совершенно отдельный механизм от обычного разрешения DNS. Например, если домен “yourcompany.com” указывает на IP 1.2.3.4 (фиктивный IP-адрес), это не обязательно означает, что обратное разрешение для IP является 1.2.3.4.

Для хранения записей rDNS существует определенный тип записи DNS, называемый записью PTR. Эта запись также известна как ”запись ресурсов” (RR) и задает IP-адреса всех систем, используя инвертированную нотацию.

Эта конфигурация rDNS позволяет выполнять поиск IP-адреса в DNS, так как inaddr.arpa домен добавляется в инвертированную нотацию IP, превращая IP в доменное имя.

Например: чтобы преобразовать IP-адрес 1.2.3.4 в PTR-запись, нам нужно инвертировать IP и добавить домен inaddr.arpa в результате чего получается следующая запись: 4.3.2.1.in-addr.arpa.

Классическая работа системы DNS заключается в преобразовании или разрешении IP-адресов в имена, но некоторые сценарии требуют обратного, и это означает, что имена подключенных к интернету устройств переводятся с их IP-адресов. Это то, что называется rDNS, или обратное разрешение.

Поддерживают ли все типы IP-адресов rDNS? Безусловно, и IPv4 и IPv6 поддерживают поиск rDNS. В случае адресов на основе IPv4 поисковые запросы используют специальный домен in-addr.arpa, в то время как для IPv6 rDNS поиск специального домена ip6.arpa используется.

Что такое обратный DNS? Основные инструменты для выполнения обратного поиска DNS

Нужен ли мне rDNS? Текущее использование обратного DNS

Насколько важна rDNS тогда? Может ли мой интернет-бизнес жить без него?

Ответ-да…и нет. В то же время.

Если у вас нет настройки rDNS для вашей ИТ-инфраструктуры, она все равно будет работать. Это не является строгим требованием. Однако некоторые вещи могут работать не так, как ожидалось, или могут вызвать трудности. Продолжай читать.

Когда rDNS полезно?

  • Если вы хотите, чтобы предотвратить проблемы с электронной почтой. Если вы размещаете свой собственный почтовый сервер, rDNS становится довольно полезным для ваших исходящих писем. Запись rDNS позволяет отслеживать происхождение электронной почты, повышая доверие к почтовому серверу и становясь надежным источником для многих популярных поставщиков услуг электронной почты, таких как Gmail, Yahoo, Hotmail и других. Некоторые серверы входящей электронной почты даже не позволяют вашей электронной почте поступать на их почтовые ящики, Если у вас нет настройки записи rDNS. Поэтому, если вы используете свой собственный почтовый сервер, вы захотите иметь его в виду.
  • Когда вы проводите расследование киберпреступности. Еще одно популярное использование обратных записей DNS-это выявление потенциальных угроз и массовые сканеры по всему интернету. Используя обе конечные точки API безопасности или веб-продукты, такие как SurfaceBrowser, вы или ваша команда можете легко идентифицировать авторов и сети, стоящие за массовым сканированием, распространением вредоносных программ или другими видами вредоносных действий — так же, как Трой Мурш показал в нашем блоге, как использовать обратные записи DNS для идентификации массовых сканеров .

Как я могу выполнить обратный поиск DNS?

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

Некоторые из этих веб-утилит известны как обратные инструменты DNS, и все они делают одно и то же: запрашивают данный IP-адрес для разрешения имени хоста. Давайте сначала рассмотрим некоторые примеры на основе терминалов.

Мощная команда dig приходит на помощь, когда нам нужно выполнить обратный поиск DNS. С помощью параметра-x можно выполнить простой обратный поиск, чтобы сопоставить адрес с именами всего за несколько секунд.

Этот параметр dig автоматически выполняет поиск для традиционного имени IP-адреса, такого как 94.2.0.192.in-addr.arpa, и установите тип запроса и класс в PTR и IN соответственно для адресов IPv6. Поиск rDNS выполняется с использованием формата nibble под IP6.ARPA домен.

Пример вывода:

[[email protected] ~]$ dig -x 1.1.1.1
; <<>> DiG 9.11.10-RedHat-9.11.10-1.fc30 <<>> -x 1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56773
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 7
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;1.1.1.1.in-addr.arpa. IN PTR
;; ANSWER SECTION:
1.1.1.1.in-addr.arpa. 1096 IN PTR one.one.one.one.
;; AUTHORITY SECTION:
1.1.1.in-addr.arpa. 69422 IN NS ns3.cloudflare.com.
1.1.1.in-addr.arpa. 69422 IN NS ns7.cloudflare.com.
;; ADDITIONAL SECTION:
ns3.cloudflare.com. 86027 IN A 162.159.7.226
ns3.cloudflare.com. 86027 IN A 162.159.0.33
ns3.cloudflare.com. 86027 IN AAAA 2400:cb00:2049:1::a29f:21
ns3.cloudflare.com. 86027 IN AAAA 2400:cb00:2049:1::a29f:7e2
ns7.cloudflare.com. 203 IN A 162.159.6.6
ns7.cloudflare.com. 203 IN A 162.159.4.8
;; Query time: 13 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Sep 18 11:20:01 -03 2019
;; MSG SIZE rcvd: 248

Самое интересное заключается в следующем:

1.1.1.1.in-addr.arpa. 1096 IN PTR one.one.one.one.

Вы можете grep выходные данные для более четкого результата.

Хост

Команда host, вероятно, является самой популярной командой, когда речь заходит о выполнении быстрого разрешения rDNS с терминала. Синтаксис довольно прост:

host XX.XX.XX.XX

Где XX. XX. XX. XX-это реальный IP-адрес. Давайте рассмотрим несколько примеров.

Cloudflare поставляется в первую очередь с обратным запросом разрешения DNS против 1.1.1.1:

$ host 1.1.1.1
1.1.1.1.in-addr.arpa domain name pointer 1.1.1.1.in-addr.arpa.

То же самое относится и к любому другому IP-адресу, например DNS-серверу Google:

$ host 8.8.8.8
8.8.8.8.in-addr.arpa domain name pointer dns.google.

Или наши собственные securitytrails.com IP-адрес:

$ host 151.139.243.5
Host 5.243.139.151.in-addr.arpa. not found: 3(NXDOMAIN)

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

G-Suite Toolbox Dig

Некоторое время назад Google выпустила очень полезный ресурс под названием G-Suite dig , онлайн-утилита, которая позволяет выполнять любой тип DNS-запросов на основе простого, но сложного веб-интерфейса.

В этом случае выберите запись “PTR”, введите свой IP-адрес и получите полный результат rDNS за считанные секунды.

Недостатком этой утилиты является то, что она позволяет получать результаты только для одного IP-адреса, что не удобно, когда вам нужно выполнить массовое сканирование rDNS.

Обратная конечная точка DNS API

Использование нашего мощного API является еще одним отличным источником для запроса нашей пассивной базы данных DNS для любых записей PTR компании.

Конечная точка “/v1/ips/list” позволяет запрашивать домен apex (в этом случае cloudflare.com), так что вы можете легко обнаружить все известные IP-адреса, связанные с Cloudflare.com доменное имя.

Давайте использовать быстрый скрипт python, чтобы увидеть, как это выглядит:

import requests
url = "https://api.securitytrails.com/v1/ips/list"
querystring = {"apikey":"your_api_key_here","page":"1"}
payload = "{\"query\":\"ptr_part = 'cloudflare.com'\"}"
response = requests.request("POST", url, data=payload, params=querystring)
print(response.text)

Пример вывода:

Что такое обратный DNS? Основные инструменты для выполнения обратного поиска DNS

В дополнение к записям PTR, вы также найдете открытые порты для каждого из хостов, возвращенных нашей службой API.

Благодаря нашему полностью основанному на HTTP API, вы также можете выполнить простой запрос CURL из командной строки или использовать любые другие популярные языки, включая Node.js, JavaScript, Ruby, Go и PHP.

Массивная разведка rDNS

Когда мы говорим, что SurfaceBrower – это идеальный инструмент для исследования поверхности атаки “все-в-одном”, мы действительно имеем это в виду. Помимо всех зон DNS, доменных имен, SSL и открытых портов данных он имеет, SurfaceBrowser может быть использован в качестве инструмента массового обратного поиска DNS.

Чтобы изучить данные rDNS от любой компании, просто запустите SurfaceBrowser с консоли вашего аккаунта по адресу: https://securitytrails.com/app/sb/

Выберите любое доменное имя, которое вы хотите изучить, а затем нажмите на опцию “обратный DNS”, как показано ниже:

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

Первое, что вы увидите при загрузке области PTR-записей, – это сводка по открытым портам и сводка по аналогичным записям, что позволяет легко фильтровать всю текущую информацию rDNS в соответствии с вашими потребностями.

В этом случае, исследуя fbi.gov доменное имя выявило 289 записей. Каждый из них может быть изучен в области результатов, что позволяет исследовать запись PTR, открытые порты и количество связанных IP-адресов. Взглянуть:

Если вам нужно найти связанные IP-адреса, указывающие на любую PTR-запись, просто нажмите число+ для немедленных результатов::

Что такое обратный DNS? Основные инструменты для выполнения обратного поиска DNS

Этот второй PTR-экран данных показывает вам общее количество IP-адресов, а также где они размещены и текущие открытые порты, найденные для каждого из них.

fbi.gov это “маленькая ” организация, когда речь заходит о PTR-записях, хотя мы нашли много полезной информации. Но вот что происходит, когда вы исследуете большую онлайн-компанию, такую как Google:

Ибо … cache.google.com мы нашли около 94 тыс. IP-адресов, связанных с этой записью PTR. Представьте себе выполнение этого поиска с помощью традиционных обратных инструментов DNS. Это может занять целую вечность!

Последняя мысль

Сегодня мы узнали, что обратный DNS-это не только отличный способ улучшить ваши исследования кибербезопасности, но и сохранить вашу электронную почту в отличной форме, используя правильные PTR-записи.

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

Как получить reverse dns lookup

Что такое Reverse DNS легко понять, если вы знаете что такое DNS. Получение Reverse DNS — противоположенность DNS.

Т.е. если традиционный (прямой) DNS заключается в получении ip-адреса по хосту, то Reverse DNS (обратный, противоположенный) — это получение хоста по ip-адресу. Также Reverse DNS называют PTR-записью (pointer, указатель).

Как получить запись reverse DNS lookup на linux?

Для получения reverse DNS нужно воспользоваться одной из двух команд:

  1. nslookup IP
  2. dig +short -x IP

Если вам нужно только имя хоста (без дополнительной информации), то удобно будет воспользоваться командой dig с опциями -x и +short , которая вернёт одну строку - только искомый host.

-x - опция говорит включить обратный поиск DNS вместо прямого. Обратный поиск DNS (reverse dns lookup) означает, что вы хотите искать домен или имя хоста по IP-адресу.

+short - опция скрывает информацию (номер порта и адрес) о сервере, который предоставил ответ.

$ nslookup 93.125.99.10
Server:		127.0.1.1
Address:	127.0.1.1#53

Non-authoritative answer:
10.99.125.93.in-addr.arpa	name = vh50.hosterby.com.

Authoritative answers can be found from:
99.125.93.in-addr.arpa	nameserver = ns1.tutby.com.
99.125.93.in-addr.arpa	nameserver = ns2.tutby.com.
ns2.tutby.com	internet address = 178.124.133.100
ns1.tutby.com	internet address = 93.125.30.200


$ dig +short -x 93.125.99.10
vh50.hosterby.com.

Как видно, dig вернул всего одну строку vh50.hoster.by.

Пример reverse DNS на картинке:

reverse dns lookup

Хост jeka.by висит на ip 93.125.99.10. Это дешёвый shared хостинг. На этом IP висит большое количество сайтов. Для этого же ip обратным адресом является хост моего хостера vh50.hosterby.com.

Солидные ресурсы в обязательном порядке имеют собственные настроенные reverse dns. Это нужно хотя бы для того, чтобы вероятность попадания электронных писем в спам была меньше. Для этого адрес в поле From должен совпадать с доменом, указанным в reverse dns (совпадать с PTR). Это связано с тем, что спамеры часто подделывают доменные имена при отправке почты.

Для PTR записей нет конкретных технических требований. Но всё же большинство провайдеров используют следующие правила:

  • Для каждого IP-адреса существует одна единственная PTR запись;
  • Для серверa с несколькими IP-адресами будут прописаны несколько PTR записей, по одной на каждый IP-адрес;
  • Для любого почтового сервера должна быть установлена MX-запись и A-запись – это правило является одним из самых важных;
  • Для каждой PTR записи должна быть А-запись, а вот наоборот – не обязательно.
Дата добавления: 5 лет назад reverse dns lookup

Просмотров: 246

Обратный DNS - это... Что такое Обратный DNS?

  • DNS — У этого термина существуют и другие значения, см. DNS (значения). DNS Название: Domain Name System Уровень (по модели OSI): Прикладной Семейство: TCP/IP Порт/ID: 53/TCP, 53/UDP Назначение протокола: Разрешение доменных имён …   Википедия

  • DNS-сервер — DNS сервер, name server  приложение, предназначенное для ответов на DNS запросы по соответствующему протоколу. Также DNS сервером могут называть хост, на котором запущено приложение. Содержание 1 Типы DNS серверов 2 Виды DNS запросов …   Википедия

  • Обратный запрос DNS — in addr.arpa специальная , предназначенная для определения имени хоста по его IPv4 адресу, используя PTR запись. Адрес хоста AAA.BBB.CCC.DDD транслируется в обратной нотации и превращается в DDD.CCC.BBB.AAA.in addr.arpa. Благодаря иерархической… …   Википедия

  • ДНС — DNS Название: Domain Name System Уровень (по модели OSI): Прикладной Семейство: TCP/IP Порт/ID: 53/UDP Назначение протокола: Разрешение доменных имён Спецификация: RFC 1034, RFC 1035 / STD 13 Основные реализации (клиен …   Википедия

  • 6to4 — это переходный механизм, позволяющий передавать IPv6 пакеты через IPv4 сети, и не требующий создания двусторонних туннелей. Это, как правило, используется, когда конечный пользователь или сайт хотят получить соединение с IPv6 Интернетом, но не… …   Википедия

  • Электронная почта — Для термина «Mail» см. другие значения. Типичный интерфейс клиента электронной почты …   Википедия

  • Е-мейл — Типичный интерфейс клиента электронной почты, с возможностью выбора папок с сообщениями (слева), сообщений (справа вверху) и просмотра текста сообщений (справа внизу). Электронная почта (англ. email, e mail, от англ. electronic mail)  технология… …   Википедия

  • И-мэйл — Типичный интерфейс клиента электронной почты, с возможностью выбора папок с сообщениями (слева), сообщений (справа вверху) и просмотра текста сообщений (справа внизу). Электронная почта (англ. email, e mail, от англ. electronic mail)  технология… …   Википедия

  • Имейл — Типичный интерфейс клиента электронной почты, с возможностью выбора папок с сообщениями (слева), сообщений (справа вверху) и просмотра текста сообщений (справа внизу). Электронная почта (англ. email, e mail, от англ. electronic mail)  технология… …   Википедия

  • Имэйл — Типичный интерфейс клиента электронной почты, с возможностью выбора папок с сообщениями (слева), сообщений (справа вверху) и просмотра текста сообщений (справа внизу). Электронная почта (англ. email, e mail, от англ. electronic mail)  технология… …   Википедия

  • Настраиваем rDNS и PTR-записи | OpenRate.us

    Все почтовые серверы, осуществляющие подключения к почтовым серверам должны иметь валидные и осмысленные обратные DNS записи.

    Корректно настроенные rDNS адреса нужны, чтобы отправлять сообщения с вашего собственного сервера. Практически все почтовые серверы отвергнут приём сообщения ещё на стадии начала сессии, если у IP-адреса вашего сервера отсутствует запись в обратной зоне DNS. Причина отказа удалённым почтовым сервером может быть такой:

    550-"IP address has no PTR (address to name) record in the DNS, or when the PTR record does not have a matching A (name to address) record. Pls check and correct your DNS record."
    550-There's no corresponding PTR for your IP address (IP-address), which is 550 required. Sorry, bye.
    550 Your IP has no PTR Record

    Число 550 во всех трёх случаях является стандартным кодом почтового SMTP сервера, сообщающего о критической ошибке, которая препятствует дальнейшей работе в рамках данной почтовой сессии. Вообще все ошибки серии 500 являются критическими и продолжение передачи почты после их появления невозможно. Текст же поясняет причину отказа более подробно и сообщает, что администратор почтового сервера-получателя настроил его на проверку наличия у почтового сервера-отправителя записи в обратной зоне DNS (rDNS) и в случае её отсутствия сервер-получатель обязан отказывать отправителю в соединении (SMTP-ошибки серии 5XX).

    Настройка rDNS

    Правами на настройку обратной зоны DNS (reverse DNS) обладает лишь владелец соответствующего блока IP-адресов, которой эта зона соответствует. Как правило этим владельцем оказывается провайдер, владеющий собственной автономной системой.

    Оператору блока IP-адресов для регистрации обратной зоны DNS необходимо зарегистрировать в своём личном кабинете на сайте RIPE объект типа «domain», указать адрес DNS-серверов, которые будут поддерживать зону rDNS и настроить поддержку зоны вида 3.2.1.in-addr.arpa на них. За ресурсы в обратной зоне отвечает указатель (pointer) — запись типа PTR. К ней-то и идут запросы о разрешении IP-адреса и имя хоста (см. ниже описание принципа построения PTR записи).

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

    В обоих случаях имя IP-адресу почтового сервера, а особенно корпоративного почтового сервера, следует давать осмысленно.

    Примеры хороших имён для сервера почты:

    mail.domain.ru 
    mta.domain.ru 
    mx.domain.ru

    Примеры плохих имён:

    host-192-168-0-1.domain.ru
    customer192-168-0-1.domain.ru 
    vpn-dailup-xdsl-clients.domain.ru
    

    Такие имена с высокой вероятностью попадут под фильтр как назначенные клиентским компьютерам, на которых не может быть установлен почтовый сервер, следовательно с них вероятно рассылается спам.

    С успехом использовать запросы к обратным зонам DNS можно и нужно сразу после запуска почтового сервера. Для этого необходимо произвести лишь небольшую настройку ПО. В разных почтовых серверах настройка проверки rDNS делается по-разному:

    В Postfix необходимо включить опцию

    reject_unknown_client

    В Exim

    verify = reverse_host_lookup

    Проверка обратной зоны DNS: http://remote.12dt.com
    Введите свой IP адрес, если отображается ваш домен — настройка правильная

    PTR

    PTR-запись (от англ. pointer – указатель) связывает IP хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP хоста в обратной форме вернёт имя данного хоста.

    В целях уменьшения объёма нежелательной почты серверы-получатели электронной почты проверяют наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.

    in-addr.arpa — специальная доменная зона, предназначенная для определения имени хоста по его IPv4-адресу, используя PTR-запись. Адрес хоста AAA.BBB.CCC.DDD транслируется в обратной нотации и превращается в DDD.CCC.BBB.AAA.in-addr.arpa. Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP-адресов. Для этого в записях авторитативного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC/24) отвечает отдельный сервер.

    Например, если IP вашего почтового сервера 78.56.158.23. То в NS записи сервера или настройки хостера необходимо добавить следующую DNS запись (IP при этом записывается в обратном порядке):

    23.158.56.78.in-addr.arpa IN PTR mail.mydomain.ru.

    Проверка http://centralops.net/co/DomainDossier.aspx

    Источники

    Mailvalidator.ru

    Peterhost.ru

    Обратный просмотр DNS — Википедия

    Материал из Википедии — свободной энциклопедии

    Обратный просмотр DNS (англ. reverse DNS lookup) — обращение к особой доменной зоне для определения имени узла по его IP-адресу c помощью PTR-записи.

    Для выполнения запроса адрес узла переводится в обратную нотацию, способ перевода зависит от версии IP:

    • IPv4-адрес 192.168.0.1 превращается в 1.0.168.192.in-addr.arpa.;
    • IPv6-адрес 2001:db8::567:89ab — в b.a.9.8.7.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.[1].

    Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP-адресов. Для этого в записях авторитетного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC.000/24) отвечает отдельный сервер.

    Количество PTR-записей, описывающих разные имена, на один адрес не ограничивается спецификациями, но может ограничиваться размером UDP-пакета, так как DNS-сервер инкапсулирует свой ответ в UDP. В большинстве случаев для одного IP-адреса создаётся только одна PTR-запись, но бывает и так, что их создаётся множество — например, когда IP-адрес используется для нескольких виртуальных серверов с разными именами.

    Выполнение обратного запроса

    При запросе считывается запись «PTR», содержащая искомое доменное имя. Если запись отсутствует или соответственный поддомен не делегирован, то IP-адрес считается не имеющим обратной записи DNS.

    PTR-записи не требуют какой-либо специальной обработки, это простые записи, подобные CNAME, который определяет псевдонимы.

    in-addr.arpa

    DNS-запись in-addr.arpa выглядит так:

    56.34.12.10.in-addr.arpa. IN PTR host1.example.net.
    

    Это будет означать, что IP-адресу 10.12.34.56 соответствует имя узла host1.example.net.

    ip6.arpa

    DNS-запись ip6.arpa выглядит так:

    5.4.3.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR host1.example.net.
    

    Это будет означать, что IPv6-адресу 2001:0db8::1:2345 соответствует имя узла host1.example.net.

    Бесклассовая адресация

    При использовании бесклассовой адресации возникает проблема с делегированием отдельных подсетей, не совпадающих по размеру с классом (то есть с поддоменом очередного уровня).

    Для решения этой проблемы был создан RFC 2317, описывающий делегирование поддоменов in-addr.arpa в бесклассовой адресации.

    Для делегирования диапазонов адресов IPv6 используется доменная зона ip6.arpa.

    Интересные факты

    • Многие интернет-службы компании Google имеют в обратной зоне DNS записи, оканчивающиеся суффиксом «1e100.net», что является вариантом написания числа «гугол» в экспоненциальной нотации (единица, умноженная на 10 в степени 100).

    Примечания

    Источники

    Обратный просмотр DNS - Вики

    Обратный просмотр DNS (англ. reverse DNS lookup) — обращение к особой доменной зоне для определения имени узла по его IP-адресу c помощью PTR-записи.

    Для выполнения запроса адрес узла переводится в обратную нотацию, способ перевода зависит от версии IP:

    • IPv4-адрес 192.168.0.1 превращается в 1.0.168.192.in-addr.arpa.;
    • IPv6-адрес 2001:db8::567:89ab — в b.a.9.8.7.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.[1].

    Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP-адресов. Для этого в записях авторитетного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC.000/24) отвечает отдельный сервер.

    Количество PTR-записей, описывающих разные имена, на один адрес не ограничивается спецификациями, но может ограничиваться размером UDP-пакета, так как DNS-сервер инкапсулирует свой ответ в UDP. В большинстве случаев для одного IP-адреса создаётся только одна PTR-запись, но бывает и так, что их создаётся множество — например, когда IP-адрес используется для нескольких виртуальных серверов с разными именами.

    Выполнение обратного запроса

    При запросе считывается запись «PTR», содержащая искомое доменное имя. Если запись отсутствует или соответственный поддомен не делегирован, то IP-адрес считается не имеющим обратной записи DNS.

    PTR-записи не требуют какой-либо специальной обработки, это простые записи, подобные CNAME, который определяет псевдонимы.

    in-addr.arpa

    DNS-запись in-addr.arpa выглядит так:

    56.34.12.10.in-addr.arpa. IN PTR host1.example.net.
    

    Это будет означать, что IP-адресу 10.12.34.56 соответствует имя узла host1.example.net.

    ip6.arpa

    DNS-запись ip6.arpa выглядит так:

    5.4.3.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR host1.example.net.
    

    Это будет означать, что IPv6-адресу 2001:0db8::1:2345 соответствует имя узла host1.example.net.

    Бесклассовая адресация

    При использовании бесклассовой адресации возникает проблема с делегированием отдельных подсетей, не совпадающих по размеру с классом (то есть с поддоменом очередного уровня).

    Для решения этой проблемы был создан RFC 2317, описывающий делегирование поддоменов in-addr.arpa в бесклассовой адресации.

    Для делегирования диапазонов адресов IPv6 используется доменная зона ip6.arpa.

    Интересные факты

    • Многие интернет-службы компании Google имеют в обратной зоне DNS записи, оканчивающиеся суффиксом «1e100.net», что является вариантом написания числа «гугол» в экспоненциальной нотации (единица, умноженная на 10 в степени 100).

    Примечания

    Источники

    DNS записи

    DNS (англ. Domain Name System — система доменных имён) — распределённая система (распределённая база данных), способная по запросу, содержащему доменное имя хоста (компьютера или другого сетевого устройства), сообщить IP адрес или (в зависимости от запроса) другую информацию. DNS работает в сетях TCP/IP. Как частный случай, DNS может хранить и обрабатывать и обратные запросы, определения имени хоста по его IP адресу — IP адрес по таблице соответствия преобразуется в доменное имя, и посылается запрос на информацию типа «PTR».

    Ключевые характеристики DNS

    DNS обладает следующими характеристиками:

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

    DNS важна для работы Интернета, ибо для соединения с узлом необходима информация о его IP-адресе, а для людей проще запоминать буквенные (обычно осмысленные) адреса, чем последовательность цифр IP-адреса. В некоторых случаях это позволяет использовать виртуальные серверы, например, HTTP-серверы, различая их по имени запроса. Первоначально преобразование между доменными и IP-адресами производилось с использованием специального текстового файла HOSTS, который составлялся централизованно и обновлялся на каждой из машин сети вручную. С ростом Сети возникла необходимость в эффективном, автоматизированном механизме, которым и стала DNS.

    DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы описано в RFC 882 и RFC 883. В 1987 публикация RFC 1034 и RFC 1035 изменили спецификацию DNS и отменили RFC 882 и RFC 883 как устаревшие. Некоторые новые RFC дополнили и расширили возможности базовых протоколов.

    Дополнительные возможности

        * поддержка динамических обновлений
        * безопасные соединения (DNSsec)
        * поддержка различных типов информации (SRV-записи)

    Терминология и принципы работы

    Ключевыми понятиями DNS являются:

        * Зона — логический узел в дереве имён. Право администрировать зону может быть передано третьим лицам, за счёт чего обеспечивается распределённость базы данных. При этом персона, передавшая право на управление в своей базе данных хранит информацию только о существовании зоны (но не подзон!), информацию о персоне (организации), управляющей зоной, и адрес серверов, которые отвечают за зону. Вся дальнейшая информация хранится уже на серверах, ответственных за зону.
        * Доме́н — название зоны в системе доменных имён (DNS) Интернета, выделенной какой-либо стране, организации или для иных целей. Структура доменного имени отражает порядок следования зон в иерархическом виде; доменное имя читается слева направо от младших доменов к доменам высшего уровня (в порядке повышения значимости), корневым доменом всей системы является точка (.), следом идут домены первого уровня (географические или тематические), затем — домены второго уровня, третьего и т. д. (например, для адреса ru.wikipedia.org домен первого уровня — org, второго wikipedia, третьего ru). На практике точку в конце имени часто опускают, но она бывает важна в случаях разделения между относительными доменами и FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена).
        * Поддомен (англ. subdomain) — имя подчинённой зоны. (например, wikipedia.org — поддомен домена org, а ru.wikipedia.org — домена wikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения.
        * DNS-сервер — специализированное ПО для обслуживания DNS. DNS-сервер может быть ответственным за некоторые зоны и/или может перенаправлять запросы вышестоящим серверам.
        * DNS-клиент — специализированная библиотека (или программа) для работы с DNS. В ряде случаев DNS-сервер выступает в роли DNS-клиента.
        * Ответственность (англ. authoritative) — признак размещения зоны на DNS-сервере. Ответы DNS-сервера могут быть двух типов: ответственные (когда сервер заявляет, что сам отвечает за зону) и неответственные (англ. Non-authoritative), когда сервер обрабатывает запрос, и возвращает ответ других серверов. В некоторых случаях вместо передачи запроса дальше DNS-сервер может вернуть уже известное ему (по запросам ранее) значение (режим кеширования).
        * DNS-запрос (англ. DNS query) — запрос от клиента (или сервера) серверу. Запрос может быть рекурсивным или нерекурсивным. Нерекурсивный запрос либо возвращает данные о зоне, которая находится в зоне ответственности DNS-сервера (который получил запрос) или возвращает адреса корневых серверов (точнее, адрес любого сервера, который обладает большим объёмом информации о запрошенной зоне, чем отвечающий сервер). В случае рекурсивного запроса сервер опрашивает серверы (в порядке убывания уровня зон в имени), пока не найдёт ответ или не обнаружит, что домен не существует. На практике поиск начинается с наиболее близких к искомому DNS-серверов, если информация о них есть в кеше и не устарела, сервер может не запрашивать DNS-серверы). Рекурсивные запросы требуют больше ресурсов от сервера (и создают больше трафика), так что обычно принимаются от «известных» владельцу сервера узлов (например, провайдер предоставляет возможность делать рекурсивные запросы только своим клиентам, в корпоративной сети рекурсивные запросы принимаются только из локального сегмента). Нерекурсивные запросы обычно принимаются ото всех узлов сети (и осмысленный ответ даётся только на запросы о зоне, которая размещена на узле, на DNS-запрос о других зонах обычно возвращаются адреса корневых серверов).
        * Субдомен — дополнительное доменное имя 3-го уровня в основном домене. Может указывать как на документы корневого каталога, так и на любой подкаталог основного сервера. Например, если у вас есть домен вида mydomain.ru, вы можете создать для него различные поддомены вида mysite1.mydomain.ru, mysite2.mydomain.ru и т. д.

    Система DNS содержит иерархию серверов DNS. Каждый домен или поддомен поддерживается как минимум одним авторитетным сервером DNS (от англ. authoritative — авторитетный, заслуживающий доверия; в Рунете применительно к DNS и серверам имен часто употребляют и другие варианты перевода: авторизированный, авторитативный), на котором расположена информация о домене. Иерархия серверов DNS совпадает с иерархией доменов.

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

    Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию, а в протоколе есть средства, позволяющие поддерживать синхронность информации, расположенной на разных серверах. Существует 13 корневых серверов, их адреса практически не изменяются.

    Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP датаграммы. TCP используется для AXFR-запросов.

    Рекурсия

    Рассмотрим на примере работу всей системы.

    Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org»? Однако, сервер DNS может ничего не знать не только о запрошенном имени, но даже обо всём домене wikipedia.org. В этом случае имеет место рекурсия: сервер обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является авторитетным для зоны org.» Тогда сервер DNS направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является авторитетным для зоны wikipedia.org.» Наконец, тот же запрос отправляется к третьему DNS-серверу и получает ответ — IP-адрес, который и передаётся клиенту — браузеру.

    В данном случае при разрешении имени, то есть в процессе поиска IP по имени:

        * браузер отправил известному ему DNS-серверу т. н. рекурсивный запрос — в ответ на такой тип запроса сервер обязан вернуть «готовый результат», то есть IP-адрес, либо сообщить об ошибке;
        * DNS-сервер, получив запрос от клиента, последовательно отправлял итеративные запросы, на которые получал от других DNS-серверов ответы, пока не получил авторитетный ответ от сервера, ответственного за запрошенную зону.

    В принципе, запрошенный сервер, мог бы передать рекурсивный запрос «вышестоящему» DNS-серверу и дождаться готового ответа.

    Запрос на определение имени обычно не идёт дальше кэша DNS, который сохраняет ответы на запросы, проходившие через него ранее. Вместе с ответом приходит информация о том, сколько времени разрешается хранить эту запись в кэше.

    Обратный DNS-запрос

    DNS используется в первую очередь для преобразования символьных имён в IP-адреса, но он также может выполнять обратный процесс. Для этого используются уже имеющиеся средства DNS. Дело в том, что с записью DNS могут быть сопоставлены различные данные, в том числе и какое-либо символьное имя. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя. Обратный порядок записи частей IP-адреса объясняется тем, что в IP-адресах старшие биты расположены в начале, а в символьных DNS-именах старшие (находящиеся ближе к корню) части расположены в конце.

    Записи DNS

    Наиболее важные типы DNS-записей:

        * Запись A (address record) или запись адреса связывает имя хоста с адресом IP. Например, запрос A-записи на имя referrals.icann.org вернет его IP адрес — 192.0.34.164
        * Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.NET вернет его IPv6 адрес — 2001:7fd::1
        * Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя
        * Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена.
        * Запись NS (name server) указывает на DNS-сервер для данного домена.
        * Запись PTR (pointer) или запись указателя связывает IP хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP хоста в reverse форме вернёт имя (FQDN) данного хоста (см. Обратный DNS-запрос). Например, (на момент написания), для IP адреса 192.0.34.164: запрос записи PTR 164.34.0.192.in-addr.arpa вернет его каноническое имя referrals.icann.org. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.
        * Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги кеширования зонной информации и взаимодействия DNS-серверов.
        * Запись SRV (server selection) указывает на серверы для сервисов, используется, в частности, для Jabber.

    Зарезервированные доменные имена

    Документ RFC 2606 (Reserved Top Level DNS Names — Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. Кроме example.com, example.org и example.net, в эту группу также входят test, invalid и др.

    Интернациональные доменные имена

    Доменное имя может состоять только из ограниченного набора ASCII символов, позволяя набрать адрес домена независимо от языка пользователя. ICANN утвердил основанную на Punycode систему IDNA, преобразующую любую строку в кодировке Unicode в допустимый DNS набор символов.

    Программное обеспечение DNS

    Серверы имен:

        * BIND (Berkeley Internet Name Domain)
        * djbdns (Daniel J. Bernsteins DNS)
        * MaraDNS
        * NSD (Name Server Daemon)
        * PowerDNS
        * Microsoft DNS Server (в серверных версиях операционных систем Windows NT)
        * MyDNS

    Информация о домене

    Многие домены верхнего уровня поддерживают сервис whois, который позволяет узнать кому делегирован домен, и другую техническую информацию.

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *