company_banner

Внедрение Anycast DNS

    Anycast DNS

    С весны 2013 года мы начали внедрять технологию Anycast для наших NS-cерверов. Ниже мы вкратце расскажем о том, что представляет собой эта технология и какие преимущества она дает нашим клиентам.

    Оригинал в корпоративном блоге Селектела

    Что такое Anycast?


    Время отклика сервера во многом зависит от его географической удаленности от точки запроса. Как правило, чем меньше расстояние между сервером и точкой запроса, тем меньше время отклика. Но скорость обмена данными между сервером и компьютером пользователя зависит еще от целого ряда факторов: оборудование хостера, характеристики используемого им интернет-канала и т.п. Обмен пакетами между веб-узлами далеко не всегда осуществляется по кратчайшему и наиболее удобному маршруту.

    Одним из эффективных способов, позволяющих оптимизировать движение пакетов, является использование технологии Anycast. Слово anycast может быть переведено как «отсылка кому угодно» или «произвольная отсылка». Anycast — метод отсылки пакетов, при котором данные отправляются ближайшему из потенциальных получателей.

    Как это работает?


    Для использования технологии Anycast со стороны клиента не требуется никаких специальных серверов, сетей или специальных клиентов.

    Смысл метода Anycast заключается в анонсировании одинакового префикса IP-адресов одновременно из нескольких точек сети через протокол BGP. В результате данные передаются по наиболее короткому маршруту — на ближайший узел, которому присвоен анонсированный IP-адрес. При этом понятие «короткий маршрут» в данном случае трактуется не в географическом, а в топологическом смысле.

    Преимущества Anycast


    Итак, на основе технологии Anycast можно создать распределенную систему DNS с единым адресным пространством, что позволяет решать целый ряд проблем.

    Во-первых, Аnycast позволяет существенно повысить уровень надежности и отказоустойчивости DNS-сервиса. Если один из узлов системы по той или иной причине выйдет из строя, это совершенно не скажется на работе системы в целом: вся нагрузка будет перераспределена по другим серверам.

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

    В-третьих, с помощью Anycast можно решить и некоторые проблемы безопасности. Построенная на основе Anycast система устойчива к ddos-атакам: их можно нейтрализовать путем локализации на единичных узлах и ограничения области воздействия. Стойкость системы при увеличении числа запросов можно увеличить за счет простого масштабирования с распределением нагрузки. При компрометации одного из узлов он вполне может быть отключен, а его нагрузка будет распределена по остальным элементам системы.

    Точки присутствия


    Наши NS-серверы расположены в трех городах России (Санкт-Петербург, Москва, Екатеринбург), а также в странах Европы и Америки. Точки присутствия обозначены на представленной ниже карте.



    Заключение


    Использование технологии Anycast повышает уровень надежности, отказоустойчивости и безопасности DNS-системы. Мы уже приступили к реализации целого ряда нововведений на основе этой технологии.

    Так, в ближайшее время нашим клиентам будут доступны услуги по различным видам балансировки на основе DNS. В панели управления доменами можно будет указывать IP-адреса, на которые будут отправляться запросы в зависимости от географической локализации. Это даст нашим клиентам возможность более гибко распределять запросы своих пользователей.

    Планируются и другие нововведения, о которых мы расскажем в следующих публикациях.
    Selectel
    97,00
    ИТ-инфраструктура для бизнеса
    Поделиться публикацией

    Похожие публикации

    Комментарии 33

      –1
      Первая картинка должна иметь надпись 60 на номере трассы. Шар, красный бмв с белым пятном на капоте!
        +6
        Трасса №53, а не №60 не просто так.
          +3
          Именно. Наверное намёк на аналог AWS Route 53 сервис.
            0
            del
              +5
              Намек на порт DNS.
            +1
            На багажнике же пятно.
              +18
              вы еще скажите, что там динозавра быть не должно
              0
              Мастер может оставаться на моём сервере, а ваши ДНСы только как слейвы?
                0
                Нет, на данный момент такой функционал не планируется.
                0
                Также давно используем этот принцип работы.
                Скажу только что на нем работают некоторые из корневых DNS-серверов.
                Это по большей части и спасает всю систему от глобального DDos.
                  0
                  Некоторые? Да почти все
                  0
                  Без DNSSEC не интересно.
                    +1
                    DNSSEC в планах есть. Однако на данный момент самая большая сложность не в том чтобы подписать зону, а в том что у большинства отечественных пользователей рекурсоры провайдеров и их дешёвые роутеры не поддерживают DNSSEC.

                    Также есть крайне сложный вопрос: делегировать подпись dns-провайдеру (т.е. ключи будут находиться не только у владельца зоны) или загрузить файл с уже самостоятельно подписанной зоной в панель управления хостера?

                    Первый метод удобен, но второй способ гарантирует что никто кроме Вас не сможет изменить и подписать записи зоны. Лично я выбрал бы второй, но что делать если мне захочеться/нужно воспользоваться услугами хостера для фэйловера на уровне DNS или для балансировки нагрузки по географическому местоположению?
                      0
                      Я вам скажу как представитель международного регистратора поддерживающего DNSSEC.
                      Сам DNSSEC никому не интересен кроме как поиграться.
                      Он сейчас также всем нужен как и IPv6 в 2000 году.

                      У меня стоит plugin к браузеру проверяющий DNSSEC только потому что я его внедрял и лень его удалять.
                      Аудитория пользователей таких плагинов стремится к нулю, а ничем другим сейчас проверка не делается.

                      В любом случае, как правильно заметил clickfreak, отдавать свои ключи на сторону это нужно быть «очень умным».
                        0
                        Не слыхали про 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 позволит размещать уже подписанную зону без хранения ключей.
                          +2
                          Какой процент использования этой технологии?
                          Какая в ней востребованность?
                          Понятно что может десяток тысяч гиков начал это использовать и пытаться придумать ей применение.
                          Но ради этой кучки смысла внедрять технологию(совсем не простую в массовой реализации) смысла нет.
                          Это банально не принесет никаких бенефитов компании.

                          Я бы DANE не доверял по определению.
                          Нет авторитетного поручителя, каждый желающий может сделать себе сертификат который ничего не подтверждает.
                          Да здравствует фишинг и фрауд!
                          Выключу в браузере как только выкатят в апдейте.

                          А регистратору я доверяю потому что он связан договорами с администраторами зоны.
                          Потому что он застрахован минимум на 1кк$ по требованию ICANN.
                          А что меня защитит от утечки ключей DNS-хостинга?
                          Кто потом будет доказывать что их слили, а не медвед украл?
                            +2
                            В современных условиях, когда паранойя 2012 года выглядит как беспечность 2013 года, доверять любым централизованным системам нельзя. Нельзя доверять никакой системе криптографии, которая полагается на то, что некоторое юрлицо по каким-то там выдуманным основаниям не отдаст свой самый ценный и самый закрытый ключ очередному несуществующему агентству.

                            Как только мы получаем в криптосхеме «огранизация, владеющая закрытым ключом», мы смело можем предполагать, что у Евы есть полный и стопроцентный доступ к этому ключу.

                            Любая криптосхема, которая не делает этого допущения — фиговый листочек.
                              +2
                              На данный момент суть не в том что DNSSEC плохой и нам не нравится. Дело в востребованности со стороны клиентов. Как бы печально это ни звучало, но если я сейчас ради 2,5 пользователей проделаю, хоть и интересную, но трудоёмкую работу… тогда все остальные более востребованные фичи клиентам придёться ждать гораздо дольше.

                              SSHFP чтобы не отвечать yes

                              Сначала пользователь должен сделать соответствующую RR, что может занять больше времени. Как много новых пользователей ходит по ssh на этот сервер, где они не набирают 'yes'? Или вы всегда подключаетесь с разных машин где не сохранены отпечатки?

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

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

                              Договор, а вообще я не доверяю, но не делать же своего регистратора ради своих доменов?

                              Если не хотите доверять ключи, пусть провайдер DNS позволит размещать уже подписанную зону без хранения ключей.

                              Этот вариант точно будет реализован. Есть также проблема введения новых географических узлов в случае использования клиентом функционала балансировки по маршрутизации или фэйловера на уровне DNS: клиенту на своей стороне каждый раз нужно будет подписывать зону во всех возможных вариантах.
                          0
                          Интересно услышать как вы внедряете, а не сам факт. хочется больше техн деталей.
                          Как сам процесс происходит, какие проблемы возникают.
                            +1
                            Процесс добавления ноды происходит достаточно просто — установка системы, накатывание своей обвязки для управления, запуск репликации и мониторнга. Самый интересный этап — начало анонсирования, в эти моменты я держал пальцы скрещенными чтобы запросы распределялись между нодами равномерно и следуя хоть какой-то логике.

                            Самое сложное — это сделать так чтобы запросы приходили туда куда они должны приходить с наименьшими задержками, а не как хотят операторы, желающие урвать денег побольше, наплевав на своих пользователей (есть у нас в России, запросы из Хабаровска уходили в Киев мимо Екатеринбурга, СПб и Москвы). Основной метод исправления — prepend'ы на анонсах, главное не переборщить.
                              0
                              Какой DNS-сервер используете?
                            +1
                            Как процесс происходит я иногда слышу. Звучит это не всегда лестно в адрес авторов разнообразного ПО, периодическим обсуждением трёхзначных RFC, уходящих во времена, когда они писались для DOD (Department of Defense USA) и прочим ужасом, который сопровождает человека, который решил задаться вопросом о том, какие символы и в каком комплекте могут быть в поле SOA.
                            +2
                            Любопытно, как вы анонсируете в глобальный BGP индивидуальные IP адреса ваших ns серверов? Все что мельче /24 обычно фильтруют.
                              +4
                              Решение было тяжёлым, но по-другому реализовать попросту нельзя. На благое дело были выделены две /24 сети.
                              –1
                              Любопытно, как вы анонсируете в глобальный BGP индивидуальные IP адреса ваших ns серверов? Все что мельче /24 обычно фильтруют.
                                0
                                На самом деле было бы интересно почитать про «накатывание своей обвязки для управления, запуск репликации и мониторнга». Тут не обойтись без дополнительного сервера расположенного у провайдера, анонсирующего ваши две подсети.
                                  +1
                                  Безусловно, в каждой географической точке расположены выделенные серверы, которые и обрабатывают клиентские запросы. Серверы держат с операторами BGP-сессии, что позволяет нам самостоятельно манипулировать анонсами. Должен отметить при таком раскладе очень удобно проводить обслуживание:
                                  1. Прекращаем анонсировать сеть, которую может затронуть работами — запросы в течение максимум минуты распределяются по другим географически распределённым узлам. Для клиентов это почти незаметно, единственный побочный эффект — небольшое увеличение времени ответа за счёт увеличения расстояния до ближайшего доступного узла.
                                  2. Проводим необходимые работы.
                                  3. Проверяем что всё в порядке и узел отвечает на все запросы корректно.
                                  4. Начинаем анонсировать сеть. Запросы на узел начинают идти в течение 10 секунд.

                                  В качестве инструмента автоматизации используется Ansible. Работает через ssh и не требует на удалённом узле установки каких-либо дополнительных пакетов, кроме питона, который как правило уже есть в минимально установленной ОС. На обновление узла уходит около минуты — основное время это ожидание когда разойдётся информация по маршрутизаторам провайдеров и прекратятся DNS-запросы.

                                  Для мониторинга и статистики DNS-запросов используется самописаная система. Да, мы знаем какие записи доменов спрашивали, сколько раз и когда. При большом желании можем даже сказать кто именно (как правило это рекурсоры провайдеров пользователей, что не удивительно). Также мы знаем какие RR-записи спрашивают, но наши пользователи их по какой-либо причине не прописали (самая распространённая отсутствующая — AAAA-запись, т.к. рекурсоры спрашивают её в первую очередь).
                                    0
                                    Безусловно, в каждой географической точке расположены выделенные серверы, которые и обрабатывают клиентские запросы.

                                    Это я прекрасно понимаю, однажды меня заинтересовала anycast тема, в результате написал вот это.
                                    Интересно было как вы решили проблему подключения к интерфейсу управления конкретного сервера, так как для управления вам нужен не любой, а именно конкретный сервер. На сколько я понимаю по вашему ответу, на каждом из серверов по 2 сетевые карты (IP адреса в разных подсетях) первая для управления — IP из подсети провайдера на площадке которого расположен сервер, вторая — отвечает на DNS запросы и анонсирует свою подсеть/24 в BGP. Ну, и наверное, на каждом из серверов есть статический маршрут до подсети из которой производится управление через первую сетевую карту.
                                    Изначально мне представилась не самая правильная схема с дополнительным сервером, расположенным «топологически близко» к обоим серверам, через который осуществляется доступ на управление через IP адреса из подсети анонсируемой в BGP, поэтому и задал вопрос.

                                      0
                                      На самом деле проблем с подключением никаких нет и всё может работать через один сетевой интерфейс сервера, т. к. в плане настройки в ОС anycast IP-адрес ничем не отличается от IP-адреса для управления. Основная разница «снаружи»: маршруты для первого могут вести на разное географически распределённое оборудование, а для второго — только на конкретный сервер. Ну а анонсы можно запускать через этот же сетевой интерфейс, с адресами интерфейса они по сути не связаны.
                                  0
                                  промазал с веткой, del
                                    0
                                    Поздравляю компанию и ее пользователей с прекрасным начинанием, внедрение 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)». Следуя формальной логике получается что первые четыре имени это один и тот же физический сервер. Наверное это конфигурационная ошибка и физически сервера все же разные?
                                      0
                                      1) Да.
                                      2) Скиньте, пожалуйста, в личку IP-адрес с которого отправлялись запросы и, желательно, Ваше географическое местоположение. Также такая ситуация может быть во время работ, либо в результате фейловера.

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое