Разное

Nic ru mx записи: Настройка услуги «Перенаправление почты» — RU-CENTER

03.06.1981

Содержание

запись — Яндекс 360 для бизнеса. Справка

Переезд в Яндекс 360 для бизнеса

Мы собрали ответы на частые вопросы о том, как перенести данные вашей организации в Яндекс 360 для бизнеса из Google Workspace, Microsoft 365 и других платформ. Смотреть >

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

Если вы делегировали домен на серверы Яндекса, MX-запись будет настроена автоматически.

  1. Добавить MX-запись
  2. Проверить, правильно ли настроена MX-запись
  1. Войдите в панель управления доменом (зоной DNS) на сайте компании, которая предоставляет вам DNS-хостинг.

  2. Удалите существующие MX-записи.

  3. Создайте новую MX-запись со следующими значениями полей (в разных панелях управления названия полей могут различаться):

    • Значение — mx. yandex.net.

      Точка в конце имени сервера обязательна, если ваша панель управления не добавляет ее по умолчанию.

    • Приоритет — 10

      Если приоритет со значением 10 не предусмотрен в панели управления, укажите любой другой отличный от нуля приоритет.

    • Имя поддомена (или Хост) — @

      В некоторых панелях управления вместо символа @ нужно указать имя вашего домена (например, example.org.). Если вам не удается указать ни @, ни имя домена, оставьте это поле пустым.

      Если это поле отсутствует в панели управления, можно его не указывать.

    • Если требуется заполнить поле TTL, укажите 21600.

  4. Подождите, пока изменения вступят в силу. Может потребоваться до 72 часов, чтобы DNS-серверы в интернете обменялись данными о новых DNS-записях.

reg.ru

  1. Откройте страницу https://reg.ru и войдите в ваш аккаунт.

  2. Нажмите кнопку с вашим логином и выберите Домены и услуги.

  3. Нажмите ссылку с именем нужного домена. Откроется страница Управление.

  4. Выберите DNS-серверы и управление зоной.

  5. Удалите существующие MX-записи.

  6. Добавьте новую MX-запись со следующими значениями полей:

  7. Подождите, пока изменения в DNS вступят в силу. Может потребоваться до 72 часов, чтобы DNS-серверы в интернете обменялись данными о новых DNS-записях.

masterhost.ru

  1. Откройте страницу https://cp.masterhost.ru и войдите в ваш аккаунт.

  2. На панели справа выберите DNS-зоны.

  3. Нажмите ссылку с именем нужного домена. Откроется страница Просмотр DNS-зоны.

  4. Удалите существующие MX-записи.

  5. Добавьте новую MX-запись со следующими значениями полей:

  6. Подождите, пока изменения в DNS вступят в силу. Может потребоваться до 72 часов, чтобы DNS-серверы в интернете обменялись данными о новых DNS-записях.

sweb.ru

  1. Откройте страницу https://mcp.sweb.ru и войдите в ваш аккаунт.

  2. В разделе Управление хостингом нажмите ссылку DNS.

  3. В выпадающем списке выберите нужный домен.

  4. Удалите существующие MX-записи.

  5. Добавьте новую MX-запись со следующими значениями полей:

  6. Подождите, пока изменения в DNS вступят в силу. Может потребоваться до 72 часов, чтобы DNS-серверы в интернете обменялись данными о новых DNS-записях.

beget. com

  1. Откройте страницу https://cp.beget.com и войдите в ваш аккаунт.

  2. Нажмите ссылку DNS.

  3. В выпадающем списке выберите нужный домен.

  4. В нижней части страницы найдите строку с нужным доменом и нажмите значок . DNS-записи домена станут доступными для редактирования.

  5. Удалите существующие MX-записи.

  6. Добавьте новую MX-запись со следующими значениями полей:

  7. Подождите, пока изменения в DNS вступят в силу. Может потребоваться до 72 часов, чтобы DNS-серверы в интернете обменялись данными о новых DNS-записях.

Собственные инструкции провайдеров по настройке DNS-записей:

  • Timeweb

  • NetAngels

  • 1Gb.ru

  • Hostinger

  • 1hs.ru

  • RedDock

Чтобы избежать проблем с отправкой или получением почты, проверьте правильность настройки DNS-записей. Это можно сделать, например, с помощью сервиса http://www. digwebinterface.com или другой dig-утилиты.

  1. Откройте страницу http://www.digwebinterface.com.

  2. В поле Hostnames or IP addresses укажите имя вашего домена, например example.org.

  3. В поле Type выберите MX и нажмите кнопку Dig.

Ответ должен иметь вид:

example.org.  20755 IN MX 10 mx.yandex.net.

Если сервер не отвечает на запрос, ответ не совпадает с нужным или в ответе присутствуют лишние записи, значит MX-запись настроена некорректно. Настройте ее по инструкции.

Внимание. Прежде чем повторно проверять DNS-записи, подождите 72 часа. Это время нужно, чтобы DNS-серверы в интернете успели обновить данные о записях.

Особенности национального хостинга! / likes / блог студии Клондайк!

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

