Записи в DNS из NetXMS

в 17:48, , рубрики: DNS, NetXMS, powerdns, мониторинг сети, Сетевые технологии, системное администрирование, метки: , , ,

Некоторое время назад наша группа инженеров плотно подсела на систему мониторинга NetXMS. Киллер-фичей оказалась графическая конcоль:

image

Ничего настолько же наглядного и удобного (да, это очень субъективный критерий) в знакомых нам OpenNMS и Zabbix нет и близко. Систему мониторинга стало возможно использовать не просто как механизм оповещений о возникающих проблемах, а в первую очередь для анализа текущего состояния сети.

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

Действительно, какой смысл для каждого из нескольких сотен хостов заводить соответствующие записи A и PTR? Пусть мы не слишком напрягались, всего лишь редактируя файл /etc/hosts для dnsmasq, однако можно ведь избежать и этой совершенно ненужной работы.

Мы выбрали PostgreSQL в качестве СУБД для NetXMS, соответственно нам потребовался DNS-сервер, умеющий доставать как минимум A и PTR из PostgreSQL. Сходу нашлись следующие варианты:

  • Dynamically Loadable Zones для BIND
  • Generic PgSQL backend для PowerDNS
  • Относительная экзотика — реализации DNS-серверов на perl или python, специально предназначенные для расширения собственными обработчиками, к этой же категории можно отнести PipeBackend и RemoteBackend для PowerDNS

Слишком экзотитческие решения мы отбросили, к bind у нас иррациональное отвращение, поэтому остался PowerDNS. В его конфигурационый потребовалось добавить:

load-modules=gpgsql
launch=gpgsql
gpgsql-host=nxhost
gpgsql-dbname=nxdb
gpgsql-user=nxreader
gpgsql-password=nxreaderpwd
recursor=8.8.8.8

PowerDNS ожидает увидеть в БД nxdb следующие таблицы:

CREATE TABLE domains (
    id              SERIAL PRIMARY KEY,
    name            VARCHAR(255) NOT NULL,
    master          VARCHAR(128) DEFAULT NULL,
    last_check      INT DEFAULT NULL,
    type            VARCHAR(6) NOT NULL,
    notified_serial INT DEFAULT NULL, 
    account         VARCHAR(40) DEFAULT NULL
);
  
CREATE TABLE records (
    id              SERIAL PRIMARY KEY,
    domain_id       INT DEFAULT NULL,
    name            VARCHAR(255) DEFAULT NULL,
    type            VARCHAR(10) DEFAULT NULL,
    content         VARCHAR(65535) DEFAULT NULL,
    ttl             INT DEFAULT NULL,
    prio            INT DEFAULT NULL,
    change_date     INT DEFAULT NULL
);

Разумеется, таких таблиц там нет, но вместо них есть следующее:

nxdb=> SELECT id, name, primary_ip, last_modified FROM nodes INNER JOIN object_properties ON id = object_id;
  id  |          name          |   primary_ip    | last_modified 
------+------------------------+-----------------+---------------
    1 | ns                      | 10.1.1.1        |    1376221181

Поэтому требуемые таблицы легко заменяются представлениями:

CREATE OR REPLACE VIEW domains AS
    SELECT
        0::INT AS id,
        'domain.local'::TEXT AS name,
        NULL::TEXT AS master,
        NULL::INT as last_check,
        'NATIVE'::TEXT as type,
        NULL::INT as notified_serial,
        NULL::TEXT as account;

CREATE OR REPLACE VIEW records AS
    SELECT
        0::INT AS id,
        0 AS domain_id,
       'domain.local' AS name,
       'SOA'::TEXT AS type,
       'ns.domain.local'::TEXT AS content,
        0 AS ttl,
        NULL::INT AS prio,
        NULL::TEXT AS change_date
    UNION
    SELECT
        id,
        0 AS domain_id,
        LOWER(name) AS name,
        'A'::TEXT AS type,
        primary_ip::TEXT AS content,
        0 AS ttl,
        NULL::INT AS prio,
        last_modified::TEXT AS change_date
    FROM nodes
        INNER JOIN object_properties ON id = object_id;

