DNS - Historique des versions

Justine le 22 juin 2022 à 11:54

2022-06-22T11:54:41Z

← Version précédente		Version du 22 juin 2022 à 11:54
Ligne 1 :		Ligne 1 :
			[[Category:reseau]]
	= Introduction =		= Introduction =

Justine : /* DNSSEC */

2021-11-27T21:12:57Z

DNSSEC

← Version précédente		Version du 27 novembre 2021 à 21:12
Ligne 305 :		Ligne 305 :
	* https://berthub.eu/dnssec/		* https://berthub.eu/dnssec/
	* https://metebalci.com/blog/a-minimum-complete-tutorial-of-dnssec/		* https://metebalci.com/blog/a-minimum-complete-tutorial-of-dnssec/
			* https://wiki.debian.org/DNSSEC%20Howto%20for%20BIND%209.9+

	== Présentation ==		== Présentation ==

Justine : /* DNSSEC */

2021-11-27T21:06:29Z

DNSSEC

← Version précédente		Version du 27 novembre 2021 à 21:06
Ligne 301 :		Ligne 301 :
	= DNSSEC =		= DNSSEC =
	https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-20-fr		https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-20-fr

			== A VOIR ==
			* https://berthub.eu/dnssec/
			* https://metebalci.com/blog/a-minimum-complete-tutorial-of-dnssec/

	== Présentation ==		== Présentation ==

Justine le 23 novembre 2021 à 14:41

2021-11-23T14:41:39Z

← Version précédente		Version du 23 novembre 2021 à 14:41
Ligne 309 :		Ligne 309 :
	Chaque zone DNS a une paire de clefs. L'admin de la zone utilise la clef privée de la zone pour signer les données DNS dans la zone et générer des signatures numériques. La clef publique est publiée dans la zone même afin de pouvoir être facilement extraite. Ensuite, tout client recevant des données d'un résolveur peut aller vérifier la légitimité des données en vérifiant la signature auprès de la zone d'origine.		Chaque zone DNS a une paire de clefs. L'admin de la zone utilise la clef privée de la zone pour signer les données DNS dans la zone et générer des signatures numériques. La clef publique est publiée dans la zone même afin de pouvoir être facilement extraite. Ensuite, tout client recevant des données d'un résolveur peut aller vérifier la légitimité des données en vérifiant la signature auprès de la zone d'origine.

	[[Fichier:~~Dnssec for dummies~~.png\|cadre\|~~Un schèma~~ (très) simpliste]]
	~~Addendum : Ce n'est pas le client qui vérifie la signature, c'est le résolveur.~~		[[Fichier:Tasoeur.png\|cadre\|Schéma d'explication (très) simpliste]]

	On gagne deux fonctions avec DNSSEC :		On gagne deux fonctions avec DNSSEC :

Justine le 23 novembre 2021 à 14:29

2021-11-23T14:29:31Z

← Version précédente	Version du 23 novembre 2021 à 14:29
Ligne 298 :	Ligne 298 :



		= DNSSEC =
		https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-20-fr

		== Présentation ==
		Le protocole DNS, en lui-même, n'est pas sécurisé. Il date des années 80, alors qu'internet n'était pas ce qu'il est aujourd'hui. Quand un résolveur envoie une requête vers un serveur faisant autorité, il n'as aucun moyen de vérifier son identité ou l'authenticité de la réponse. De plus, il peut alors se retrouver à mettre une réponse erronnée en cache : l'attaquant aura alors empoisonné le cache de celui-ci.

		Des extensions de sécurité ont alors créées par l'IETF à partir des années 90, appellées DNSSEC. Ce système renforce l'authentification du DNS en utilisant des signatures numériques, sur le principe de la cryptographie à clefs publiques.

		Chaque zone DNS a une paire de clefs. L'admin de la zone utilise la clef privée de la zone pour signer les données DNS dans la zone et générer des signatures numériques. La clef publique est publiée dans la zone même afin de pouvoir être facilement extraite. Ensuite, tout client recevant des données d'un résolveur peut aller vérifier la légitimité des données en vérifiant la signature auprès de la zone d'origine.

		[[Fichier:Dnssec for dummies.png\|cadre\|Un schèma (très) simpliste]]
		Addendum : Ce n'est pas le client qui vérifie la signature, c'est le résolveur.

		On gagne deux fonctions avec DNSSEC :
		* L'authentification de l'origine des données : le résolveur peut vérifier que ses données sont les bonnes.
		* La protection de l'intégrité des données : on sait que les données n'ont pas été modifiées lors du transit puisqu'elles sont signées.

		La clef publique d'une zone est publiée : mais comment lui faire confiance ? Celle-ci est signée numériquement, elle aussi; pas par elle-même, mais par la "zone mère", soit son TLD. icann.org a une clef publique signée par .org. Ainsi, la chaîne de confiance remonte jusqu'au TLD lui-même. Le mécanisme réel est un peu plus complexe, bien sûr, mais le principe reste le même.

		Ce jeu de clefs se signant les unes les autres est appellé chaîne de confiance; la première clef de cette chaîne est appellée ancre de confiance. Généralement, un résolveur prend comme ancre de confiance la clef de la zone racine. Il peut alors construire une chaîne de confiance pour n'importe quel nom de domaine.

		DNSSEC n'est pas automatique, mais il est conseillé de le déployer. C'est très facile pour un résolveur : on a juste à lui demander de vérifier les clefs. Le déploiement sur une zone est un peu plus complexe, sans que ce soit insurmontable.

Justine le 5 décembre 2018 à 21:59

2018-12-05T21:59:22Z

Voir les modifications

Justine le 4 décembre 2018 à 00:46

2018-12-04T00:46:35Z

Voir les modifications

Justine : Page créée avec « = Introduction = L'un des protocoles les plus répandus, cela dit c'est aussi un des plus difficiles à expliquer. Il est important de savoir l'expliquer simplement à u... »

2018-12-02T00:54:28Z

Page créée avec « = Introduction = L'un des protocoles les plus répandus, cela dit c'est aussi un des plus difficiles à expliquer. Il est important de savoir l'expliquer simplement à u... »

Nouvelle page

= Introduction =

L'un des protocoles les plus répandus, cela dit c'est aussi un des plus difficiles à expliquer. Il est important de savoir l'expliquer simplement à un recruteur. De plus, il faut savoir l'expliquer à un débutant : lors d'un dépannage, si je peux expliquer simplement à la personne que je dépanne ce qu'est le DNS par exemple, elle aura plus confiance, une notion importante dans le travail d'admin S&R.

DNS signifie Domain Name System.

Le DNS est un:

*Système
**Hiérarchique
**Distribué
*A pour vocation de traduire des noms de domaine en adresse IP, pour que cela soit simple à lire pour un humain.

Les intérêts du DNS : le DNS travaille sur des noms de domaine, qui sont vecteurs d'identité sur le réseau (facebook, google, amazon...) : DNS permet de véhiculer une image de marque, les noms de domaine valent beaucoup d'argent. Il permet de se souvenir de notion complexes (@IPv4/6) et permet aussi d'éviter de devoir prévenir tout le monde lors d'un changement d'hébergeur (et donc d'adresse IP). 

Dans le passé, avant DNS, il existait un fichier HOSTS.txt, ancêtre de /etc/hosts qui contenait toutes les adresses IP et tous les noms d'hôte de tout le monde ! Il était distribué sur le réseau local par un point central.. Bien entendu, au moindre problème concernant les distributeurs de ce fichier prenait des proportions... De plus la gestion des droits sur ce fichier était compliquée. Cela prenait de plus du temps, et le versioning posait problème aussi.

DNS est défini dans les RFC882 et 882 en nov 1983. Il a par la suite été standardisé. BIND est créé en 1985. Le fichier HOSTS comptait 600 entrées en 1987, tandis que DNS en comptait 20000. DNS a pris 4 ans a être complètement déployé.

= Les noms de domaine =

Ne pas confondre nom de domaine et DNS:

*Les noms de domaine peuvent exister sans DNS : DNS n'est qu'une des implémentations techniques des noms de domaines.

Un nom de domaine:

*Est un identificateur sur le réseau (machine, équipement, société...)
*Vecteur d'identité (Marques...)
*Il y'a des règles d'obtention pour obtenir un nom de domaine : on ne peut pas avoir n'importe quel nom de domaine : il faut passer par un registrar, qui va nous louer un nom de domaine.

Un registrar est un organisme commercial ou non (eu.org). Il est habilité à délivrer des noms de domaine pour certains TLD et respecte les règles d'obtention. On peut citer : OVH, 1&1, Gandi, etc... Les règles d'obtention sont basées sur la loi du pays. 

== Aspect juridique ==

L'AFNIC est une assoc 1901 qui gère le .fr; en cas de problème, c'est elle qu'il faut contacter (cyber-squatting, par exemple), et par là même par la justice française. 

Exemple de problème qui a existé : les iles Tuvalu ont le TLD .tv, et sont gérées par la reine Elizabeth 2. Le .tv est mal géré est passe pour de la télévision : ainsi TF1 avait acheté wat.tv. Ils ont perdu ce nom de domaine temporairement en 2009, à cause de la gestion moins performante du .tv, et ne pouvaient pas contacter l'AFNIC. Cela s'est reproduit par la suite.

Il faut s'assurer de relouer les domaines avant leur expiration pour éviter les problèmes !

De la même façon, un coréen avait acheté france2/3.com et en avait fait un site x; il a demandé des millions de $.

facebook.com a été acheté 200 000$. Etc...

Le nom de domaine étant un tel identificateur, il faut vraiment TOUT faire pour ne pas le perdre : surveiller les dates de dépassement et envoyer les mails adaptés aux responsables avant, au risque d'être face à des gens qui demandent des rançons.

= Serveurs Racine =

En DNS on a la racine : le . final d'un FQDN, juste au-dessus des TLD. C'est le plus haut domaine. On a alors la notion de serveurs racine : tous les serveurs racine connaissent tous les serveurs de TLD. C'est leur utilité.

Leur objectif est de relayer les demandes vers les serveurs TLD, on les contacte quand on ne sait pas qui contacter. On peut récupérer toutes ces infos par FTP, si on veut. Les résolveurs/serveurs récursifs connaissent les serveurs de racine et leurs adresses. Un résolveur peut interroger les serveurs racine si besoin.

On devrait en fait parler d'enregistrements racine ; on a 13 enregistrements de noms dans la racine, gérés par 12 structures indépendantes. Ils vont de A.ROOT-SERVERS.NET à M.ROOT-SERVERS.NET sur 24 @IP : 13 en ipv4 et 11 en IPv6. Ces enregistrements sont connus des resolvers. Leur but est (en gros) d'être SOA sur la racine et de transférer les demandes client aux TLD.

= TLD : Top Level Domain =

Les TLD sont souvent appellés "extensions"; c'est un abus de langage.

On a une hiérarchie dans DNS:

*La racine tout en haut
*Ensuite les TLD (1er niveau TLD) ou nom de domaine de premier niveau (mais la traduction est contestée).
*Na pas dire extension : c'est du langage néophyte (un TLD n'étend rien...)

