Что такое dns простыми словами
Содержание:
- DNS запрос к определённому серверу имён
- TLSA-запись
- Restrictions on CNAME Records
- Как настроить DNS
- Как в nslookup указать сервер для запросов
- SRV-запись
- Основные ресурсные записи DNS
- Сервисная шина предприятия (ESB)
- Как показать A запись домена
- What is a CNAME Record?
- Создание файла зоны и настройка записей
- Назначение записи псевдонима домена DNAME в DNS
- Общая архитектура брокера объектных запросов (CORBA)
- MX
- SOA
- Понимание вывода Dig
DNS запрос к определённому серверу имён
По умолчанию сервера имён для запроса берутся из файла /etc/resolv.conf, но вы можете указать любой другой DNS сервер — просто напишите его после имени домена:
host google.com ns4.google.com
Пример вывода:
Using domain server: Name: ns4.google.com Address: 216.239.38.10#53 Aliases: google.com has address 172.217.19.46 google.com has address 172.217.19.46 google.com has address 172.217.19.46 google.com has IPv6 address 2a00:1450:4005:808::200e google.com mail is handled by 30 alt2.aspmx.l.google.com. google.com mail is handled by 20 alt1.aspmx.l.google.com. google.com mail is handled by 50 alt4.aspmx.l.google.com. google.com mail is handled by 10 aspmx.l.google.com. google.com mail is handled by 40 alt3.aspmx.l.google.com.
TLSA-запись
TLSA-запись позволяет владельцу домена подтвердить подлинность используемого сертификата или цифровой подписи средствами DNSSEC. С помощью TLSA-записи вы можете сохранить отпечаток TLS или SSL-сертификата на вашем DNS-сервере.
Пример TLSA-записи
_443._tcp.www.example.com IN TLSA 3 0 1 12B1B210D87C674F0C748E0E259CEB328C4A33A11F19467700EB2
Пояснения к примеру
443 — порт TLS-сервера
tcp — используемый протокол TLS-сервера
www.example.com — доменное имя TLS-сервера
3 — способ использования сертификата TLS-сервера
0 — какая часть сертификата используется при сопоставлении его содержимого со значением TLSA
1 — метод сопоставления данных сертификата с данными TLSA
12B1B210D87C674F0C748E0E259CEB328C4A33A11F19467700EB2 — данные сертификата
При добавлении TLSA-записи укажите:
- Имя записи в формате _port_.protocol или _port_.protocol.domain. Например, «_443 _.tcp» или «_443 _.tcp.www.example.com».
- Способ использования сертификата TLS-сервера:
- 0 — ограничение CA — TLSA содержит информацию о сертификате удостоверяющего центра (УЦ). УЦ должен присутствовать в цепочке валидации при установлении TLS-соединения;
- 1 — служба ограничения сертификата — TLSA содержит информацию о сертификате сервера;
- 2 — доверенный источник — TLSA содержит информацию о корневом сертификате;
- 3 — сертификат домена — TLSA содержит информацию о сертификате сервера. Этот сервер должен быть конечным сертификатом в цепочке валидации. Такой способ позволяет использовать самоподписанные сертификаты.
- Какая часть сертификата используется при сопоставлении его содержимого со значением TLSA:
- 0 — полный сертификат;
- 1 — открытый ключ.
- Метод сопоставления данных сертификата с данными TLSA:
- 0 — хеш не используется — полное точное совпадение;
- 1 — SHA-256 — совпадение значений хеш-функции SHA-256;
- 2 — SHA-512 — совпадение значений хеш-функции SHA-512.
- Данные сертификата.
Restrictions on CNAME Records
- A CNAME cannot be placed at the root domain level, because the root domain is the DNS Start of Authority (SOA) which must point to an IP address.
- CNAME records must point to another domain name, never to an IP address.
- A hostname defined in a CNAME record must have no other resource records of other types (MX, A, etc.), except for DNSSEC records like RRSIG and NSEC.
- CNAME records can point to other CNAME records, but this is not considered a good practice as it is inefficient.
- MX and NS records must never point to a CNAME alias.
- Domains that are used for e-mail may not have a CNAME record — this can have undesirable results with different mail servers.
Как настроить DNS
Мы выяснили, где меняются ресурсные записи. Следующим шагом нужно войти в личный кабинет провайдера, чтобы изменить DNS. Дальнейшие действия зависят от провайдера, рассмотрим 2 самых распространенных варианта.
Если домен делегирован на Яндекс.Коннект
NS-записи такого вида в кабинете регистратора домена говорят о том, домен делегирован на Яндекс.Коннект, т.е. DNS-записи хранятся и редактируются в аккаунте Яндекса в настройках сервиса Вебмастер. Самое сложное в этом случае — найти доступы от аккаунта в Яндексе (вида @yandex.ru), под которым домен был заведен в Коннекте.
Чтобы изменить DNS, нужно кликнуть на «Управление DNS» соответствующего домена:
DNS-записи здесь уже заполнены, нужно только указать новый IP-адрес для записи типа А, которая связывает IP с доменным именем:
Готово! Обновление DNS-записей домена происходит в течение 72 часов, но по нашему опыту у некоторых провайдеров сайт начинает открываться уже через пару часов.
Если домен делегирован на хостинг
В личном кабинете регистратора домена можно также встретить NS-записи другого вида:
Конкретно в этом случае они означают, что домен делегирован на хостинг firstvds.ru, значит, и DNS-записи хранятся там. Дальнейшие действия зависят от того, куда переносим сайт.
Перенос сайта на другой сервер того же хостера
В этом случае в панели управления следует найти место, где меняются ресурсные записи домена, и в записи типа A указать IP-адрес нового сервера. Менять остальные DNS-записи не требуется.
Перенос сайта на другой хостинг
Если на прежнем сервере кроме этого сайта больше ничего не размещено, возникает необходимость переноса ресурсных записей на новый хостинг. Данный процесс осуществляется в несколько шагов:
Шаг 1: Перенос DNS на другой сервер
В Личном кабинете нового хостера необходимо найти место, где прописываются DNS, и прописать такие же записи, как у прежнего хостера, за исключением записи типа A — здесь нужно будет указать IP-адрес нового сервера.
Шаг 2: Проверка MX-записей домена
При переносе ресурсных записей существует опасность неправильной настройки MX-записей, которые сообщают различным почтовым программам о том, где находится нужный почтовый сервер. Если не перенести MX-записи с прежнего сервера или заполнить их некорректно, владелец сайта может остаться без почты на домене на долгий срок — он сможет отправлять письма, но входящие получать не будет. При этом отправитель письма на почтовый ящик на домене после отправки получит следующее уведомление:
Если в течение трех суток MX-записи не будут настроены правильным образом, то неполученные письма потеряются навсегда, при этом отправитель получит уведомление о том, что письмо не доставлено.
Если в указанный срок проблема все же будет устранена, то входящие письма не потеряются, а придут позже, когда DNS-серверы в интернете обменяются данными о новых DNS-записях. Обновление DNS-записей занимает от 2 до 72 часов.
Шаг 3: Настройка NS-записей
После настройки ресурсных записей необходимо указать NS-записи нового хостера в личном кабинете регистратора домена — перенаправить домен на новый хостинг. Узнать, как должны выглядеть NS-записи для нового хостинга можно в справочных материалах, который предоставляет хостер при покупке тарифа, либо обратившись в службу технической поддержки хостинга. Стоит быть особенно внимательными — при неправильном заполнении NS-записей домена сайт не заработает при обновлении DNS-серверов.
Выше мы рассмотрели ситуацию, когда DNS-записи редактируются на стороне хостера, и на прежнем сервере кроме переносимого сайта больше ничего не размещено. Существуют и другие ситуации:
- Владелец сайта хранит на прежнем хостинге несколько сайтов.
В этом случае переносить DNS-записи и перенаправлять NS-сервера домена в панели управления доменом на другой хостинг не обязательно — они могут храниться в прежнем месте. Необходимо только изменить записи типа A, указав IP-адрес нового сервера.
NS-записи и DNS-записи хранятся в одном месте — в панели управления доменом.
Так случилось с нашим клиентом — домен его сайта куплен через провайдера Majordomo, который кроме хостинга еще предоставляет услугу регистрации домена. У данного провайдера NS-записи и DNS хранятся и редактируются в одном месте. В этом случае так же не требуется правка NS-записей и перенос DNS в другое место, достаточно в записи типа А указать новый IP-адрес.
Как в nslookup указать сервер для запросов
Если вы хотите сделать запрос к определённому DNS серверу (а по умолчанию адреса серверов берутся из файла /etc/resolv.conf), то после доменного имени достаточно указать имя хоста или IP DNS сервера:
nslookup zalinux.ru 8.8.4.4
Как получить записи NS (Name Server) в nslookup
NS запись содержит сервера имён данного домена, для их просмотра выполните команду вида:
nslookup -query=ns zalinux.ru
Сервера Имён — это авторитативные сервера для данного домена, которые являются самый первым источником данных о DNS записях для данного домена.
Как правило, конечный пользователь обращается не к авторитативному серверу (поскольку их много — для каждого домена может быть свой), а к кэширующему DNS серверу.
SRV-запись
SRV-запись — определяет имя хоста и порт сервера домена. Позволяет использовать несколько для одного домена. SRV-записи используются только некоторыми п. Например, протоколы SIP и XMPP.
Укажите Домен, к которому относится ресурсная запись.
Укажите Приоритет (priority) и Вес (weight) сервера. , тем меньше приоритет. Клиент сперва пытается подключиться к наиболее приоритетному серверу. Если он недоступен, то к следующему по приоритету и т. д. Если у серверов одинаковый приоритет, то первым будет отправлен запрос к серверу, который имеет больший вес. Если с определённым значением приоритета только один сервер, то для него вес должен быть указан равным 0.
Укажите Порт (port) сервера, на который будет отправлен запрос.
Основные ресурсные записи DNS
Основополагающая запись DNS — SOA (start of authority record) или начальная запись зоны: запись, указывающая местоположение эталонной записи о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги кеширования зонной информации и данные о взаимодействиях DNS-серверов.
Пример записи SOA:
@ IN SOA <primary-name-server> <hostmaster-email> (
<serial-number>
<time-to-refresh>
<time-to-retry>
<time-to-expire>
<minimum-TTL> )
Например:
@ 86400 IN SOA ua.example.com. hostmaster.example.com. ( 2009092102 ; Serial 10600 ; Refresh 800 ; Retry 3400000 ; Expire 86400 ) ; Minimum TTL
Где:
Serial – Серийный номер самого файла зоны. Серийный номер увеличивается каждый раз при изменении данных домена. Когда вторичный сервер проверяет необходимость обновления данных, он проверяет серийный номер записи SOA на первичном сервере.
Refresh — значение времени в секундах. Показывает время, через которое вторичный сервер будет пытаться обновить данные зоны с первичного сервера (читая SOA первичного сервера). Рекомендуется устанавливать значения от 1200 до 43200 секунд. Низкое значение (1200) устанавливается при частой необходимости обновления данных. Высокое 43200 (12 часов), если такой необходимости нет.
Retry — значение времени в секундах. Определяет время между попытками, если вторичный сервер не может связаться с первичным сервером, когда время обновления истекло. Рекомендуемые значения от 180 (3 минуты) до 900 (15 минут) и выше.
Expire — значение времени в секундах. Значение срока. Если попытки обновления данных не привели к успеху, то по истечении срока вторичный сервер перестаёт отвечать на запросы для данного домена и стирает свою копию файла зоны. Если контакт установлен, значения срока и обновления сбрасываются, и цикл начинается снова. Рекомендуется устанавливать значения от 1209600 до 2419200 секунд (2-4 недели).
TTL – Время жизни. Время, на протяжении которого запись ресурса этой зоны действительна в кэше других серверов.
*Обратите внимание, что временные промежутки можно вводить не только в секундах. Возможны варианты ввода данных в других форматах, например: 2w14h(2 недели 14 часов), 1d2h(1 день 2 часа), 4h30m(4 часа 30 минут), 30m45s(30 минут 45секунд), или любые другие варианты при использовании соответствующих букв
Кроме записи SOA, существуют другие ресурсные записи. Мы рассмотрим основные:
Запись А – запись соответствия имени хоста его IP-адресу.
Запись AAAA — запись соответствия имени хоста его IP-адресу для протокола IPv6.
Запись CNAME – запись канонического имени для псевдонима (одноуровневая переадресация). Данная запись используются для перенаправления трафика с субдомена, например почтового сервера, на другой сервер. Создание записи CNAME не нарушает работу электронной почты и других служб.
Запись MX (Mail Exchanger) – запись адреса почтового шлюза для домена. Управляет маршрутизацией почтовых сообщений для протокола SMTP. Запись критически важна для протокола SMTP.
Запись NS (Name Server) – запись адреса узла отвечающего за доменную зону. Указывает на сервера DNS, ответственные за конкретный домен и его поддомены.
Запись PTR (Domain name pointer) — используется для обратного разрешения IP-адресов в имена узлов в домене in-addr.arpa.
Запись SRV (Service Locator) — указатель на службу. Запись используется для поиска серверов, на которых функционируют определенные службы (Active Directory, Jabber).
Сервисная шина предприятия (ESB)
Сервисная шина предприятия использовала веб-сервисы уже в 1990-х, когда они только развивались (быть может, некоторые реализации сначала использовали CORBA?).
ESB возникла во времена, когда в компаниях были отдельные приложения. Например, одно для работы с финансами, другое для учёта персонала, третье для управления складом, и т. д., и их нужно было как-то связывать друг с другом, как-то интегрировать. Но все эти приложения создавались без учёта интеграции, не было стандартного языка для взаимодействия приложений (как и сегодня). Поэтому разработчики приложений предусматривали конечные точки для отправки и приёма данных в определённом формате. Компании-клиенты потом интегрировали приложения, налаживая между ними каналы связи и преобразуя сообщения с одного языка приложения в другой.
Очередь сообщений может упростить взаимодействие приложений, но она не способна решить проблему разных форматов языков. Впрочем, была сделана попытка превратить очередь сообщений из простого канала связи в посредника, доставляющего сообщения и преобразующего их в нужные форматы/языки. ESB стал следующей ступенью в естественной эволюции простой очереди сообщений.
В этой архитектуре используется модульное приложение (composite application), обычно ориентированное на пользователей, которое общается с веб-сервисами для выполнения каких-то операций. В свою очередь, эти веб-сервисы тоже могут общаться с другими веб-сервисами, впоследствии возвращая приложению какие-то данные. Но ни приложение, ни бэкенд-сервисы ничего друг о друге не знают, включая расположение и протоколы связи. Они знают лишь, с каким сервисом хотят связаться и где находится сервисная шина.
Клиент (сервис или модульное приложение) отправляет запрос на сервисную шину, которая преобразует сообщение в формат, поддерживаемый в точке назначения, и перенаправляет туда запрос. Всё взаимодействие идёт через сервисную шину, так что если она падает, то с ней падают и все остальные системы. То есть ESB — ключевой посредник, очень сложный компонент системы.
Это очень упрощённое описание архитектуры ESB. Более того, хотя ESB является главным компонентом архитектуры, в системе могут использоваться и другие компоненты вроде доменных брокеров (Domain Broker), сервисов данных (Data Service), сервисов процессной оркестровки (Process Orchestration Service) и обработчиков правил (Rules Engine). Тот же паттерн может использовать интегрированная архитектура (federated design): система разделена на бизнес-домены со своими ESB, и все ESB соединены друг с другом. У такой схемы выше производительность и нет единой точки отказа: если какая-то ESB упадёт, то пострадает лишь её бизнес-домен.
Главные обязанности ESB:
- Отслеживать и маршрутизировать обмен сообщениями между сервисами.
- Преобразовывать сообщения между общающимися сервисными компонентами.
- Управлять развёртыванием и версионированием сервисов.
- Управлять использованием избыточных сервисов.
- Предоставлять стандартные сервисы обработки событий, преобразования и сопоставления данных, сервисы очередей сообщений и событий, сервисы обеспечения безопасности или обработки исключений, сервисы преобразования протоколов и обеспечения необходимого качества связи.
У этого архитектурного паттерна есть положительные стороны. Однако я считаю его особенно полезным в случаях, когда мы не «владеем» веб-сервисами и нам нужен посредник для трансляции сообщений между сервисами, для оркестрирования бизнес-процессами, использующими несколько веб-сервисов, и прочих задач.
Также рекомендую не забывать, что реализации ESB уже достаточно развиты и в большинстве случаев позволяют использовать для своего конфигурирования пользовательский интерфейс с поддержкой drag & drop.
Достоинства
- Независимость набора технологий, развёртывания и масштабируемости сервисов.
- Стандартный, простой и надёжный канал связи (передача текста по HTTP через порт 80).
- Оптимизированный обмен сообщениями.
- Стабильная спецификация обмена сообщениями.
- Изолированность контекстов домена (Domain contexts).
- Простота подключения и отключения сервисов.
- Асинхронность обмена сообщениями помогает управлять нагрузкой на систему.
- Единая точка для управления версионированием и преобразованием.
Недостатки
- Ниже скорость связи, особенно между уже совместимыми сервисами.
- Централизованная логика:
- Единая точка отказа, способная обрушить системы связи всей компании.
- Большая сложность конфигурирования и поддержки.
- Со временем можно прийти к хранению в ESB бизнес-правил.
- Шина так сложна, что для её управления вам потребуется целая команда.
- Высокая зависимость сервисов от ESB.
Как показать A запись домена
Информацию о различных типах DNS записях смотрите в статье «Введение в DNS терминологию, компоненты и концепции».
Достаточно указать только домен, для которого делается запрос, например, чтобы узнать A запись (содержит IP адрес сервера, на котором работает данный сайт) для доменного имени zalinux.ru:
dig zalinux.ru
Пример вывода:
Большая часть вывода является комментариями — они начинаются с точки с запятой (;)
Первая группа строк показывает версию программы, домен, информацию о котором запрашивается, глобальные опции, информация об ошибках, флаги, количество запросов, ответов и другие данные:
; <<>> DiG 9.14.4 <<>> zalinux.ru ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18537 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
Данная группа строк показывает информацию о сделанном запросе, в том числе домен и тип DNS записи.
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;zalinux.ru. IN A
Значимая информация содержится в разделе ответа — именно здесь показан IP сайта:
;; ANSWER SECTION: zalinux.ru. 3799 IN A 185.26.122.38
Последняя группа комментариев содержит техническую информацию, в том числе время, которое занял запрос; DNS сервер, к которому был сделан запрос; время, когда был сделан запрос и другое:
;; Query time: 484 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Ср июл 24 03:21:13 MSK 2019 ;; MSG SIZE rcvd: 55
What is a CNAME Record?
A Canonical Name (CNAME) Record is used in the Domain Name System (DNS) to create an alias from one domain name to another domain name. A common example is the www subdomain which is provided as an alias to the root domain name — users accessing “www.example.com” are referred to the root domain (or DNS zone apex) “example.com”.
A few common uses of CNAME records are:
- Providing a separate hostname for specific network services, such as email or FTP, and pointing that hostname to the root domain
- Many hosted services provide a subdomain for each customer on the service provider’s domain (e.g. company.hostname.com), and use CNAME to point to the customer’s domain (www.company.com).
- Registering the same domain in several countries and pointing the country versions to the main “.com” domain
- Pointing from several websites owned by the same organization to a primary website
Создание файла зоны и настройка записей
Создаем каталог master (если он отсутствует).
В CentOS / Red Hat:
mkdir /var/named/master
В Ubuntu / Debian:
mkdir /var/cache/bind/master
И создаем файл зоны (в нашем примере test.local).
CentOS / Red Hat:
vi /var/named/master/test.local
Ubuntu / Debian:
vi /var/cache/bind/master/test.local
Приводим его к следующему виду:
$TTL 14400
test.local. IN SOA ns1.test.local. admin.test.local. (
2017082401 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
604800 ; Negative Cache TTL
)
IN NS ns1.test.local.
IN NS ns2.test.local.
IN MX 10 mx.test.local.
IN MX 20 mx2.test.local.
@ IN A 192.168.1.1
localhost IN A 127.0.0.1
ns1 IN A 192.168.1.2
ns2 IN A 192.168.1.3
mx IN A 192.168.1.4
mail IN A 192.168.1.5
www IN CNAME test.local.
Формат записей: <имя узла> <класс (всегда ставится IN)> <тип записи> <значение>.
Немного подробнее:
| Параметр | Описание |
|---|---|
| $TTL | Время актуальности записей в секундах. Необходим, чтобы указать другим DNS-серверам, как долго стоит хранить запись у себя в кэше. Слишком малое значение увеличит нагрузку на сервер, а большое приведет к слишком длительному процессу изменения записи. |
| SOA-запись | В данном примере эта запись идет сразу после параметра TTL. Ее стоит описать отдельно. Она хранит общие настройки для зоны.
|
| <имя узла> | Собственно доменное имя хоста. Может записываться без домена (как в данном примере) — он будет дописан автоматически. Также может быть записан полностью с доменом — в таком случае необходимо поставить точку на конце, например, mail.test.local. Если не указывается или обозначается знаком собаки (@), запись создается для имени зоны (в данном случае, test.local). |
| <класс> | Всегда используется IN (Internet). Указывает на тип сети. |
| <тип записи> |
Основные типы записей, использующиеся в DNS:
|
| <значение> | Используется IP-адрес, имя узла, текстовая запись. |
Чтобы зона начала работать, перечитываем ее:
rndc reload
Назначение записи псевдонима домена DNAME в DNS
ДНС зоны содержат в себе некоторое количество разных типов записей и каждая из которых, заточена под определенные функции и задачи. Самые популярные, это A-записи, MX-записи или CNAME-записи, так как они очень часто используются в рабочей среде или тестах, но вот о существовании других типов DNS-записей, знают далеко не многие, а если и знают, то не помнят для чего они нужны и в каких сценариях.
Если мы с вами обратимся к Википедии, то там очень скупая информация, о записи DNAME, просто псевдоним домена, и более ничего, но слава боги, что хоть есть в сети подробное описание rfc6672 (http://www.zytrax.com/books/dns/apd/rfc6672.txt), где можно почерпнуть информацию.
Представим себе ситуацию, что у вас есть домен Pyatilistnik.com, компанию поглотили или произошел небольшой ребрендинг, и она теперь имеет домен Pyatilistnik.org. Так как DNS-зона Pyatilistnik.com, может содержать большое количество записей, которые ссылаются на сервисы компании, которыми пользуются клиенты или сотрудники, то логично, что всякие простои в работе, будут идти не на пользу компании, а переносить все же их нужно в новую зону Pyatilistnik.org. Вот в таком случае и будет полезной запись ДНС типа DNAME, которая и будет делать перенаправление (Редирект), но не любого имени из зоны Pyatilistnik.com в зону Pyatilistnik.org, а только тех, которые имеются в обоих зонах.
Понятно, что можно использовать и на время переноса CNAME записи, но это только тогда, когда их очень мало, вы же не будите, это делать для сотни или две записей. Схематично, это можно изобразить вот так. Пользователь делает запрос по имени dc1.pyatilistnik.com, DNS-сервер имея у себя эту зону и зону pyatilistnik.org, видит, что есть DNAME запись в первой зоне, благодаря чему он перенаправляет запрос во вторую зону, там обнаруживается запись dc1.pyatilistnik.org, которая отдается DNS-серверу и уже дальше пользователю.
Хочу отметить,что необязательно обе зоны могут быть на одно DNS-сервере, первый сервер, вполне может иметь сервер условной пересылки
Ну и перейдем от теории к практики. У меня есть DNS-сервер в котором есть две основные зоны, старая Pyatilistnik.com и новая root.pyatilistnik.org, мне нужно перенаправлять все днс-запросы из старой зоны Pyatilistnik.com в новую. Щелкаете правым кликом по вашей зоне, и из контекстного меню выбираете пункт «Другие новые записи».
Находим в списке «типов записей ресурса» вот такую «Псевдоним домена (DNAME)» и нажимаем создать запись.
В открывшемся редакторе, вы оставляете пустым (символизирующим корень домена) поле «Псевдоним (если не указан, используется имя род. домена)», ниже вы будите видеть его полное FQDN имя и указываете полное FQDN имя конечного домена, у меня это root.pyatilistnik.org, после чего нажимаете OK.
Когда DNAME-запись создана,
то пробуем пропинговать и обратиться к имени dc1.pyatilistnik.com, напоминаю, что во второй зоне, куда мы ссылаемся, она должна быть.
Открываем командную строку, не обязательно от имени администратора и вводим команду ping.
ping dc01.patilistnik.com
И как видите мне на это отвечает dc01.root.pyatilistnik.org, вот видно, как отработала DNAME-запись на DNS сервере.
Напоминаю, что в основном данные сценарии используют при миграции или при полном поглощении, а может и ребрендинге компании. Надеюсь, что было полезно, а с вами был Иван Семин, автор и создатель IT блога Pyatilistnik.org,
Общая архитектура брокера объектных запросов (CORBA)
В 1980-х началось активное использование корпоративных сетей и клиент-серверной архитектуры. Возникла потребность в стандартном способе взаимодействия приложений, которые созданы с использованием разных технологий, исполняются на разных компьютерах и под разными ОС. Для этого была разработана CORBA. Это один из стандартов распределённых вычислений, зародившийся в 1980-х и расцветший к 1991 году.
Стандарт CORBA был реализован несколькими вендорами. Он обеспечивает:
- Не зависящие от платформы вызовы удалённых процедур (Remote Procedure Call).
- Транзакции (в том числе удалённые!).
- Безопасность.
- События.
- Независимость от выбора языка программирования.
- Независимость от выбора ОС.
- Независимость от выбора оборудования.
- Независимость от особенностей передачи данных/связи.
- Набор данных через язык описания интерфейсов (Interface Definition Language, IDL).
Сегодня CORBA всё ещё используется для разнородных вычислений. Например, он до сих пор является частью Java EE, хотя начиная с Java 9 будет поставляться в виде отдельного модуля.
Хочу отметить, что не считаю CORBA паттерном SOA (хотя отношу и CORBA, и SOA-паттерны к сфере распределённых вычислений). Я рассказываю о нём здесь, поскольку считаю недостатки CORBA одной из причин возникновения SOA.
Принцип работы
Сначала нам нужно получить брокер объектных запросов (Object Request Broker, ORB), который соответствует спецификации CORBA. Он предоставляется вендором и использует языковые преобразователи (language mappers) для генерирования «заглушек» (stub) и «скелетов» (skeleton) на языках клиентского кода. С помощью этого ORB и определений интерфейсов, использующих IDL (аналог WSDL), можно на основе реальных классов генерировать в клиенте удалённо вызываемые классы-заглушки (stub classes). А на сервере можно генерировать классы-скелеты (skeleton classes), обрабатывающие входящие запросы и вызывающие реальные целевые объекты.
Вызывающая программа (caller) вызывает локальную процедуру, реализованную заглушкой.
- Заглушка проверяет вызов, создаёт сообщение-запрос и передаёт его в ORB.
- Клиентский ORB шлёт сообщение по сети на сервер и блокирует текущий поток выполнения.
- Серверный ORB получает сообщение-запрос и создаёт экземпляр скелета.
- Скелет исполняет процедуру в вызываемом объекте.
- Вызываемый объект проводит вычисления и возвращает результат.
- Скелет пакует выходные аргументы в сообщение-ответ и передаёт его в ORB.
- ORB шлёт сообщение по сети клиенту.
- Клиентский ORB получает сообщение, распаковывает и передаёт информацию заглушке.
- Заглушка передаёт выходные аргументы вызывающему методу, разблокирует поток выполнения, и вызывающая программа продолжает свою работу.
Достоинства
- Независимость от выбранных технологий (не считая реализации ORB).
- Независимость от особенностей передачи данных/связи.
Недостатки
- Независимость от местоположения: клиентский код не имеет понятия, является ли вызов локальным или удалённым. Звучит неплохо, но длительность задержки и виды сбоев могут сильно варьироваться. Если мы не знаем, какой у нас вызов, то приложение не может выбрать подходящую стратегию обработки вызовов методов, а значит, и генерировать удалённые вызовы внутри цикла. В результате вся система работает медленнее.
- Сложная, раздутая и неоднозначная спецификация: её собрали из нескольких версий спецификаций разных вендоров, поэтому (на тот момент) она была раздутой, неоднозначной и трудной в реализации.
- Заблокированные каналы связи (communication pipes): используются специфические протоколы поверх TCP/IP, а также специфические порты (или даже случайные порты). Но правила корпоративной безопасности и файрволы зачастую допускают HTTP-соединения только через 80-й порт, блокируя обмены данными CORBA.
MX
Запись MX (Mail Exchange) — почтовый обменник, записи такого типа используются для обозначения списка хостов, которые сконфигурированы для приема почты посланной на это доменное имя. Помимо адреса почтового сервера содержат числовое значение обозначающее приоритет, т.е. более низкие числа показывают более высокий приоритет, а приоритеты одинаковые отправители должны использовать в произвольном порядке хосты MX для равномерного распределения нагрузки.
Пробуем:
nslookup -type=MX download.openlib.org.ua
| download.openlib.org.ua MX preference = 5, mail exchanger = alt1.aspmx.l.google.com download.openlib.org.ua MX preference = 5, mail exchanger = alt2.aspmx.l.google.com download.openlib.org.ua MX preference = 10, mail exchanger = aspmx3.googlemail.com download.openlib.org.ua MX preference = 10, mail exchanger = aspmx4.googlemail.com download.openlib.org.ua MX preference = 10, mail exchanger = aspmx5.googlemail.com download.openlib.org.ua MX preference = 30, mail exchanger = aspmx2.googlemail.com download.openlib.org.ua MX preference = 1, mail exchanger = aspmx.l.google.com alt1.aspmx.l.google.com internet address = 74.125.53.27 alt2.aspmx.l.google.com internet address = 74.125.67.27 aspmx3.googlemail.com internet address = 72.14.213.27 aspmx4.googlemail.com internet address = 209.85.229.27 aspmx5.googlemail.com internet address = 74.125.157.27 aspmx2.googlemail.com internet address = 74.125.43.27 aspmx.l.google.com internet address = 74.125.39.27 |
как видим этот домен использует почтовые сервера Google, расположенные по приоритетам. Если сервер с высоким приоритетом выключен по какой либо причине, то почтовый сервера отправитель отправляет почту на следующий сервер по списку.
SOA
Запись SOA (Start Of Authorisation) — начальная запись зоны, указывает на основной сервер который отвечает за данный домен. Для каждой зоны должна быть только одна и единственная зона SOA.
Так что из себя представляет запись SOA Давайте посмотрим:
Все эксперименты будут проведены на примере домена thetech.сom.ua.
Открываем командную строку cmd.exe и набираем в ней:
nslookup -type=SOA download.openlib.org.ua
в ответ получаем:
| download.openlib.org.ua primary name server = ns1.gigahost.ua responsible mail addr = hostmaster.gigahost.ua serial = 2010102009 refresh = 14400 (4 hours) retry = 7200 (2 hours) expire = 604800 (7 days)default TTL = 3600 (1 hour) |
Понимание вывода Dig
В простейшей форме, когда он используется для запроса одного хоста (домена) без каких-либо дополнительных аргументов, dig довольно многословен.
В следующем примере мы выполним запрос для получения информации о домене .
Результат должен выглядеть примерно так:
Объясним вывод команды dig:
-
В первой строке вывода печатается установленная версия dig и запрос, который был вызван. Во второй строке отображаются глобальные параметры (по умолчанию – только cmd).
Если вы не хотите, чтобы эти строки были включены в вывод, используйте эту опцию . Эти параметры должны быть самым первым аргументом после команды dig.
-
В этом разделе содержатся технические сведения об ответе, полученном от запрашиваемого органа (DNS-сервера). Первая строка этого раздела – заголовок, включая код операции (действие, выполняемое dig) и состояние действия. В нашем случае статус означает, что запрашиваемый орган обслуживал запрос без каких-либо проблем.
Эта часть вывода может быть удалена с помощью опции . Когда этот параметр используется, он отключает некоторые другие разделы заголовков.
-
Этот раздел отображается по умолчанию только в более новых версиях утилиты dig.
Если вы не хотите, чтобы этот раздел был включен в вывод, используйте этот параметр .
-
Это раздел, где dig показывает наш запрос (вопрос). По умолчанию dig запросит запись A.
Вы можете отключить этот раздел, используя эту опцию .
-
Раздел ANSWER дает нам ответ на наш вопрос. Как мы уже упоминали, по умолчанию dig запросит запись A. В этом случае мы видим, что домен указывает на IP-адрес .
Обычно вы не хотите отключать ответ, но вы можете удалить этот раздел с вывода с помощью этой опции .
-
Раздел «AUTHORITY» сообщает нам, какой сервер(ы) является полномочным органом для ответа на запросы DNS о запрошенном домене.
Вы можете отключить этот раздел вывода с помощью этой опции .
-
Раздел ADDITIONAL дает нам информацию об IP-адресах авторитетных DNS-серверов, указанных в разделе полномочий.
-
Это последний раздел вывода dig, который включает статистику запроса.
Вы можете отключить эту часть с помощью опции .
