M. Andrews (ISC)S. Weiler (SPARTA)February20062006-11-032007-11-14
L'une des faiblesses les plus souvent citées du
DNS est son manque de sécurité. Pour authentifier les données servies,
le protocole DNSSEC a été développé, dans les
et suivants. Notre RFC vient d'ajouter
un nouveau type de données, pour indiquer une racine de signature
différente de la "vraie" racine. (Notez que ce RFC a ensuite été
ramené à la catégorie « Intérêt historique seulement », en novembre
2019, et que DLV est donc abandonné depuis, voir le .)
DNSSEC calque sa structure sur celle du
DNS : hiérarchique, avec une racine, gérée par
le gouvernement des États-Unis, via
l'IANA. Normalement, la racine est signée par
l'IANA, qui signe les délégations des TLD qui à
leur tour signent les délégations des titulaires de noms de
domaine. (Ces délégations apparaissent dans les enregistrements de
type DS - Delegation Signer.)
Mais cette hiérarchie pose des problèmes : que faire si
l'IANA, par exemple parce que
l'ICANN est bloquée par des problèmes
politiciens, ne veut ou ne peut pas signer la racine ? (Aujourd'hui,
la seule racine du DNS signée l'est en PGP et
par Verisign, l'opérateur à qui le gouvernement
états-unien a délégué la gestion technique de la racine. Elle est
accessible en ,
la signature étant dans le même répertoire.)
D'ou l'idée de base de DLV (DNSSEC Lookaside
Validation) : dissocier la racine du DNS et la racine de
signature DNSSEC. Avec DLV, on peut créer une racine de signature en,
par exemple, dlv.isc.org et la peupler
d'enregistrements DLV. Si les résolveurs DNS sont configurés pour les
chercher là, DNSSEC marchera bien et on aura contourné le problème
policitien.
Les enregistrements DS sont donc remplacés par des DLV, spécifiés
dans notre RFC, et qui ont exactement le même
format. BIND les met en œuvre depuis la
version 9.3.2 et 9.4.0. Voici un exemple de récupération de DLV avec dig :
> DiG 9.5.0-P2 <<>> DLV sources.org.dlv.isc.org.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30687
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;sources.org.dlv.isc.org. IN DLV
;; ANSWER SECTION:
sources.org.dlv.isc.org. 3600 IN DLV 22107 5 2 AF12A23DFBCDB5609DCEC2C2FBD3CD65AEEFE49CBE0751C65C71C983 986B7DE5
sources.org.dlv.isc.org. 3600 IN DLV 14347 3 2 0D5D5B209264BBA5EDAEC9B95843901073BF27F01702B144FFC1389D 747DAB7F
...
]]>
À noter que notre RFC normalise un format de données, pas la façon
de l'utiliser. C'est l'objet du qui, entre autres, décrit ce qui se passe si deux racines DLV coexistent,
peut-être pour des parties différentes du DNS.