[[File:DNS1.png]]

On voit ici l'arborescence avec les TLD.

On a plusieurs types de TLD (l'aspect juridique change en fonction du pays):

*Country-Code TLD ou ccTLD: Associé à un pays, un état souverain ou un territoire indépendant: .fr, .be, .de, etc... On en compte environ 260. Des règles existent pour les ccTLD : les .fr sont accessibles aux entreprises européennes et au particuliers dans l'UE et aussi Suède, Norvège, Islande, Liechtenstein... Valable 12 mois par tacite reconduction.
*Internationalized ccTLD ou IDN ccTLD: c'est un TLD avec des caractères non latins ou latin accentué (d'autres alphabets) : mandarin, arabe, etc. En effet au début l'alphabet latin imposé posait des problèmes aux pays qui n'utilisent pas notre alphabet. Cela s'est fait suite à la menace d'une sission dans la racine de la part de la Chine.
*Generic TLD : .com, net, .edu, etc... On en a environ 300, découpés en:
**domaines génériques non commandités restreints
**domaines génériques non commandités non restreints
**domaines génériques parrainés : les STLD
*Sponsored TLD ou STLD : .catholic, .coop, .frogans, .xxx, .paris, etc. L'ICANN a ouvert les TLD à ceux qui le souhaitaient pour faire évoluer les usages. Pour chacun de ces TLD, le sponsor qui le met en place doit définir une charte avec un but et des règles pour définir à quoi sert le TLD (par exemple, .museum est réservé aux musées). Cela passe par un appel d'offre et des frais de dossier élevés. Par exemple, pour .paris il faut prouver que:
**On réside en RP
**qu'on y exerce des activités professionelles, personnelles, commerciales ou culturelle ou que
**l'on justifie de tout autre lien d'attachement direct ou indirect avec la région parisienne.
**Et d'autrezs règles...
*Reserved TLD ou RTLD :
**Pas dans les serveurs racine, et donc impossibles à contacter
**On a le .example, qui sert juste aux exemples pour documenter
**.invalid
**.localhost : éviter les conflits avec localhost
**.test pour les tests
**Non recommandés : .lan, .local, etc...
**Il faut bien songer que les TLD qui n'existent pas encore pourront exister plus tard : si ils invente le .lan, on sera dans la panade si on l'as utilisé ! Il faut éviter les TLD qui n'existent pas : dans le lan, il faut créer un sous-domaine de notre domaine local.

