Файл хоста блокировки рекламы, доступный всем компьютерам в локальной сети

DNS - неподходящий инструмент для этой работы.

Давайте сначала разберемся с какой-нибудь глупостью:

Должен ли я иметь еще один компьютер все время...?

Нет, это не 1950-е годы. Компьютеры могут работать более чем на одном сервере одновременно. Многие Unices успешно делают это, в том числе запускают собственные полнофункциональные разрешающие DNS-серверы с разрешением, как стандарт - из коробки - с 1980-х годов. Используйте всегда включенный компьютер, который, как вы говорите, у вас уже есть.

Настройка DNS-сервера является следующим шагом, когда кто-то хочет распространять hosts файл на несколько машин. Это, в конце концов, причина, по которой DNS возник в первую очередь. Итак, тупой ответ на ваш вопрос

Должен ли я установить независимый DNS-сервер в своей сети и убедиться, что все мои локальные компьютеры используют его?

Да.". Это то, что нужно сделать, чтобы увеличить подачу таких данных на всю локальную сеть.

Тем не менее, DNS является неправильным инструментом для работы, которую вы хотите сделать. Я знаю, что это могло показаться фантастической идеей создать hosts файл с большим количеством имен и таким образом блокирует рекламу, но он не масштабируется - как вы уже обнаружили и как другие обнаружили еще в 1980-х годах - и (даже если он был изменен для использования DNS-сервера контента), он не подходит. Это не достаточно детально, и это нарушение слоев.

• Это многоуровневое нарушение, потому что вы не мешаете браузеру WWW извлекать контент через HTTP/HTTPS. Вместо этого вы изменяете сопоставления имени и адреса, используемые всеми вашими компьютерами. Таким образом, вы меняете сопоставления для SMTP, IMAP, POP, FTP, HTTP, NTP, CIFS и т. Д. И всего остального, что ищет доменные имена и сопоставляет их с IP-адресами. Для тех гостей в вашей локальной сети, которые могут захотеть сделать что-то кроме просмотра веб-страниц с доменными именами, которые вы в одностороннем порядке считаете "рекламой", все по-королевски испорчено. Вы атакуете ситуацию не на том уровне. Слой отображения имени → адреса - не тот, с которым можно обойти. Уровень HTTP / HTTPS есть.
• Это недостаточно детально, потому что, как только вы проделаете это достаточно долго, рекламодатели будут мудры для вас. Возможно, самый вопиющий пример того, как это проблематично, это то, что Google по крайней мере один веб-баг обслуживает, чей URL имеет доменное имя. www.google.com, Заблокируйте это, используя свой подход кувалдой к грецкому ореху, и вы заблокировали себя почти от всего Google. Существует много других примеров того же, где скрипты всплывающих окон / всплывающих окон, собственные инжекторы cookie, веб-ошибки и другие неприятности обслуживаются из тех же доменов, что и желаемый контент. Я предлагаю провести обход базы данных, используемой adzapper - многие записи в которой используют регулярные выражения для сопоставления только с некоторыми URL-адресами домена - чтобы увидеть, насколько широко это происходит в настоящее время.

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

Существует два варианта правильного подхода, оба из которых работают на уровне HTTP, и оба имеют более высокую степень детализации, чем целые домены:

• Укажите браузеру WWW напрямую, куда отправлять его транзакции HTTP / HTTPS для нежелательного контента. Один часто делает это с помощью сценария PAC, и есть много людей, которые публикуют сценарии PAC для размещения рекламных объявлений, на которых можно основываться. (Сценарий Джона Р. Ло Версо существует уже более полувека.) Один из них помещает список регулярных выражений в сценарий PAC и сообщает браузеру WWW, откуда следует загружать сценарий. Браузер WWW сам перенаправляет свои транзакции HTTP / HTTPS, без необходимости изменять службу DNS, без необходимости возиться с дополнительным / заменяющим оборудованием и не затрагивая другие протоколы, другое программное обеспечение и работу других людей.

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

• Запустите прокси-сервер HTTP, который имеет набор правил сопоставления с образцом для механизма перенаправления / перезаписи, и дайте указание всем браузерам WWW отправлять через него свой HTTP-трафик. (Это дает дополнительное преимущество, заключающееся в том, что при желании можно наложить более драконовские ограничения на HTTP-трафик на границах своей локальной сети, поскольку весь трафик должен исходить из серверной части прокси-HTTP-сервера.) Adzapper и Privoxy - это два нескольких прокси-серверов HTTP, доступных для этой цели. Вместо того, чтобы браузер WWW перенаправлял свой трафик WWW, прокси-сервер HTTP делает это. С некоторыми умными прокси-серверами HTTP можно делать всевозможные трюки.

В течение почти десятилетия я сам использовал первый подход. Его недостаток заключается в том, что обработка сценариев PAC в WWW-браузере даже сегодня довольно хитрая. Легко создать сценарий, который не будет работать во всех браузерах WWW, режимы сбоев ужасны (например, встроенный в RealPlayer браузер WWW зависает / аварийно завершает работу, если представлен, например, с неверным сценарием PAC.) И взаимодействия между сценариями PAC и Механизмы защиты просмотра веб-страниц, используемые некоторыми инструментами защиты от вредоносных программ, часто бывают не очень хорошими. Тем не менее, этот подход, который я могу поручиться на опыте, будет работать, пока он очень осторожен, в широком диапазоне браузеров WWW, работающих на различных платформах.

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

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

Используйте правильный инструмент для работы. DNS здесь не тот инструмент.

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

Вы можете просмотреть дистрибутив брандмауэра, такой как ipcop, smoothwall, pfsense и т. Д., Затем отключите DHCP и т. Д. На беспроводном маршрутизаторе. Правильный способ сделать это - отключить Wi-Fi на маршрутизаторе и установить третий сетевой адаптер для Wi-Fi (один адаптер для WAN, один для LAN и Wi-Fi для беспроводной связи).

Многие из этих пакетов имеют дополнительное преимущество внутреннего антиспама.

Я использовал ipcop и pfsense, и они просты в обслуживании, но если у вас есть COAX (например, verizon fios), вам, возможно, придется перепрыгнуть через некоторые обручи (я сделал это, это работоспособно, но по какой-то причине, когда Модем потерял питание, "обходной путь", который я использовал, вернулся отключенным и потребовал вмешательства пользователя, чтобы восстановить интернет)