Dns обновить: Как обновить кэш DNS на своем компьютере?
Как обновить кэш DNS на своем компьютере?
Нужно открыть командную строку.
Для Windows XP и ранее:
Для этого нажмите меню «Пуск», там выберите «Выполнить» и введите там слово cmd (английскими буквами) после чего нажмите Enter.
У вас откроется командная строка Windows. Введите там следующую фразу: ipconfig /flushdns и нажмите Enter (можно скопировать, чтобы не писать руками — тут копируете, в командной строке правой кнопкой мышки вставляете).
Если вы увидите следующее:
Настройка протокола IP для Windows
Успешно сброшен кэш распознавателя DNS.
то значит кэш DNS очищен. Можно закрыть командную строку.
Для Windows Vista, Windows 7, 8, 8.1, 10:
Для этого нажмите меню «Пуск», там в строке Поиска внизу введите слово cmd (английскими буквами) после чего нажмите Enter (если строки поиска нет, то в меню зайдите в Поиск). У Вас найдется программа cmd, запустите её.
У вас откроется командная строка Windows. Введите там следующую фразу: ipconfig /flushdns и нажмите Enter (можно скопировать, чтобы не писать руками — тут копируете, в командной строке правой кнопкой мышки вставляете).
Если вы увидите следующее:
Настройка протокола IP для Windows
Успешно сброшен кэш распознавателя DNS.
то значит кэш DNS очищен. Можно закрыть командную строку.
Для Mac OS
Для этого нужно ввести в Терминал одну команду. Найти Терминал можно по пути: Программы/Утилиты.
Пользователям OS X 10.6 Snow Leopard или более ранних версий необходимо ввести следующую команду:
sudo dscacheutil -flushcache
Пользователям OS X 10.7, 10.8 Mountain Lion и 10.9 Mavericks необходимо ввести следующую команду:
sudo killall -HUP mDNSResponder
Вопросы по теме:
Как сделать nslookup или tracert? →
назад в категорию «Общие вопросы»
Как обновить DNS кэш | Блог TipRus.com
При переносе домена или настройке хоста часто встречается ситуация, когда после изменения IP-адреса какого-либо хоста, в настройках зоны DNS, изменения на некоторых машинах изменяются не сразу. Проблема кроется в том, что ОС часто кэширует DNS и обновляет этот кэш не тогда, когда нам это надо.
Распространенным решением является прописывание настроек в hosts вручную. Или перезагрузка. Выполнять эти действия не очень-то удобно. Есть путь попроще — обновить DNS кеш через «Командную строку».
Обновление DNS кеша на Windows
Команда: «ipconfig /flushdns».
Команда «ipconfig /displaydns» поможет посмотреть кэш для посещенных доменов.
Примечание: для запуска комманды нажмите Start -> Run и вписать туда указанные команды.
Обновление DNS кэша на Linux
Вообще-то, Linux не кэширует DNS. Так что все вопросы следует направлять в используемым DNS серверам. Другими словами, надо использовать DNS сервер, который обновляется достаточно регулярно. Есть, конечно, и брутальный способ — перезапустить сеть командой «sudo /etc/init.d/networking restart».
Также встречаются люди, которые устанавливают nscd, который как раз и занимается кэшированием. Если этот демон запущен, его надо перезапустить «/etc/rc.d/init.d/nscd restart». В определенных случаях поможет команда «sudo /etc/resolvconf/update-libc.d/avahi-daemon».
Примечание: в разных дистрибутивах команды могут несколько отличаться.
И еще, если у Вас используется локально установленный BIND, то поможет команда «rndc flush» в BIND9 или «ndc flush» в BIND8.
Обновление DNS кеша на MacOS X
Решение такое же простое, как и в Windows. В терминале нужно ввести команду «lookupd -flushcache».
И если, все равно не работает…
Не забывайте, что разные приложения могут самостоятельно кэшировать записи DNS. В частности браузеры это делают весьма активно. Проблема лечится перезапуском нужной программы.
www.tiprus.com
Что происходит, когда вы обновляете свой DNS / Блог компании Mail.ru Group / Хабр
Fenix by Takeda11
Многие путаются в обновлении записей DNS, когда изменяют IP-адрес своего сайта. Почему эти записи медленно обновляются? Неужели действительно нужно ждать два дня, чтобы всё обновилось? Почему одни посетители видят новый IP, а другие — старый?
Команда Mail.ru Cloud Solutions перевела статью разработчика и автора статей Джулии Эванс, где она отвечает на эти вопросы и популярно рассказывает, что происходит во время обновления DNS с точки зрения фронтендера.
Вот краткое исследование того, что происходит за кулисами, когда вы обновляете запись DNS.
Как работает DNS: рекурсивные и авторитетные DNS-серверы
Во-первых, нам нужно немного объяснить систему DNS. Существует два вида DNS-серверов: авторитетные и рекурсивные.
Авторитетные DNS-серверы (также известные как серверы имен) хранят базу данных IP-адресов для каждого домена, за который они отвечают. Например, прямо сейчас авторитетный DNS-сервер для github.com — это ns-421.awsdns-52.com
. Вы можете спросить у него IP-адрес github.com вот таким запросом:
dig @ns-421.awsdns-52.com github.com
Рекурсивные DNS-серверы сами по себе ничего не знают о том, кому принадлежит какой IP-адрес. Они вычисляют IP-адрес для домена, запрашивая его у соответствующих авторитетных DNS-серверов, а затем кэшируют этот IP-адрес на случай, если их снова спросят о нем. Так, 8.8.8.8 — это рекурсивный DNS-сервер.
Когда люди посещают ваш веб-сайт, они, вероятно, делают DNS-запросы к рекурсивному DNS-серверу. Итак, как же работают рекурсивные DNS-серверы? Давайте посмотрим!
Как рекурсивный DNS-сервер запрашивает IP-адрес github.com
Давайте рассмотрим пример того, что делает рекурсивный DNS-сервер (например, 8.8.8.8), когда вы запрашиваете у него IP-адрес (запись А) для github.com. Во-первых, если у него уже есть кэшированный результат, он выдаст его. Но что, если все кэши просрочены? Вот что происходит.
Шаг 1: IP-адреса для корневых DNS-серверов жестко закодированы в его исходном коде. Вы можете увидеть это в исходном коде unbound. Допустим, для начала он выберет 198.41.0.4. Вот официальный источник этих жестко закодированных IP-адресов, также известный как «корневой файл подсказок» (root hints file).
Шаг 2: Спросить корневые серверы имен о github.com.
Мы можем приблизительно воспроизвести то, что происходит, с помощью команды dig
. Она выдает нам новый авторитетный сервер имен для запроса: сервер имен для .com
с IP-адресом 192.5.6.30.
$ dig @198.41.0.4 github.com
...
com. 172800 IN NS a.gtld-servers.net.
...
a.gtld-servers.net. 172800 IN A 192.5.6.30
...
Детали ответа DNS немного сложнее — в этом случае есть раздел авторитетности (authority section) с некоторыми записями NS и дополнительный раздел с записями A, так что вам не нужно делать дополнительный поиск, чтобы получить IP-адреса этих серверов имен.
На практике в 99,99% случаев там уже будет кэшированный адрес серверов имен .com
, но мы делаем вид, что действительно начинаем с нуля.
Шаг 3: Спросить серверы имен .com
о github.com.
$ dig @192.5.6.30 github.com
...
github.com. 172800 IN NS ns-421.awsdns-52.com.
ns-421.awsdns-52.com. 172800 IN A 205.251.193.165
...
У нас есть новый IP-адрес для отправки запроса! Это один из серверов имен для github.com.
Шаг 4: Спросить у серверов имен github.com об адресе github.com.
Мы почти закончили!
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
Итак, у нас есть запись А для github.com. Теперь у рекурсивного сервера есть IP-адрес github.com, и он может вернуть его вам. И он смог провернуть всю процедуру, начиная всего с нескольких жестко закодированных IP-адресов: адресов корневых серверов имен.
Как увидеть все шаги рекурсивного DNS-сервера: dig +trace
Чтобы посмотреть, что рекурсивный DNS-сервер будет делать для резолвинга домена, можно запустить:
$ dig @8.8.8.8 +trace github.com
Эта команда показывает все DNS-записи, которые запрашивает рекурсивный сервер, начиная с корневых DNS-серверов, то есть все четыре шага, которые мы только что прошли.
Обновим записи DNS
Теперь, когда мы знаем основы работы DNS, давайте обновим некоторые записи DNS и посмотрим, что произойдет.
При обновлении записей DNS существует два основных варианта:
- сохранить те же серверы имен;
- изменить серверы имен.
Поговорим о TTL
Но мы забыли кое-что важное. Это TTL. Как мы сказали ранее, рекурсивный DNS-сервер будет кэшировать записи до истечения срока их действия. Он принимает решение об истечении срока действия записи в зависимости от ее TTL (time to live, времени жизни).
В этом примере сервер имен GitHub для его DNS-записи возвращает TTL 60, что означает 60 секунд:
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
Это довольно короткий TTL. Теоретически, если бы все DNS-реализации следовали стандарту DNS, это означало бы, что если GitHub решил изменить IP-адрес для github.com, каждый получил бы новый IP-адрес в течение 60 секунд. Давайте посмотрим, как это происходит на практике.
Вариант 1: обновление записи DNS на тех же серверах имен
Во-первых, я обновила свои серверы имен (Cloudflare), чтобы получить новую запись DNS — запись A, которая сопоставляет test.jvns.ca
на 1.2.3.4:
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 299 IN A 1.2.3.4
Это сработало немедленно! Не было никакой необходимости ждать вообще, потому что перед этим не было никакой DNS-записи test.jvns.ca
, которая могла быть кэширована. Отлично. Но похоже, что новая запись кэшируется в течение примерно пяти минут (299 секунд).
Итак, а если мы попытаемся изменить этот IP-адрес? Я изменила его на 5.6.7.8, а затем запустила тот же DNS-запрос:
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 144 IN A 1.2.3.4
Похоже, что на этом DNS-сервере запись 1.2.3.4 всё еще кэшируется в течение 144 секунд. Интересно, что если запросить 8.8.8.8 несколько раз, вы получите противоречивые результаты — иногда он выдает новый IP, а иногда старый. Вероятно, 8.8.8.8 на самом деле распределяет нагрузку на кучу разных бэкендов, у каждого из которых собственный кэш.
После пяти минут ожидания все кэши 8.8.8.8 обновились и всегда возвращали новую запись 5.6.7.8. Потрясающе. Это довольно быстро!
Не всегда можно полагаться на TTL
Как и в большинстве интернет-протоколов, не всё подчиняется спецификации DNS. Некоторые DNS-серверы интернет-провайдеров будут кэшировать записи дольше, чем указано в TTL. Например, в течение двух дней вместо пяти минут. И люди всегда могут жестко закодировать старый IP-адрес в своем файле /etc/hosts
.
На практике при обновлении записи DNS с пятиминутным TTL можно ожидать, что большой процент клиентов быстро перейдет на новые IP-адреса (например в течение 15 минут), а затем появится куча отставших, которые будут медленно обновляться в течение следующих нескольких дней.
Вариант 2: обновление ваших серверов имен
Итак, мы видели, что когда вы обновляете IP-адрес, не меняя свои серверы имен, многие DNS-серверы довольно быстро получают новый IP-адрес. Отлично. Но что произойдет, если вы измените свои серверы имен? Давайте попробуем!
Я не хотела обновлять серверы имен для своего блога, поэтому вместо этого взяла другой свой домен и использовала его в примерах для журнала по HTTP это examplecat.com.
Раньше мои серверы были установлены на dns1.p01.nsone.net
. Я решила изменить их на серверы Google с адресами ns-cloud-b1.googledomains.com
и так далее.
Когда я внесла изменения, мой доменный регистратор несколько зловеще высветил сообщение: «Изменения в examplecat.com сохранены. Они вступят в силу в течение ближайших 48 часов». Затем я установила новую запись A для домена, чтобы она указывала на 1.2.3.4.
Ладно, давайте посмотрим, изменилось ли что-нибудь:
$ dig @8.8.8.8 examplecat.com
examplecat.com. 17 IN A 104.248.50.87
Никаких изменений. Если я спрошу другой DNS-сервер, то он знает новый IP:
$ dig @1.1.1.1 examplecat.com
examplecat.com. 299 IN A 1.2.3.4
Но 8.8.8.8 по-прежнему ничего не знает. Причина, по которой 1.1.1.1 видит новый IP, хотя я только что изменила его пять минут назад, вероятно, заключается в том, что никто никогда не спрашивал 1.1.1.1 об этом examplecat.com раньше — значит, у него в кэше ничего не было.
У серверов имен TTL намного больше
Причина, по которой мой регистратор говорил: «Это займёт 48 часов» в том, что TTL на NS-записях (сведения о том, к какому серверу имен должен обратиться рекурсивный сервер) намного больше.
Новый сервер имен определенно возвращает новый IP-адрес для examplecat.com:
$ dig @ns-cloud-b1.googledomains.com examplecat.com
examplecat.com. 300 IN A 1.2.3.4
Но вспомните, что произошло, когда мы запросили серверы имен github.com раньше:
$ dig @192.5.6.30 github.com
...
github.com. 172800 IN NS ns-421.awsdns-52.com.
ns-421.awsdns-52.com. 172800 IN A 205.251.193.165
...
172 800 секунд — это 48 часов! Таким образом, обновление сервера имен, как правило, занимает гораздо больше времени. Время нужно, чтобы закончился срок действия кэшей и распространился новый адрес. Это гораздо дольше, чем просто обновление IP-адреса без изменения вашего сервера имен.
Как обновляются ваши серверы имен
Когда я обновляю серверы имен для examplecat.com
, сервер имен .com
получает новую запись NS с новым доменом. Подобно этому:
dig ns @j.gtld-servers.net examplecat.com
examplecat.com. 172800 IN NS ns-cloud-b1.googledomains.com
Но как туда попадает эта новая запись NS? Фактически, я говорю своему регистратору доменов, какими хочу видеть новые серверы имен, обновляя их на веб-сайте, а затем мой регистратор доменов говорит серверам имен .com
сделать обновление.
Для .com
эти обновления происходят довольно быстро (в течение нескольких минут), но я думаю, что для некоторых других зон TLD серверы имен могут применять обновления не так быстро.
Библиотека DNS-резолвера вашей программы также может кэшировать записи DNS
Еще одна причина, по которой TTL может не соблюдаться на практике: многие программы должны резолвить DNS-имена, а некоторые программы также будут кэшировать DNS-записи в памяти на неопределенный срок (до тех пор, пока программу не перезапустят).
Например, есть статья о настройке JVM TTL для поиска DNS-имен. Я сама писала не так много кода JVM для поиска DNS, но небольшой поиск в интернете о JVM и DNS создает впечатление, что вы можете настроить JVM так, чтобы он кэшировал каждый поиск DNS в течение бесконечного времени (например, см. этот тикет ElasticSearch).
Вот и всё!
Надеюсь, что это поможет вам понять, что происходит при обновлении вашего DNS.
Оговорюсь, что всю историю распространения DNS определяют не только TTL. Некоторые рекурсивные DNS-серверы наверняка не уважают TTL, даже такие основные серверы как 8.8.8.8. Так что даже если вы просто обновляете запись A, указав маленький TTL, возможно, что на практике всё равно будут приходить запросы на старый IP в течение дня или двух.
После публикации этой статьи я изменила серверы имен для examplecat.com обратно к старым значениям.
Что еще почитать:
- Go и кеши CPU.
- Какую базу данных выбрать для проекта, чтобы не пришлось выбирать снова.
- Наш канал в Телеграме о цифровой трансформации.
Сколько по времени обновляется DNS? Как быстрее обновить DNS?
Процедура регистрации домена или переноса сайта на другой хостинг, всегда подразумевает редактирование DNS записей. Для того чтобы сайт полноценно работал и был доступен, как вам, так и другим пользователям в интернете, домену нужно прописать имена DNS-сервера, которые выдаются хостингом. Это все выполняется довольно просто и быстро, но дело не в этом. Дело в том, что прописав новые DNS-сервера для домена, они должны обновиться. Как показывает практика, они обновляются не так быстро как хотелось бы, именно поэтому сайт доступен будет не сразу, что не всегда устраивает, особенно если мы производим перенос сайта на другой хостинг.
Сколько по времени обновляется DNS? На этот вопрос, точного ответа вам никто не даст, так как обновление dns зависит от того, как часто именно ваш интернет провайдер производит очистку кэша dns. Некоторые провайдеры, такую очистку производят 1 раз в день (чаще всего после полуночи), другие 1 раз в 2 дня, а бывает и такое, что 1 раз в 7 дней.
Отсюда вытекает следующее, что создав или перенеся сайт, мы не всегда сможем начать работу с ним, наполнять или исправлять его. Что делать в таком случае, ведь ждать пока провайдер соизволит почистить кэш dns не вариант, согласны?
Есть 2 выхода из этой ситуации:
- Узнать у своего провайдера, как часто они производят очистку кэша DNS и в какое время. Если это делается раз в сутки, то можно подстроиться, и создать домен или перенести сайт на другой хостинг в определенное время.
- Прописать новый IP адрес своего домена в файле hosts на компьютере, что позволит получить доступ к сайту сию же секунду, без ожидания обновления DNS.
Как быстрее обновить DNS?
Как вы уже поняли, ускорить процесс обновления DNS не получится, т.к. это во власти интернет провайдера, и периодичность обновления dns у всех провайдеров разная. Но можно пойти другим путем, т.е. прописать IP адрес и домен в файле hosts, что позволит отбросить в сторону все ожидания.
Для начала, вы должны понимать, что такое DNS и для чего он нужен. DNS — это так называемая система доменных имен, которая позволяет привязать к домену, IP адрес хостинга, к которому он будет припаркован.
Теперь можно приступать к процедуре. Для ее реализации, вам понадобится знать:
- IP-адрес сервера, на котором размещен ваш сайт. Его вы сможете узнать в панели управления хостингом (чаще всего это cPanel).
- Доменное имя сайта.
Т.к. у некоторых (особенно у новичков), могут возникнуть проблемы с нахождением IP-адреса сервера, я поясню, где его найти.
Проще всего конечно, спросить у хостера это, но можно узнать и самому. Для этого, нужно зайти в сPanel и убедиться, что выбрана тема «x3«. Если нет, то необходимо переключиться на нее:
Далее, необходимо слева найти информационное меню — «Статистика«:
Затем нужно это меню развернуть, нажав на стрелочку сбоку него. После чего появится полная статистика, где в графе «Общий IP-адрес» будет указан IP-адрес сервера:
Все, теперь у вас есть все, что нужно указать в файле hosts. Найти сам файл hosts на своем компьютере вы сможете в папке etc, которая находится по адресу — C:\windows\system32\drivers\etc.
После того, как его нашли, нужно его открыть. Можно открыть даже блокнотом, но я предпочитаю пользоваться Notepad ++. Затем в самом конце документа необходимо дописать строчку, которая будет состоять из вашего IP-адреса и через пробел дописывается доменное имя. Что-то типа такого:
46.4.80.243 mntaxi.ru
В самом файле же, это будет выглядеть вот так:
После, все это дело сохраняем, и не перезагружая даже компьютер можем сразу же убедиться, что на сайт мы сможем зайти без каких-либо проблем. Дней через 5-7, сайт будет работать и без этого, так что можете в файле hosts эту запись, потом удалить.
Некоторые операционки могут отказать в сохранении файла, написав что-то типа, что файл используется другой программой. Но это не проблема, просто напросто сам файл hosts нужно открыть с правами администратора и все заработает.
Теперь, когда вы знаете, сколько обновляются DNS и как этот процесс можно обойти, вы сможете, пока идет это обновление, настроить, или наполнить свой сайт материалами.
Что такое обновление DNS, почему оно происходит так долго и как его можно ускорить
Обновление DNS – это такая штука, которая может заставить понервничать многих начинающих вебмастеров. Купил домен, оплатил хостинг, создал сайт, а он не доступен. И так продолжается несколько дней, а то и недель.
Всё это происходит от обновления DNS и задержек в этом процессе – явление нормальное, которое является техническим недостатком мирового интернета и конкретно вашего интернет-провайдера.
Что такое DNS
DNS – английская аббревиатура, которая расшифровывается как domain name system – система доменных имён. Представляет собой систему, которая содержит доменные имена и IP адреса им равнозначные.
Благодаря DNS простым пользователям интернета не нужно записывать в адресную строку браузера IP адрес сайта, на который он хочет попасть, который может выглядеть так – 185.201.54.45. Достаточно просто написать доменное имя сайта, например, site.ru и система DNS сама найдёт в своей базе необходимый IP и отобразит сайт в браузере.
Вот так DNS облегчает всем жизнь.
Обновления DNS
В интернете каждую секунду появляются новые сайты. Тут вы можете узнать, сколько из них только на WordPress. Потому каждый раз регистрируются новые IP и доменные имена.
Каждый интернет-провайдер хранит на своём DNS сервере список этих IP и доменов. Однако он не может обновлять его каждую секунду, а делает это намного реже – раз в сутки, три дня, неделю. Именно поэтому обновление DNS так задерживается, и не всегда новый сайт будет отображаться на том или ином компьютере.
Поэтому обновление DNS может задерживать просмотр каждого нового сайта. При этом если в одной точке мира новый домен уже отображается нормально, то не обязательно, что так будет и в другой. Пройдёт до недели, пока сайт появится во всём мире.
Как можно ускорить обновление DNS
Обновление DNS ускорить невозможно. Однако когда вы зарегистрировали домен и создали на хостинге новый сайт, и пока DNS вашего провайдера не обновился, есть один способ начать работать со своим проектом поскорее. Для этого нужно на своём компьютере в настройках интернет-подключения прописать публичный DNS, который раздаёт Google – 8.8.8.8. Они обновляются очень часто, и уже в течение одних суток вы сможете видеть и работать со своим новым сайтом.
Где-то через неделю можно убрать DNS Google и прописать своего провайдера. Это необходимо для того чтобы убедиться, что обновление DNS прошло и у вас.
Просмотр и обновление DNS-записей
В этой статье мы так же рассмотрим Обновление свойств и начальной записи зоны, так что садитесь поудобнее, и начинайте работать :).
Чтобы просмотреть или обновить DNS-записи, выполните следующие действия:
1. Дважды щелкните нужную зону. Записи зоны отобразятся в правой панели.
2. Дважды щелкните DNS-запись, которую хотите просмотреть или обновить. Откроется диалоговое окно свойств записи. Внесите необходимые изменения и щелкните ОК.
Кстати, возможно скоро я уеду в отпуск, постараюсь и в это время вести блог. Почитал про отпуск в сети, и теперь ни как не могу отказать себе в этом. Тем более, что имею Право! Уже не помню когда последний раз куда-то ездил…Ладно, я отвлёкся, давайте теперь рассмотрим обновление свойств DNS-записей и начальной записи зоны.
Обновление свойств и начальной записи зоны
У каждой зоны есть свойства, задающие общие параметры зоны – начальную запись зоны (SOA), уведомление об изменениях, интеграцию с WINS. Чтобы настроить свойства зоны в консоли Диспетчер DNS (DNS Manager), выполните следующие действия:
• Щелкните правой кнопкой зону, которую хотите обновить, и выберите в контекстном меню команду Свойства (Properties).
• Выделите зону и выберите в меню Действие (Action) команду Свойства (Properties).
Окна свойств зон прямого и обратного просмотра одинаковы, за исключением вкладок WINS и WINS-R. В зонах прямого просмотра вкладка WINS служит для настройки просмотров имей NetBIOS. В зонах обратного просмотра вкладка WINS-R предназначена для настройки обратных просмотров имен NetBIOS.
Безопасное динамическое обновление записей на MS DNS из Linux / Хабр
Введение
В процессе настройки клиентов службы AD под управлением ОС Ubuntu Linux, я столкнулся с несвоевременным обновлением записей на DNS сервере средствами Samba, а также с некорректной работой команды «net ads dns register». Что вызывает сопуствующие проблемы при работе с доменными компьютерами.
Например, наличие двух DNS серверов в dhclient.conf приводит к появлению ошибки «ERROR_DNS_GSS_ERROR» после выполнения «net ads dns register -P».
В поисках решения этой проблемы я перечитал много статей и баг-репортов, и наткнулся на статью Warlock_ua «Безопасное динамическое обновление DNS записей в Windows домене из Linux (GSS-TSIG)». Идея показалась мне интересной. Но мне не понравилось решение с созданием отдельной учетной записи пользователя домена, которая имеет права на изменение всех записей DNS-зоны. Во-первых, это потенциально небезопасно. Во-вторых, в Windows уже существуют готовое решение: каждая учетная запись компьютера имеет право изменять свою запись на DNS. Почему бы этим не воспользоваться?
За основу я взял скрипт learn-address.sh от Warlock_ua, и доработал его с учетом своих нужд.
Об инфраструктуре
Имеем службу AD под управлением Windows Server 2008 R2 Standard, а также MS DNS сервер. Ими заведуют администраторы Windows. DHCP-сервер реализован на базе Cisco. Этим заведуют администраторы сети. Что так, для меня все это где-то в облаке, и немного похоже на черный ящик. Также у нас есть клиенты под управлением ОС Ubuntu 14.04 (Trusty), с установленным ПО Samba 4.1.6, isc-dhcp-client. Это по моей части.
Скрипт для обновления записей на DNS
Всю процедуру ввода в домен AD компьютеров под управлением Ubuntu я в описывать не буду, т. к. это выходит за рамки статьи. Опишу только ключевые моменты.
Компьютер, который будет обновлять свою запись на DNS, должен быть введен в домен. Т.е. у него должна быть учетная запись в домене. Для начала нужно будет получить пароль для учетной записи компьютера из Trivial DataBase. Сделать это можно с помощью утилиты tdbdump:
sudo tdbdump -k SECRETS/MACHINE_PASSWORD/DOMAIN /var/lib/samba/private/secrets.tdb | sed 's/\\\00$//'
После этого нужно создать keytab-файл с учетными данными машины с помощью утилиты ktutil:
ktutil <<EOF
addent -password -p [email protected] -k 1 -e rc4-hmac
$MPAS
write_kt $keytab_file
quit
EOF
Далее нужно получить билет kerberos:
kinit -k -t $keytab_file $user
И можно обновлять запись на DNS для конкретной учетной записи компьютера.
Обзор nsupdate-gsstsig
nsupdate-gsstsig update <ip> <hostname>
Листинг nsupdate-gsstsig
#!/bin/bash
###
### Объявляем переменные и читаем параметры скрипта
###
dnsserver=dc1
fwdzone=domain.local
# Зоны обратного просмотра у нас не используются.
# Кому надо, может самостоятельно раскомментировать соотвествующие строки.
#revzone=115.70.10.in-addr.arpa
ttl=300
op=$1
addr=$2
#revaddr=`echo $addr | sed -re 's:([0-9]+).([0-9]+).([0-9]+).([0-9]+):4.3.2.1.in-addr.arpa:'`
cn=$3
fqdn=$cn.$fwdzone
addfile=add_$addr
delfile=del_$addr
# Подразумевается, что имя учетной записи компьютера в AD,
# CNAME и имя компьютера совпадают
user=$cn
keytab_file=./machine_krb5.keytab
###
### Получаем пароль учетной записи компьютера
###
MPAS=`sudo tdbdump -k SECRETS/MACHINE_PASSWORD/DOMAIN /var/lib/samba/private/secrets.tdb | sed 's/\\\00$//'`
###
### Экспортируем keytab-файл
###
ktutil <<EOF
addent -password -p [email protected] -k 1 -e rc4-hmac
$MPAS
write_kt $keytab_file
quit
EOF
###
### Изменяем запись на DNS
###
addRecord() {
kinit -k -t $keytab_file $user
cat <<EOF > $addfile
gsstsig
server $dnsserver
zone $fwdzone
update delete $fqdn a
update add $fqdn $ttl a $addr
send
EOF
#zone $revzone
#update delete $revaddr ptr
#update add $revaddr $ttl ptr $fqdn
#send
#EOF
cat <<EOF > $delfile
gsstsig
server $dnsserver
zone $fwdzone
update delete $fqdn a
send
EOF
#zone $revzone
#update delete $revaddr ptr
#send
#EOF
nsupdate -v $addfile
rm -f $addfile
rm -f $delfile
}
delRecord() {
kinit -k -t $keytab_file $user
nsupdate -v $delfile
rm -f $delfile
}
case $op in
add|update)
addRecord
;;
delete)
delRecord
;;
*)
echo "Unable to handle operation $op. Exiting" exit 1
esac
rm $keytab_file
Запуск скрипта
Для удобства запуска я разместил скрипт в /bin/nsupdate-gsstsig.
Чтоб информация в DNS обновлялась автоматически, я создал скрипт regdns и поместил его в /etc/network/if-up.d/.
Листинг regdns
#!/bin/sh
# Помещаем имя компьютера в переменную
SHOST=`cat /etc/hostname`
# Помещаем IP-адрес не lo интерфейса в перменную
IP=$(ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print $1}')
# Обновляем запись на DNS-сервере
nsupdate-gsstsig update $IP $SHOST
Источники информации
Настройка динамического обновления DNS в Windows DHCP Server
Знаете ли вы, что Windows DHCP-сервер может динамически обновлять записи для своих клиентов на DNS-сервере ? Наличие DHCP-сервера , обновляющего записи DNS для клиентских машин, очень полезно, если у вас есть сетевое приложение, которое так сильно полагается на разрешение имен для обмена данными. Однако конфигурация DHCP-сервера Windows по умолчанию — обновлять записи A и PTR для клиентов только по запросу .В большинстве случаев это работает не очень стабильно. В этом посте мы расскажем, как настроить динамическое обновление DNS в Windows DHCP Server и убедиться, что он полностью работает.
Настройка динамического обновления DNS в Windows DHCP Server
В нашем сообщении о концепции обновления и обновления на сервере DNS мы кратко объяснили, что сервер DHCP может стать владельцем записи DNS для своих клиентов . Владелец записи имеет право изменять / удалять запись.Теперь наша цель состоит в том, чтобы убедиться, что DHCP-сервер может постоянно обновлять записи DNS для всех своих клиентов .
Шаг 1. Настройте DHCP-сервер на постоянное динамическое обновление записей
Вы можете начать настройку динамического обновления DNS на DHCP-сервере Windows, открыв консоль DHCP . Разверните имя сервера> щелкните правой кнопкой мыши на IPv4 > выберите Properties > DNS tab.
По умолчанию в Windows Server 2012 R2 вы увидите параметр « Включить динамическое обновление DNS в соответствии с настройками ниже », включенный по умолчанию, и у вас есть два следующих варианта выбора:
- Динамически обновлять записи DNS A и PTR только по запросу клиентов DHCP. — это выбор по умолчанию.Этот параметр означает, что ваш DHCP-сервер будет обновлять записи DNS для клиентов только в том случае, если клиенты по какой-либо причине не могут выполнить обновление. Как указано ниже, это может работать некорректно, особенно если клиенты не являются компьютерами под управлением Windows.
- Всегда динамически обновлять записи DNS A и PTR — Теперь вы должны изменить выбор на эту опцию . Что произойдет, так это то, что DHCP-сервер выполнит обновление независимо от того, может это сделать клиент или нет.
Теперь вы также можете заметить, что на той же вкладке в свойствах DHCP-сервера есть несколько других параметров.Приведенное ниже объяснение расскажет вам о функциях каждой опции и о том, что вам нужно с ними делать:
- Отменить записи A и PTR при удалении аренды — Как следует из названия, при удалении аренды DHCP для соответствующего клиента будет удалена ранее зарегистрированная запись A и PTR. Установите флажок , чтобы включить эту опцию, так как это поможет очистить неиспользуемые записи на DNS-сервере.
- Динамически обновлять записи DNS для DHCP-клиентов, которые не запрашивают обновления. — Эта опция присутствует только в том случае, если у вас очень старый компьютер или компьютер не под управлением Windows в качестве DHCP-клиента, который не выполняет динамическое обновление своей собственной записи в DNS-сервер. Установите флажок , чтобы включить эту опцию и заставить DHCP-сервер выполнить обновление DNS для них.
- Отключить динамическое обновление для записей PTR — Когда вы активируете эту опцию, ваш DHCP-сервер будет выполнять динамическое обновление только для записей A. Вам решать, что делать с этой опцией, но в этом примере мы не ставим галочку в поле для этой опции и позволяем DHCP-серверу также управлять записями PTR.
Со всеми настройками здесь мы фактически настроили DHCP-сервер на владение всеми его клиентскими записями на DNS-сервере.Однако мы еще далеки от завершения, поскольку нам необходимо сделать несколько дополнительных шагов.
Шаг 2. Добавьте DHCP-сервер в группу безопасности DnsUpdateProxy
Если DHCP-сервер находится на другом компьютере, чем контроллер домена, убедитесь, что включает DHCP-сервер в группу DnsUpdateProxy в Active Directory (см. Рисунок ниже). В противном случае DHCP-сервер не сможет обновлять записи на DNS-сервере.
Шаг 3. Введите учетные данные для защиты динамического обновления DNS.
Это применимо, если зона DNS, в которой ваш DHCP-сервер будет регистрировать / обновлять записи, является зоной , интегрированной в Active Directory, , которая допускает только безопасные динамические обновления .
Вам необходимо предоставить учетную запись пользователя в свойствах DHCP-сервера . Откройте вкладку Advanced свойств DHCP-сервера и нажмите кнопку Credentials .
Введите имя пользователя , домен и пароль в доступное поле.
Обратите внимание, что учетная запись может быть обычной учетной записью пользователя без каких-либо специальных привилегий, но она должна существовать в том же лесу, что и DNS-сервер .Вы также можете использовать учетную запись пользователя из другого леса, если его лес установил доверие леса с лесом, в котором находится DNS-сервер.
Шаг 4. Настройте защиту имени
Поскольку мы включаем опцию « Динамически обновлять записи DNS для DHCP-клиентов, которые не запрашивают обновления », это означает, что мы разрешаем машинам, не относящимся к домену, или машинам без Windows иметь свои записи в DNS. сервер. Есть вероятность, что такая машина имеет то же имя хоста, что и другая существующая машина в сети.Если это произойдет, это может вызвать путаницу в разрешении имен.
Чтобы предотвратить такую проблему, мы можем активировать защиту имени DHCP . Вернитесь на вкладку DNS в параметре DHCP-сервера в разделе Защита имени > щелкните Настроить .
Установите флажок с по Включить защиту имени .
Таким образом, DHCP-сервер будет по-прежнему арендовать IP-адрес, как правило, , но не будет создавать DNS-запись, если запись с таким же именем уже существует .
Ну, это почти все, что вам нужно для настройки динамического обновления DNS на DHCP-сервере Windows. С этого момента ваш DHCP-сервер будет заботиться о записях DNS для своих клиентов. DHCP-сервер будет регистрировать и обновлять записи для своих клиентов , а также удаляет записи для истекших договоров аренды . Это гарантирует, что DNS-сервер не будет заполнен записями о неактивных клиентах. Кроме того, вы также можете настроить устаревание и очистку в зоне DNS с до , совпадающей со временем аренды DHCP , и это поможет очистить неиспользуемые записи.
Следующие две вкладки изменяют содержимое ниже.
Я практикующий ИТ-специалист со специализацией в сетевой и серверной инфраструктуре. У меня многолетний опыт проектирования, анализа, эксплуатации и оптимизации инфраструктурных решений для сетей корпоративного масштаба. Вы можете отправить мне сообщение в LinkedIn или электронное письмо по адресу [email protected], чтобы узнать подробнее о материалах, которые я написал, или о возможности сотрудничества в проекте.
.
Как внести изменения в DNS с минимальным временем простоя
Изменение записей DNS может привести к тому, что ваш сайт будет недоступен на какое-то время.
В этой статье объясняется, как можно минимизировать время простоя при изменении записей доменного имени.
NS записи
При изменении записей сервера имен сначала убедитесь, что ваш новый сервер (и) имен определяет
те же записи, что и на ваших старых серверах имен. То есть ваши новые серверы имен
должен быть в готовом к использованию состоянии.
Теперь вы можете изменить свои записи NS так, чтобы они указывали на новые серверы имен.Но обратите внимание на то, что NS-записи ваших родительских DNS-серверов обычно
кешируется на 48 часов. Таким образом, вы должны держать свои старые серверы имен в сети на
не менее 48 часов после внесения изменений в записи NS.
Прочие записи
Для записей A, MX, PTR и т. Д. Есть хороший способ
обновить запись, не имея противоречивых данных. Что я имею в виду под «непоследовательным»
это следующий сценарий:
Предположим, у вас есть запись A для www.dnswatch.info, указывающий на IP-адрес
193.111.199.111 со значением «Время жизни», равным 3600 (1 час). И давай дальше
предположим, что теперь вы хотите обновить эту запись A, чтобы она указывала на IP
адрес 193.111.199.214.
Если вы только что изменили запись, DNS-преобразователи во всем мире, которые не
если старые данные будут кэшированы, то сразу же появится новый IP-адрес (193.111.199.214).
Но преобразователи DNS, у которых эта запись кэширована (например, преобразователь, который уже запросил
ваш сервер имен 8 минут назад) все равно будет видеть старый IP-адрес (193.111.199.111).
Итак, если преобразователь запросит ваш сервер имен 8 минут назад, он увидит старый
данные на следующие 52 минуты, поскольку установлено значение «Время жизни»
до 1 часа, что означает, что запись может кэшироваться на 1 час.
Если бы, например, за этими IP-адресами был какой-то веб-сервер, некоторые браузеры теперь получали бы доступ
ваш старый веб-сервер (на старом IP), а некоторые будут запрашивать данные с вашего нового веб-сервера (на новом IP).
Простое решение для этого несогласованного состояния выглядит следующим образом:
Сначала уменьшите TTL записи, которую вы хотите изменить, до минимального значения,
е.г. 30 секунд. Затем подождите «старое значение TTL» секунд. Так что мы бы
В нашем последнем примере пришлось ждать 1 час после уменьшения TTL до 30, потому что
старый TTL был 1 час. По истечении этого периода вы можете изменить свои данные. Или вы можете
теперь еще больше уменьшите TTL до 5 секунд. Затем подождите 30 секунд, а затем выполните
актуальное обновление записи. Это приводит к несогласованности ваших данных DNS.
всего на 5 секунд вместо часа, как в исходном примере.
Однако не забудьте снова увеличить TTL после изменения записи.
и убедиться, что ваше изменение было успешным.Если оставить TTL на 5 секунд,
ваши DNS-серверы могут быть перегружены запросами на поиск. Кроме того, поиск в DNS
может занять некоторое время (иногда даже полсекунды), поэтому конечному пользователю потребуется много перерывов на кофе.
написано Джаном Оздемиром
30 сентября 2005 г.
.
Как защитить обновления DNS на DNS-серверах Microsoft — статьи TechNet — США (английский)
Ведение записей DNS может быть очень сложной задачей, если это делается вручную. Вот почему DNS-серверы Microsoft разрешают динамические обновления DNS, но это нужно включать с осторожностью, так как это нужно делать безопасным способом. Эта вики
В статье объясняется, как можно защитить обновления DNS на DNS-серверах Microsoft Windows.
DNS-записи могут быть статическими или динамическими.
Статическая запись DNS — это запись, созданная вручную администратором DNS, или динамическая запись, преобразованная администратором DNS в статическую.Эти записи ведутся вручную и должны администрироваться только доверенными лицами. Обеспечение
обновление статических записей DNS требует ограничения лиц, имеющих право обновлять их.
Как преобразовать динамическую запись ресурса в статическую, не создавая ее заново в DNS:
http://social.technet.microsoft.com/wiki/contents/articles/21726.how-to-convert-a-dynamic-resource-record-to-a-static-one-without-re-creating-it- in-dns.aspx
Динамические записи DNS создаются DNS-клиентами или системами от имени DNS-клиентов (пример: DHCP-серверы).Разрешение обновлений динамического DNS сводит к минимуму административные усилия по обслуживанию зон DNS. На DNS-серверах Microsoft есть три возможных конфигурации
для динамических обновлений:
- Нет : динамические обновления не разрешены. Управление записями зоны DNS необходимо производить вручную.
- Небезопасный и безопасный : динамические обновления принимаются без проверки, является ли источник обновлений надежным или нет.
- Только безопасные : динамические обновления принимаются только из надежных источников.Этот параметр доступен только в том случае, если ваша основная зона DNS размещена на контроллере домена и является зоной DNS, интегрированной в AD.
Если для компании требуется включение динамических обновлений, настоятельно рекомендуется использовать
Защитите только опцию динамических обновлений .
Это связано с тем, что источник обновлений DNS считается надежным, только если:
- Источник обновления DNS был аутентифицирован в Active Directory
- Источник обновления DNS имеет разрешение на обновление записи DNS (*)
(*) Если запись DNS для обновления не существует в вашей зоне DNS, то новая Будет создана запись DNS, и источник обновления DNS будет установлен как владелец и будет предоставлен
Полный доступ разрешение на новую запись DNS.
На следующем рисунке показан процесс безопасного динамического обновления:
Безопасное динамическое обновление :
http://technet.microsoft.com/en-us/library/cc961412.aspx
Чтобы определить, кто может вносить обновления в существующую запись DNS, вы можете изучить списки ACL в
Безопасность Вкладка его свойств:
Нажав на Advanced и затем перейдя на Owner , вы сможете определить владельца записи DNS (используя
Только безопасная Динамические обновления, учетная запись AD источника обновления DNS будет установлена в качестве владельца записи DNS).
Сочетание аутентификации на основе AD и системы авторизации ACL предлагает безопасный способ разрешить обновления DNS, когда клиенты DNS напрямую запрашивают обновления DNS-серверов.
По умолчанию для динамического обновления записей DNS требуется, чтобы клиенты DNS запрашивали это. Если у компании есть DNS-клиенты (например, Windows NT), которые не запрашивают обновления DNS-записей для регистрации в их зонах DNS, то компании требуется система, которая
будет регистрировать записи DNS от имени клиента: Microsoft предлагает использовать для этого DHCP-серверы Windows Server.
DHCP-сервер можно настроить для регистрации DNS-записей от имени своих клиентов и предложить следующие настройки:
- Включить динамическое обновление DNS в соответствии с настройками ниже : включение этого флажка позволит DHCP-серверу выполнять динамические обновления DNS от имени своих клиентов. Если
Динамически обновлять записи DNS A и PTR только по запросу клиентов DHCP
Если используется опция , сервер DHCP будет обновлять записи DNS A и PTR для клиента DHCP, только если клиент запросил это.Если
Всегда динамически обновлять записи DNS A и PTR. Если опция включена, сервер DHCP будет обновлять записи DNS A и PTR клиента DHCP независимо от того, запрашивал ли клиент выполнение собственных обновлений. - Отменить записи A и PTR при удалении аренды : включение этого флажка заставит DHCP-сервер удалить записи DNS A и PTR для клиента, когда его аренда DHCP истечет и не будет продлена.
- Динамически обновлять записи DNS A и PTR для DHCP-клиентов, которые не запрашивают обновления (например, клиенты под управлением Windows NT 4 . 0):
Включение этого флажка заставит DHCP-сервер выполнять динамическое обновление записей DNS A и PTR для DHCP-клиентов, которые не запрашивают обновления.
Здесь необходимо отметить, что серверы DHCP не смогут определить, является ли клиент DHCP доверенным или нет, и будут запрашивать обновления от имени своего клиента. Чтобы избежать присвоения имени сервера / клиента другому серверу / клиенту через динамический DHCP
обновления для DNS, важно, чтобы функция защиты имен была включена на DHCP-серверах.
Что такое защита имени :
http://blogs.technet.com/b/teamdhcp/archive/2009/01/29/what-is-name-protection.aspx
На самом деле есть два способа сделать DHCP-сервер Windows Server авторизованным для регистрации записей A и PTR DNS от имени своего клиента:
- Путем добавления DHCP-сервера в группу DNSUpdateProxy AD: любой аутентифицированный пользователь может стать владельцем зарегистрированных DNS-записей DHCP-сервером, поскольку они не имеют защиты.Это не рекомендуемый вариант.
- При добавлении DHCP-сервера в группу DNSUpdateProxy AD и использовании учетных данных динамического обновления DNS: при использовании учетной записи AD в качестве учетных данных для динамического обновления DNS записи DNS, зарегистрированные DHCP-сервером, будут иметь эту учетную запись AD в качестве владельца.
Это предотвращает их обновление любым аутентифицированным пользователем. Это рекомендуемый вариант, и он необходим для работы безопасных динамических обновлений, когда ваш DHCP-сервер размещен на контроллере домена.
Право собственности на запись DNS и группа DnsUpdateProxy:
http://technet.microsoft.com/en-us/library/dd334715(v=ws.10).aspx
Примечание: Если DNS-запись была создана непосредственно DNS-клиентом, то по умолчанию DHCP-сервер не сможет обновлять эту DNS-запись, поскольку у него нет на это разрешений.
Использование регистрации DHCP для записей DNS A и PTR от имени клиентов DHCP имеет еще один недостаток, заключающийся в том, что учетная запись DHCP AD в качестве владельца новых записей DNS делает эти записи недоступными для непосредственного обновления клиентами.Это связано с тем, что в списках ACL этих записей клиенты не имеют разрешения на обновление своих собственных записей.
Обновление записей ресурсов DNS :
http://technet.microsoft.com/en-us/library/ff631099(v=ws.10).aspx
DHCP: группа DNSupdateproxy должна быть защищена, если защита имени включена в любой области IPv6:
http://technet.microsoft.com/en-us/library/ee941128(v=ws.10).aspx
Поскольку разрешение обновлений динамического DNS может завершиться множеством устаревших записей DNS, которые необходимо очистить, включение устаревания и очистки DNS должно помочь в автоматической очистке динамических записей.
Как работает устаревание и очистка DNS : http://social.technet.microsoft.com/wiki/contents/articles/21724.how-dns-aging-and-scavenging-works.aspx
.