Я не говорю что IPv6 это плохо, IPv6 это хорошо, можно и красиво, но десятки клиентов которые «ложат» Ваш DNS сервер запросами типа AAAA? localhost. это действительно плохо.
Я не предлагаю убивать IPv6 я предлагаю вводить адекватные ограничения на использование DNS запросов определенных типов.
P.S. спасибо, что дочитали статью хотя бы до этого момента.
Это ресолвер для клиентов домашнего интернет, т е конечных потребителей. Они все приходят к DNS со своими ip адресами. Если Вам кажется, что будут жалобы из-за слишком жестких лимитов — поправьте их в соответствии с Вашими желаниями :)
Как мы все прекрасно понимаем, дело не в пользователях а в их запросах, и в отсутствии штатных средств ограничивать аппетиты конечного пользователя.
Дело в том, что например в том же bind есть только одна опция которая может быть полезна — ограничение общего количества рекурсивных запросов, но что произойдет с bind-ом когда все эти запросы сделает один клиент? Правильно. Он просто перестанет обрабатывать валидные запросы других клиентов.
Допустим Ваш провайдер имеет два подключение к своим апстримам и анонсит им свои сети, Ваш пакет улетает через один канал а ответ возвращается совсем по другому маршруту.
Утрированно: пакет улетел через Гваделупу а вернулся через Амстердам.
1. hashsize = nf_conntrack_max / 8 не правда, на больших объемах трафика hashsize должен быть максимально приближен к nf_conntrack_max это снижает нагрузку на ЦПУ NAT сервера
2. Крутить MTU на интерфейсах ни имеет никакого смысла. Трафик у Вас транзитный и пакуеты будут бегать с MTU 1500 так что ваши 9000 никуда.
Я не предлагаю убивать IPv6 я предлагаю вводить адекватные ограничения на использование DNS запросов определенных типов.
P.S. спасибо, что дочитали статью хотя бы до этого момента.
Вы просто отсрочили ту же самую проблему, когда один клиент со скоростью в 100Мбит/s начинает тупо валить ваш DNS вполне валидными DNS запросами.
Дело в том, что например в том же bind есть только одна опция которая может быть полезна — ограничение общего количества рекурсивных запросов, но что произойдет с bind-ом когда все эти запросы сделает один клиент? Правильно. Он просто перестанет обрабатывать валидные запросы других клиентов.
На самом деле это огромная проблема.
rndc status
recursive clients: 268/14900/15000
Согласитесь куда уж проще организовать масс шейп
ipfw pipe 1 config bw 200Kbit/s mask dst-ip 0x000fffff
ipfw pipe 2 config bw 200Kbit/s mask src-ip 0x000fffff
ipfw add 11 pipe 1 ip from any to 172.16.0.0/12 out
ipfw add 12 pipe 2 ip from 172.16.0.0/12 to any in
ну либо использовать таблицы для различных тарифных планов.
Утрированно: пакет улетел через Гваделупу а вернулся через Амстердам.
Поставьте равным и сами увидите что нагрузка на CPU уменьшится :)
2. Разве я где-то сказал что 1500 бегать не будут? Будут, конечно. Но если включить jumbo frame, то бегать будет значительно лучше
в 2 раза быстрее? :)
Кстати что там насчет ethtool -k ethX и ethtool -g ethX на ваших интерфейсах?
Что за сетевые посоветуете приобретать под NAT?
Какое ядро использовать?
2. Крутить MTU на интерфейсах ни имеет никакого смысла. Трафик у Вас транзитный и пакуеты будут бегать с MTU 1500 так что ваши 9000 никуда.