Comments 33
Первая картинка должна иметь надпись 60 на номере трассы. Шар, красный бмв с белым пятном на капоте!
UFO just landed and posted this here
Также давно используем этот принцип работы.
Скажу только что на нем работают некоторые из корневых DNS-серверов.
Это по большей части и спасает всю систему от глобального DDos.
Скажу только что на нем работают некоторые из корневых DNS-серверов.
Это по большей части и спасает всю систему от глобального DDos.
Без DNSSEC не интересно.
DNSSEC в планах есть. Однако на данный момент самая большая сложность не в том чтобы подписать зону, а в том что у большинства отечественных пользователей рекурсоры провайдеров и их дешёвые роутеры не поддерживают DNSSEC.
Также есть крайне сложный вопрос: делегировать подпись dns-провайдеру (т.е. ключи будут находиться не только у владельца зоны) или загрузить файл с уже самостоятельно подписанной зоной в панель управления хостера?
Первый метод удобен, но второй способ гарантирует что никто кроме Вас не сможет изменить и подписать записи зоны. Лично я выбрал бы второй, но что делать если мне захочеться/нужно воспользоваться услугами хостера для фэйловера на уровне DNS или для балансировки нагрузки по географическому местоположению?
Также есть крайне сложный вопрос: делегировать подпись dns-провайдеру (т.е. ключи будут находиться не только у владельца зоны) или загрузить файл с уже самостоятельно подписанной зоной в панель управления хостера?
Первый метод удобен, но второй способ гарантирует что никто кроме Вас не сможет изменить и подписать записи зоны. Лично я выбрал бы второй, но что делать если мне захочеться/нужно воспользоваться услугами хостера для фэйловера на уровне DNS или для балансировки нагрузки по географическому местоположению?
Я вам скажу как представитель международного регистратора поддерживающего DNSSEC.
Сам DNSSEC никому не интересен кроме как поиграться.
Он сейчас также всем нужен как и IPv6 в 2000 году.
У меня стоит plugin к браузеру проверяющий DNSSEC только потому что я его внедрял и лень его удалять.
Аудитория пользователей таких плагинов стремится к нулю, а ничем другим сейчас проверка не делается.
В любом случае, как правильно заметил clickfreak, отдавать свои ключи на сторону это нужно быть «очень умным».
Сам DNSSEC никому не интересен кроме как поиграться.
Он сейчас также всем нужен как и IPv6 в 2000 году.
У меня стоит plugin к браузеру проверяющий DNSSEC только потому что я его внедрял и лень его удалять.
Аудитория пользователей таких плагинов стремится к нулю, а ничем другим сейчас проверка не делается.
В любом случае, как правильно заметил clickfreak, отдавать свои ключи на сторону это нужно быть «очень умным».
Не слыхали про DANE? На этапе подготовки стандарта стандарта Хром умел валидировать самодписанный ssl-сертификат через DNSSEC habrahabr.ru/post/138490/ до момента когда Adam Langley не решил, что это технология ОПЕРЕДИЛА ВРЕМЯ и не выкинул ее поддержку из Хрома github.com/agl/dnssec-tls-tools/issues/4
На сегодняшний день стандарт уже принят и скоро будет работать в FireFox wiki.mozilla.org/Security/DNSSEC-TLS-details
Кроме этого, я уже сегодня использую записи SSHFP чтобы не отвечать yes в момент первого подключения к SSH-серверу.
GnuPG уже умеет понимать PKA-записи www.gushi.org/make-dns-cert/HOWTO.html
Почему Вы сегодня доверяете регистратору возможность указания master-серверов DNS для домена но боитесь доверить ключи для подписания зоны? Если не хотите доверять ключи, пусть провайдер DNS позволит размещать уже подписанную зону без хранения ключей.
На сегодняшний день стандарт уже принят и скоро будет работать в FireFox wiki.mozilla.org/Security/DNSSEC-TLS-details
Кроме этого, я уже сегодня использую записи SSHFP чтобы не отвечать yes в момент первого подключения к SSH-серверу.
GnuPG уже умеет понимать PKA-записи www.gushi.org/make-dns-cert/HOWTO.html
Почему Вы сегодня доверяете регистратору возможность указания master-серверов DNS для домена но боитесь доверить ключи для подписания зоны? Если не хотите доверять ключи, пусть провайдер DNS позволит размещать уже подписанную зону без хранения ключей.
Какой процент использования этой технологии?
Какая в ней востребованность?
Понятно что может десяток тысяч гиков начал это использовать и пытаться придумать ей применение.
Но ради этой кучки смысла внедрять технологию(совсем не простую в массовой реализации) смысла нет.
Это банально не принесет никаких бенефитов компании.
Я бы DANE не доверял по определению.
Нет авторитетного поручителя, каждый желающий может сделать себе сертификат который ничего не подтверждает.
Да здравствует фишинг и фрауд!
Выключу в браузере как только выкатят в апдейте.
А регистратору я доверяю потому что он связан договорами с администраторами зоны.
Потому что он застрахован минимум на 1кк$ по требованию ICANN.
А что меня защитит от утечки ключей DNS-хостинга?
Кто потом будет доказывать что их слили, а не медвед украл?
Какая в ней востребованность?
Понятно что может десяток тысяч гиков начал это использовать и пытаться придумать ей применение.
Но ради этой кучки смысла внедрять технологию(совсем не простую в массовой реализации) смысла нет.
Это банально не принесет никаких бенефитов компании.
Я бы DANE не доверял по определению.
Нет авторитетного поручителя, каждый желающий может сделать себе сертификат который ничего не подтверждает.
Да здравствует фишинг и фрауд!
Выключу в браузере как только выкатят в апдейте.
А регистратору я доверяю потому что он связан договорами с администраторами зоны.
Потому что он застрахован минимум на 1кк$ по требованию ICANN.
А что меня защитит от утечки ключей DNS-хостинга?
Кто потом будет доказывать что их слили, а не медвед украл?
В современных условиях, когда паранойя 2012 года выглядит как беспечность 2013 года, доверять любым централизованным системам нельзя. Нельзя доверять никакой системе криптографии, которая полагается на то, что некоторое юрлицо по каким-то там выдуманным основаниям не отдаст свой самый ценный и самый закрытый ключ очередному несуществующему агентству.
Как только мы получаем в криптосхеме «огранизация, владеющая закрытым ключом», мы смело можем предполагать, что у Евы есть полный и стопроцентный доступ к этому ключу.
Любая криптосхема, которая не делает этого допущения — фиговый листочек.
Как только мы получаем в криптосхеме «огранизация, владеющая закрытым ключом», мы смело можем предполагать, что у Евы есть полный и стопроцентный доступ к этому ключу.
Любая криптосхема, которая не делает этого допущения — фиговый листочек.
На данный момент суть не в том что DNSSEC плохой и нам не нравится. Дело в востребованности со стороны клиентов. Как бы печально это ни звучало, но если я сейчас ради 2,5 пользователей проделаю, хоть и интересную, но трудоёмкую работу… тогда все остальные более востребованные фичи клиентам придёться ждать гораздо дольше.
Сначала пользователь должен сделать соответствующую RR, что может занять больше времени. Как много новых пользователей ходит по ssh на этот сервер, где они не набирают 'yes'? Или вы всегда подключаетесь с разных машин где не сохранены отпечатки?
Опять же, я не против этого типа записей, в планах они тоже есть. Но недостаточно выкатить сырую фичу просто для галочки, нужно чтобы это действительно было удобно и имело смысл.
Договор, а вообще я не доверяю, но не делать же своего регистратора ради своих доменов?
Этот вариант точно будет реализован. Есть также проблема введения новых географических узлов в случае использования клиентом функционала балансировки по маршрутизации или фэйловера на уровне DNS: клиенту на своей стороне каждый раз нужно будет подписывать зону во всех возможных вариантах.
SSHFP чтобы не отвечать yes
Сначала пользователь должен сделать соответствующую RR, что может занять больше времени. Как много новых пользователей ходит по ssh на этот сервер, где они не набирают 'yes'? Или вы всегда подключаетесь с разных машин где не сохранены отпечатки?
Опять же, я не против этого типа записей, в планах они тоже есть. Но недостаточно выкатить сырую фичу просто для галочки, нужно чтобы это действительно было удобно и имело смысл.
Почему Вы сегодня доверяете регистратору возможность указания master-серверов DNS для домена но боитесь доверить ключи для подписания зоны?
Договор, а вообще я не доверяю, но не делать же своего регистратора ради своих доменов?
Если не хотите доверять ключи, пусть провайдер DNS позволит размещать уже подписанную зону без хранения ключей.
Этот вариант точно будет реализован. Есть также проблема введения новых географических узлов в случае использования клиентом функционала балансировки по маршрутизации или фэйловера на уровне DNS: клиенту на своей стороне каждый раз нужно будет подписывать зону во всех возможных вариантах.
Интересно услышать как вы внедряете, а не сам факт. хочется больше техн деталей.
Как сам процесс происходит, какие проблемы возникают.
Как сам процесс происходит, какие проблемы возникают.
Процесс добавления ноды происходит достаточно просто — установка системы, накатывание своей обвязки для управления, запуск репликации и мониторнга. Самый интересный этап — начало анонсирования, в эти моменты я держал пальцы скрещенными чтобы запросы распределялись между нодами равномерно и следуя хоть какой-то логике.
Самое сложное — это сделать так чтобы запросы приходили туда куда они должны приходить с наименьшими задержками, а не как хотят операторы, желающие урвать денег побольше, наплевав на своих пользователей (есть у нас в России, запросы из Хабаровска уходили в Киев мимо Екатеринбурга, СПб и Москвы). Основной метод исправления — prepend'ы на анонсах, главное не переборщить.
Самое сложное — это сделать так чтобы запросы приходили туда куда они должны приходить с наименьшими задержками, а не как хотят операторы, желающие урвать денег побольше, наплевав на своих пользователей (есть у нас в России, запросы из Хабаровска уходили в Киев мимо Екатеринбурга, СПб и Москвы). Основной метод исправления — prepend'ы на анонсах, главное не переборщить.
Как процесс происходит я иногда слышу. Звучит это не всегда лестно в адрес авторов разнообразного ПО, периодическим обсуждением трёхзначных RFC, уходящих во времена, когда они писались для DOD (Department of Defense USA) и прочим ужасом, который сопровождает человека, который решил задаться вопросом о том, какие символы и в каком комплекте могут быть в поле SOA.
Любопытно, как вы анонсируете в глобальный BGP индивидуальные IP адреса ваших ns серверов? Все что мельче /24 обычно фильтруют.
Любопытно, как вы анонсируете в глобальный BGP индивидуальные IP адреса ваших ns серверов? Все что мельче /24 обычно фильтруют.
На самом деле было бы интересно почитать про «накатывание своей обвязки для управления, запуск репликации и мониторнга». Тут не обойтись без дополнительного сервера расположенного у провайдера, анонсирующего ваши две подсети.
Безусловно, в каждой географической точке расположены выделенные серверы, которые и обрабатывают клиентские запросы. Серверы держат с операторами BGP-сессии, что позволяет нам самостоятельно манипулировать анонсами. Должен отметить при таком раскладе очень удобно проводить обслуживание:
1. Прекращаем анонсировать сеть, которую может затронуть работами — запросы в течение максимум минуты распределяются по другим географически распределённым узлам. Для клиентов это почти незаметно, единственный побочный эффект — небольшое увеличение времени ответа за счёт увеличения расстояния до ближайшего доступного узла.
2. Проводим необходимые работы.
3. Проверяем что всё в порядке и узел отвечает на все запросы корректно.
4. Начинаем анонсировать сеть. Запросы на узел начинают идти в течение 10 секунд.
В качестве инструмента автоматизации используется Ansible. Работает через ssh и не требует на удалённом узле установки каких-либо дополнительных пакетов, кроме питона, который как правило уже есть в минимально установленной ОС. На обновление узла уходит около минуты — основное время это ожидание когда разойдётся информация по маршрутизаторам провайдеров и прекратятся DNS-запросы.
Для мониторинга и статистики DNS-запросов используется самописаная система. Да, мы знаем какие записи доменов спрашивали, сколько раз и когда. При большом желании можем даже сказать кто именно (как правило это рекурсоры провайдеров пользователей, что не удивительно). Также мы знаем какие RR-записи спрашивают, но наши пользователи их по какой-либо причине не прописали (самая распространённая отсутствующая — AAAA-запись, т.к. рекурсоры спрашивают её в первую очередь).
1. Прекращаем анонсировать сеть, которую может затронуть работами — запросы в течение максимум минуты распределяются по другим географически распределённым узлам. Для клиентов это почти незаметно, единственный побочный эффект — небольшое увеличение времени ответа за счёт увеличения расстояния до ближайшего доступного узла.
2. Проводим необходимые работы.
3. Проверяем что всё в порядке и узел отвечает на все запросы корректно.
4. Начинаем анонсировать сеть. Запросы на узел начинают идти в течение 10 секунд.
В качестве инструмента автоматизации используется Ansible. Работает через ssh и не требует на удалённом узле установки каких-либо дополнительных пакетов, кроме питона, который как правило уже есть в минимально установленной ОС. На обновление узла уходит около минуты — основное время это ожидание когда разойдётся информация по маршрутизаторам провайдеров и прекратятся DNS-запросы.
Для мониторинга и статистики DNS-запросов используется самописаная система. Да, мы знаем какие записи доменов спрашивали, сколько раз и когда. При большом желании можем даже сказать кто именно (как правило это рекурсоры провайдеров пользователей, что не удивительно). Также мы знаем какие RR-записи спрашивают, но наши пользователи их по какой-либо причине не прописали (самая распространённая отсутствующая — AAAA-запись, т.к. рекурсоры спрашивают её в первую очередь).
Безусловно, в каждой географической точке расположены выделенные серверы, которые и обрабатывают клиентские запросы.
Это я прекрасно понимаю, однажды меня заинтересовала anycast тема, в результате написал вот это.
Интересно было как вы решили проблему подключения к интерфейсу управления конкретного сервера, так как для управления вам нужен не любой, а именно конкретный сервер. На сколько я понимаю по вашему ответу, на каждом из серверов по 2 сетевые карты (IP адреса в разных подсетях) первая для управления — IP из подсети провайдера на площадке которого расположен сервер, вторая — отвечает на DNS запросы и анонсирует свою подсеть/24 в BGP. Ну, и наверное, на каждом из серверов есть статический маршрут до подсети из которой производится управление через первую сетевую карту.
Изначально мне представилась не самая правильная схема с дополнительным сервером, расположенным «топологически близко» к обоим серверам, через который осуществляется доступ на управление через IP адреса из подсети анонсируемой в BGP, поэтому и задал вопрос.
На самом деле проблем с подключением никаких нет и всё может работать через один сетевой интерфейс сервера, т. к. в плане настройки в ОС anycast IP-адрес ничем не отличается от IP-адреса для управления. Основная разница «снаружи»: маршруты для первого могут вести на разное географически распределённое оборудование, а для второго — только на конкретный сервер. Ну а анонсы можно запускать через этот же сетевой интерфейс, с адресами интерфейса они по сути не связаны.
промазал с веткой, del
Поздравляю компанию и ее пользователей с прекрасным начинанием, внедрение Anycast для DNS сервисов.
Есть пара технических вопросов:
1) Вы сознательно используете только одну автономную систему для Anycast?
2) Сервера ns[1-4].selectel.org на запросы с nsid отвечают что все они это «73 70 62 31 (s) (p) (b) (1)». Только ns5.selectel.org говорит о себе «6d 73 6b (m) (s) (k)». Следуя формальной логике получается что первые четыре имени это один и тот же физический сервер. Наверное это конфигурационная ошибка и физически сервера все же разные?
Есть пара технических вопросов:
1) Вы сознательно используете только одну автономную систему для Anycast?
2) Сервера ns[1-4].selectel.org на запросы с nsid отвечают что все они это «73 70 62 31 (s) (p) (b) (1)». Только ns5.selectel.org говорит о себе «6d 73 6b (m) (s) (k)». Следуя формальной логике получается что первые четыре имени это один и тот же физический сервер. Наверное это конфигурационная ошибка и физически сервера все же разные?
Sign up to leave a comment.
Внедрение Anycast DNS