Комментарии 30
Почти как и DNS, NTP должны работать в иерархической форме — серверы уровня Stratum 0 передают информацию серверам Stratum 1, которые передают информацию серверам Stratum 2, и так далее, вниз по иерархии. Обычный домашний маршрутизатор, коммутатор или точка доступа наподобие тех, в которые D-Link прошила адреса NTP-серверов, должны были отправлять запросы серверу Stratum 2 или Stratum 3.
Странная ситуация, что такая иерархия не форсируется вайтлистами. А то выходит, что зная адреса 0 и 1, конечному юзеру нет никакого профита в подключении к 2 и 3, кроме абстрактного всеобщего блага.
Теперь — форсируется. А раньше было джентельменство. А конечному пользователю нет никакого профита использовать stratum 0 или stratum 1 — он не заметит разницы.
И да — мне стыдно. Но есть девайсы в которых нельзя прописать FQDN для синхронизации, только IP.
На ntp.org указаны IP серверов Stratum 1 и 2. Дальнейшие уровни только в виде FQDN. Резолвить их в IP и пользоваться этими адресами не получается, потому что они периодически меняются и старые IP перестают отвечать (уже пройдённый этап).
Вот как в таком случае правильно поступить?
Поднять свой NTP сервер?
ps я именно так и поступаю. Ставил несколько раз видеонаблюдение, и везде, где микротики — синхронизирую их часы c ru.pool.nto.org, а камеры уже с этим сервером.
А уж если я позволяю себе брать время со Statum-1, то получившийся Stratum-2 сервер добавляю ntp.org пул.
package: ntp 6.46.6
Т.е. нужно как минимум делать скриптом отслеживание изменения IP.
Или я чего-то не знаю? С Микротиком никогда нельзя быть уверенным, что знаешь всё.
Неизвестны другие условия задачи, потому могу только предполагать:
- Завести свой NTP сервер, если это возможно. Если у вас много таких устройств, то найти куда установить ntpd, думаю, не составит особого труда.
- Написать скриптик, который будет по крону проверять, не сменился ли адрес у используемого NTP сервера, и посылающий письмо с уведомлением об этом. Если устройств немного, то это не должно доставить особых проблем.
Собственно, предполагалось, как я понимаю, что п.1 всегда должен выполняться.
P.S. Сам грешен: полтора десятка лет назад тоже синхронизировался со stratum 1, после исправился.
Предположим у нас одна большая организация. Тогда без проблем — поднимаем где-то свой сервак и всё. Выделим для этого виртуалку или даже физическую машину, или поднимем где-то за компанию. Хотя это решение всё равно нельзя назвать красивым. Т.к. мы на ровном месте организовали себе еще один сервис/виртуальную или даже физическую машину, и это надо так или иначе поддерживать. А по факту оно нам надо? Если можно просто синхронизироваться с кем-то в интернете. Ну т.е. я имею в виду, что я не сторонник плодить лишние сущности там где они не нужны.
А теперь представим, что у нас много организаций. Причем в каких-то кроме роутера и юзерских компов вообще нет ничего. Надо в каждой поднять сервер? А если не на чем поднять? Или надо поднять один на всех где-то во внешнем мире? Тоже вариант так себе — почему мы должны завязывать сторонние организации на какой-то единый сервис (кто его при этом будет оплачивать и админить?). В общем идея со своим сервером не очень (как по мне).
Идея со скриптом в общем-то страдает от тех же недостатков. Скрипт надо где-то запускать. Если устройств много менять это всё потом. И т.д.
Но впрочем никто же не гарантирует, что ip серверов Stratum 1/2 тоже не поменяются. Так что и здесь не идеальное решение.
Вывод в общем такой, что производители не позволяющие прописать FQDN поступают очень плохо.
Производители, не позволяющие прописать FQDN, конечно, не доработали свой продукт, но… Но давайте не забывать, что никто ничего нам не должен за бесплатно. Так что если нам нужно настолько точно синхронизировать часы, то об этом мы должны сами озаботиться. В данном случае, либо выбрав другой продукт, либо реализовав NTP сервер своими силами.
Предположим у нас одна большая организация.
Значит, хотя бы 1 сервер должен быть. Поднять там ещё и ntpd несложно.
А теперь представим, что у нас много организаций. Причем в каких-то кроме роутера и юзерских компов вообще нет ничего. Надо в каждой поднять сервер? А если не на чем поднять? Или надо поднять один на всех где-то во внешнем мире? Тоже вариант так себе — почему мы должны завязывать сторонние организации на какой-то единый сервис (кто его при этом будет оплачивать и админить?)
Но вы ж и так завязываете их на сторонний сервис. Который может в любой момент решить что вы обнаглели и закрыться файерволом.
кто его при этом будет оплачивать и админить?
Ну, если у вас есть доступ к оборудованию сторонних организаций и обязанности по поддержке — значит, деньги тоже должны быть.
Значит, хотя бы 1 сервер должен быть. Поднять там ещё и ntpd несложно.
С большой организацией в общем особых проблем нет, я не спорю. Кстати если есть домен Active Directory, то время можно брать с любого контроллера домена (не забыв предварительно настроить эмулятор PDC на синхронизацию с внешним источником, благо FQDN он понимает).
Проблема больше с мелкими конторами, особенно если их много.
Но вы ж и так завязываете их на сторонний сервис. Который может в любой момент решить что вы обнаглели и закрыться файерволом.
Так я и не говорю, что синхронизироваться с Stratum 1/2 это идеальное решение. Надеялся, что кто-то подкинет какую-нибудь изящную идею (помимо поднятия своего сервера).
Ну, если у вас есть доступ к оборудованию сторонних организаций и обязанности по поддержке — значит, деньги тоже должны быть.
Понимаете в чём проблема. Завязывать сторонние организации на какой-то свой внешний сервис это плохой тон. Должно быть сделано так, что если вы завтра уволитесь отовсюду, то после вас следующему админу должна достаться автономная система, а не привязанная к каким-то внешним сервисам. Понятно, что в современном мире практически всегда какие-то внешние сервисы используются (особенно в мелких конторах). Какая-нибудь почта Google/Yandex, тот же pool.ntp.org. Но это сервисы поддерживаемые гигантами ранка или сообществом, вероятность их закрытия крайне мала. А вот если админ Вася поднял вовне какой-то сервис и подвесил на него кучу компаний, то это всё будет работать пока Васе это интересно.
Поэтому поднимать внешний сервер для разных контор я считаю плохой идеей (плохим тоном, если точнее). Свой сервер внутри — в некоторых случаях нерационально.
Если можно просто синхронизироваться с кем-то в интернете.
ПРОСТО нельзя. В своем периметре NTP сервер обязателен так же, как и свой DNS. Это и необходимость обеспечения отказоустойчивости, и безопасности, и минимального расхождения времени на отдельно взятой площадке
- Не надо никого обманывать: в Chromium нет никакой ошибки, ошибка в самом протоколе DNS, а Chromium с данной функцией всего лишь её триггер.
- Сама по себе функция появилась для детектирования мудаков-рекламщиков, нарушающих спецификацию и обманывающих пользователей DNS. Может, для начала, начать искать другие пути разрешения этой проблемы?
- А эта ли функция является основным генератором DNS запросов? А при вводе чего-то похожего на DNS имя в omnibox не производятся запросы для проверки, действительно ли это действительное DNS имя?
Всего-то нужно было оставить отдельне поле поиска. Пользователь сам выберет, нажать ctrl+l или ctrl+k. Хотя сейчас это тоже должно срабатывать. Тогда, например, адреса без / и
в начале и без / в конце считать поиском, если в них нет точки. Не очевидно, но это была бы не единственная неочевидная вещь в хроме
При чём тут поиск в браузере, когда проблема в поиске на стороне провайдера?
Суть именно в этом. Поисковые провайдеры омнибокса (алгоритмы в браузере) пытаются "угадать", что именно пользовать вводит, адрес, доменное имя или поисковой запрос. Там всё довольно накручено, можно посмотреть, например, статью от "яндекс браузера" про подсказки и омнибокс.
Если бы поля поиска и адреса были бы разные, пользователь скорее всего реже вводил бы левые адреса в строку адреса, которые бы провайдеры перехватывали, и мог бы спокойно вводить что угодно в строку поиска, всё это бы уходило в поисковую систему без всяких неоднозначных ситуаций.
Но вообще, да, отвечая на вопрос: теоретически может сработать. Трюк ведь в том, чтобы послать такой запрос, на который не будет знать ответа dns провайдера, но который не дойдет до корневых серверов. Значит минимальное условие такое: корневой домен известен (.com например), а второй уровень — сгенерирован случайно.
Задолбать .com-ресолверы вместо root DNS? Так себе решение, мне кажется. Вот если вместо .com использовать разные TLD, выбранные из фиксированного списка случайно, то должно быть получше.
Насколько я знаю, там механизма задалбывания корневых DNS нет, и проблемой то, с чем борется хромиум, фаерфокс не считает. Есть какие-то свои эвристики как отличить поисковый запрос от адреса.
Мне эвристики не нравятся (не конкретно у фокса, а в принципе), я отключил и у меня 2 раздельные строки. Когда я ввожу в адресную строку router я всегда попадаю в настройки своего роутера.
Одна из функций Chromium создаёт огромную нагрузку на корневые DNS-серверы