Некоторое время назад наша группа инженеров плотно подсела на систему мониторинга NetXMS. Киллер-фичей оказалась графическая конcоль:
Ничего настолько же наглядного и удобного (да, это очень субъективный критерий) в знакомых нам 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