Организация Linux Foundation опубликовала (https://www.linuxfoundation.org/press-release/cloud-native-c.../) значительный выпуск DNS-сервера CoreDNS 1.0.0 (https://coredns.io/), написанного на языке Go и построенного с использованием наработок проекта Caddy (https://www.opennet.ru/opennews/art.shtml?num=44817). CoreDNS может применяться в качестве авторитетного, кэширующего или рекурсивного DNS-сервера, предоставляя возможности, достаточные для работы в качестве замены BIND 9, Knot, NSD или PowerDNS. Сервер развивается в направлении максимального упрощения настройки и обеспечения гибкости в реализации задуманных решений. Код распространяется (https://github.com/coredns/coredns) под лицензией Apache 2.0.Все этапы обработки данных DNS можно контролировать и при необходимости расширять функциональность через плагины. Более того, сам по себе CoreDNS предствляет набор плагинов (https://coredns.io/plugins/), в которые вынесены как основные возможности, связанные с DNS (обработка файлов зонами, поддержание кэша, DNSSEC), так и дополнительные функции, такие как обнаружение сервисов Kubernetes, накопление метрик для системы мониторинга Prometheus, поддержка фильтров для перезаписи запросов, интеграция с системой хранения конфигурации etcd, балансировка нагрузки и т.п. DNS-запросы могут приниматься как через традиционные UDP/TCP, так и при помощи TLS (RFC 7858) и gRPC.
Основные возможности:
- Обработка данных доменных зон из файлов, как для DNS, так и для DNSSEC (поддерживается только NSEC);
- Получение данных доменных зон от первичных DNS-серверов (работа в роли вторичного DNS-сервера) с передачей информации посредством AXFR;
- Формирование цифровых подписей для данных DNS-зон на лету (DNSSEC);
- Балансировка нагрузки на несколько серверов;
- Поддержка трансфера зон (работа в роли первичного DNS-сервера);
- Автоматическая загрузка файлов с данными DNS-зон с диска;
- Работа в роли кэширующего сервера;
- Средства для проверки работоспособности узлов (плагин health);
- Поддержка использования etcd в качестве бэкенда и работы в роли замены SkyDNS;
- Поддержка использования k8s (kubernetes);
- Поддержка функционирования в роли прокси для перенаправления запросов на другие серверы (рекурсивный сервер);
- Предоставления метрик для систем мониторинга;
- Предоставление логов запросов и ошибок;
- Поддержка DNS-класса CH, используемого в Chaosnet;
- Наличие средств для профилирования работы;
- Возможности перезаписи запросов (qtype, qclass и qname);
- Работа в роли сервиса whoami.В новом выпуске значительно улучшены возможности для интеграции с платформой оркестровки контейнеров Kubernetes - CoreDNS теперь может применяться для организации работы службы DNS в качестве полноценной замены kube-dns. При этом CoreDNS демонстрирует более высокую производительность и достаточно скромные требования к ресурсам. Например, при использовании в кластере из 5000 серверов с нагрузкой 18 тысяч DNS-запросов в секунду, CoreDNS потребляет около 73 Мб ОЗУ, в то время как kube-dns расходует 97 Мб ОЗУ и способен обработать только 7 тысяч DNS-запросов в секунду.
В CoreDNS также добавлена порция дополнительных возможностей для Kubernete, отсутствующих в kube-dns, таких как фильтрация записей по метке или пространству имён, режим верификации pod-ов, получение данных через endpoint_pod_names, реализация поиска специфичных для пространств имён путей на стороне сервера, возможность создания собственных DNS-записей (https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/).URL: https://www.linuxfoundation.org/press-release/cloud-native-c.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=47674
Сегодня прям какой-то день анонсов ДНС серверов.
Неделя DNS, популяция DNS-серверов выросла вдвое.
Да, DNS надо продвигать в массы, а то пойди яблочники до сих пор ipшники руками вбивают.
У них же этот как его, Bonjour. Я всегда подозревал что французы - утонченные извращенцы.
> У них же этот как его, Bonjour. Я всегда подозревал что французыREQUEST("мусьё, силь ву пле муа ВэКашеку.com")
Скоро DNS по популярности догонят медиаплейеры :)
> поддерживается только NSECВ общем, ещё пилить и пилить.
>>Например, при использовании в кластере из 5000 серверов с нагрузкой 18 тысяч DNS-запросов в секундуэто нагрузка ?
и не говори, лет 20 назад на Pentium 133/64Мб апач столько отрабатывал.
А эта ...бень - CoreDNS (written in Go), на один dns-запрос потребляет 73 Мб ОЗУ, :рукалицо:
тот же bind в 2010 40к держать мог )пс: https://www.dns-oarc.net/files/workshop-201005/MartinHaller-...
> тот же bind в 2010 40к держать мог )Сейчас оптимизация - это докупка РАМы, SSD иль сразу ещё одну ноду в кластер.
Если ты разуешь глазки и посмотришь на графики по собственной ссылке, то они "почему-то" в основном обрываются на восьмой секунде линейного теста (~18k, но реакция уже в этот момент была нестабильной, то есть вряд ли бы он проработал с такой нагрузкой долго). А если долистаешь аж до графика latency, то увидишь прекрасное - bind сперва стал тормозить, а потом вовсе навернулся и перестал отвечать очень близко к восьмой секунде, поэтому дальше и не меряли (cpu кончылся, вах).
Надо сказать, что первым склеил ласты (и вообще с самого начала давал безобразную задержку) всеми любимый powerdns, а до 40 доехал только ripe'овый nsd, причем, судя по очень малому росту задержек и линейному - cpu, он-то мог бы и дальше продолжать.в качестве оправдания bind'а - тест синтетический, это не kubernetes'овые ноды, которые делают реальные запросы о реальных хостах (и, надо думать, рекурсивные), это тест authoritative зоны с безумным конфигом (не 5000, а Zone-file 550000 delegated domains (includes 100000 IDN name)
- то есть актуально только для root и gtld.
> в качестве оправдания bind'а - тест синтетическийНа практике все еще хуже. На большом количестве реальных зон бинду становилось плохо уже на этапе их загрузки. А nsd справляется без проблем.
>> в качестве оправдания bind'а - тест синтетический
> На практике все еще хуже. На большом количестве реальных зон бинду становилось
> плохо уже на этапе их загрузки. А nsd справляется без проблем.этап загрузки - банальная линейная обработка. А у nsd она вынесена в отдельный компилирующий код, который точно так же тормозит, но на этапе еще до загрузки. При этом добавляется новая грабля - ты не можешь быть уверен, что db соотвествует текстовому конфигу и вынужден это место тщательно огораживать.
Возможно, опять же, gtld оно и надо. Владельцам кластера из 5000 нод - не знаю, не пробовал. При 1000+ реальных хостов с сотнями authoritative на каждый и еще по мелочи - ничего ужасного с bind не происходит. А перезагружать его все равно нельзя, может лечь прод.
Времена, когда еще можно было отключать dns для перезагрузки, остались в 90х годах вовсе не потому, что он долго запускается.
> что db соотвествует текстовому конфигуОткровенно говоря, сами файлы зон, в при нормальном раскладе, меняются нечасто. А при изменении не впадлу сделать и nsd-control reload my.domain Домены же добавляются и вовсе редко. Соответственно NSD и принял схему их предзагрузки в RAM и отдачи уже оттуда. И она, как вы верно подметили, прекрасно работает.
Это у вас что-то с топологией не то. Перезагрузка одной ноды — вполне штатная операция. В особенности, с учётом "протечек" bind в некоторых сценариях.* Если требуется непрерывная доступность операций записи, может потребоваться мультимастер. Например, тот же bind9 с бэкэндами в ldap. Или тот же pdns, воткнутый во что-нибудь m-m. При заявленном в посте выше профиле, запись вполне себе прокачает что bind что pdns. Ну а чтение всё равно слейвы обслуживают (надеюсь).
> Это у вас что-то с топологией не то. Перезагрузка одной ноды —
> вполне штатная операция.не для кластеров, лепящих 18/s
(и да, оно ж еще и регистрироваться в этот dns лезет - то есть, и на запись тоже, и нет, вряд ли его можно уговорить регать сервис в одном месте, а за информацией ходить в другой)в общем, я, наверное, ничего не хочу больше знать про kubernetes и его кластеры.
5000 нод, кластер! 5000, Карл!18000/5000 = 3.600 запроса в сек. на одну ноду!!! :)
> 18000/5000 = 3.600 запроса в сек. на одну ноду!!! :)3.6 - ваще не много
> 5000 нод, кластер! 5000, Карл!еще один нифига не понял о чем речь
Кластер о котором речь - ни разу не для dns'ов, это dns специально для обслуживания того кластера.И да, каждый элемет за каким-то хером рожает по 3.5 запроса в секунду (и то, скорее всего, только пока кое-как работает, а когда ляпнется - это ж контейнеры, они всегда ляпаются - то и 33 сгенерит)
"оно так работает".
> и не говори, лет 20 назад на Pentium 133/64Мб апач столько отрабатывал.Ох, уж эти сказки, ох, уж эти сказочники.
> А эта ...бень - CoreDNS (written in Go), на один dns-запрос потребляет 73 Мб ОЗУ
Если прочитать внимательно, то 73 метра это не на один запрос, а всего. Если предположить, что при 18k rps на каждый запрос уходило в среднем 100ms, то это около 40k памяти на запрос.
> Ох, уж эти сказки, ох, уж эти сказочники.Из уважения: две запятые из трёх были лишние, берегитесь сезонной малвари псевдограмотности.
>>>Например, при использовании в кластере из 5000 серверов с нагрузкой 18 тысяч DNS-запросов в секунду
> это нагрузка ?какого размера у тебя кластер? Дай угадаю - никакого.
Да, это нагрузка.
(правда, непонятно, откуда берущаяся и что они все забыли в dns - вероятно, очередной синтетический тест)
>непонятно, откуда берущаясяService discovery через DNS
>>непонятно, откуда берущаяся
> Service discovery через DNS18/s ? Хрена себе, оно так работает?
Такая нагрузка возникает из-за того, что записи имеет TTL 0 - обычная практика для service discovery.
В итоге как только система оркестрации замечает, что контейнер не проходит health check проверку, дается команда DNS серверу исключить dns запись (тип AAA) об этом контейнере.
ну то есть в кластере из 5000 nodes (заметим, не серверов, а контейнеров всего-то навсего - читай 5000 процессов не считая мелких сервисных) 18 раз в секунду какой-нибудь да оказывается дохлым? ;-)Не то чтобы я особенно удивлен...
Учитывая особенности днс нейм серверов, кешей и ттл лучше уж сравнивать рекурсоры и количество клиентов за ними.
дружище, ты разговариваешь с воображаемым другом. Уже третий коммент не в тему.
Ты явно нихрена не понял, о чем вообще речь.
речь в коментах как минимум идёт о производительностисего поделия в качестве днс нейм сервера и его производительности. Если речь идёт о кластере и хер пойми каком кластере и нафига там днс то возникает ещё куча других вопросов. Сервис дискавери на базе днс в кластере ? вы чё серьёзно ?
нет. (c)
на нет, спору нет (ц)
ну вообщем, да)
Но во первых у dns спрашивают не конкретный контейнер, а AAA запись сервиса в которой ip:port контейнера + адреса меняются по правилам round-robin, вероятность попасть на выпавший контейнер минимальна.
Вот если у Вас 5001 )))
> вообщемГасстгелять!
Dns-у кластер не нужен.
У меня 4 ноды, и почти 1к зон. Нагрузка в среднем 500qps на ноду, в пиках до 5к qps регистрировал.
> Dns-у кластер не нужен.вот соглашусь
http://freedns.afraid.org/stats/
Чем это может быть полезно для домохозяйки, использующей Acrylic DNS как кеширующий DNS и как замену hosts с поддержкой масок, под офтопик?
> Чем это может быть полезно для домохозяйки, использующей Acrylic DNS как кеширующий
> DNS и как замену hosts с поддержкой масок, под офтопик?под офтопиком прекрасный собственный dns, домохозяйке ничего другого не требуется.
Он в 2016-м году даже view научился. (правда, это, наверное, последнее что от него нужно)
А оно умеет сразу несколько днс опрашивать? А маски поддерживает? Про семерочку вопрос, не про серверную ось.