The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Организация Linux Foundation представила DNS-сервер CoreDNS 1.0.0

04.12.2017 22:57

Организация Linux Foundation опубликовала значительный выпуск DNS-сервера CoreDNS 1.0.0, написанного на языке Go и построенного с использованием наработок проекта Caddy. CoreDNS может применяться в качестве авторитетного, кэширующего или рекурсивного DNS-сервера, предоставляя возможности, достаточные для работы в качестве замены BIND 9, Knot, NSD или PowerDNS. Сервер развивается в направлении максимального упрощения настройки и обеспечения гибкости в реализации задуманных решений. Код распространяется под лицензией Apache 2.0.

Все этапы обработки данных DNS можно контролировать и при необходимости расширять функциональность через плагины. Более того, сам по себе CoreDNS предствляет набор плагинов, в которые вынесены как основные возможности, связанные с 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 также добавлена порция дополнительных возможностей для Kubernetes, отсутствующих в kube-dns, таких как фильтрация записей по метке или пространству имён, режим верификации pod-ов, получение данных через endpoint_pod_names, реализация поиска специфичных для пространств имён путей на стороне сервера, возможность создания собственных DNS-записей.

  1. Главная ссылка к новости (https://www.linuxfoundation.or...)
  2. OpenNews: Доступен HTTP-сервер Caddy 0.9
  3. OpenNews: Релиз DNS-сервера BIND 9.11, перешедшего на новую лицензию
  4. OpenNews: Релиз DNS-сервера NSD 4.0
  5. OpenNews: Выпуск DNS-сервера Knot DNS 2.2
  6. OpenNews: Релиз распределенной системы хранения конфигурации etcd 3.2
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/47674-dns
Ключевые слова: dns, coredns
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (39) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, pavlinux (ok), 23:33, 04/12/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Сегодня прям какой-то день анонсов ДНС серверов.
     
     
  • 2.3, Аноним (-), 23:57, 04/12/2017 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Неделя DNS, популяция DNS-серверов выросла вдвое.
     
     
  • 3.5, pavlinux (ok), 01:56, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Да, DNS надо продвигать в массы, а то пойди яблочники до сих пор ipшники руками вбивают.
     
     
  • 4.8, Аноним (-), 02:48, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    У них же этот как его, Bonjour. Я всегда подозревал что французы - утонченные извращенцы.
     
     
  • 5.13, pavlinux (ok), 03:51, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > У них же этот как его, Bonjour. Я всегда подозревал что французы

    REQUEST("мусьё, силь ву пле муа ВэКашеку.com")

     
  • 3.22, Аноним (-), 09:39, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Скоро DNS по популярности догонят медиаплейеры :)
     

  • 1.4, xm (ok), 00:10, 05/12/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > поддерживается только NSEC

    В общем, ещё пилить и пилить.

     
  • 1.9, Sw00p aka Jerom (?), 03:13, 05/12/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >>Например, при использовании в кластере из 5000 серверов с нагрузкой 18 тысяч DNS-запросов в секунду

    это нагрузка ?

     
     
  • 2.10, pavlinux (ok), 03:19, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    и не говори, лет 20 назад на Pentium 133/64Мб апач столько отрабатывал.
    А эта ...бень - CoreDNS (written in Go), на один dns-запрос потребляет 73 Мб ОЗУ, :рукалицо:
     
     
  • 3.11, Sw00p aka Jerom (?), 03:28, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    тот же bind в 2010 40к держать мог )

    пс: https://www.dns-oarc.net/files/workshop-201005/MartinHaller-OARC.pdf

     
     
  • 4.12, pavlinux (ok), 03:40, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > тот же bind в 2010 40к держать мог )

    Сейчас оптимизация - это докупка РАМы, SSD иль сразу ещё одну ноду в кластер.

     
  • 4.15, пох (?), 05:03, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Если ты разуешь глазки и посмотришь на графики по собственной ссылке, то они "почему-то" в основном обрываются на восьмой секунде линейного теста (~18k, но реакция уже в этот момент была нестабильной, то есть вряд ли бы он проработал с такой нагрузкой долго). А если долистаешь аж до графика latency, то увидишь прекрасное - bind сперва стал тормозить, а потом вовсе навернулся и перестал отвечать очень близко к восьмой секунде, поэтому дальше и не меряли (cpu кончылся, вах).
    Надо сказать, что первым склеил ласты (и вообще с самого начала давал безобразную задержку) всеми любимый powerdns, а до 40 доехал только ripe'овый nsd, причем, судя по очень малому росту задержек и линейному - cpu, он-то мог бы и дальше продолжать.

    в качестве оправдания bind'а - тест синтетический, это не kubernetes'овые ноды, которые делают реальные запросы о реальных хостах (и, надо думать, рекурсивные), это тест authoritative зоны с безумным конфигом (не 5000, а Zone-file 550000 delegated domains (includes 100000 IDN name)
    - то есть актуально только для root и gtld.

     
     
  • 5.17, angra (ok), 06:10, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > в качестве оправдания bind'а - тест синтетический

    На практике все еще хуже. На большом количестве реальных зон бинду становилось плохо уже на этапе их загрузки. А nsd справляется без проблем.


     
     
  • 6.20, пох (?), 09:35, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> в качестве оправдания bind'а - тест синтетический
    > На практике все еще хуже. На большом количестве реальных зон бинду становилось
    > плохо уже на этапе их загрузки. А nsd справляется без проблем.

    этап загрузки - банальная линейная обработка. А у nsd она вынесена в отдельный компилирующий код, который точно так же тормозит, но на этапе еще до загрузки. При этом добавляется новая грабля - ты не можешь быть уверен, что db соотвествует текстовому конфигу и вынужден это место тщательно огораживать.
    Возможно, опять же, gtld оно и надо. Владельцам кластера из 5000 нод - не знаю, не пробовал. При 1000+ реальных хостов с сотнями authoritative на каждый и еще по мелочи - ничего ужасного с bind не происходит. А перезагружать его все равно нельзя, может лечь прод.
    Времена, когда еще можно было отключать dns для перезагрузки, остались в 90х годах вовсе не потому, что он долго запускается.

     
     
  • 7.27, xm (ok), 12:55, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > что db соотвествует текстовому конфигу

    Откровенно говоря, сами файлы зон, в при нормальном раскладе, меняются нечасто. А при изменении не впадлу сделать и nsd-control reload my.domain Домены же добавляются и вовсе редко. Соответственно NSD и принял схему их предзагрузки в RAM и отдачи уже оттуда. И она, как вы верно подметили, прекрасно работает.

     
  • 7.32, PnDx (ok), 16:59, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это у вас что-то с топологией не то. Перезагрузка одной ноды — вполне штатная операция. В особенности, с учётом "протечек" bind в некоторых сценариях.

    * Если требуется непрерывная доступность операций записи, может потребоваться мультимастер. Например, тот же bind9 с бэкэндами в ldap. Или тот же pdns, воткнутый во что-нибудь m-m. При заявленном в посте выше профиле, запись вполне себе прокачает что bind что pdns. Ну а чтение всё равно слейвы обслуживают (надеюсь).

     
     
  • 8.37, пох (?), 19:34, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    не для кластеров, лепящих 18 s и да, оно ж еще и регистрироваться в этот dns ле... текст свёрнут, показать
     
  • 5.33, pavlinux (ok), 17:24, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    5000 нод, кластер! 5000, Карл!

    18000/5000 = 3.600 запроса в сек. на одну ноду!!! :)

     
     
  • 6.38, Moomintroll (ok), 19:39, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > 18000/5000 = 3.600 запроса в сек. на одну ноду!!! :)

    3.6 - ваще не много

     
  • 6.39, пох (?), 19:40, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > 5000 нод, кластер! 5000, Карл!

    еще один  нифига не понял о чем речь
    Кластер о котором речь - ни разу не для dns'ов, это dns специально для обслуживания того кластера.

    И да, каждый элемет за каким-то хером рожает по 3.5 запроса в секунду (и то, скорее всего, только пока кое-как работает, а когда ляпнется - это ж контейнеры, они всегда ляпаются - то и 33 сгенерит)
    "оно так работает".

     
  • 3.14, angra (ok), 03:54, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > и не говори, лет 20 назад на Pentium 133/64Мб апач столько отрабатывал.

    Ох, уж эти сказки, ох, уж эти сказочники.

    > А эта ...бень - CoreDNS (written in Go), на один dns-запрос потребляет 73 Мб ОЗУ

    Если прочитать внимательно, то 73 метра это не на один запрос, а всего. Если предположить, что при 18k rps на каждый запрос уходило в среднем 100ms, то это около 40k памяти на запрос.

     
     
  • 4.23, Michael Shigorin (ok), 09:42, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Ох[B],[/B] уж эти сказки, ох[B],[/B] уж эти сказочники.

    Из уважения: две запятые из трёх были лишние, берегитесь сезонной малвари псевдограмотности.

     
  • 2.16, пох (?), 05:07, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>>Например, при использовании в кластере из 5000 серверов с нагрузкой 18 тысяч DNS-запросов в секунду
    > это нагрузка ?

    какого размера у тебя кластер? Дай угадаю - никакого.
    Да, это нагрузка.
    (правда, непонятно, откуда берущаяся и что они все забыли в dns - вероятно, очередной синтетический тест)

     
     
  • 3.19, Аноним (-), 08:25, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >непонятно, откуда берущаяся

    Service discovery через DNS

     
     
  • 4.21, пох (?), 09:37, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >>непонятно, откуда берущаяся
    > Service discovery через DNS

    18/s ? Хрена себе, оно так работает?

     
  • 3.25, Анонин (?), 10:42, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Такая нагрузка возникает из-за того, что записи имеет TTL 0 - обычная практика для service discovery.
    В итоге как только система оркестрации замечает, что контейнер не проходит health check проверку, дается команда DNS  серверу исключить dns запись (тип AAA) об этом контейнере.

     
     
  • 4.29, пох (?), 13:32, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну то есть в кластере из 5000 nodes (заметим, не серверов, а контейнеров всего-то навсего - читай 5000 процессов не считая мелких сервисных) 18 раз в секунду какой-нибудь да оказывается дохлым? ;-)

    Не то чтобы я особенно удивлен...

     
     
  • 5.30, Sw00p aka Jerom (?), 14:31, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Учитывая особенности днс нейм серверов, кешей и ттл лучше уж сравнивать рекурсоры и количество клиентов за ними.
     
     
  • 6.36, пох (?), 19:29, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    дружище, ты разговариваешь с воображаемым другом. Уже третий коммент не в тему.
    Ты явно нихрена не понял, о чем вообще речь.

     
     
  • 7.42, Sw00p aka Jerom (?), 00:06, 06/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    речь в коментах как минимум идёт о производительностисего поделия в качестве днс нейм сервера и его производительности. Если речь идёт о кластере и хер пойми каком кластере и нафига там днс то возникает ещё куча других вопросов. Сервис дискавери на базе днс в кластере ? вы чё серьёзно ?
     
     
  • 8.43, пох (?), 15:47, 06/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    нет c ... текст свёрнут, показать
     
     
  • 9.44, Sw00p aka Jerom (?), 16:12, 06/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    на нет, спору нет ц ... текст свёрнут, показать
     
  • 5.31, Анонин (?), 16:42, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    ну вообщем, да)
    Но во первых у dns спрашивают не конкретный контейнер, а AAA запись сервиса в которой ip:port контейнера + адреса меняются по правилам round-robin, вероятность попасть на выпавший контейнер минимальна.
    Вот если у Вас 5001 )))
     
     
  • 6.34, Аноним (-), 18:25, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > вообщем

    Гасстгелять!

     
  • 3.26, Sw00p aka Jerom (?), 12:11, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Dns-у кластер не нужен.
    У меня 4 ноды, и почти 1к зон. Нагрузка в среднем 500qps на ноду, в пиках до 5к qps регистрировал.
     
     
  • 4.28, xm (ok), 12:58, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Dns-у кластер не нужен.

    вот соглашусь
    http://freedns.afraid.org/stats/

     

  • 1.35, Синтоловая Базука (?), 19:22, 05/12/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Чем это может быть полезно для домохозяйки, использующей Acrylic DNS как кеширующий DNS и как замену hosts с поддержкой масок, под офтопик?
     
     
  • 2.40, пох (?), 19:42, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Чем это может быть полезно для домохозяйки, использующей Acrylic DNS как кеширующий
    > DNS и как замену hosts с поддержкой масок, под офтопик?

    под офтопиком прекрасный собственный dns, домохозяйке ничего другого не требуется.
    Он в 2016-м году даже view научился. (правда, это, наверное, последнее что от него нужно)

     
     
  • 3.41, Синтоловая Базука (?), 19:49, 05/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А оно умеет сразу несколько днс опрашивать? А маски поддерживает? Про семерочку вопрос, не про серверную ось.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру