Dns адрес изменился что это
Как увидеть все шаги рекурсивного DNS-сервера: dig +trace
Чтобы посмотреть, что рекурсивный DNS-сервер будет делать для резолвинга домена, можно запустить:
Эта команда показывает все DNS-записи, которые запрашивает рекурсивный сервер, начиная с корневых DNS-серверов, то есть все четыре шага, которые мы только что прошли.
Адреса публичных DNS-серверов
Ниже — некоторые популярные адреса DNS-серверов для IPv4 и IPv6, предпочтительные и альтернативные соответственно:
Всем привет. Со вчерашнего дня на рабочих компьютерах с Виндовс 7 самопроизвольно изменяются ДНС сервера в настройках сетевой. У меня настроен DHCP на Dell Sonicwall подсеть 192.168.1.0. Работает давно, настройки не менял, проверил - все по старому. Если делаю ipconfig /renew - ПК получает верные настройки. Через определенное время снова сбивается, причем в ДНС прописывается АйПи из подсети 192.168.0.0! один. Феномен локализован только на Виндовс 7, у меня кроме них еще 8, 8.1, 10. ДНС меняется бессистемно по времени. Может сразу на группе ПК, может на одном. На вирусы проверил, Касперский стационар, Др.Веб Кьюрейт, Эсет онлайн сканер - чисто. Набор программ стандартный, офис, почтовик, пара броузеров, скайп и т.д. Может кто-то сталкивался с подобным полтергейтсом? Какое-то обновление шалит? Куда копать то?? Хелп.
- Изменен тип Dmitriy Vereshchak Microsoft contingent staff 18 августа 2015 г. 6:35 Тема переведена в разряд обсуждений по причине отсутствия активности.
У серверов имен TTL намного больше
Причина, по которой мой регистратор говорил: «Это займёт 48 часов» в том, что TTL на NS-записях (сведения о том, к какому серверу имен должен обратиться рекурсивный сервер) намного больше.
172 800 секунд — это 48 часов! Таким образом, обновление сервера имен, как правило, занимает гораздо больше времени. Время нужно, чтобы закончился срок действия кэшей и распространился новый адрес. Это гораздо дольше, чем просто обновление IP-адреса без изменения вашего сервера имен.
Не всегда можно полагаться на TTL
Как и в большинстве интернет-протоколов, не всё подчиняется спецификации DNS. Некоторые DNS-серверы интернет-провайдеров будут кэшировать записи дольше, чем указано в TTL. Например, в течение двух дней вместо пяти минут. И люди всегда могут жестко закодировать старый IP-адрес в своем файле /etc/hosts .
На практике при обновлении записи DNS с пятиминутным TTL можно ожидать, что большой процент клиентов быстро перейдет на новые IP-адреса (например в течение 15 минут), а затем появится куча отставших, которые будут медленно обновляться в течение следующих нескольких дней.
Вот и всё!
Надеюсь, что это поможет вам понять, что происходит при обновлении вашего DNS.
Оговорюсь, что всю историю распространения DNS определяют не только TTL. Некоторые рекурсивные DNS-серверы наверняка не уважают TTL, даже такие основные серверы как 8.8.8.8. Так что даже если вы просто обновляете запись A, указав маленький TTL, возможно, что на практике всё равно будут приходить запросы на старый IP в течение дня или двух.
Что не так с CNAME
Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX , ни A , ни NS , ничего.
Обновим записи DNS
Теперь, когда мы знаем основы работы DNS, давайте обновим некоторые записи DNS и посмотрим, что произойдет.
При обновлении записей DNS существует два основных варианта:
- сохранить те же серверы имен;
- изменить серверы имен.
Wildcards
Большинство DNS-серверов поддерживают шаблоны (wildcards). Например, есть wildcard CNAME для *.web01.bugsplat.info указывает на web01.bugsplat.info . Тогда любой хост на web01 будет указывать на web01.bugsplat.info и не нужно создавать новые записи:
Все ответы
У вас в сети завелся какой-то девайс, маршрутизатор или что-то подобное.
Проверить очень просто - посмотрите на вашем Win7 ip-адрес DHCP-сервера. Наверняка он не соответствует вашему Dell Sonicwall.
Соответствует ) Это первое что мне в голову пришло. Меняются только ДНС - айпи, маска, гейт остаются как и прежде (например работает скайп). при ipconfig /renew айпишник не меняется. Я сопоставлял мак и айпи с рабочих ПК и с таблизы leases на DHCP - они совпадают! Реально какая-то чертовщина.
самопроизвольно только кошки плодятся, проверьте логи.. и сеть на наличие других дхцп серверов. ща каджый второй чайник и принтер может работать дхцп сервером.
проверьте мак-адрес, который соответствует ip dhcp-сервера, когда все в порядке и когда прописывается левый dns.
Если бы был другой дхцп то сбивалось бы на всех устройствах. Устройства под другими ОС, в том числе на Андроиде, айпи-камеры, вай-фай точки подобной проблемы не испытывают. Кроме того зачем ПК, который получил адрес перезапрашивать его через 5-15 минут.. Насколько я помню он должен перезапросить айпи через половину времени, отведенного на аренду, а у меня это 24 часа. Запустил DHCP Checker.. Посмотрим.
Можно такое сделать скриптами, политиками, через дхцп и руками
Проверьте первые 2 варианта
1 например можно проверить включив брандмауэр, второе можно проверить через результирующую политику (gpresult или rsop)
Мои мыслительные процессы прервал знакомый, сообщив, что та же самая история происходит и при попытке зайти в ВК с телефона. Это была зацепка. Телефон был подключен к домашней wi-fi точке, к той же, что и проблемный компьютер. Попросив знакомого зайти в ВК с мобильного интернета, отключившись от wi-fi, я отмел вариант заражения телефона — открывалась настоящая версия. Вывод был только один — заражен роутер.
Всему виной безответственность
Перейдя на 192.168.1.1, я попросил знакомого логин и пароль от роутера и услышал в ответ… admin:admin! Что?! Как можно было не сменить пароль на роутере раздающем wi-fi?! Поразительная безответственность! Знакомый пожал плечами.
Проверив DNS я обнаружил следующее:
Второй адрес мне хорошо известен, это DNS Google, а вот первый я раньше не встречал. Он был даже не из нашего региона.
Ничего, кроме как перейти по этому адресу, в голову не пришло. Предо мной предстал фейк QIWI, при чем, опять же, отменного качества. (Кстати, он до сих пор там).
Я удалил этот адрес из DNS, заменив его стандартным для нашего региона, сменил пароль на роутере и перезапустил его. После этого, все заработало как положено. Выслушав благодарности знакомого, я решил заняться фейком поплотнее.
Вот это поворот
Сейчас там расположена ненормативная лексика, но когда я его нашел, там была форма с названием «Fake admin panel» и поля для логина и пароля. Чем черт не шутит? Подумал я, и ввел admin:admin. Как вы думаете, что произошло?
Я оказался в админке, с логами всех входов в фейки мошенников! Поразительно, они попались на своем же методе заражения.
Признаю, я сначала подумал, что это ханипот, и попробовал войти в один из кошельков QIWI из лога. Данные были верными, на счету кошелька было около 1000 рублей. Значит, это не ханипот. Я вышел из кошелька, и начал изучать админку.
В тылу врага
(эти игрушечки сверху шевелились, когда на них наводишь крыской, и издавали звук (и это была не флешка))
Неплохие результаты (не считая btc), да?
Отдельно нужно отметить лог QIWI, судя по всему, ради него это все и было сделано. В логе QIWI отображался не только логин, пароль и IP, но и баланс на момент входа, а так же включено ли SMS подтверждение для платежей (что поразительно, в большей части аккаунтов оно было выключено). Такой лог, говорит о том, что после авторизации через фейк, человека авторизировало на реальном QIWI, и бедняга даже не подозревал о подвохе.
В правом верхнем углу отображается количество записей, которые еще не убраны в архив (замечу, что эти записи пополнялись очень быстро).
А внизу (на картинке не видно), были кнопочки для удобного экспорта не архивных логов в txt файл и кнопочка для восстановления всех записей из архива.
Ощущая, что мое время на исходе, я восстановил все записи из архива QIWI и скачал их себе. Хотел проделать тоже самое с остальными сервисами, но не смог. Потому как при следующем запросе я увидел ошибку 403, а потом и то, что там есть сейчас.
Результаты
Полученный файл я очистил от одинаковых записей и проверил нет ли там кошелька моего знакомого. Знакомому повезло, его кошелек в руки мошенников не попал.
Вот этот файл (естественно без паролей), можете проверить, нет ли там вашего кошелька.
Эксперимента ради, просканировал свою подсеть. Нашел 8 роутеров, на 3х из которых стандартный пароль.
Внимательный читатель найдет на этой картинке IPv6
Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS — страшная и непонятная штука. Эта статья — попытка развеять такой страх. DNS — это просто, если понять несколько базовых концепций.
Что такое DNS
DNS расшифровывается как Domain Name System. Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.
Базовые штуки
Давайте взглянем на маппинг между именем и адресом:
Команда dig это такой швейцарский армейский нож для DNS-запросов. Крутой, многофункциональный инструмент. Вот первая часть ответа:
Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:
dig по-умолчанию запрашивает A -записи. A это address (адрес), и это один из фундаментальных видов записей в DNS. A содержит один IPv4 -адрес. Есть эквивалент для IPv6 -адресов — AAAA . Давайте взглянем на ответ:
Тут говорится, что у хоста web01.bugsplat.info. есть один адрес A : 192.241.250.244 . Число 300 это TTL , или time to live (время жизни). Столько секунд можно держать значение в кэше до повторной проверки. Слово IN означает Internet . Так сложилось исторически, это нужно для разделения типов сетей. Подробнее об этом можно почитать в документе IANA's DNS Parameters.
Оставшаяся часть ответа описывает сам ответ:
В частности, здесь говорится, как долго сервер откликался, какой у сервера IP-адрес ( 192.168.1.1 ), на какой порт стучался dig ( 53 , DNS-порт по-умолчанию), когда запрос был завершен и сколько байтов было в ответе.
Как видите, при обычном DNS-запросе происходит куча всего. Каждый раз, когда вы открываете веб-страницу, браузер делает десятки таких запросов, в том числе для загрузки всех внешних ресурсов вроде картинок и скриптов. Каждый ресурс отвечает за минимум один новый DNS-запрос, и если бы DNS не был рассчитан на сильное кэширование, то трафика генерировалось бы очень много.
Но в этом примере не видно, что DNS-сервер 192.168.1.1 связался с кучей других серверов чтобы ответить на простой вопрос: «куда указывает адрес web01.bugsplat.info ?». Давайте запустим трейс чтобы узнать о всей возможной цепочке, которую пришлось бы пройти dig 'у, если бы информация не был закэширована:
Информация выводится в иерархической последовательности. Помните как dig вставил точку . после хоста, web01.bugsplat.info ? Так вот, точка . это важная деталь, и она означает корень иерархии.
Корневые DNS-сервера обслуживаются различными компаниями и государствами по всему миру. Изначально их было мало, но интернет рос, и сейчас их 13 штук. Но у каждого из серверов есть десятки или сотни физических машин, которые прячутся за одним IP.
Итак, в самом верху трейса находятся корневые сервера, каждый определен с помощью NS- записи. NS -запись связывает доменное имя (в данном случае, корневой домен) с DNS-сервером. Когда вы регистрируете доменное имя у регистратора типа Namecheap или Godaddy, они создают NS -записи для вас.
В следующем блоке видно, как dig выбрал случайный корневой сервер, и запросил у него A -запись для web01.bugsplat.info . Видно только IP-адрес корневого сервера ( 192.5.5.241 ). Так какой именно корневой сервер это был? Давайте узнаем!
Возвращаясь к нашему начальному запросу: корневой сервер F вернул другой набор NS -серверов. Он отвечает за домен верхнего уровня info . dig запрашивает у одного из этих серверов запись A для web01.bugsplat.info , и получает в ответ еще один набор NS -серверов, и потом запрашивает у одного из этих серверов запись A для web01.bugsplat.info. . И, наконец, получает ответ!
Уф! Сгенерировалось бы много трафика, но почти все эти записи были надолго закэшированы каждым сервером в цепочке. Ваш компьютер тоже кэширует эти данные, как и ваш браузер. Чаще всего DNS-запросы никогда не доходят до корневых серверов, потому что их IP-адреса почти никогда не изменяются («Наверно все таки речь идет о большом TTL для записей в их базе. Если у DNS сервера IP адрес вообще ни разу не изменялся, то это не означает, что его база навечно закеширована» — прим. от rrrav). Домены верхнего уровня com , net , org , и т.д. тоже обычно сильно закэшированы.
Другие типы
Заметьте, что MX -запись указывает на имя, а не на IP-адрес.
Еще один тип, который вам скорее всего знаком, это CNAME . Расшифровываетя как Canonical Name (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:
Библиотека DNS-резолвера вашей программы также может кэшировать записи DNS
Еще одна причина, по которой TTL может не соблюдаться на практике: многие программы должны резолвить DNS-имена, а некоторые программы также будут кэшировать DNS-записи в памяти на неопределенный срок (до тех пор, пока программу не перезапустят).
Например, есть статья о настройке JVM TTL для поиска DNS-имен. Я сама писала не так много кода JVM для поиска DNS, но небольшой поиск в интернете о JVM и DNS создает впечатление, что вы можете настроить JVM так, чтобы он кэшировал каждый поиск DNS в течение бесконечного времени (например, см. этот тикет ElasticSearch).
Как работает DNS: рекурсивные и авторитетные DNS-серверы
Во-первых, нам нужно немного объяснить систему DNS. Существует два вида DNS-серверов: авторитетные и рекурсивные.
Рекурсивные DNS-серверы сами по себе ничего не знают о том, кому принадлежит какой IP-адрес. Они вычисляют IP-адрес для домена, запрашивая его у соответствующих авторитетных DNS-серверов, а затем кэшируют этот IP-адрес на случай, если их снова спросят о нем. Так, 8.8.8.8 — это рекурсивный DNS-сервер.
Когда люди посещают ваш веб-сайт, они, вероятно, делают DNS-запросы к рекурсивному DNS-серверу. Итак, как же работают рекурсивные DNS-серверы? Давайте посмотрим!
Шаг 1: IP-адреса для корневых DNS-серверов жестко закодированы в его исходном коде. Вы можете увидеть это в исходном коде unbound. Допустим, для начала он выберет 198.41.0.4. Вот официальный источник этих жестко закодированных IP-адресов, также известный как «корневой файл подсказок» (root hints file).
Детали ответа DNS немного сложнее — в этом случае есть раздел авторитетности (authority section) с некоторыми записями NS и дополнительный раздел с записями A, так что вам не нужно делать дополнительный поиск, чтобы получить IP-адреса этих серверов имен.
Мы почти закончили!
Запросы к другим серверам
Давайте представим, что конфигурация DNS испорчена. Вам кажется, что вы исправили проблему, но не хотите ждать когда обновится кэш чтобы удостовериться. С помощью dig можно сделать запрос к публичному DNS-серверу вместо своего дефолтного, вот так:
Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2 .
Изменение DNS-серверов в свойствах подключения
Следующий метод ручной установки DNS-серверов в Windows 11 — использование старого интерфейса свойств подключения:
- Нажмите правой кнопкой мыши по кнопке «Пуск» и выберите пункт «Выполнить» (либо нажмите клавиши Win+R), введите ncpa.cpl и нажмите Enter.
- В открывшемся списке подключения нажмите правой кнопкой мыши по подключению, DNS-серверы для которого нужно изменить и выберите пункт «Свойства».
- В списке компонентов подключения выберите «IP версии 4 (TCP/IPv4)» или «IP версии 6 (TCP/IPv6)» и нажмите кнопку «Свойства».
- Выберите пункт «Использовать следующие адреса DNS-серверов», укажите предпочитаемый и альтернативный DNS-сервер, примените настройки.
Как и в предыдущем случае, может пригодиться очистка кэша DNS с помощью команды ipconfig /flushdns в командной строке.
Изменение DNS-сервера в Параметрах Windows 11
Стандартный метод изменения адресов DNS-сервера в Windows 11 — использование «Параметров». Шаги будут следующими:
Как правило, сделанные изменения начинают действовать сразу, но вы можете очистить кэш DNS, запустив командную строку от имени администратора и используя команду ipconfig /flushdns
Вариант 1: обновление записи DNS на тех же серверах имен
Во-первых, я обновила свои серверы имен (Cloudflare), чтобы получить новую запись DNS — запись A, которая сопоставляет test.jvns.ca на 1.2.3.4:
Это сработало немедленно! Не было никакой необходимости ждать вообще, потому что перед этим не было никакой DNS-записи test.jvns.ca , которая могла быть кэширована. Отлично. Но похоже, что новая запись кэшируется в течение примерно пяти минут (299 секунд).
Итак, а если мы попытаемся изменить этот IP-адрес? Я изменила его на 5.6.7.8, а затем запустила тот же DNS-запрос:
Похоже, что на этом DNS-сервере запись 1.2.3.4 всё еще кэшируется в течение 144 секунд. Интересно, что если запросить 8.8.8.8 несколько раз, вы получите противоречивые результаты — иногда он выдает новый IP, а иногда старый. Вероятно, 8.8.8.8 на самом деле распределяет нагрузку на кучу разных бэкендов, у каждого из которых собственный кэш.
После пяти минут ожидания все кэши 8.8.8.8 обновились и всегда возвращали новую запись 5.6.7.8. Потрясающе. Это довольно быстро!
CNAME для Heroku или Github
С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME . См. документацию.
Поговорим о TTL
Но мы забыли кое-что важное. Это TTL. Как мы сказали ранее, рекурсивный DNS-сервер будет кэшировать записи до истечения срока их действия. Он принимает решение об истечении срока действия записи в зависимости от ее TTL (time to live, времени жизни).
В этом примере сервер имен GitHub для его DNS-записи возвращает TTL 60, что означает 60 секунд:
Как обновляются ваши серверы имен
Как изменить DNS-сервер в командной строке
И ещё один способ: изменение адресов DNS-серверов в командной строке. Необходимые шаги:
- Запустите командную строку от имени администратора.
- Введите команду
- В результате выполнения команды вы увидите список подключений, обратите внимание на имя интерфейса для подключения, DNS-серверы которого планируется изменить, используем его в следующем команде.
- Для того, чтобы установить предпочитаемый DNS-сервер для подключения, используем команду:
- Для установки альтернативного DNS-сервера команды выглядит следующим образом:
- Завершите выполнение настроек очисткой кэша DNS с помощью команды ipconfig /flushdns
На этом настройка DNS-серверов будет завершена.
Заключение
Надеюсь, теперь у вас есть базовое понимание DNS. Все стандарты описаны в документах:
Есть еще пара интересных RFC, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.
Fenix by Takeda11
Многие путаются в обновлении записей DNS, когда изменяют IP-адрес своего сайта. Почему эти записи медленно обновляются? Неужели действительно нужно ждать два дня, чтобы всё обновилось? Почему одни посетители видят новый IP, а другие — старый?
Вариант 2: обновление ваших серверов имен
Итак, мы видели, что когда вы обновляете IP-адрес, не меняя свои серверы имен, многие DNS-серверы довольно быстро получают новый IP-адрес. Отлично. Но что произойдет, если вы измените свои серверы имен? Давайте попробуем!
Ладно, давайте посмотрим, изменилось ли что-нибудь:
Никаких изменений. Если я спрошу другой DNS-сервер, то он знает новый IP:
Типичные ситуации
Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.
Редирект домена на www
Читайте также: