1. Я глубоко уверен, что авторитетный и рекурсор на одной машине — это плохо. Я в докладе объясняю, почему.
2. Я не особый сторонник bind, поскольку он по сути больше авторитетный сервер, нежели рекурсор, который предлагает мне хранить БД в текстовом виде. От чего я тоже хочу уйти подальше.
3. Держать открытый рекурсивный DNS в Интернет порой надо, увы. В моем случае, как только мы закрылись от таких запросов снаружи, вылезли две вещи:
— один крупный оператор связи косанул с настройкой абонентских роутеров и ходит резольвить к нам (и его абоненты, разумеется, пострадали в первую очередь)
— один из наших коллег ставил наши резольверы в сетевых настройках некоторых систем, которые он уже давно не администрирует, то есть пострадали бы достаточно крупные, хоть и не очень важные для нас люди.
Поэтому в итоге у нас резольвер смотрит в интернер, увы.
Давайте сначала коротко про ANY. Я придерживаюсь того, что описывает CloudFlare в своем блоге. Там отличная история, как они планомерно отказывались от ANY.
Когда мы вырубали его, то руководствовались двумя вещами:
1. Анализ того, что мы видим в запросах (99,9% были нелегитимные запросы)
2. Насколько пострадают от наших действий пользователи (т.е. с повышенным внимание отрабатывали запросы «не работает» от наших абонентов).
Результат оказался вполне нормальным: никто не пострадал, мир стал чище.
На нашем проде было видно, что ANY на резольверах используется только ботнетами.
Однако, про ANY на авторитетных серверах вышла смешная история. Одному из наших клиентов перестали доходить письма из Бюро Кредитных Историй. После краткого расследования стало понятно, что там на той стороне qmail как раз какой-то адовой версии, которая шлет нашим авторитетным серверам ANY (авторы qmail где-то в списке рассылки говорили, что это круто и быстро).
В итоге, на авторитетных у нас ANY можно, а на резольверах низя.
Я думаю, Вы говорите про другое, у PowerDNS есть Recursor. Но я, к сожалению, не помню, почему им не пользовался. Наверное, просто больше нравился unbound.
Но, думаю, что я несправедливо упустил его в разделе резольверов.
Умеют, однако задача была уйти от единой точки отказа.
Каждый ns в итоге совершенно самостоятелен и не зависит от какой-то центральной базы.
В распределенных географически инсталляциях (даже на малых расстояниях), может быть так, что связность ns до базы лежит (упал канал), а связь клиентов до ns не лежит (т.е. они хотят ответов).
Поэтому еще раз, каждый ns обладает всем необходимым, чтобы ответить на запрос.
Почитайте внимательно, я говорю об отказе от master/slave вообще. Зоны всегда одинаковые везде, поскольку синхронизируется бэкенд.
Ну и простая цитата из документации про supermaster (которая хорошо поясняет, почему это костылик для малого количества постоянных доменов):
Note: Removal of zones provisioned using the supermaster must be done on the slaves themselves. As there is no way to signal this removal from the master to the slave.
То есть, если я убрал зону на мастере, то надо сходить и как-то руками ее убрать на слейве. Минуточку, это же… OH SHI~
У меня (по обыкновению) большая просьба к тем, кто ставит минус — хотя бы говорите, чем не понравилось. Это поможет лично мне в дальнейшем. Заранее спасибо :)
Смотрите в чем фишка. Децентрализация достижима, только не всегда удобна. Да, один IP-адрес что-то передает другому, только вот фишка в том, что передает и как.
Децентрализация достижима. Не решены некоторые проблемы, я о них пишу, поэтому и хочу понять — есть ли решения. Вы совершенно верно упомянули Netsukuku, но там, как мне кажется, замах слишком серьезен. Т.е. физический уровень не получить без провайдера — кто мне кабель протянет?
Документацию I2P читал неоднократно, дело немного в другом. Я же писал про адресацию, и про то, что единого резолва в рамках I2P может не быть, это грустно.
А кроме того, бутстрап мне лично не нравится — ну что за дела, децентрализованная сеть по сути лезет в централизованный интернет, чтобы там что-то взять. Странно.
На мой взгляд, плагином не обойтись. Если я правильно понимаю, то плагин — это кусочек JS кода, а тут ситуация сложнее, не уверен, что оптимально получится.
Думаю, что поддержка TOR/I2P на уровне браузера — лучше, в смысле, быстрее.
1. Я глубоко уверен, что авторитетный и рекурсор на одной машине — это плохо. Я в докладе объясняю, почему.
2. Я не особый сторонник bind, поскольку он по сути больше авторитетный сервер, нежели рекурсор, который предлагает мне хранить БД в текстовом виде. От чего я тоже хочу уйти подальше.
3. Держать открытый рекурсивный DNS в Интернет порой надо, увы. В моем случае, как только мы закрылись от таких запросов снаружи, вылезли две вещи:
— один крупный оператор связи косанул с настройкой абонентских роутеров и ходит резольвить к нам (и его абоненты, разумеется, пострадали в первую очередь)
— один из наших коллег ставил наши резольверы в сетевых настройках некоторых систем, которые он уже давно не администрирует, то есть пострадали бы достаточно крупные, хоть и не очень важные для нас люди.
Поэтому в итоге у нас резольвер смотрит в интернер, увы.
Когда мы вырубали его, то руководствовались двумя вещами:
1. Анализ того, что мы видим в запросах (99,9% были нелегитимные запросы)
2. Насколько пострадают от наших действий пользователи (т.е. с повышенным внимание отрабатывали запросы «не работает» от наших абонентов).
Результат оказался вполне нормальным: никто не пострадал, мир стал чище.
Однако, про ANY на авторитетных серверах вышла смешная история. Одному из наших клиентов перестали доходить письма из Бюро Кредитных Историй. После краткого расследования стало понятно, что там на той стороне qmail как раз какой-то адовой версии, которая шлет нашим авторитетным серверам ANY (авторы qmail где-то в списке рассылки говорили, что это круто и быстро).
В итоге, на авторитетных у нас ANY можно, а на резольверах низя.
Я думаю, Вы говорите про другое, у PowerDNS есть Recursor. Но я, к сожалению, не помню, почему им не пользовался. Наверное, просто больше нравился unbound.
Но, думаю, что я несправедливо упустил его в разделе резольверов.
Если пробовать делать это на транзакциях, то есть, делать кучу операций в транзакции, то это атомарно, как и RENAME TABLE, но гораздо более медленно.
Каждый ns в итоге совершенно самостоятелен и не зависит от какой-то центральной базы.
В распределенных географически инсталляциях (даже на малых расстояниях), может быть так, что связность ns до базы лежит (упал канал), а связь клиентов до ns не лежит (т.е. они хотят ответов).
Поэтому еще раз, каждый ns обладает всем необходимым, чтобы ответить на запрос.
Первый же день эксплуатации показал, что с репликацией не по пути :(
Ну и простая цитата из документации про supermaster (которая хорошо поясняет, почему это костылик для малого количества постоянных доменов):
То есть, если я убрал зону на мастере, то надо сходить и как-то руками ее убрать на слейве. Минуточку, это же… OH SHI~
Децентрализация достижима. Не решены некоторые проблемы, я о них пишу, поэтому и хочу понять — есть ли решения. Вы совершенно верно упомянули Netsukuku, но там, как мне кажется, замах слишком серьезен. Т.е. физический уровень не получить без провайдера — кто мне кабель протянет?
А кроме того, бутстрап мне лично не нравится — ну что за дела, децентрализованная сеть по сути лезет в централизованный интернет, чтобы там что-то взять. Странно.
Думаю, что поддержка TOR/I2P на уровне браузера — лучше, в смысле, быстрее.