hi. i got a problem .

Just speak

how to fix

if you want to give me a file to try

It always must be 42

this time it should work

it's better because of that

same problem there

Здравствуйте, регламента на вопрос нет, но я попытаюсь спросить: Ради раздачи dns в виртуалки, использования dns over tls и блокирования неугодных доменов я воспользовался unbound. И вот с последним юзкейсом возникли проблемы. Блокировать так как это делает другие[1][2] отправляя в ответ на dns запрос ответ NXDOMAIN или вообще какое-то странное перенаправление на 0.0.0.0, как в первой и четвёртой ссылке, не получается. Вот просто не работает. Однако, прочтя мануал по урезанной версии этого же unbound, но с более простым конфигом я узнал, что следовало бы в ответ отправить refuse[3]. Теперь всё действительно заработало, но осталась неясность: Нормально ли так вообще блокировать домены с  always_nxdomain  , а не refuse ? Почему люди так делающие иногда  могут ссылаться на RFC8020: NXDOMAIN: There Really Is Nothing Underneath ? Хотя казалось бы этот документ тут не причём.
[1]: https://www.tumfatig.net/20190405/blocking-ads-using-unbound8-on-openbsd/
[2]: https://github.com/StevenBlack/hosts/wiki/Unbound
[3]: https://man.openbsd.org/unwind.conf.5#block
[4]: https://raw.githubusercontent.com/k0nsl/unbound-blocklist/master/blocks.conf

мне кажется, Refused честнее. он явно говорит "вы кто такие? идите нахуй! я вас не знать не желаю"

Refused - The name server refuses to perform the specified operation  for policy reasons.  For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer)  for particular data.

RFC1035 если что

а всё остальное - это какой-то hijack блин, еще бы на 127.0.0.1 отправлять, как баннерорезки в /etc/hosts

с другой стороны, после refused некоторые DNS клиенты по идее могут дальше по списку своих DNS серверов пойти, но это ж твоя локалка и твои виртуалки, ты точно знаешь, что там других нет :)

REFUSED is generally considered the best approach, indicates that the server is configured not to answer this query. Overall a good fit, whether or not it's not explicitly mandated that it must be used in this particular case.

Есть и такое мнение

Спасибо

Здраствуйте, вопрос по поддержанию работы UNIX-like операционной системы с выделенным айпи и доступом по ssh.
Читая параграф про SSH в FreeBSD hankdbook, я наткнулся в нём на инструкции к утилите mtree[0].
В нём написано, что более продвинутой IDS утилитой как aide[1] также можно пользоваться. Меня устраивает и mtree, но вот закавыка: мне говорили, что файл, в который aide пишет информацию о содержимом фс, нужно держать на другом хосте, по очевидным причинам того, что если кто-то ещё имеет доступ по SSH, то тому не составит труда файл с информацией о директории изменить. Это меня сбивает с толку, потому что в пример из хэндбука вывод mtree храниться в пределах одного сервера. Может ли быть это как-то связано с тем, что в mtree можно флагом -s передать seed для чексумм. И предохраняет ли это как-то это как-то от модификации ? Ведь получается не зная seed, нельзя создать новую чексумму.

[0]:https://docs.freebsd.org/en/books/handbook/security/#openssh
[1]: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-using-aide

если уж так заморачиваться, проще созданный mtree файл со спецификацией сдернуть на другую машину, где злоумышленник его не найдет

Хорошо, благодарю. Просто другая машина ещё какие-то недели две не предвидится

к себе домой стащи :)

на флешку сохранить, там точно не найдут :)))

Пожалуй так и поступлю, спасибо :)