Виктор ТаранТех. Директор студии Клондайк


В данной статье рассмотрим самую простую услугу хостинг-провайдеров — регистрация доменных имён и какие проблемы возникают с дальнейшем.

Рассмотрим простые примеры

1. hc.ru не позволяет редактировать ns сервера для домена!

Искал в админке, не нашёл — написал в техническую поддержку:

И это одна из самых необходимых услуг, которая нужна пользователю от регистратора. И это один из ведущих регистраторов!

2. nic.ru берёт деньги за воздух! Чтобы отредактировать mx запись у домена — пожалуйста отдельно заплати, причём два раза!

Суть вопроса: к примеру нужно делегировать корпоративную почту на Яндекс или Google Apps, для этого нужно изменить SOA запись (фактически это прописать две строчки за 2 минуты в настройках домена). Нам предлагают заплатить за это примерно 50 $ в год для одного домена.

*Решение вопроса — переписать ns сервера домена на сторонний сервис (к примеру Яндекс), там сделать все записи, что нужно, потом уже сослаться на хостинг.

Рассмотрим более сложный вариант

3. infobox.ru ставит пользователя в сложную ситуацию!

Порой, приводя из самых легких задач к тупиковым ситуациям. Собственно перенеся сайт со старого сервера на другой требуется изменить NS на новый сервер, где уже имеется bind сервер с соответствующей записью SOA. Вроде бы подвоха нет.

В общем тут все легко, заходим, находим записи DNS, входим — вроде все как нужно.

Собственно в данном скриншоте я уже удалил NS записи, но изначально они тут были и отправляли на nic.ru. Собственно удалив, А записи, на всякий случай я забил NS сервера и с чистой совестью закрыл админку поставив статус задачи выполнено. Поскольку в работоспособности своего bind сервера я уверен.

Однако вечером стало ясно, что данный фокус не прошел.

После недолгих раздумий, входим в редактирование домена, приводим его внешний вид до состояния как у остальных доменов. Хоть и с первого взгляда несколько странно, но кто его знает — главное чтоб «работало». Собственно фото и отображает данное мероприятие.

Запись типа

ПУСТО А IP — создается автоматически техподдержка сказала для примера;

* А IP — создается не особо понятно зачем, техническая поддержка тоже не смогла объяснить внятно, но черт с ним — примерный смысл и так понятен. Да и разбираться особо времени нет, нужно чтобы сайт уже заработал, а потом можно и разбираться.

*.* A IP — вообще в начале ошарашила, сразу повеяло виндовой маской поиска, которая в линуксе представлена в виде *, но и тут вроде как смысл понятен, однако зачем — так и не ясно.

WWW A IP — ну тут как раз все норм.

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

По сему добавил запись:

ДОМЕН А IP — сохранил и со свободной совестью закрыл. Уж в таком варианте оно точно должно заработать.

Однако ж, нет;)

Вот в этом моменте я уже обратился в службу поддержки, полагая что лыжи явно едут не у меня.

По результатам переговоров с службой поддержки стало ясно: Кнопка DNS не предназначена для DNS!

Желаешь изменить NS — зайди в кнопку «настройка и оплата», внутри ищем неприметную ссылочку «изменение Named серверов для этого домена», а настройки в DNS вообще можно не учитывать — они так…. как бы для красоты, ну и для субдоменов. Директивы типа NS и зачем они там вообще не смогли мотивировать никак.

В результате банальная переписка NS серверов растянулась на 3 дня, поскольку DNS кеш у данного сервера очень большой, фактически больше 24 часов.

скриншоты ниже:

Непосредственно об услуге хостинга

В попытках впихнуть как можно больше сельди в бочку, NIC.ru стал чуть ли не лидером рынка, не являясь при этом гигантом отрасли!

Начиная с банального отсутствия ЛЮБОГО акселератора на php версии старше 5.2, по заявлениям тех поддержки его и не будет поскольку «он ест много памяти»!!! На мое утверждение «ну, собственно, да, и?» более вразумительного, чем то, что софт использующий оперативную память в качестве кеша использует оперативную память я не добился.

Это было основанием убить вообще все акселерации, а замечу, даже при маленьких проектах скорость работы сайта может повыситься столь простой технологией до 10 раз! Собственно благодаря таким приколам хостинг NIC на максимальном тарифе дает от 0,2 до 5 попугайчиков по оценке монитора производительности 1С-Битрикс, при требуемых 30, замечу вполне достижимых.

Фактически, проблема не у Битрикса в том, что не каждый хостинг ему подходит, это вопрос хостингов, так как если делать всё как положено, то количество сайтов, размещенных на одном сервере, резко сократится.

Ну и такие приятные мелочи, как банальная НЕХВАТКА памяти на nic.ru и peterhost.ru (у остальных хоть как-то). Подключаясь к этим двум приятным хостингам по ssh, я не удивляюсь фразе «нет памяти для запуска MC или архиватора»! При этом логи сайтов с посещаемостью 30 человек в день на Joomla 1.5 могут выглядеть примерно так: (скриншот прикладываю)

