DNS

mais aussi DNSSEC, DNS CAA, DANE…

Licence Creative Commons

Domain Name System : pourquoi ?

  • Associer des noms à des adresses (passer de l'identité à l'adressage)
  • Et inversement, savoir quel nom est associé à quelle adresse

Donc en gros, c'est un annuaire…

Un système hiérarchique

  • une racine « . »
  • qui délègue les TLD, Top Level Domains (.com, .fr, etc…)
  • qui délègue à leur tour d'autres domaines…
  • la racine est connue de tous
  • la racine est le seul point de fragilité (et elle est répartie dans plusieurs pays du monde)

Zones et enregistremnts

  • chaque entrée dans l'annuaire est un Resource Record (ou RR, ou enregistrement)
  • Toutes les entrées d'un domaine (ou d'un sous-domaine) sont regroupés dans une zone
  • les zones sont facilement réplicables (totalement ou partiellement)

Quelques exemples de RR

  • SOA ou Start Of Authority
  • NS ou Name Server
  • A pour les adresses IPv4
  • AAAA pour les adresses IPv6
  • CNAME pour les alias (indirection)
  • MX ou Mail eXchange
  • TXT pour un enregistrement texte

Serveurs DNS : deux fonctions

  • Serveur faisant autorité : gérant au moins une zone ou une délégation de zone
  • Résolveur : pouvant résoudre et mettre en cache des RRs

Chemin de résolution

On cherche à résoudre l'IPv6 test.giteu.be.

La racine est déjà connue, le résolveur demande donc :


					$ dig +short @a.root-servers.net. -t ns be.
					c.ns.dns.be.
					y.ns.dns.be.
					x.ns.dns.be.
					d.ns.dns.be.
					a.ns.dns.be.
					b.ns.dns.be.
					

					$ dig +short @c.ns.dns.be. -t ns giteu.be.
					ns100.ovh.net.
					dns100.ovh.net.
					

					$ dig +short @ns100.ovh.net. -t aaaa test.giteu.be.
					2001:bc8:26c1:101:d250:99ff:fe70:ee60
					

DNSSEC

Principaux problèmes de sécurité de DNS

  • utilise majoritairement UDP (fallback en TCP si la requête est trop grosse)
  • Les résolveurs peuvent très facilement « mentir » ou manipuler les requêtes
  • On peut très facilement « empoisonner » le cache d'un résolveur
  • On ne peut pas mettre un résolveur sur chaque client (ce serait trop beaucoup trop lourd !)

Toujours un problème de confiance…

  • le client ne peut pas faire confiance au résolveur
  • le résolveur ne peut pas faire confiance au réseau

Plusieurs degrés de signature

  • Création d'un enregistrement RRSIG
  • Chaque enregistrement de la zone est signé par une ZSK Zone Signing Key
  • Cette ZSK est signée par une KSK Key Signing Key
  • L'empreinte de la KSK est stocké dans un enregistrement DS Delegation Signer du niveau supérieur dans l'aborescence
  • Cette empreinte est elle-même signée par la ZSK de la zone supérieure
  • La racine est signée par elle-même et connue de tous

DANE : DNS-based Authentication of Named Entities

  • L'idée de base est de publier les certificats ou ses signatures dans le DNS
  • Création d'un nouvel enregistrement TLSA
  • Peut aussi être associé à des services différents (comme SRV)

DANE : DNS-based Authentication of Named Entities


					_443._tcp.www.ietf.org. TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6
					_25._tcp.giteu.be. TLSA 3 1 1 9FB0AE6576BD40B4ECC4F844BD97004117AE7EA07B081D3AC864FA02AE58127C
					

DNS CAA : DNS Certificate Authority Authorization

  • Indique simplement quelle(s) autorité(s) sont autorisés pour un domaine donné
  • Nouveau RR CAA

DNS CAA : DNS Certificate Authority Authorization


					giteu.be.	IN	CAA	0 issue "letsencrypt.org"
					

Conclusion

Questions ? Suggestions ? Insultes ?