Результат:

$ nslookup 
> ns
Server:         10.1.1.1
Address:        10.1.1.1#53

Name:   ns.domain.local
Address: 10.1.1.1

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

CREATE OR REPLACE VIEW domains AS
    SELECT
        0::INT AS id,
        'domain.local'::TEXT AS name,
        NULL::TEXT AS master,
        NULL::INT as last_check,
        'NATIVE'::TEXT as type,
        NULL::INT as notified_serial,
        NULL::TEXT as account;

CREATE OR REPLACE VIEW records AS
    SELECT
        0::INT AS id,
        0 AS domain_id,
       'domain.local' AS name,
       'SOA'::TEXT AS type,
       'ns.domain.local'::TEXT AS content,
        0 AS ttl,
        NULL::INT AS prio,
        NULL::TEXT AS change_date
    UNION
    SELECT
        id,
        0 AS domain_id,
        LOWER(name) AS name,
        'A'::TEXT AS type,
        primary_ip::TEXT AS content,
        0 AS ttl,
        NULL::INT AS prio,
        last_modified::TEXT AS change_date
    FROM nodes
        INNER JOIN object_properties ON id = object_id
    UNION
    SELECT
        0::INT AS id,
        0 AS domain_id,
        'in-addr.arpa' AS name,
        'SOA'::TEXT AS type,
        'ns.domain.local'::TEXT AS content,
        0 AS ttl,
        NULL::INT AS prio,
        NULL::TEXT AS change_date
    UNION
    SELECT
        interfaces.id,
        0 AS domain_id,
        reverse_address(interfaces.ip_addr::INET) AS name,
        'PTR'::TEXT AS type,
        (object_properties.name||'.'||interfaces.description)::TEXT AS content,
        0 AS ttl,
        NULL::INT AS prio,
        last_modified::TEXT AS change_date
    FROM interfaces
        INNER JOIN nodes on nodes.id = interfaces.node_id
        INNER JOIN object_properties on nodes.id = object_id;

Результат:

$ nslookup 
> 10.7.1.1
Server:         10.1.1.1
Address:        10.1.1.1#53

1.1.1.10.in-addr.arpa   name = ns.eth0.

В коде упоминается функция reverse_address, ее реализация выглядит так:

CREATE OR REPLACE FUNCTION reverse_address(addr inet)
RETURNS text 
AS
$t$
DECLARE
    mask integer;
    parts text[];
    part text;
    retval text;
    rounds integer;
    host text;
BEGIN
    retval := '';
    rounds := 0;
    mask := masklen(addr);
    host := host(addr);
    IF (family(addr) = 4) THEN
        IF (mask < 8) THEN
            rounds := 4;
        ELSIF (mask < 16) THEN
            rounds := 3;
        ELSIF (mask < 24) THEN
            rounds := 2;
        ELSIF (mask < 32) THEN
            rounds := 1;
        END IF;
        FOREACH part in ARRAY regexp_split_to_array(host, '.') LOOP
            rounds := rounds + 1;
            IF (rounds <= 4) THEN
                retval := part || '.' || retval;
            END IF;
        END LOOP;
        RETURN retval || 'in-addr.arpa';
    ELSE
        RETURN 'ip6.arpa';
    END IF;
END;
$t$
LANGUAGE 'plpgsql'
IMMUTABLE;

И это единственная часть реализации, специфичная для PostgreSQL. Все остальное можно сделать аналогичным образом на других СУБД, поддерживаемых NetXMS и PowerDNS.

Напоследок о производительности: это решение, конечно, не годится для публичных DNS-серверов. Для внутреннего употребления — вполне. При первом выполнении все запросы укладываются в 100 msec, затем работает кэш. Есть поле для оптимизации с использованием параметров gpgsql-*-query вместо представлений, но пока нам хватает.

Автор: evnp

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js