Бывают и более весёлые случаи! К примеру sweb.ru при попытке админа спросить версию ядра по SSH говорит «я не знаю»! На вопрос в тех. поддержку «Что вообще мы можем сделать по SHH?» — получили ответ «можно скопировать файлы» 🙂

Собственно ответ на вопрос — какие особенности национального хостинга? ОТВЕТ — бегите с национальных хостингов!

Создание и применение MX-записи домена

  • Обучение
  • 15 декабря 2021
  • 7 мин.
  • Руководитель Rush Analytics Дмитрий Цытрош

  • Обновлено 05 августа 2022 Что изменено?

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

навигация по статье

  1. MX-запись домена — что это
  2. Как создать MX-запись домена
  3. Как настроить MX-запись домена
  4. Как выполнить проверку MX-записи домена

MX-запись домена — что это

MX (Mail eXchange) — основная DNS-запись для электронной почты, указывающая, какими серверами она обрабатывается. Это почтовый шлюз, который использует сервер для доставки электронных писем, используя протокол SMTP. То есть это набор данных, указывающих на сервер, где обрабатываются почтовые сообщения. Если этот параметр не настроен или настроен неверно, сообщения не будут доходить до адресата.

Для оптимизации доставки почтовых писем используются разные типы записей, одной из которых является preference mail exchanger. MX-запись показывает сервер, на котором обрабатывается почта для домена сайта.

Например, для почтового домена example.com и почтового сервера mail. example.com запись будет выглядеть так: example.com. IN MX 10 mail.example.com, где

  • example.com — доменное имя, для которого обрабатывается электронная почта;
  • IN MX — вид записи;
  • 10 — приоритет записи;

mail.example.com — A-имя почтового сервера.

MX — это запись, которая указывает на A-запись почтового сервера и не может указывать на IP или CNAME. Она является приоритетной, если у домена больше одного почтового сервера, и указывает, куда идет обращение в первую, вторую и последующие очереди. Очередность показывает, куда осуществляется обращение, если предыдущий сервер недоступен по техническим причинам.

Особенности использования:

  • Если у domain нет MX записей или такие серверы недоступны, сервер, с которого идет отправка сообщения, пробует отправить почту на IP, который указан в A-записи домена. Такой процесс называют А-доставкой, но его лучше не использовать.
  • Наличие такой записи дает возможность серверам сделать проверку DNS-зоны и почтовых шлюзов на соответствие уникальности сетевого адреса узла.
    Такая проверка нужна для защиты от спама.
  • При отсутствии MX записи для домена сайта или обнаружении ошибок в ее данных, почтовые сообщения с высокой степенью вероятности не будут доставлены.

Принцип работы MX записей:

  1. Сервер, отправляющий электронную почту, производит запрос mail exchanger.
  2. Система присылает список хостов, которые принимают сообщения.
  3. Сервер-отправитель связывается с нужными серверами через протокол передачи электронных писем, пока не установит связь с одним из них.

Присоединяй­тесь к
Rush-Analytics уже сегодня

7-ми дневный бесплатный доступ к полному функционалу. Без привязки карты.

Попробовать бесплатно

Как создать MX-запись домена

Использование большинства веб-сервисов для доставки почты предполагает создание и настройку MX-записи. Таким образом осуществляется переподключение DNS сервиса электронки на внешнее серверное оборудование.

Что нужно сделать для добавления новой записи вашего домена:

  1. Зайдите в панель управления веб-хостинга ISPmanager, выберите вкладку «Управление записями». Для входа нужно нажать на кнопку «Создать».
  2. В открывшемся окне введите нужную информацию в полях регистрации. Следите, чтобы не было ошибок. На данном этапе можно воспользоваться подсказками. Выберите тип записи, заполните все нужные поля.
  3. Сохраните результаты.
Тип информации
Значение
Название записиВыбирается произвольно, может включать название поддомена
Время обновления
Тип записиУказывает на назначение, различается индивидуальными параметрами
Доменное имя
ПриоритетПоказывает первоочередность обращений
Табл. 1 Информация, которую нужно внести для создания MX-записи

Как настроить MX-запись домена

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

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

Для проверки такой записи можно использовать различные инструменты (приведены в Табл. 2).

Табл. 2 какие инструменты можно использовать для проверки MX-записи

Инструмент
Особенности и плюсы применения
Специальные интернет-сервисыДля проверки нужно зайти на сервис, ввести в указанное поле доменное имя сайта и нажать кнопку проверки
Утилита Nslookup, встроенная в WindowsПроверка осуществляется через командную строку панели задач или меню Пуск. В открывшемся окне вводится команда nslookup -type=mx имя_домена, затем нажимается Enter. После этого будет выведена подробная информация о домене и приоритетах (если доменов несколько)

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


Просмотров

3956

Рейтинг

5,0/5

Оценить

Комментариев

Комментировать

Другие наши статьи

На страницу статей
  • Копирайтинг

SEO тексты для сайта: зачем нужны и как заказать

SEO-текст — это материал, раскрывающий суть продаваемого продукта, оптимизированный под поисковый маркетинг. СЕО-текст отличается от обычного тем, что его пишут не только для пользователей, но и для поисковых систем, которые распределяю

  • Дмитрий Цытрош
  • 17 октября 2021
  • 10 мин.

