Plusieurs registres de noms de domaine proposent des mises à jour presque en temps réel. Comment réalisent-ils cela ?
Traditionnellement, les
On peut douter de l'intérêt d'un tel service : j'avoue ne pas
comprendre pourquoi on ne peut pas attendre six ou douze heures pour avoir
son nom de domaine mais certains semblent estimer qu'ils mourront dans
d'atroces souffrances si l'Internet ne s'adapte pas immédiatement à
leurs désirs. Alors, voyons les techniques possibles (je ne sais pas
comment fait
Il y en a deux : mettre à jour le serveur DNS dynamiquement ou bien
faire s'appuyer le serveur sur une
La première possibilité est donc d'utiliser les mises à jour dynamiques
du DNS, décrites dans le
L'autre solution repose sur la
On peut utiliser le traditionnel logiciel
L'autre serveur de noms en logiciel libre qui peut utiliser une
base de données est
Comparons la configuration d'un tel registre en utilisant une base
log_connections = on
log_disconnections = on
log_duration = on
log_statement = 'all'
log_hostname = on
Les requêtes SQL envoyées par le serveur de noms apparaitront
alors dans le journal du SGBD. Une fois les tests effectués, il vaut mieux débrayer cet
enregistrement, très coûteux en performances et en place disque.
BIND-DLZ peut utiliser le modèle de données qu'on veut, puisque
l'administrateur système définit les requêtes
CREATE TABLE DNS_Records (
zone TEXT NOT NULL,
host TEXT NOT NULL, -- Should be named "domain", probably
ttl INTEGER DEFAULT 60,
type TEXT NOT NULL CONSTRAINT Supported_types CHECK (type IN ('SOA', 'NS', 'A', 'AAAA', 'MX')),
mx_priority INTEGER,
contact TEXT,
serial INTEGER,
refresh INTEGER,
retry INTEGER,
expire INTEGER,
minimum INTEGER,
data TEXT NOT NULL
);
INSERT INTO DNS_Records (zone, host, type, data) VALUES ('example', 'ns1.nic',
'A', '192.0.2.1');
INSERT INTO DNS_Records (zone, host, type, data) VALUES ('example', 'ns1.nic',
'AAAA', '2001:DB8::1035:1');
INSERT INTO DNS_Records (zone, host, type, contact, serial, refresh, retry, expire, minimum,
data) VALUES
('example', '@', 'SOA', 'me.nic', 2007011710, 300, 60, 86400,
10, 'ns1.nic');
INSERT INTO DNS_Records (zone, host, type, mx_priority, data)
VALUES ('example', '@',
'MX', 10, 'mail.mypostfix.com');
Notez que certains champs (comme mx_priority ou expire) n'ont de sens
que pour certains types d'enregistrement DNS.
Avec cette base, je peux configurer BIND. DLZ va remplacer certains
jetons comme %zone% par leur valeur au moment de la requête (si je
demande des informations sur
dlz "PostgreSQL zone" {
database "postgres 2
{dbname=registry-bind}
{SELECT zone FROM dns_records WHERE zone = '%zone%'}
{SELECT ttl, type, mx_priority,
case WHEN lower(type)='txt' then '\"' || data || '\"' else data end
FROM dns_records WHERE zone = '%zone%' AND host = '%record%'
AND NOT (type = 'SOA' OR type = 'NS')}
{SELECT ttl, type, mx_priority, data, contact, serial, refresh, retry, expire,
minimum FROM dns_records WHERE zone = '%zone%' and (type = 'SOA' or type='NS')}
{SELECT ttl, type, mx_priority, data, contact, serial, refresh, retry, expire,
minimum FROM dns_records WHERE zone = '%zone%'}
{}";
};
Une fois BIND lancé avec cette configuration, tout marche :
>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52332
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
...
;; AUTHORITY SECTION:
example. 10 IN SOA ns1.nic.example. me.nic.example. 2007011710 300 60 86400 10
]]>
Merveille de la mise à jour en temps réel, si je fais un INSERT SQL,
je vois le résultat de suite :
% dig +short @localhost AAAA www.foobar.example.
%
registry-bind=> INSERT INTO DNS_Records (zone, host, type, data)
VALUES ('example', 'www.foobar', 'AAAA',
'2001:DB8::3330:128');
INSERT 0 1
% dig +short @localhost AAAA www.foobar.example.
2001:db8::3330:128
DLZ ne semble pas avoir de
Contrairement à DLZ,
CREATE TABLE domains (
id SERIAL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
master VARCHAR(20) 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(6) DEFAULT NULL,
content VARCHAR(255) DEFAULT NULL,
ttl INT DEFAULT NULL,
prio INT DEFAULT NULL,
change_date INT DEFAULT NULL,
CONSTRAINT domain_exists
FOREIGN KEY(domain_id) REFERENCES domains(id)
ON DELETE CASCADE
);
puis nous la peuplons :
INSERT INTO domains (name, type) VALUES ('example', 'NATIVE');
INSERT INTO records (domain_id, name, content, type,ttl,prio)
VALUES (1,'example','ns1.nic.example me.nic.example
2007011701', 'SOA',86400,NULL);
INSERT INTO records (domain_id, name, content, type,ttl,prio)
VALUES (1,'ns1.nic.example','192.0.2.1','A',120,NULL);
INSERT INTO records (domain_id, name, content, type,ttl,prio)
VALUES (1,'ns1.nic.example','2001:DB8::1035:1','AAAA',120,NULL);
Il reste à configurer PowerDNS pour utiliser cette base :
launch=gpgsql
gpgsql-user=registry
gpgsql-dbname=registry-pdns
Nous pouvons alors faire les mêmes tests qu'avec BIND-DLZ et obtenir, logiquement, les mêmes résultats.
Contrairement à DLZ, PowerDNS a un
Les vrais essais comparatifs de performance sont prévus mais pas encore réalisés.