🙂 Выиграйте беспроводную колонку!

Fplus растет активно растет и предлагает все больше гаджетов для вашего быта, работы и отдыха. Не хотите пропустить свежие новости? Подписывайтесь на Fplus и участвуйте в конкурсе!

Как принять участие:
1. Подпишитесь на канал @fplus_ru
2. Нажмите кнопку “Принять участие” под конкурсным постом

Оставайтесь на связи и следите за розыгрышем!

Приз - беспроводная колонка, а результаты конкурса будут объявлены 3 декабря ! 😉

С полными правилами розыгрыша можно ознакомиться по ссылке!

erid: LjN8K7Re6

​​Когда DNS использует UDP, а когда TCP?

Чтобы правильно ответить на этот вопрос обратимся к RFC5966, который говорит, что TCP используется для трансфера зон или ответов, размер которых превышает 512 байт.

С трансфером зон все понятно, здесь нам требуется обеспечить максимальную целостность данных, поэтому целесообразно использовать TCP, даже в ущерб скорости и производительности.

А вот что такое ограничение на 512 байт и откуда оно взялось? Это связано с техническими ограничениями протокола UDP и обеспечением обратной совместимости. Проще говоря, если мы хотим быть уверенными, что любой узел сможет получить DNS-ответ по UDP, его размер не должен превышать 512 байт.

В противном случае сервер должен перейти на использование протокола TCP, либо клиент получит усеченный ответ (то, что поместится в 512 байт).

А теперь о том, какие именно записи могут превышать 512 байт:

🔸 Многочисленные записи: если запрашивается доменное имя, которое имеет много A-записей или AAAA-записей размер ответа может превышать 512 байт.

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

🔸 Записи типа CNAME: могут указывать на доменные имена, которые имеют многочисленные А-записи

🔸 DNSSEC: в этом случае дополнительные криптографические записи (RRSIG, DNSKEY) могут значительно увеличить размер ответа.

🔸 Дополнительные записи: например, NS, TXT или SRV записи, которые могут быть многочисленными и иметь достаточно большой размер.

Однако использование TCP в данном случае не является обязательным, существуют расширения протокола DNS - EDNS0, в рамках которого резолвер может в запросе указать какой размер ответа он может принять через UDP и сервер отправит ему такой ответ даже если его размер превышает 512 байт.

❓Кто должен поддерживать TCP? Согласно стандарту, все реализации должны поддерживать оба протокола, но есть и более строгие требования.

Стандарт требует обязательной поддержки от:

🔸 Авторитативного сервера, хранящего зону для ее возможной передачи тому, кто имеет право ее запросить

🔸 Рекурсивных серверов и форвардеров, для того чтобы они могли передавать большие ответы от серверов клиентам.

🔸 Конечных DNS-клиентов (реализаций в ОС и т.д.) – для возможности принимать не усечённые запросы.

Однако в отношении последних есть некоторые послабления, стандарт разрешает не реализовывать поддержку TCP для специализированных или маломощных устройств, если заранее известны все возможные DNS-ответы и среди них не будет превышающих 512 бит, либо получение усеченных ответов не влияет на нормальное функционирование системы.

Что это может быть? Например, какой-нибудь интернет ларек или касса самообслуживания. Когда мы знаем все возможные DNS-запросы и знаем все ответы на них.

Либо если нас интересует сугубо интернет-серфинг и не предполагаем никаких запросов кроме записей типа А, в этом случае даже если мы получим усеченный ответ это никак не помешает нормальной работе.

Также стандарт устанавливает порядок использования протоколов. Резолвер прежде всего должен попытаться выполнить UDP-запрос, должен, но не обязан.

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

В случае если TCP-соединение с сервером уже установлено, то клиент может продолжать его использовать не возвращаясь на протокол UDP.

Установка и настройка сервера лицензирования 1С:Предприятие

Управление лицензиями 1С:Предприятия - задача не простая, особенно если у вас в эксплуатации несколько серверов или используется виртуализация.