Получите 7 дней бесплатного доступа

Здесь вы можете собрать поисковые подсказки из Яндекс, Google или YouTube

Зарегистрироваться

Яндекс почта для домена с хостингом от Webnames.ru

Как сделать почту со своим доменом? С помощью доменной почты Яндекс настроить корпоративный email стало очень просто и быстро всего за 7 шагов.

Содержание

  1. Подключение домена к Яндексу
  2. Подтверждение прав на домен
  3. Добавление MX-записи
  4. Добавление SPF-записи
  5. Проверка записей Яндексом
  6. Добавление DKIM-подписи
  7. Создание почтовых ящиков

Подключение домена к Яндексу

Откройте Яндекс Коннект и войдите в Админку: https://connect. yandex.ru/portal/admin

Нажмите (+) возле пункта меню Домены:

Впишите имя своего домена и нажмите Добавить:

Подтверждение прав на домен

Теперь нужно подтвердить Яндексу, что это ваш домен. Сделаем это с помощью TXT-записи на DNS-серверах.

Нажмите на вкладку DNS, выделите мышкой и скопируйте текст проверочной записи:

Теперь внесём эту запись на DNS-сервер хостинга.

Войдите в панель управления хостингом: https://proto.gohost.ru:1500/

Откройте раздел Доменные имена. Щелкните по имени домена и нажмите кнопку Записи:

В открывшемся списке записей нажмите кнопку Создать:

В окошке добавления записи:

  • Укажите в первом поле символ @ (он означает, что это запись для самого домена)
  • Выберите тип записи TXT
  • Вставьте в текстовое поле проверочную запись, скопированную из админки Yandex.
  • Нажмите Ок.

Добавление MX-записи

Теперь внесём записи, необходимые для работы непосредственно почты.

Сперва удалим старые записи. Щелкните по имеющиейся записи типа МХ и нажмите Удалить.

Аналогично удалите TXT-запись, в которой указан префикс SPF:

Внесём новую MX-запись. Эта запись указывает, на какой именно почтовый сервер следует доставлять почту.

Щелкните по кнопке Создать.

  • В первом поле укажите @
  • Выберите тип записи MX
  • В поле «Домен» укажите mx.yandex.net. (обязательно с точкой в конце!)
  • В поле «Приоритет» укажите 10
  • Нажмите Ок.

Добавление SPF-записи

SPF-запись необходима, чтобы письма не попадали в спам.

Щелкните по кнопке Создать.

  • В первом поле укажите @
  • Выберите тип записи TXT
  • В поле «Значение» укажите: v=spf1 redirect=_spf.yandex.net
  • Щелкните Ок

Вот как выглядят правильно добавленные записи:

Теперь необходимо подождать несколько часов, прежде чем Yandex сможет увидеть эти записи.

Проверка записей Яндексом

Спустя несколько часов откройте Яндекс.Коннект, раздел Почта / Домены: https://admin.yandex.ru/domains

Нажмите Подтверить домен, чтобы посмотреть текущее состояние проверки:

Если подтверждение произошло, Яндекс сообщит об этом:

Добавление DKIM-подписи

DKIM-подпись не обязательна, но её наличие защищает вас от подделки ваших писем злоумышленниками. Также она существенно снижает шанс на попадание отправляемых писем в спам.

На той же странице внизу есть раздел, откуда нужно скопировать текст DKIM-подписи:

Вернёмся в панель управления хостингом и добавим эту подпись.

Щелкните по кнопке Создать.

  • В первом поле укажите @
  • Выберите тип записи TXT
  • В поле «Значение» внесите весь текст подписи целиком.
  • Щелкните Ок

На этом настройки со стороны домена завершены.

Теперь вся входящая почта для вашего домена будет поступать и обрабатываться серверами Яндекса.

Создание почтовых ящиков

Теперь добавим почтовый ящик на стороне Yandex. Это делается в Админке, раздел Пользователи: https://admin.yandex.ru/users

Нажмите кнопку Добавить пользователей:

Заполните форму с данными и сохраните пользователя:

Всё готово.

Теперь с этим новым почтовым ящиком можно входить в Яндекс Почту и работать с почтой точно так же, как с обычным ящиком вида что-то@yandex.ru:

Кстати, хотите себе тоже трёхсимвольный домен .RU по обычной цене?

01/02/2021


Поделиться


Полезные статьи

Как перевести сайт на https?

Переводим сайт на https. Установка https на сайте может испугать немного неподготовленного пользователя, которому при… читать далее

Что такое dns простыми словами

DNS – это компьютерная распорядительная система для получения информации о доменах. Этот сервис призван поддерживать … читать далее

Что такое ddos-атака

DDoS-атаками называются нападения на интернет-ресурсы с целью лишить их возможности обработки запросов пользователей…. читать далее

… все статьи

Адреса серверов POP3, IMAP и SMTP

