Les collisions DNS opposant des espaces de noms publiques et privés sont un phénomène latent et mal connu, mais pourtant couramment rencontré. Il n’existe pas de solution technique globale (comme le masque de sous réseau IP), et il revient donc aux responsables informatiques de tenir leur écosystème privé. L’ ICANN, en collaboration avec les principaux acteurs du système DNS, a d’ailleurs mis en place une mesure d’alerte a l’attention des administrateurs. Il s’agit en effet de cette fameuse adresse IP 127.0.53.53, composée du nombre 53, par analogie au protocole DNS.
Deux TLD sur lesquels l’ICANN met l’accent (ou plutôt le point)…
Ces collisions de noms sont en effet préoccupantes pour les organismes de régulation tels que l’ICANN, mais doivent également être prises très au sérieux par les responsables SI. On parle bien de fuite DNS, pouvant mener à la divulgation d’informations sensibles. Si par exemple la machine répondant à l’adresse 127.0.53.53 venait à ouvrir ses ports, il y a fort a parier qu’elle y recevrait un torrent de données et mots de passes confidentiels provenant de réseaux privés situés aux quatre coins du monde.
Que faut il faire alors ?
Et bien on s’démerde, comme d’hab. On parle sécurité… donc on mesure le risque, et on en prend le moins possible. Tu vois le truc ?
Il faut d’abord distinguer la cause de la fuite. Ensuite les solutions peuvent être diverses selon le cas ou les systèmes utilisés.
J’ai choisi un domaine déjà délégué par l’ICANN:
La on cherche les problèmes, à moins que le réseau en question ne soit jamais relié a internet, ça ne pourra pas être propre. La seule solution serait de surcharger les serveurs racines (DNS sinkhole).
Non le mieux et de se dégoter un nom de domaine qui n’existe pas publiquement, et qui a le moins de chance possible de le devenir.
www.domainealaconquepersonnenevoudrajamais
Ce dernier est vraiment ‘secure’, mais pas facile assumer. Il existe en réalité trois TLD qui ne seront jamais délégués par l’ICANN, car trop largement utilisés dans le domaine privé.
- .corp
- .home
Le .local est envisageable car réservé, si toutefois aucun protocole DNS multicast n’est utilisé.
Pour un domaine plus personnalisé, il faudra donc naturellement vérifier qu’il n’existe pas déjà, mais aussi qu’il n’est pas en cours de négociation pour les années avenir. En effet, un domaine non déposé peut le devenir d’un jour a l’autre. C’est qui serait arrivé a de nombreuse universitées utilisant .cs (pour Computer Science), lorsque la Tchécoslovaquie a obtenu son ccTLD.
Liste des TLD actifs: https://data.iana.org/TLD/tlds-alpha-by-domain.txt
TLD en cours de traitement: https://gtldresult.icann.org/
Le .lan n’est pas déposé, le jours ou ils le mettent en alerte, 127.0.53.53 va peut être prendre un petit DDOS.
Domaine de recherche et multiples préfixes:
La c’est plus traître. Le domaine de recherche (ou DNS Search List) permet de rendre le suffix DNS implicite. Ainsi, si je demande l’adresse de ‘serveur‘, le système me résous implicitement ‘serveur.domaine‘. C’est rudement pratique, mais ça peut dérailler si l’on se met à a utiliser des noms d’hôte composés de plusieurs préfixes, ou plus concrètement d’un ou plusieurs points. ‘database.prod‘ à de forte chances de tomber en 127.0.53.53 car ‘prod’ est interprété comme un suffix.
Sous Linux, on peut toutefois palier à ce problème en éditant le fichier resolv.conf:
search domaine options ndots:2
Dans un environnement de production, la bonne pratique reste d’utiliser systématiquement des noms de domaine pleinement qualifiés (fqdn), et d’éviter les points (.) dans les noms d’hôtes, en les remplaçant par des tirets (-).
Une autre stratégie consiste a utiliser un nom de domaine publique, même en interne. Cela nécessite en revanche une configuration plus complexe au niveau DNS et/ou réseau.
[Sources]
https://www.icann.org/resources/pages/name-collision-2013-12-06-en
https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf
