Il y a deux situations de vulnérabilité : lors d'un dialogue entre serveur pour le transfert de zones et l'interrogation d'un serveur par un resolveur.
C'est une chaîne de confiance, comme toujours en sécurité, qui remonte par construction du fonctionnement du serveur de noms interrogé par votre application jusqu'aux serveurs racines.

La version ISC du programme BIND utilise deux stratégies différentes.
Dans le cas d'un dialogie de serveur à serveur il s'agit d'un mécanisme nommé TSIG/TKEY.
Dans le deuxième cas d'une interrogation par un resolveur il s'agit de DNSSEC.

TSIG/TKEY utilisent une clef symétrique, donc partagée par les deux serveurs (cette clef leur est connue par des mécanismes différents).
DNSSEC utilise un mécanisme basé sur le principe d'un échange de clefs publiques.

Outre le fait d'obtenir une information erronée on peut avoir des attaques de type “déni de services“.

1 - TSIG/TKEY pour sécuriser les transferts

L'usage d'une clef symétrique indique qu'il s'agit d'un secret partagé entre 2 serveurs. Cette même clef sert au chiffrement et au déchiffrement des données. Le bon usage veut que l'on dédie une clef à un certain type de transaction (par exemple le transfert d'une zone) entre deux serveurs donnés. Cette manière de procéder se traduit rapidement par un grand nombre de clefs à gérer ce qui interdit un déploiement généralisé sur l'Internet.

Pour éviter de trop longs temps de chiffrement, ce ne sont pas les données à transférer qui sont chiffrées (elles ne sont pas confidentielles), mais leur empreinte (“fingerprints”) avec un algorithme de type MD5 ou SHA1X17.

Le serveur qui reçoit un tel paquet signé, calcule l'empreinte du paquet avec le même algorithme, déchiffre celle jointe avec la clef secrète partagée et compare les deux empreintes.

L'intérêt de ces transferts signés est que les serveurs secondaires sont certains de mettre à jour leur zones avec des données qui proviennent bien du détenteur du SOA.

TSIG

TSIG comme “Transaction SIGnature” est la méthode décrite dans la RFC 2845 et basée sur l'usage d'une clef symétrique. La génération de cette clef peut être manuelle ou automatisée avec le programme “dnssec-keygen”.

La propagation de cette clef est manuelle (scp...), donc mise en place au coup par coup.

TSIG sert également à la mise à jour dynamique, la connaissance de la clef par le client sert à la fois à l'authentifier et à signer les données.

TKEY

TKEY, décrit dans la RFC 2930, rend les mêmes services que TSIG tout en évitant le transport du secret (TSIG). Cette caractéristique est basée sur le calcul la clef symétrique automatiquement avec l'algorithme de Diffie-Hellman plutôt que par un échange “manuel” X19.

Par contre, cet algorithme à base du tandem clef publique - clef privée suppose l'ajout d'un champ KEY dans les fichiers de configuration du serveur.

2 - DNSSEC pour sécuriser les interrogations

DNSSEC décrit dans la RFC 2535 permet la distribution d'une clef publique (champ KEY), la certification de l'origine des données, l'authentification des transactions (transferts, requêtes).

Mis en place, le DNSSEC permet de construire une chaîne de confiance, depuis le “top level” jusqu'au serveur interrogé par votre station de travail.

3 - Attaque DNS par amplification

Le fonctionnement repose sur UDP, protocole pour lequel l'en-tête est facilement falsifiable, notamment sur l'adresse de retour. Il est ainsi très facile d'envoyer une requête à un serveur, avec une adresse de retour qui est celle d'une machine victime plutôt que la sienne :

La machine peut recevoir un message du serveur de noms , non sollicité. Il est bien évident qu'un seul message de ce type reste sans effet, cependant la machine victime peut être submergée par un flot de réponses qui saturent complètement ses accès réseaux, c'est une une attaque DNS par amplification et qui provoque un déni de service sur le site qui la subit.