Обновить ресурсную запись NS | Помощь
Обновить ресурсную запись NS | Помощь | API 1cloud.ru Информация, необходимая для обновления существующей ресурсной NS-записи на DNS-серверах 1cloud через API. Входные параметры POST-запроса (id, DomainId, HostName, Name), пример запроса, request header, пример ответа.
- Главная
- API
- DNS
Для того, чтобы обновить существующую NS запись на DNS серверах 1cloud, необходимо отправить PUT запрос по адресу https://api.1cloud.ru/dns/recordns/{id}, где {id} — уникальный идентификатор записи.
Ответом будет JSON объект, данный объект будет содержать все атрибуты обновлённой записи.
Входные параметры
| Название | Тип | Описание |
|---|---|---|
| id | string | Уникальный идентификатор обновляемой записи |
| DomainId | string | Уникальный идентификатор домена |
| HostName | string | Доменное имя или @ |
| Name | string | Доменное имя NS сервера |
|
TTL |
string |
Длительность кэширования записи в секундах. Может содержать следующие значения:
|
Выходные параметры
| Название | Тип | Описание |
|---|---|---|
| ID | number | Уникальный идентификатор домена |
| Name | string | Наименование домена |
| string | Техническое наименование домена | |
| State | string | Статус домена на момент обработки запроса. Может содержать следующие значения:
|
| DateCreate | DateTime | Дата создания домена |
| LinkedRecords | list | Список записей, которые ассоциированы с данным доменом. Содержит список объектов, каждый из которых имеет следующие атрибуты:
|
Пример запроса
curl -X PUT -H 'Content-Type: application/json' -H 'Authorization: Bearer 75bb9805c018b1267b2cf599a38b95a3a811e2ef7ad9ca5ed838ea4c6bafaf50' "https://api.
1cloud.ru/dns/recordns/1" -d '{"DomainId":"1", "Name":"hostname.ns"}'
Request Header
Content-Type: application/json Authorization: Bearer 75bb9805c018b1267b2cf599a38b95a3a811e2ef7ad9ca5ed838ea4c6bafaf50
Пример ответа
[
{
"ID":"8",
"TypeRecord":"NS",
"IP":"",
"HostName":"@",
"Priority":"",
"Text":"",
"MnemonicName":"",
"ExtHostName":"hostname.ns.",
"State":"New",
"TTL":"3600",
"CanonicalDescription":"@ 3600 IN NS hostname.ns."
}
]
Последнее обновление: 03.06.2018
Последовательность изменения NS сервера для Домена. (для linux администраторов) / likes / блог студии Клондайк!
Правильно переписываем NS запись для Домена.
Данная статья предназначена для профессионалов.
Если данная статья вам сложна, существует более простая версия данной статьи.
Для начала разберемся, что мы имеем. Для этого воспользуемся замечательной утилитой host c дополнительным клюем -a (все) , получим информацию о текущих настройках SOA окружения.
host -a klondike-studio.ru
Как мы видим из рисунка сервер 188.138.84.137 держит наш сайт,
Ns сервера выглядят очень странно да и еще 4 уровня. Что косвенно указывает на собственный ДНС сервер и скорее всего именно на данном же сервере что и сам сайт, это легко проверить.
Собственно, как я и предположил ДНС сервер расположен там же где и сайт, а следовательно, сразу предполагаем что и админка у них общая, хотя тут уже как повезет.
Нам теперь понятно где именно нужно искать существующую SOA запись. Реальная запись может отличаться, собственно посмотрим саму запись, и сразу видим что сервер посторонним глазам лишнего не показывает. На самом деле в настройках куда больше информации.
А следовательно, при переносе нужно учесть и этот факт, так что заходим в админку, в моем случае, у меня есть доступ до root ssh и мне быстрей глянуть в самом bind сервере.
vim /etc/bind/pri.klondike-studio.ru
Отлично, теперь мы видим и остальные записи, PTR в принципе можно и пропустить.
Соответственно на новом ДНС сервере нам нужно будет добавить субдомены: crm dev m mail
Данное доменное имя более не будет выступать в роли днс сервера, а следовательно ns1 ns2 нам более не нужны.
Редактируем зону на новом сервере, как правило существуют уже стандартные шаблоны. Нам нужно всего лишь добавить субдомены spf и так далее.
Поскольку почту, мы уносим на яндекс Почта для домена нам нужно будет скорректировать и MX запись.
И к существующее spf добавить
include:_spf.yandex.ru
Но не как рекомендует яндекс.
v=spf1 redirect=_spf.yandex.ru
PTR я на всякий все же добавлю, как говориться лучше «перебдеть». Хоть сотрудники Яндекс и уверили, что проблем не будет, однако две строчки добавить не так сложно, чтобы потом думать как и что мы пропустили.
Как формируются PTR записи можно найти в интернете, поскольку данный сервер делал я, то wizard уже создал и ее и SPF уже скорректированными.
Результате получаем вот это:
После применяем и ждем изменении, проверить примерились ли они достаточно легко, для этого можно использовать как и nsloocup так и тот же host только c принудительным указанием ns сервера ответчика. В моем случае я могу скинуть кеш самостоятельно, поскольку имею полный доступ до сервера, и применение приходит за несколько секунд. Теперь проверяем:
host -a klondike-studio.ru ns1.klondike-s.ru
Видим что ns сервер ns1.klondike-s.ru уже знает о данном домене и следовательно нам остается только переписать ns сервера. Как только они перепишутся на новые, существующий сайт сразу начнет работу уже с нового сервера поскольку все записи на нем уже корректны.
Отдельно стоит обратить внимание на следующий факт:
В конце стоит точка, и это не опечатка, а очень важный факт. Поскольку многие админки хостеров сами доставляют точку к имени ns сервера то нужно учитывать и этот факт. Если уже созданные записи NS не содержат точку на конце то следует ее и не ставить в противном случае скрипт создаст вам запись типа «klondike-s.
ru.»
Если же в вашей админке точки ставятся, то соответственно е нужно поставить, недопустимо не соблюдать это правило, поскольку точка это верхний регистратор, вещь принципиальная. Соответствен данное правило распространяется и на MX записи.
В принципе все сделано осталось убедиться что все корректно работает.
Для начала мы убедились что новый ДНС сервер уже отдает саму запись, соответственно жде когда перепишутся НС не забываем что кеш у доменных имен всегда очень внушительный и кеширует его все кому не лень. От вашей ос (в ubuntu так и не нашел как его корректно сбросить не устанавливая полноценного днс кеш) в windows.
ipconfig /flushdns
Для корректно же работы в linux мы можем сделать следующее.
Принудительно указать принудительно днс сервер в настройках сети нужный нам ns1.klondiek-s.ru сервер.
Так же можно указывать его для разработчиков на новом сервере, если сайт все еще работает на старом, фактически разработчик разрабатывает на новой площадке, когда клиент все еще пользуется старой.
Указать, любезно предоставленные google, днс сервера.
Их кеш скидывается куда быстрей чем у нашего провайдера я вообще предпочитаю через них работать. «8.8.8.8» (ребята не экономят на хороших IP адресах на самом деле там их куча 4.4.4.4 5.5.5.5 6.6.6.6 и т. д.
Самый легкий способ, поскольку у меня большое количество ssh доступов до серверов по всему миру можно воспользоваться утилитой linkx или w3m.
Однако стоит помнить если вы зайдете на новый сервер и зайдете с консольного браузера то локальная ДНС запись перебьет внешнюю и вы попадете на сайт уже на данном сервере. Что тоже полезно когда вы подключаете базу данных и вам нужно проконтролировать корректно ли она подключилась. Однако не подходит для тестирования актуальности ДНС. А вот другие сервера для этого отлично подходят.
Консоль в помощь.
dig NS klondike-studio.ru
nslookup klondikestudio.ru
У последнего через пробелы можно указать еще и днс сервер ответчика.
Ну и напоследок, после полного переписывания, проходим по всем доменам указанных в, А записях, проходим по всем почтам, отправляем почту на разные ящики: яндекс, маил и корпоративную почту. Особенное внимание майлу — если у вас некорректно указан spf, почта может не дойти.
В моем случае, после проверки пришлось внести корректировку, поскольку домен 3 уровня crm ссылался на локальную машину, в свою очередь на ней, в виртуалхосте был прописан редирект типа R, уходящий на дугой адрес. Собственно, пришлось создать данный вид редиректа и на новом сервере. Большинство программистов предпочитают сделать это средством .htacces s, но для этого на сервере нужно создавать отдельную учетку под пользователя, и вообще заводить место под сайт и т. д. Мне проще сделать все нормальным способом прямо в virtualhost или CHNAME, в моем случае еще и портфорвардинг мне проще было сделать именно так.
Сеть— Лучшее понимание NS Record и Authorative Server
Задавать вопрос
спросил
Изменено 1 год, 4 месяца назад
Просмотрено 252 раза
Я пытаюсь понять, как работает DNS.
Даже после небольшого количества поисков мне все еще не ясно, как работает NS-запись. Теперь я следую двум фактам.
Факт 1 (на основании этой статьи, абзац первый)
Запись NS или (запись сервера имен) сообщает рекурсивным серверам имен какие серверы имен являются авторитетными для зоны.
Факт 2 (здесь, в разделе авторитетного сервера имен)
Полномочный сервер имен содержит информацию, относящуюся к доменное имя, которое он обслуживает (например, google.com), и может предоставить рекурсивное резолвер с IP-адресом этого сервера, найденным в DNS A запись…
Теперь, скажем, я выбираю компанию A в качестве провайдера доменного имени — я купил свое доменное имя у A пока я размещаю свое веб-приложение на сервере компании B .
Итак, исходя из фактов 1 и 2, мой вопрос:
(1) Будет ли компания A (у которой я купил доменное имя) работать для меня как авторитетный сервер и будет ли она указывать на B ‘ с сервера через (запись)?
(2) Поскольку запись NS указывает, где находится мой полномочный сервер, это означает, что запись NS не будет храниться на полномочном сервере.
Верно ли это предположение?
(3) Где-то я должен установить все записи DNS (такие как A-запись, MX-запись, CNAME-запись), чтобы они правильно указывали на сервер размещения моего веб-приложения. Авторитетный сервер — это место для этого, которое я должен сам обслуживать?
Заранее спасибо. ( Я знаю, что много спрашивал в том же посте. Вам может показаться скучным, извините за это. )
- сеть
- система доменных имен
- сервер имен
- ns-record
- DNS-запись
На самом деле в вопросе задействованы три субъекта (по крайней мере, концептуально):
- Регистратор («А» в вопросе)
- DNS-хостинг-провайдер
- Хостинг-провайдер («В» под вопросом)
Теоретически роль регистратора заключается только в регистрации доменных имен в реестре и обновлении параметров зарегистрированных доменных имен в реестре от имени владельца регистрации (заказчика).
На практике многие регистраторы также предоставляют услуги хостинга DNS в дополнение к регистрации доменного имени либо бесплатно в качестве дополнительной услуги, либо в качестве дополнительной услуги.
В таких случаях стоит отметить, что одно и то же лицо, являющееся и регистратором, и провайдером хостинга DNS, является случайным с точки зрения фактического функционирования системы.
Теоретически регистрант (заказчик) сообщает регистратору, какие серверы имен он хочет использовать для своего доменного имени, и регистратор вносит их в реестр, после чего соответствующие записи NS публикуются в родительской зоне.
В случае, когда вы также используете услуги хостинга DNS, предоставляемые компанией-регистратором, информация о серверах имен для их собственных серверов имен обычно вводится без каких-либо явных действий со стороны владельца регистрации.
- Это полностью зависит от того, предоставляет ли регистратор («компания А») также услуги хостинга DNS (согласно примечанию выше) и, очевидно, также от того, решит ли регистрант их использовать.
- Существует
записей NSв данных делегирования в родительской зоне, чтобы разрешить распознавателям фактически находить полномочные серверы имен дочерней зоны, нополномочных записей NSявляются частью дочерней зоны.
Эти наборы записей NSвсегда должны совпадать! (Не забудьте обновить оба) - При желании вы можете запустить свой собственный сервер имен или воспользоваться услугами какого-либо провайдера DNS-хостинга (как отмечалось ранее, такие услуги может предоставлять компания-регистратор, но вы также можете использовать любого другого провайдера DNS-хостинга).
Эти наборы записей Зарегистрируйтесь или войдите в систему
Зарегистрируйтесь с помощью Google
Зарегистрироваться через Facebook
Зарегистрируйтесь, используя адрес электронной почты и пароль
Опубликовать как гость
Электронная почта
Обязательно, но не отображается
Опубликовать как гость
Электронная почта
Требуется, но не отображается
Нажимая «Опубликовать свой ответ», вы соглашаетесь с нашими условиями обслуживания, политикой конфиденциальности и политикой использования файлов cookie
Система доменных имен— преобразователь DNS против записи NS TTL
Когда преобразователь DNS ищет в домене/зоне авторитетный сервер имен, принимает ли он все 6 записей и циклически перебирает их?
Да, правильный рекурсивный сервер имен учитывает все серверы имен и каждый раз будет пытаться запрашивать самый быстрый из них.
Приблизительный алгоритм такой:
- при холодном старте (без кеша), пробовать их все случайным образом, записывать, как быстро они отвечают (вам может понадобиться отделить там UDP-кейс от TCP-кейса)
- через некоторое время начните чаще использовать самый быстрый на основе предыдущих ответов
- , но обратите внимание, что вам нужно убедиться, что вы не привязаны на неопределенный срок к какому-либо заданному серверу имен, вам нужно «время от времени» пробовать и другие. Почему? Потому что топология сети может меняться, как и сами серверы имён.
ns3может быть более быстрым сегодня для вашей конкретной точки зрения, но, возможно, завтра вместо этого будетns5; поэтому вы должны использовать самый быстрый, но не всегда, просто чтобы иметь возможность автоматически обнаруживать любой другой быстрее, чем тот, который вы считаете самым быстрым прямо сейчас.
Если резолвер использует 1-й сервер NS
Стой здесь.
Записи идут набором, а не списком. То есть в DNS нет внутреннего порядка. Конечно есть порядок в проводном или дисплейном представлении, но он не исходит из протокола.
Наборы пластинок — мешки: вы получаете пластинки без заказов. Фактически, вы можете видеть, что многие серверы имен для одного и того же запроса, если в ответе есть несколько записей, будут упорядочивать записи по-разному каждый раз, когда вы запрашиваете, именно для борьбы с клиентскими системами, которые будут учитывать только первый элемент и пренебрегать остальными.
, когда этот полномочный сервер имен не отвечает
См. алгоритм выше: если один из серверов имен в наборе NS не отвечает, вы можете считать, что это то же самое, что «отвечает как самый медленный из любого другого». У клиентского DNS есть тайм-ауты, поэтому он не будет ждать бесконечно, но отметит, что этот конкретный сервер имен работает слишком медленно, и переключится на другие.
Таким образом, в первый раз вы подвергаетесь штрафу, потому что система должна попытаться связаться с этим сервером имен, немного подождать (несколько секунд), повторить попытку и в какой-то момент прекратить использование этого сервера имен.
После этого рампы он будет использовать другие серверы имен, и все будет быстро. Но в первый раз, когда вам нужно обнаружить, что данный сервер имен работает медленно/не отвечает, пытаясь связаться с ним, вы не можете сделать вывод о проблеме, не пытаясь.
Значит ли это, что мне нужно установить короткий TTL для NS-записей?
Возможно, но в основном это не имеет значения. Почему? Поскольку ваши записи NS публикуются в родительской зоне вашего домена, чтобы обеспечить делегирование DNS. Они публикуются там с TTL, конечно, так как все записи имеют прикрепленный к ним TTL, но они публикуются в зоне, которую вы не контролируете, поэтому вы НЕ можете выбирать их значения TTL!
(Здесь идет сложная/не до конца законченная дискуссия о тех записях, типа NS , которые состоят из двух частей: родительской и дочерней, с вопросом «какая из них действительно авторитетна»? Если у родителя TTL 1 неделя для записей NS , а у вас в зоне те же записи NS имеют TTL 1 секунду, что должен делать рекурсивный сервер имен? Можно прийти к выводу, что обычно дочерняя часть делегации является авторитетной, поэтому здесь выигрывает 1 секунда; на практике несколько реализаций DNS «ориентированы на родителей», то есть они используют данные на родительской стороне, поэтому здесь выигрывает 1 неделя)
TTL — это всегда компромисс.
Узнав об этом, некоторые люди сразу же делают вывод, что все работает лучше с очень низким значением TTL… что верно для некоторых случаев и не очень для других. Кэши — это хорошо, если бы их не было (иначе: не использовались достаточно большие TTL), вы не были бы устойчивы к любым небольшим проблемам, из-за которых все исчезло бы, потому что имена кешей уже истекли бы.
Также значение TTL не влияет (или оказывает незначительное) влияние на описанный выше алгоритм при циклическом обходе всех серверов имен, попытках с тайм-аутом и схождении на самом быстром.
Итак, если вы посмотрите на то, что происходит на серверах имен TLD (которые содержат записей NS для всех доменов в этом TLD) или в различных рекомендациях, вы часто увидите записей NS с TTL 1 или 2 дня.
Любые советы о том, как DNS-преобразователь работает с неотзывчивым NS и его TTL?
Каждый преобразователь делает свое собственное 🙂 На самом деле это не указано в протоколе, это деталь реализации.
Вы можете изучить исходный код того, который сможете установить, но, вероятно, не сможете получить информацию об этом от крупных общедоступных поставщиков рекурсивных DNS.
Вы можете найти более подробную информацию здесь:
- https://securityintelligence.com/subverting-binds-srtt-algorithm-derandomizing-ns-selection/
- https://www.nanog.org/meetings/nanog54/presentations/Tuesday/Yu.pdf
RFC 1034 §5.3.3 также дает некоторую информацию (обратите внимание, что он учитывает один случай, о котором вы забыли: данный сервер имен может иметь несколько IP-адресов — сегодня даже это всегда должно быть, с одним IPv4 и одним IPv6 — и нет никакой гарантии, что вы получите результаты за одинаковое количество времени с каждым):
Помимо имен и адресов серверов данные SLIST структуру можно отсортировать, чтобы в первую очередь использовать лучшие серверы и обеспечить что все адреса всех серверов используются в циклическом режиме. сортировка может быть простой функцией предпочтения адресов на локальном сеть по сравнению с другими или может включать статистику прошлых событий, например предыдущее время отклика и средние показатели.
Шаг 3 отправляет запросы до тех пор, пока не будет получен ответ. Стратегия циклически перебирать все адреса для всех серверов с тайм-аут между каждой передачей. На практике важно использовать все адреса многосетевого хоста и слишком агрессивная повторная передача политика фактически замедляет отклик при использовании несколькими распознавателями бороться за один и тот же сервер имен и даже иногда за один резольвер. SLIST обычно содержит значения данных для управления тайм-аутами. и отслеживать предыдущие передачи.
RFC 1035 §7.2 говорит следующее:
Чтобы завершить инициализацию SLIST, преобразователь прикрепляет все информация об истории, которую он имеет для каждого адреса в SLIST. Это будет обычно состоят из своего рода средневзвешенных значений времени отклика адреса и среднее значение адреса (т. е. как часто адрес ответил вообще на запрос). Обратите внимание, что это информация должна храниться по адресам, а не по сервера имен, потому что время отклика и среднее значение конкретный сервер может значительно отличаться от адреса к адресу.
Примечание
также, что эта информация на самом деле специфична для адреса резолвера /
пара адресов сервера, поэтому преобразователь с несколькими адресами может захотеть
вести отдельные истории для каждого из своих адресов. Часть этого шага
должен иметь дело с адресами, которые не имеют такой истории; в этом случае
ожидаемое время прохождения туда-обратно 5-10 секунд должно быть наихудшим случаем, с
нижние оценки для той же локальной сети и т. д.Обратите внимание, что всякий раз, когда выполняется делегирование, алгоритм распознавателя повторно инициализирует SLIST.
Информация устанавливает частичное ранжирование доступного имени адреса серверов. Каждый раз, когда выбирается адрес, и состояние должно быть изменено, чтобы предотвратить его повторный выбор, пока все другие адреса не будут был опробован. Таймаут для каждой передачи должен быть на 50-100% больше чем среднее прогнозируемое значение, чтобы учесть отклонение в ответе.
Также, чтобы закончить и более конкретно об этом:
Как показано в этой рецензии от imperva
В этой статье, на которую вы ссылаетесь, рассказывается о проблеме, возникшей у людей, использующих серверы имен Dyn, когда произошел сбой.
Тогда да, если вы используете только серверы имен Dyn, у вас есть проблема. Даже если вы измените свою зону, чтобы использовать другие, запись TTL NS означает, что ваше изменение не будет видно сразу. Но на самом деле это ничего не говорит о TTL, но много говорит об управлении DNS: если вы хотите быть устойчивым, для важных зон используйте не одного провайдера DNS, а несколько (что, конечно, требует некоторой координации между их вы не можете просто произвольно смешивать и сопоставлять провайдерам X и Y, и это еще сложнее, если вы через DNSSEC в микс, но возможно).
Таким образом, именно из-за алгоритма, быстро составленного выше, даже если 2 из 5, скажем, серверов имен не отвечают полностью, потому что у этого конкретного провайдера есть проблема, другой возьмет на себя нагрузку и заставит ваш домен работать.