Pour tester un TLD, on peut faire une requête sur nic.TLD : host nic.fr, host nic.xyz, etc.

= Serveurs SOA et récursif =

== SOA ==

Cette partie est importante à maîtriser !

SOA:

*Start Of Authority
*Serveur faisant autorité sur un domaine : cela signifie que ce serveur contient la vérité sur un domaine.
*C'est le serveur SOA qu'il faut contacter pour le domaine dont il est SOA.

Si je veux contacter trois serveurs dans un domaine coucou.fr, il faut s'adresser au(x) SOA de ce domaine. Si j'achète un domaine justine.fr et que je désigne trois SOA pour ce domaine, ces informations seront enregistrées directement dans le .fr, et tout le monde saura quels serveurs détiennent la vérité sur ce nom de domaine.

En effet on peut en avoir plusieurs:

*Géré par les clients DNS
*Géré par les serveurs DNS
*Un domaine DEVRAIT avoir plusieurs SOA

On a en général un serveur primaire et un/des secondaires (Maître/esclave). Par exemple, le .fr a plusieurs soa :

*f.ext.nic.fr
*d.nic.fr
*etc...

Le ext signifie que les serveurs sont à l'extérieur (pour éviter les pannes si ils sont tous dans le même site géo. / réseau). Ici, le d.nic.fr est dans le réseau et les autres sont à l'extérieur (hors du pays, en l'occurence). Il vaut mieux déclarer IPv4 et IPv6 pour chaque SOA.

== Récursif ==

Il s'agit de serveurs résolveurs/serveurs récursifs (c'est pareil), qui interrogent les serveurs DNS pour tous les postes d'un réseau local : au lieu que chaque poste accède à tous les DNS à chaque fois en faisant la récursion lui-même, on passe par un résolveur (pour centraliser les demandes des clients) qui les résoudra. Ils sont généralement mis en place sur un LAN / réseau d'entreprise.

[[File:DNS2.png]]Ici à gauche du schéma, derrière le resolver, j'aurais des clients.

Un LAN peut avoir plusieurs récursifs:

*Répartition de charge
*Failover (mais ralentissement en cas de panne).
*Pas de synchro nécessaire.

== Recommandations ==

Sur un réseau, avec un domaine:

*Plusieurs serveurs SOA:
**Sur plusieurs sites géographiques/plusieurs OS/plusieurs logiciels
*Plusieurs resolveurs:
**Au plus proche des utilisateurs
*Resolveurs différents des SOA

 

 

 

DNS - Historique des versions

Justine le 22 juin 2022 à 11:54

Justine : /* DNSSEC */

Justine : /* DNSSEC */

Justine le 23 novembre 2021 à 14:41

Justine le 23 novembre 2021 à 14:29

Justine le 5 décembre 2018 à 21:59

Justine le 4 décembre 2018 à 00:46

Justine : Page créée avec « = Introduction = L'un des protocoles les plus répandus, cela dit c'est aussi un des plus difficiles à expliquer. Il est important de savoir l'expliquer simplement à u... »

Justine : /* DNSSEC */

Justine : /* DNSSEC */

Justine : Page créée avec « = Introduction = L'un des protocoles les plus répandus, cela dit c'est aussi un des plus difficiles à expliquer. Il est important de savoir l'expliquer simplement à u... »