Тема с SDN похоже больше волнует облачных операторов. В традиционных операторах связи мысль о централизации CP на мой взгляд вызывает «тихий ужас». Чем больше оператор связи, тем сильнее в нем идея — «не складывать все яйца в одну корзину». Если централизованный CP в какой то момент поведет себя неправильно — потеряем всю сеть.
Другое дело централизованная конфигурация услуг, с высоким уровнем абстракции. Это действительно привлекательная идея. Есть и соответствующее ПО для этого, например Tail-F NCS.
Разные Etag для одинаковых объектов с разных узлов CDN на одиночного клиента в рамках одиночной сессии конечно не влияют. Но, если оператор доступа в Интернет использует «прозрачные http кеши» то, если не исключать использование Etag в кеш-индексе, то образуются дубликаты объектов.
А можно вопрос про Yandex CDN?
Почему для одинаковых объектов с разных узлов CDN выдается разных Etag?
Пример для файла /browser/update/prtnrs/yandex_s_1700_12508.exe
На узле download.cdn.yandex.net.cache-default05h.cdn.yandex.net Etag — 3737429142
А на узле download.cdn.yandex.net.cache-default03h.cdn.yandex.net Etag — 4275026038
Более того, именно так и необходимо делать, раз контент не уникальный для каждого клиента. Во многих регионах у провайдеров используются решения по кешированию http, в силу ограниченной емкости внешних каналов. Много где еще используются спутниковые каналы.
По мотивам той, старой ошибки в DNS у Касперского:
1) Домен kaspersky.com делегирован на авторитативных DNS серверах так и самой Лаборатории Касперского, так и на авторитативных DNS серверах ЗАО «Макомнет». Другими словами, чтобы глобально навредить Касперскому необходимо и достаточно скомпрометировать стороннюю вообщем то организацию. Вроде бы мелочь и даже не ошибка в чистом виде, но выглядит на мой взгляд странно, так как в явном виде оставлен вектор атаки, который можно было закрыть;
2) Домен geo.kaspersky.com делегирован на авторитативных DNS серверах, физически расположенных исключительно за пределами РФ с круговой сетевой задержкой из Москвы от 60 до 140+ миллисекунд. Вроде бы тоже не страшно, но «долго» отвечающие авторитативные DNS сервера повышают вероятность удачной DNS Cache Poisoning атаки против кеширующих DNS серверов российских ISP.
Перечисленное не является ошибками в явном виде, они в некотором виде спорные, больше похожи на паранойю. Но Лаборатория Каперского работает на поле информационной безопасности и учитывая это, мне все же кажется что это ляпы, которых быть не должно. Особенно первый пункт.
В апреле 2011 я находил потенциальную уязвимость у Касперского, которая заключалась в том, что на авторитативных DNS серверах в зоне geo.kaspersky.com была ошибка:
$dig ns geo.kaspersky.com @ns1.kasperskylabs.net.
;; QUESTION SECTION:
;geo.kaspersky.com. IN NS
;; AUTHORITY SECTION:
geo.kaspersky.com. 3600 IN NS geons6.kaspersky-labs.com.
geo.kaspersky.com. 3600 IN NS geons3.kaspersky-labs.com.
geo.kaspersky.com. 3600 IN NS geons4.kaspersky-labs.com.
geo.kaspersky.com. 3600 IN NS geons2.kaspersky-labs.com.
geo.kaspersky.com. 3600 IN NS geons1.kaspersky-labs.com.
geo.kaspersky.com. 3600 IN NS geons5.kaspersky-kabs.com.
Обратите внимание на последнюю запись. Домен kaspersky-kabs.com был свободен для регистрации. Его можно было зарегистрировать и поднять DNS сервер с именем geons5.kaspersky-kabs.com.
Все авторитативные DNS сервера домена geo.kaspersky-labs.com находились за пределами РФ. Если фэйковый DNS сервер был бы размещен в РФ, поближе по сетевой задержке к кеширующим серверам основных ISP, то, довольно быстро, большая часть клиентов запрашивала бы информацию именно на нем.
Написал им — откликнулись очень быстро, чуть больше часа и оперативно исправили.
К чему я это пишу? Наверное к тому, что нет идеальных поставщиков ПО, которые не допускают совсем никаких ошибок.
Более чем уверен, что если бы того копнул их поглубже — нашел бы еще что-нибудь. Но не стал этого делать, так как времени тогда (да и сейчас) на это было не найти, а они в свою очередь позабавили тем, что прислали в качестве благодарности футболку, стилизованную под Че Гевару, но с Евгением Касперским в главной роли =)
Что то мне подсказывает, что немецкий Hetzner радуется нашему законотворчеству и потирает руки, в ожидании новых русских клиентов, коих у него и так немало.
Поздравляю компанию и ее пользователей с прекрасным начинанием, внедрение 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)». Следуя формальной логике получается что первые четыре имени это один и тот же физический сервер. Наверное это конфигурационная ошибка и физически сервера все же разные?
Я три месяца отбивался от настойчивых звонков из RT.
Сначала уговаривали, что дескать и Интернет будет быстрее и связь лучше. Потом угрожали, что старую станцию скоро отключат. Потом пытались изобразить, что дескать плохо меня слышат, что связь плохая и что ее надо срочно менять. Просто детский сад какой то.
И так и не ответили на вопрос, а что если случился пожар или надо вызвать скорую, а новая телефония не работает, из-за того что в доме нет электричества.
Теперь не звонят. Видимо дошло, что я ушлый абонент и своего мнения не изменю. И пока не изменят Закон о Связи, у них не получится меня убедить, что я должен согласиться на новую услугу более низкого потребительского качества, чем у старой услуги.
То что не было подобных сообщений позволяет предположить, что ситуация заштатная и раскрытие информации по ней приведет к большим репутационным потерям, чем полное молчание. Примеры:
— какой то из важных компонентов системы не был продублирован или отсутствует зип на складе и нет договоренности с поставщиками оборудования о оперативной замене вышедшего из строя оборудования;
— нагрузка на оборудование превышало допустимую и это привело при сбое одного из компонентов перегрузку других частей системы;
— серьезная ошибка в собственном коде;
— инцидент информационной безопасности.
Не будем гадать на кофейной гуще, если компания раскроет информацию, даже несмотря на явный негатив со стороны клиентов, ей можно будет больше доверять чем сейчас. Раскрытие информации повышает ответственность. Не раскроет — лишняя причина не доверять ей.
Не могу согласиться с тем, что если за сутки информации нет — то надо сразу делать какие то выводы.
Для разбора полетов, выявление корневой причины сбоя и его описания требуется время. Специалисты которые могут описать произошедшее сейчас могут быть заняты самой аварией. И собственно одно описание причин аварии недостаточно. К нему принято прикладывать описание мер по недопущению подобных аварий в будущем.
Надеюсь, что компания публично опубликует причины сбоя. В противном случае как можно доверять их сервису? Ведь если не опубликуют — причина сбоя «облака» может быть заложена в его дизайне и сбой может повториться.
Еще немного критики: если ваш DNS сервис рассчитан в том числе и на российскую аудиторию, то как вы объясните, что нет ни одного сервера на территории РФ? Это явно не способствует низким задержкам для российских пользователей.
Есть серьезные сомнения, что ваш сервис действительно полностью совместим с RFC. Могу навскидку привести пару примеров.
Пример #1:
Запрос к доменному имени, которого нет на вашем сервере приводит к ответу NOERROR, вместо положенного в таких случаях REFUSED, если у вас домена нет или SERVFAIL, если есть но данные в нем недоступны по каким то причинам. Такое поведение чревато проблемами, при переносе DNS зон к вам или от вам.
Диагностика:
Пример #2:
Запрос NS к доменному имени отдает ненужные данные SOA в дополнительной секции. К этому большинство резолверов отнесутся толерантно, но все равно как то не красиво.
Диагностика:
$ dig +norecurse ns couchness.com. @ns1.couchness.com.
; <<>> DiG 9.6-ESV-R4-P2 <<>> +norecurse ns couchness.com. @ns1.couchness.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15646
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 5
;; QUESTION SECTION:
;couchness.com. IN NS
;; ANSWER SECTION:
couchness.com. 600 IN NS ns1.couchness.com.
couchness.com. 600 IN NS ns2.couchness.com.
;; ADDITIONAL SECTION:
ns2.couchness.com. 600 IN A 159.253.141.127
ns1.couchness.com. 600 IN SOA ns1.couchness.com. admin.couchness.com. 2011101610 86400 7200 36000 172800
ns2.couchness.com. 600 IN SOA ns1.couchness.com. admin.couchness.com. 2011101610 86400 7200 36000 172800
ns1.couchness.com. 600 IN A 178.63.65.11
ns1.couchness.com. 600 IN A 174.37.204.91
;; Query time: 54 msec
;; SERVER: 178.63.65.11#53(178.63.65.11)
;; WHEN: Sun Mar 4 20:10:25 2012
;; MSG SIZE rcvd: 193
Фокус статьи — телеком компании. У больших из них как правило есть в наличии много устаревшего, унаследованного серверного оборудования. И как правило возникает соблазн использовать какой нибудь SUN Fire V120 в качестве кеширующего dns сервера. На хорошо настроенном ПО такой сервер сможет без особых проблем обслуживать несколько тысяч dns запросов в секунды, при максимальной утилизации центрального процессора. Вопрос в том, что текущие скорости подключения клиентов измеряются в некоторых случаях в десятки мегабит. И проблемные клиенты время от времени генерируют паразитную нагрузк на dns, за счет ошибочной конфигурации в своих LAN. В моей практике встречались ситуации, когда «плохой» клиент генерил до 5000 запросов в секунду. Пара таких клиентов легко «укладывают» подобный сервер.
Например, прямо сейчас в компании, на которую я работаю, на наши кеширующие dns-сервера льется поток от одного из клиентов в 1400 запросов в секунду вида «PTR 105.1.168.192.in-addr.arpa.» Так-как мощность нашего оборудования избыточна — это не содает нам никаких проблем.
На мой взгляд использование современного оборудования на стороне провайдера в какой то степени гарантируют, что он выдержит ненормальную активность каждого единичного клиента.
Утвержение насчет кеша проверено практикой. Увеличение кеша до 1024Мб дает пару-тройку процентов увеличения эффективности кеша, с ростом нагрузки на процессор. Это практически не завязано на конкретные реализации DNS серверов.
На мой взгляд дело не в том, что 100Мбит при нормальной эксплуатации нужно обязательно заполнять, а в том, что если сервер может прокачать более 100Мбит — то ему необходимо предоставить такую возможность. Сценарии когда это может понадобиться: DDoS, вирусная активность.
Хранение авторитативных зон на кеширующем сервере плохо по нескольким причинам:
Если у вас была прописана авторитативная зона для клиента, а клиент тихо переделегировал свой домен на другие dns-сервера — то у вас либо должно быть разработано средство оперативного мониторинга для таких ситуаций, либо узнаете об этом от других клиентов, которые будут получать с вашего кеширующего сервера неправильные записи;
Более простая конфигурация сервисов. Меньше возможностей совершить конфигурационные ошибки;
Изменение векторов атаки. Например если идет атака на авторитативные сервера, то она не затронет кеширующие сервера;
Возможность увеличивать мощность обоих сервисов независимо друг от друга;
Возможность использовать ПО, которое наиболее отвечает текущей задаче. Например на авторитативных использовать ISC Bind, на кеширующих PowerDNS Recursor.
Резюме — при разделении авторитативного и рекурсивного сервиса появляется больше гибкости.
Другое дело централизованная конфигурация услуг, с высоким уровнем абстракции. Это действительно привлекательная идея. Есть и соответствующее ПО для этого, например Tail-F NCS.
Для IPTV? Чтобы картинка не разваливалась слишком.
Почему для одинаковых объектов с разных узлов CDN выдается разных Etag?
Пример для файла /browser/update/prtnrs/yandex_s_1700_12508.exe
На узле download.cdn.yandex.net.cache-default05h.cdn.yandex.net Etag — 3737429142
А на узле download.cdn.yandex.net.cache-default03h.cdn.yandex.net Etag — 4275026038
1) Домен kaspersky.com делегирован на авторитативных DNS серверах так и самой Лаборатории Касперского, так и на авторитативных DNS серверах ЗАО «Макомнет». Другими словами, чтобы глобально навредить Касперскому необходимо и достаточно скомпрометировать стороннюю вообщем то организацию. Вроде бы мелочь и даже не ошибка в чистом виде, но выглядит на мой взгляд странно, так как в явном виде оставлен вектор атаки, который можно было закрыть;
2) Домен geo.kaspersky.com делегирован на авторитативных DNS серверах, физически расположенных исключительно за пределами РФ с круговой сетевой задержкой из Москвы от 60 до 140+ миллисекунд. Вроде бы тоже не страшно, но «долго» отвечающие авторитативные DNS сервера повышают вероятность удачной DNS Cache Poisoning атаки против кеширующих DNS серверов российских ISP.
Перечисленное не является ошибками в явном виде, они в некотором виде спорные, больше похожи на паранойю. Но Лаборатория Каперского работает на поле информационной безопасности и учитывая это, мне все же кажется что это ляпы, которых быть не должно. Особенно первый пункт.
Обратите внимание на последнюю запись. Домен kaspersky-kabs.com был свободен для регистрации. Его можно было зарегистрировать и поднять DNS сервер с именем geons5.kaspersky-kabs.com.
Все авторитативные DNS сервера домена geo.kaspersky-labs.com находились за пределами РФ. Если фэйковый DNS сервер был бы размещен в РФ, поближе по сетевой задержке к кеширующим серверам основных ISP, то, довольно быстро, большая часть клиентов запрашивала бы информацию именно на нем.
Написал им — откликнулись очень быстро, чуть больше часа и оперативно исправили.
К чему я это пишу? Наверное к тому, что нет идеальных поставщиков ПО, которые не допускают совсем никаких ошибок.
Более чем уверен, что если бы того копнул их поглубже — нашел бы еще что-нибудь. Но не стал этого делать, так как времени тогда (да и сейчас) на это было не найти, а они в свою очередь позабавили тем, что прислали в качестве благодарности футболку, стилизованную под Че Гевару, но с Евгением Касперским в главной роли =)
Есть пара технических вопросов:
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:
Запрос к доменному имени, которого нет на вашем сервере приводит к ответу NOERROR, вместо положенного в таких случаях REFUSED, если у вас домена нет или SERVFAIL, если есть но данные в нем недоступны по каким то причинам. Такое поведение чревато проблемами, при переносе DNS зон к вам или от вам.
Диагностика:
Пример #2:
Запрос NS к доменному имени отдает ненужные данные SOA в дополнительной секции. К этому большинство резолверов отнесутся толерантно, но все равно как то не красиво.
Диагностика:
Например, прямо сейчас в компании, на которую я работаю, на наши кеширующие dns-сервера льется поток от одного из клиентов в 1400 запросов в секунду вида «PTR 105.1.168.192.in-addr.arpa.» Так-как мощность нашего оборудования избыточна — это не содает нам никаких проблем.
На мой взгляд использование современного оборудования на стороне провайдера в какой то степени гарантируют, что он выдержит ненормальную активность каждого единичного клиента.
Утвержение насчет кеша проверено практикой. Увеличение кеша до 1024Мб дает пару-тройку процентов увеличения эффективности кеша, с ростом нагрузки на процессор. Это практически не завязано на конкретные реализации DNS серверов.
Хранение авторитативных зон на кеширующем сервере плохо по нескольким причинам:
Резюме — при разделении авторитативного и рекурсивного сервиса появляется больше гибкости.