Основные проблемы - это оптимизация распределения лицензий и привязка лицензий к параметрам оборудования, что создает трудности в виртуальной среде.

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

https://interface31.ru/tech_it/2024/11/ustanovka-i-nastroyka-servera-licenzirovaniya-1spredpriyatie.html

Время от времени спрашивают:

Базовая настройка роутера MikroTik

За роутерами Mikrotik давно закрепилась слава "сложных" в настройке.

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

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

Сегодня мы начнем с базовой настройки, чтобы научить ваш Mikrotik всему тому, что умеют обычные роутеры.

https://interface31.ru/tech_it/2018/11/bazovaya-nastroyka-routera-mikrotik.html

Продолжаем базовые настройки роутеров Mikrotik.

Расширенная настройка Wi-Fi на роутерах Mikrotik. Режим точки доступа

Wi-Fi в роутерах Mikrotik достаточно неоднозначная тема, с одной стороны количество посвященных ей публикаций достаточно велико, но с другой, большая часть из них является простым перечислением всех присутствующих в роутере настроек с кратким описанием, без пояснений об их назначении, нужности, либо, наоборот, ненужности.

Поэтому мы в нашей статье сделаем упор на практическое применение и опции, которые реально могут вам потребоваться в повседневной деятельности. А также дадим необходимый теоретический минимум для понимания смысла отдельных настроек.

https://interface31.ru/tech_it/2020/08/rasshirennaya-nastroyka-wi-fi-na-routerah-mikrotik.html

🔥🔥Внимание! С 27 по 29 ноября курсы для системных администраторов и программистов со скидкой 30%!

🐍 Курс "Автоматизация задач на Python": создавайте скрипты для упрощения повседневных задач, становитесь мастером автоматизации с помощью языка Python.

📡 Курс "Инженер MikroTik": освойте настройку и управление сетевыми устройствами MikroTik, разберитесь в сложных сетевых конфигурациях и станьте экспертом в области построения надежных и эффективных сетей.

⚙️ Курс "DevOps": освойте все инструменты и методологии управления жизненным циклом программного обеспечения, стань техническим лидером в своей команде.

🖥 Курс "Windows Server 2022": изучите современные технологии и подходы к управлению серверной инфраструктурой на базе Windows Server 2022.

🎓Диплом о профпереподготовке по окончанию обучения!

Готов выйти на новый уровень? Выбирай курс и достигай новых высот в карьере!

👉 Выбрать курс (перейти на сайт)

#реклама
О рекламодателе

В завершение темы Wi-Fi

Нормативное регулирование Wi-Fi в Российской Федерации

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

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

Поэтому во всех странах мира существуют нормы, регламентирующие использование беспроводного оборудования, в данной статье мы рассмотрим особенности регулирования Wi-Fi в России.

https://interface31.ru/tech_it/2019/09/normativnoe-regulirovanie-wi-fi-v-rf.html

Занимательная история о том, как полоумные колонки Яндекс практически полностью завалили российский пул NTP.

https://habr.com/ru/companies/yandex/articles/861538/

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

Синхронизация времени Active Directory с внешним источником

Синхронизация времени - важный и во многом достаточно критичный аспект работы Active Directory, особенно сегодня, когда широко используется взаимодействие с внешними системами и работа с сотрудниками, которые могут находиться в различных часовых поясах.

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

https://interface31.ru/tech_it/2020/05/sinhronizaciya-vremeni-active-directory-s-vneshnim-istochnikom.html

🛠🛠Мечтаете прокачать свои навыки в электронике и программировании для работы с микроконтроллерами?

Это реальный шанс освоить отладку встроенного ПО на практике!

Приглашаем на открытый урок по отладке программ для AVR и PIC в Proteus и Multisim!

- Вы познакомитесь с особенностями моделирования работы программного обеспечения микроконтроллеров AVR и PIC в программах Proteus Professional и NI Multisim.
- Вы узнаете особенности моделирования аналоговых и цифровых схем и их взаимодействия с микроконтроллерами.

Всё это — в интерактивном формате с реальными примерами. Присоединяйтесь!

