Résolution de noms DNS
Au sommaire
Contexte
Le service de résolution de noms DNS est un des service de base de l'Internet. Son bon fonctionnement est vital pour les applicatifs réseaux (Web, mail, ...).
L'équipe réseau exploite et administre ce service DNS à l'échelle régionale.
Les serveurs hébergent :
- des "zones primaires" d'établissements
- des "zones secondaires", répliques de zones primaires d'établissements.
Tout établissement Lothaire souhaitant faire héberger sa "zone primaire" ou souhaitant avoir une réplique de sa "zone primaire" sur les serveurs DNS Lothaire peut en faire la demande à la permanence réseau.
Fonctionnalités
Le service DNS proposé se décompose en deux parties :
- les résolutions sur les zones pour lesquelles le serveur fait "autorité", ces résolutions sont possibles pour tous les clients (clients Lothaire et Internet)
- les résolutions "récursives", elles sont possibles uniquement pour les clients Lothaire (restriction par réseaux IP)
Ces 2 mécanismes sont assurés par des serveurs distincts.
Les résolutions de type "récursives" sont limitées aux clients Lothaire pour des raisons de sécurité (suivre ce lien qui explique pourquoi).
Les fonctionnalités DNS implémentées sont :
- service redondé (2 serveurs dédiés pour la partie autorité et plusieurs serveurs pour la partie récursive)
- support IPv4 : serveurs adressés en IPv4 et support des enregistrements "A" et "PTR" IPv4
- support IPv6 : serveurs adressés en IPv6 et support des enregistrements "AAAA"et "PTR" IPv6
- serveurs accessibles en IPv4 et IPv6 depuis tout l'Internet sur les ports 53/tcp et 53/udp
- pas de support des enregistrements automatiques
- interface de gestion du DNS, à destination des correspondants réseaux Lothaire, pour le changement d'enregistrements dans les zones primaires
Les serveurs rendant le service DNS autoritaires sont :
arcturus.ciril.fr : 193.50.27.66 - 2001:660:4503:201::66/64 orion.ciril.fr : 193.50.27.67 - 2001:660:4503:201::67/64
Le service récursif est assuré par plusieurs serveurs répartis sur le réseau Lothaire, tous accessibles par la même adresse IP (mécanisme ANYCAST) :
ns-rec.dc.univ-lorraine.fr : 193.50.27.27 - 2001:660:4503:2727::27
Ce service est à utiliser comme "serveur DNS récursif" selon la politique de "configuration des postes clients" des établissements. Si un établissement ne dispose pas de serveur DNS ou ne spécifie pas de politique spéciale, ns-rec.dc.univ-lorraine.fr peut être utilisé (demande préalable obligatoire, les autorisations d'utilisation faisant l'objet d'un filtrage).
DNSSEC : principes et avancement du déploiement
Description
DNSSEC permet de sécuriser les données échangées entre un client et un serveur en proposant des mécanismes de signatures pour la vérification de l'authenticité et de l'intégrité des données. DNSSEC n'a pas pour but de chiffrer les échanges entre les clients et les serveurs comme le proposent TSIG Transaction SIGnature ou IPsec Internet Protocol Security.
Ce que fait DNSSEC :
- vérification de l'authenticité des données
- vérification de l'intégrité des données
- vérification de l'intégrité de la "non existence" d'une donnée
- la protection contre certaines attaques, comme par exemple le cache poisoning (empoisonnement du cache).
Ce que ne fait pas DNSSEC :
- la confidentialité des échanges (cf. TSIG et IPsec)
- la protection contre des attaques de type DDoS
DNSSEC et les mécanismes associés ne sont pas nouveaux. Les premiers RFC sur le sujet datent de 2005. Seulement, la vérification des signatures des données s'appuie sur une publication des clés publiques dans l'arbre de délégation du DNS et ce en partant des serveurs racines (root servers). Malheureusement, les serveurs racines ne proposaient pas jusqu'à aujourd'hui le support de DNSSEC et de ce fait le déploiement de DNSSEC sur Internet n'était pas généralisable et n'avait que peu d'intérêt.
2010 est une année charnière pour le DNS et pour le déploiement de DNSSEC. En effet, les gestionnaires des serveurs racines se sont entendus pour mettre en oeuvre le support de DNSSEC d'ici l'été 2010. A partir de ce moment, la généralisation de DNSSEC va pouvoir s'opérer.
Au niveau d'un serveur DNS on peut distinguer deux fonctionnalités à mettre en oeuvre :
- la vérification des signatures des données lors des requêtes/réponses DNS : le client pourra alors considérer que la réponse fournie est authentifiée et intègre
- la signature des zones DNS hébergées et mise en place des clés pour la vérification des données : l'administrateur va dans ce contexte sécuriser ses informations et se prémunir contre certaines attaques DNS.
Contexte de déploiement DNSSEC sur Lothaire
Le schéma suivant illustre le positionnement des serveurs DNS régionaux (arcturus.ciril.fr et orion.ciril.fr) par rapport aux clients Lothaire et aux serveurs DNS présents sur Internet. On peut également voir où seront activées les fonctionnalités de vérification des signatures et de signature des zones hébergées.
Phase -1-
La phase 1 de mise en oeuvre d'un service de résolution de noms récursif avec vérification DNSSEC des signatures des zones interrogées ne pourra se faire qu'une fois que la totalité des serveurs racines supporteront intégralement DNSSEC.
Le calendrier de déploiement de DNSSEC au niveau de la racine est consultable ici : http://www.root-dnssec.org/
On peut donc envisager l'activation de cette fonctionnalité pour juillet/août 2010 sur les serveurs arcturus.ciril.fr et orion.ciril.fr.
Tous les serveurs racines supportent DNSSEC depuis le 15 juillet 2010. Les serveurs arcturus.ciril.fr et orion.ciril.fr vérifient depuis le lundi 19 juillet 2010 les enregistrements DNSSEC des requêtes à traiter (se reporter à la news News-20100720-0 pour l'annonce de ces changements).
Etant donné que le RIPE-NCC signe depuis 2005 ses zones inverses et qu'il met à disposition ses "Trust Anchors" (ie. les clés publiques), nous envisageons d'activer rapidement la vérification DNSSEC de ces zones.
D'autres TLD (.org, .gov, .se, ...) signent déjà leur zone et mettent à disposition les "Trust Anchors" nécessaires pour la vérification de ces signatures., nous envisageons d'activer rapidement la vérification DNSSEC de ces zones.
Phase -2-
La phase 2 de mise en oeuvre d'un service de résolution de noms faisant autorité avec signature DNSSEC des zones hébergées ne pourra se faire qu'après la phase 1 et progressivement sur chaque TLD quand les registres opérant ces TLD supporteront la mise en place dans leurs bases des clés publiques des sous-zones déléguées.
Les deux premiers registres qui nous intéressent sont :
- l'AFNIC pour la signature des zones en ".fr"
- et le RIPE-NCC via Renater pour la signature des zones inverses
Nous n'avons pas à ce jour d'information précise sur le support de DNSSEC et les procédures d'échanges des clés publiques avec ces registres.
D'autre part, la mise en oeuvre de la signature des zones hébergées nécessite une refonte de la gestion du service DNS sur arcturus.ciril.fr et orion.ciril.fr. Ce projet est en cours.
Avancement des signatures zones en .fr et les zones inverses RIPE-NCC
Dans un premier temps les zones qui nous intéresse sont :
- les zones inverses (w.x.y.z.in-addr.arpa) sous la responsabilité du RIPE-NCC et qui sont déléguées à Renater puis à Lothaire
- les zones en .fr
étant donné que ce sont les zones les plus utilisées dans notre contexte.
Pré-requis et support réseaux/systèmes
Les serveurs DNS régionaux arcturus.ciril.fr et orion.ciril.fr supportent déjà DNSSEC mais aucune des fonctionnalités présentées ci-dessus n'a été activée. Ces fonctionnalités seront activées selon les phases -1- et -2- expliquées précédemment.
Au niveau du réseau, le déploiement de DNSSEC sur les serveurs racines dans un premier temps puis sur les autres serveurs DNS de l'Internet nécessite que les réseaux traversés supportent les échanges de paquets DNS avec l'extension DNSSEC. Le principal problème avec le déploiement de DNSSEC est l'augmentation de la taille des paquets DNS échangés entre les clients et les serveurs. Malheureusement, le support exclusif de la taille historique de 512 octets des paquets DNS échangés est encore (trop) présent dans la configuration de certains matériels réseaux de l'Internet. Cette limitation à 512 octets empêche totalement les échanges DNSSEC et donc la résolution de noms qui est le premier service utilisé par tout ordinateur ou application qui utilise Internet.
Afin de garantir le fonctionnement de DNSSEC et tout simplement celui du DNS sur Lothaire, l'équipe réseau Lothaire a validé sur l'ensemble des équipements actifs qu'elle opère que les échanges de paquets DNS d'une taille supérieure à 512 octets n'étaient pas rejetés. Les réseaux opérés par l'équipe Lothaire sont aujourd'hui compatibles avec le futur déploiement du DNSSEC. Plus précisément les réseaux et les équipements suivants ont été validés :
- les routeurs et les réseaux des sites délocalisés Lothaire
- les commutateurs/routeurs centraux et les réseaux des sites StanNet et AmpereNet
- les réseaux protégés par les modules Firewall embarqués dans les commutateurs/routeurs StanNet
- les réseaux NATés par les modules Firewall/NAT embarqués dans les commutateurs/routeurs StanNet
- les réseaux VPN proposés par les concentrateurs centraux
L'équipe réseau Lothaire invite les administrateurs de serveurs DNS et d'équipements actifs réseaux à vérifier et à valider DÈS AUJOURD'HUI le support de DNSSEC sur leurs infrastructures.
Validation du support DNSSEC et procédure de test
- Sur une machine proposant la commande dig :
- lancer la commande
dig +short rs.dns-oarc.net txt
- Vérifiez si la réponse indique plus de 1500 octets, comme ici :
"193.50.27.66 DNS reply size limit is at least 2442"
- Sur une machine proposant la commande nslookup :
- lancer la commande
nslookup -q=txt rs.dns-oarc.net
- Vérifiez si la réponse indique plus de 1500 octets, comme ici :
"193.50.27.66 DNS reply size limit is at least 2442"
- Sur une machine qui ne propose ni la commande dig, ni la commande nslookup :
- utiliser l'outil développé par le RIPE-NCC: http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues
Références
- Présentation de DNSSEC : http://fr.wikipedia.org/wiki/Domain_Name_System_Security_Extensions
- Suivi du projet de signature de la racine : http://www.root-dnssec.org/
- Annonce par l'ICANN de signature de la racine : http://www.icann.org/fr/announcements/dnssec-qaa-09oct08-fr.htm
- Recommandations de l'AFNIC : http://www.afnic.fr/actu/nouvelles/240/l-afnic-invite-les-responsables-techniques-reseaux-a-se-preparer-a-la-signature-de-la-racine-dns-en-mai-2010
- Explications du problème de la taille de 512 octets et procédure de test : http://www.bortzmeyer.org/dns-size.html
- Synthèse des serveurs racines : http://www.root-servers.org/
- Article "Sécurité du DNS et DNSSEC" par Stéphane Bortzmeyer aux JRes2009 : https://2009.jres.org/planning_files/article/pdf/5.pdf, https://2009.jres.org/planning_files/slideshow/pdf/5.pdf
- Signature des zones inverses RIPE-NCC : http://www.ripe.net/rs/reverse/dnssec