Список почтовых серверов популярных хостингов и бесплатных сервисов для настройки почтовых клиентов и скриптов отправки и получения почты.

  • POP3 — все письма скачиваются пользователю на компьютер и удаляются с сервера, все дальнейшие действия с письмами производиться на компьютере пользователя (входящая почта).
  • IMAP — действия с письмами осуществляются на почтовом сервере.
  • SMTP— только отправка электронной почты (исходящая почта).

1

Протокол Сервер Порт SSL Без шифрования, STARTTLS
POP3 pop.masterhost.ru 995 110
IMAP imap.masterhost.ru 993 143
SMTP smtp.masterhost.ru 465 25 или 2525

Источник

2

Протокол Сервер Порт SSL Без шифрования, STARTTLS
POP3 mail.hosting.reg.ru 995 110
IMAP mail. hosting.reg.ru 993 143
SMTP mail.hosting.reg.ru 465 25 или 587

Источник

3

Протокол Сервер Порт SSL Без шифрования, STARTTLS
POP3 pop3.timeweb.ru 995 110
IMAP imap.timeweb.ru 993 143
SMTP smtp.timeweb.ru 465 25 или 2525

Источник

4

Протокол Сервер Порт SSL Без шифрования, STARTTLS
POP3 pop3. beget.com 995 110
IMAP imap.beget.com 993 143
SMTP smtp.beget.com 465 25 или 2525

Источник

5

Протокол Сервер Порт SSL Без шифрования, STARTTLS
POP3 mail.nic.ru 995 110
IMAP mail.nic.ru 993 143
SMTP mail.nic.ru 465 587, 25 или 2525

Источник

6

Протокол Сервер Порт SSL Без шифрования, STARTTLS
POP3 mail. jino.ru 110
IMAP mail.jino.ru 993 143
SMTP smtp.jino.ru 465 587

Источник

7

Протокол Сервер Порт SSL Без шифрования, STARTTLS
POP3 pop.yandex.ru 995
IMAP imap.yandex.ru 993
SMTP smtp.yandex.ru 465

Источник

8

Протокол Сервер Порт SSL Без шифрования, STARTTLS
POP3 pop. mail.ru 995
IMAP imap.mail.ru 993
SMTP smtp.mail.ru 465

Источник

9

Протокол Сервер Порт SSL Без шифрования, STARTTLS
POP3 pop.gmail.com 995
IMAP imap.gmail.com 993
SMTP smtp.gmail.com 465 587

Источник

10

Протокол Сервер Порт SSL Без шифрования, STARTTLS
POP3 pop. rambler.ru 995
IMAP imap.rambler.ru 993 143
SMTP smtp.rambler.ru 465

Источник

11

Протокол Сервер Порт SSL Без шифрования, STARTTLS
POP3
IMAP imap.mail.me.com 993
SMTP smtp.mail.me.com 587

Источник

12

Протокол Сервер Порт SSL Без шифрования, STARTTLS
POP3 pop. mail.yahoo.com 995
IMAP imap.mail.yahoo.com 993
SMTP smtp.mail.yahoo.com 465 или 587

Источник

Заметки про работу с DNS зонами




www.lissyara.su —> статьи —> FreeBSD —> программы —> DNS zones

Заметки про работу с DNS зонами

Автор: terminus.


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


…Чтобы было наглядней о чем разговор идет, опишу как происходит процесс делегирования. Делегирование — это то каким образом пространство имен в DNS делится на зоны. Зона — это обособленная ветвь пространства DNS имен которая располагается на своих авторитарных DNS серверах. В зону может входить любое количество доменов нижележащего уровня — до тех пор пока они все расположены на одних и тех же авторитарных серверах, зона у них одна и та же.
Делегирование из родительской зоны происходит путем создания NS записей. В дочерней (делегированной) зоне создается полное описание зоны начиная с SOA записи. Вот, например, когда регистрируется домен второго уровня через регистратора nic.ru, то там при регистрации просят указать имена и адреса минимум двух DNS серверов которые будут считаться авторитарными для данной ветви пространства DNS имен. Для проведения делегирования не обязательно иметь под зону именно два DNS сервера — просто у nic. ru такая политика для того чтобы заставить клиентов обеспечить надежность системы. Вот эти два сервера становятся NS записями в домене ru.

Пример. Скажем, нами регистрируется домен второго уровня под названием net.ru. Авторитарными для него будут DNS сервера ns.net.ru (IP 1.2.3.4) и ns2.dnshosting.com (IP 5.6.7.9). В записях DNS серверов отвечающих за зону ru. (которыми управляет организация nic.ru) вносится такая информация:

$TTL 300
ru.   IN   SOA   ns.ripn.net. hostmaster.ripn.net. (
         4014396 ;serial
         7200   ;refresh
         900   ;retry
         2592000   ;expire
         3600   ;neg. ttl
         )
      NS   sunic.sunet.se.
      NS   e.dns.ripn.net.
      NS   ns.ripn.net.
      NS   ns5.msk-ix.net.
; это добавили
net.ru.   NS   ns.net.ru.
net.ru.   NS   ns2.dnshosting.com.
ns.net.ru.   A   1.2.3.4

Запись "ns. net.ru. A 1.2.3.4" называют еще "glue record", она нужна в случаях, когда имя NS сервера располагается внутри делегированной зоны. Это вспомогательная запись которую обязательно указывать в таких случаях. Без нее возникла бы ситуация, когда для того чтобы узнать IP сервера ns.net.ru надо обратиться к нему по IP (замкнутый круг). Так как второй NS расположен в чужой зоне, то для него не указываем glue record.

В свою очередь на сервере ns.net.ru который является мастером для зоны net.ru создается полная SOA запись как и полагается:

$TTL 300
net.ru.   IN   SOA   ns.net.ru. hostmaster.net.ru. (
         2009012500   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns.net.ru.
      NS   ns2.dnshosting.com.
      MX 10   mail.net.ru.
ns.net.ru.   A   1. 2.3.4
www.net.ru.   A   9.8.7.6
ftp.net.ru.   A   10.11.12.13
mail.net.ru.   A   11.12.13.14

На slave сервере ns2.dnshosting.com в ручную записи не создаются, но он настраивается так чтобы периодически запрашивать мастер ns.net.ru и перекачивать с него всю информацию о записях в домене, а мастер ns.net.ru настраивается так чтобы отдавать все записи о зоне при запросах с подчиненного.

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

Например случай с делегированием домена третьего уровня. Выглядеть это будет так — в записях зоны net.ru добавляется информация с NS записями о субдомене home.net.ru (допустим, будет только один авторитарный DNS сервер для этого субдомена ns.home.net.ru IP 7.7.7.7)

$TTL 300
net. ru.   IN   SOA   ns.net.ru. hostmaster.net.ru. (
         2009012500   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns.net.ru.
      NS   ns2.dnshosting.com.
      MX 10   mail.net.ru.
ns.net.ru.   A   1.2.3.4
www.net.ru.   A   9.8.7.6
ftp.net.ru.   A   10.11.12.13
mail.net.ru.   A   11.12.13.14
;это добавили
home.net.ru.   NS   ns.home.net.ru.
ns.home.net.ru.   A   7.7.7.7

Ну и соответственно на DNS сервере ns.home.net.ru создается зона с новой SOA записью:

$TTL 300
home.net.ru.   IN   SOA   ns.home.net.ru. adminzoni.mail.ru. (
         2009012501   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg.  ttl
         )
      NS   ns.home.net.ru.
ns.home.net.ru.   A   7.7.7.7
home.net.ru.      A   7.7.7.8
www.home.net.ru.   A   7.7.7.8
proxy.home.net.ru.   A   7.7.7.9

Был приведен синтаксис зоны как это принято в BIND и NSD. Для djbdns то, что написано выше будет выглядеть так:

Zhome.net.ru:ns.home.net.ru.:adminzoni.mail.ru.: \
2009012501:7200:900:2592000:3600:300
&home.net.ru:7.7.7.7:ns.home.net.ru
+home.net.ru:7.7.7.8:300
+www.home.net.ru:7.7.7.8:300
+proxy.home.net.ru:7.7.7.9:300

До кучи, напишу заодно еще и про реверс зоны и их делегирование.
Система DNS позволяет производить обратные разрешения из IP адресов в DNS имена. Для этого в дереве имен есть специальный служебный домен под именем in-addr.arpa. Этот домен имеет 256 субдоменов, каждый из субдомменов может иметь 256 своих субдоменов, у которых могут быть 256 своих субдоменов, в которых уже будет по 256 имен. Таким образом получается структура вида a.b.c.d.in-addr.arpa. где а,b,c,d это 0-255. На эту часть DNS имен распространяются те же правила, что и на обычные имена, вот только владельцем какого-либо субдомена может стать лишь организация получившая контроль за соответствующим блоком IP адресов — например провайдер, когда покупает для своих нужд у RIPE диапазоны IP адресов. Например, если провайдер купил себе префикс с адресами 123.44.55.0/24 (256 адресов), то он может получить от RIPE (регионального регистратора) и реверс зону в которой начнет создавать PTR записи по просьбе клиентов или для своих нужд:

$TTL 300
55. 44.123.in-addr.arpa.   IN   SOA   ns.net.ru. admin.net.ru. (
         2009012500   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns.net.ru.
      NS   ns2.dnshosting.com.
1.55.44.123.in-addr.arpa.   PTR   hostname.net.ru.
2.55.44.123.in-addr.arpa.   PTR   imja.net.ru.
254.55.44.123.in-addr.arpa.   PTR   esheodnoija.net.ru.

Тут все просто и красиво потому, что в этом примере деление на DNS зону и IP субнет произошло по границе третьего и четвертого байта в IP адресе, а как делегировать половину субнета или только пару IP адресов из него? Скажем, клиент купил себе 8 "белых" IP адресов и захотел получить контроль над назначением реверс имен для них?
В таком случае можно сделать делегирование таким образом - в родительской зоне создаются CNAME записи на подставной домен, а он уже делегируется клиенту:

$TTL 300
55. 44.123.in-addr.arpa.   IN   SOA   ns.net.ru. admin.net.ru. (
         2009012500   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns.net.ru.
      NS   ns2.dnshosting.com.
1.55.44.123.in-addr.arpa.   PTR   hostname.net.ru.
2.55.44.123.in-addr.arpa.   PTR   imja.net.ru.
254.55.44.123.in-addr.arpa.   PTR   esheodnoija.net.ru.
;создаем подставные записи
7.55.44.123.in-addr.arpa.   CNAME   7.klient.55.44.123.in-addr.arpa.
8.55.44.123.in-addr.arpa.   CNAME   8.klient.55.44.123.in-addr.arpa.
9.55.44.123.in-addr.arpa.   CNAME   9.klient.55.44.123.in-addr.arpa.
10.55.44.123.in-addr. arpa.   CNAME   10.klient.55.44.123.in-addr.arpa.
11.55.44.123.in-addr.arpa.   CNAME   11.klient.55.44.123.in-addr.arpa.
12.55.44.123.in-addr.arpa.   CNAME   12.klient.55.44.123.in-addr.arpa.
13.55.44.123.in-addr.arpa.   CNAME   13.klient.55.44.123.in-addr.arpa.
14.55.44.123.in-addr.arpa.   CNAME   14.klient.55.44.123.in-addr.arpa.
;делегируем клиенту
klient.55.44.123.in-addr.arpa.   NS   ns1.klient.ru.
klient.55.44.123.in-addr.arpa.   NS   ns2.hosting.com.

Клиент принимает у себя:

$TTL 300
klient.55.44.123.in-addr.arpa.   IN   SOA   ns1. klient.ru. admin.klient.ru. (
         2009012502   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns1.klient.ru.
      NS   ns2.hosting.com.
7.klient.55.44.123.in-addr.arpa.   PTR   host1.klient.ru.
8.klient.55.44.123.in-addr.arpa.   PTR   host2.klient.ru.
9.klient.55.44.123.in-addr.arpa.   PTR   host3.klient.ru.
10.klient.55.44.123.in-addr.arpa.   PTR   host4.klient.ru.
11.klient.55.44.123.in-addr.arpa.   PTR   host5.klient.ru.
12.klient.55.44.123.in-addr.arpa.   PTR   host6.klient.ru.
13.klient.55.44.123.in-addr.arpa.   PTR   host7.klient.ru.
14.klient.55.44.123.in-addr.arpa.   PTR   host8.klient.ru.

. ..

Да, еще одна штука вспомнилась.
Я когда работал в провайдере, так все хотел приколоться и сделать себе почтовый адрес вида [email protected], но не успел — все лень было, а потом уволился и сейчас своих реверс зон нет нигде.

Между прочим, нету никакаих объективных причин почему бы такое не работало — DNS должен будет корректно отвечать на запросы о MX записях для домена 1.2.3.4.in-addr.arpa так же как и для обычных доменов. Если есть в наличии SMTP сервер «для поиграться» + желание приколоться, то можно прописать в PTR зоне MX запись, на почтовом сервере на который указывают MX запись прописать домен, и проверить как оно будет (99% что должно работать).

Еще заметка про новый домен РФ и punycode.

Как известно недавно создали новые «национальные» домены верхнего уровня. Вот список всех TLD доменов ( http://data.iana.org/TLD/tlds-alpha-by-domain.txt ). России достался свой домен под именем «РФ.». Возникает вопрос — как это работает и как его использовать. Работает это следующим образом: юзер вписывает в адресной строке броузера «россия.рф», броузер юзера перекодирует этот адрес в формат punycode и получается «xn--h2alffa9f.xn--p1ai», далее идет стандартное обращение к DNS на разрешения А записи для имени xn--h2alffa9f.xn--p1ai. Таким образом поддержка национальных языков в DNS именах — проблема клиентского програмного обеспечения. Захотел юзер посмотреть страничку — броузер должен уметь punycode. Захотел послать письмо электропочтой — почтовый клиент должен уметь punycode. И так далее.

Администратуру DNS сервера для создания зоны надо воспользоваться punycode конвертором ( например http://mct.verisign-grs.com/ ) и переконвертировать имя своего нового, модного домена из «иванломов.рф» в «xn--80adbvrgfjb.xn--p1ai». Далее все как обычно:

$TTL 300
xn--80adbvrgfjb.xn--p1ai.   IN   SOA   ns.xn--80adbvrgfjb.xn--p1ai. ad.m.ru. (
         2012082600   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg.  ttl
         )
      NS   ns.xn--80adbvrgfjb.xn--p1ai.
      NS   ns2.dnshosting.ru.
      A   56.78.90.12
ns.xn--80adbvrgfjb.xn--p1ai.   A   98.76.54.32
www      CNAME   xn--80adbvrgfjb.xn--p1ai.

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

Ссылка на обсуждение: http://forum.lissyara.su/viewtopic.php?f=3&t=14239&start=25.

размещено: 2010-03-09,
последнее обновление: 2010-08-26,
автор: terminus

оценить статью:


2014-07-27, lissyara
gmirror

Удалённое создание софтверного зеркала средствами gmirror, на диске разбитом с использованием gpart. Использование меток дисков для монтирования разделов.
2013-08-20, zentarim
Scan+Print server FreeBSD 9

Настройка сервера печати и сервера сканирования под управлением операционной системы FreebSD 9 для МФУ Canon PIXMA MP540
2011-11-20, BlackCat
Разъём на WiFi-карту

Делаем съёмной несъёмную антену на WiFi-карте путём установки ВЧ-разъёма
2011-09-14, manefesto
Настройка git+gitosis

Настройка системы контроля версия исходного кода в связке git+gitosis+ssh
2011-08-14, zentarim
Wi-FI роутер + DHCP + DNS

Настройка Wi-Fi роутера на Freebsd 8 + DNS сервер + DHCP сервер: чтобы Wi-Fi клиенты были в одной подсети с проводными, проводные и беспроводные клиенты получали адреса автоматически по DHCP, кэширующ
2011-06-15, -ZG-
Охранная система на FreeBSD+LPT

В этой статье описана попытка реализации простой охранной системы на базе FreeBSD с подключением к ней охранных устройтсв на LPT порт и видеорегистрацией.
2011-03-13, terminus
ng_nat

Описание работы ng_nat, практическое использование, достоинства и недостатки в сравнении с ipfw nat
2011-02-20, Капитан
Nagios+Digitemp

Статья описывает создание системы оповещения о превышении температуры в специальных помещениях на основе Nagios с использованием программы Digitemp.
2011-02-17, Le1
Zyxel Configuration

Скрипт для массового изменения конфига свичей Zyxel. Берет из файла iplist список ip-шек, заходит последовательно на каждый и выполняет комманды из файла commands, записывая происходящее в лог файл.
2011-02-16, fox
hast carp zfs ucarp cluster

HAST (Highly Available Storage), CARP, UCARP, ZFS, Cluster настройка и одаптация плюс личные размышления…
2011-02-04, BlackCat
Восстановление ZFS

История о том, как был восстановлен развалившийся RAIDZ ZFS-пул (перешедший в FAULTED) с помощью скотча и подручных средств. Или о том, какие приключения ожидают тех, кто не делает резервных копий.
2011-02-03, Капитан
1-Wire

Статья описывает самостоятельное изготовление контроллера DS9097 для съёма показаний с датчиков температуры DS1820 с помощью программы Digitemp.
2011-01-28, Капитан
Температура в серверной

Статья описывает построение системы наблюдения за температурой в помещении серверной с использованием программы Digitemp и выводом графиков в MRTG
2011-01-21, m4rkell
Syslog server

Как то буквально на днях, у нас завалилось, что то в еве) или не в еве не суть. Суть в том, что когда захотели снять логи с хостов esx обнаружили, что хранят эти негодяи логии только за последнии сутк
2011-01-07, lissyara
Canon/gphotofs

Монтирование цифровых фотоаппаратов Canon (PTP) как файловой системы, автоматизация этого процесса через события devd и внешние скрипты.
2010-12-13, Al
IPSec

Описание принципов работы IPSEC и способов аутентификации.
2010-12-07, manefesto
FreeBSD on flash

Было принято решении переехать на USB Flash и установить минимальный джентельменский набор для работы своего роутера. Делаем =)
2010-12-05, Fomalhaut
root ZFS, GPT

Инструкция по установке FreeBSD с использованием в качестве таблицы разделов GPT и в качестве основной файловой системы - ZFS
2010-09-05, Cancer
Настройка аудиоплеера на ximp3

Цели: Простенький аудиоплеер, для того что бы тетя продавец в магазине утром пришла нажала на кнопку Power и заиграла в зале музыка, так же был доступ по сети, общая шара куда можно заливать музыку, к
2010-08-31, Cancer
Установка и настройка OpenVPN

На днях появилась задача - объединить головной офис и 3 филиала в одну сеть через интернет посредством OpenVPN, чтобы люди могли подключаться через RDP к базам 1С на серверах.
2010-08-25, manefesto
freebsd lvm

Использование linux_lvm для работы с LVM разделами из-под FreeBSD. Проблемы которые возники при монтирование lvm раздела
2010-04-30, gonzo111
proftpd file auth&quota

Proftpd - квоты и авторизация из файлов, без использования базы данных и/или системных пользователей
2010-04-22, lissyara
tw_cli

Пошаговая инструкция по восстановлению RAID на контроллере 3ware, из которого выпал один диск. Настройка мониторинга состояния рейда и отчётов о его состоянии на email.
2010-04-14, fox
MySQL Master+Master

MySQL (Master Master) and (Master Slave) Как настроить репликацию…
2010-03-09, terminus
DNS zones

Краткий ликбез про управление DNS зонами. Примеры проведения делегирования прямых и обратных DNS зон.
подписка

NS.Tools: NIC.RU — Проверьте DNS, MX и WHOIS TEST TEST DOMEN NIC.RU

Домен или IP

ОБНОВЛЕНИЕ АНАЛИЗ


Оценка 87%

Домен

A

3 Критерии 9000 2 Инфу.