🔥Регистрируйтесь на урок 2 декабря, в 20:00 мск и получите скидку на большое обучение «Электроника и электротехника»: https://otus.pw/aX1v/?erid=LjN8KDoFu

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

Без лишнего шума и пыли АТОЛ начал переезд с SharePoint на Seafile. До основного центра загрузок еще не добрался, но второстепенные ресурсы уже переводит.

Интересно, базу знаний, которая сейчас на OneNote на что переводить начнет.

А как установить и настроить свой SeaFile можете прочитать у нас: https://interface31.ru/tech_it/2023/09/ustanovka-oblachnogo-faylovogo-servisa-seafile-na-ubuntu-server.html

​​Кто и как ведет локальную баз знаний

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

Она состоит из адресов админок, списков доменов, IP-адресов, токенов и прочих учетных данных и хранить это, в отличии от общедоступной информации надо совсем по-другому.

Что касается первой части, то мы использовали и все еще используем DokuWiki, у нее есть как плюсы, так и минусы. Начнем с последних, DokuWiki, как и любой Вики-движок требует специальной разметки.

Поэтому писать в нее могут не только лишь все, а специально обученные люди. Но и те порой косячат, поэтому приходится постоянно контролировать что там и как. Без этого беда.

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

Мы с данным подходом бились давно, но безуспешно. В большинстве случаев сотрудники рассматривают ведение документации как дополнительную бесполезную нагрузку и относятся к этому вопросу спустя рукава.

Поэтому если в такой организации есть человек, который за всем этим следит, то там будет Вики более-менее приличного вида, если нет, то там со временем будет просто куча бесполезного информационного мусора.

Но у Вики есть и неоспоримые плюсы, например, как ссылки на несуществующие страницы. Когда вы составляете документацию и понимаете, что вам надо отдельно пояснить какой-то термин или сослаться на другую процедуру, то вы просто ставите ссылку.

При переходе по такой ссылке обычный пользователь увидит, что страница до сих пор не написана, а ответственный сотрудник может прямо здесь и сейчас создать эту страницу.

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

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

Альтернатива – сервисы заметок, такие как Evernote, OneNote и аналогичные. Здесь все гораздо проще. Создаем структуру блокнотов и кидаем заметку в нужный блокнот.

Этому можно обучить даже дрессированную обезьяну, и сотрудники с этим вполне справляются. Вроде бы профит?

А вот и нет, такие заметки, как правило, разрозненны, лишены единого стиля изложения и на массив документации никак не тянут, это как была группа разрозненных заметок, так и осталась.

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

Кроме того, блокноты удобны для хранения действительно оперативной информации – явки, пароли, адреса. Все это легко шифруется встроенными средствами.

В этом плане блокноты удобны, как и в плане публикации каких-то базовых инструкций, которых не много и которые легко можно найти простым поиском.

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

На практике мы часто встречаем «документацию» в онлайн-блокнотах, найти в которых что-то крайне затруднительно, либо заброшенные Вики в которых последний раз информацию актуализировали при Царе Горохе и ее тоже надо постараться найти.

А как дела обстоят у вас?

Критическая уязвимость в Zabbix

Два дня назад опубликована критическая уязвимость CVE-2024-42327 с рейтингом CVSS 9,9 – т.е. критическая.

Обнаруженная SQL-инъекция позволяет любому пользователю Zabbix, у которого есть доступ к API, выполнить повышение привилегий.

Эксплуатация уязвимости также может привести к несанкционированному доступу к базе данных, что позволит злоумышленникам читать, изменять или удалять данные в СУБД.

На момент публикации уязвимости (27 ноября 2024 г.) конкретной информации о доступном исправлении не предоставлено.

👉 Обновлено: Fix Version/s: 6.0.32rc1, 6.4.17rc1, 7.0.1rc1

В связи с отсутствием опубликованных исправлений рекомендуется серьезно ограничить доступность API, либо временно отказаться от его использования.

https://feedly.com/cve/CVE-2024-42327