RES 203 Internet applications

Présentation au sujet: "RES 203 Internet applications"— Transcription de la présentation:

1 RES 203 Internet applications
dario.rossi Domain name system (DNS) Dario Rossi RES203 v01/2017

2 Plan Introduction L’espace de nommage DNS Base d’information du DNS
Nom et labels, Root et TLD Zones et domaines Base d’information du DNS Ressources Example de base Architecture et protocole DNS Résolution de noms Format de requetes/reponses Examples de resolution Example d’usage (et usage detournés) References Legende: le slide n’est pas objet l’examen

3 Introduction Le niveau 2 relie physiquement les équipements sur la base d’une adresse physique (MAC) Le niveau 3 relie les équipements logiquement entre eux sur la base d’une adresse logique (IP) Le niveau 4 relie les applications entre elles sur la base d’un identifiant (port) Le niveau 7, et donc les usagers, références les équipements par un nom Nom symbolique « intuitif ou facile ». Plus simple à retenir qu’une adresse Application Transport Network Data link Physical

4 Introduction Table distribué Internet, grand réseaux dynamique
Beaucoup d'adresses dans le réseau Adresses dynamiques et adresses statiques On associe aux adresses IP un nom symbolique Plus « agréable » à mémoriser qu'un numéro Les noms doivent être uniques Nécessité de tables de correspondance (exemple: /etc/host, HOST.TXT) Resolution (IP, nom) ARPANET: mis-à-jour periodique et centralisée de la base (chaque nuit), puis rediffusion à tous les hotes Probleme: Internet grandit Solution: table distribué Table distribué Extension de l’adresse à la notion de ressource Ressources correspondantes à des addresses Organisation de l’espace de nommage en domaines Chaque domaine gere ces correspondances

5 Organismes Internet Corporation for Assigned Names and Numbers (ICANN)
Assure la gestion des noms des adresses et des identifiants de ports etc. Internet Assigned Numbers Authority (IANA) Assure le travail technique de ICANs Regional Internet Registries (RIRs) Delegation du travail de IANA RFC1466 définit les règles d'allocation des adresses IP aux RIR et aux LIR RIRs APNIC (Asia Pacific Network Information Centre) ARIN (American Registry for Internet Numbers) qui a en charge les Amériques et une partie de l'Afrique subsaharienne; RIPE NCC (Réseaux IP Européens - Network Coordination Centre) qui a en charge l'Europe, le Moyen-Orient, l'ex-URSS et la partie de l'Afrique non couverte par ARIN. AfriNIC (African Regional Network Information Centre) LACNIC (Latin American and Caribbean IP address Regional Registry).

6 Domain Name System (DNS)
Les composantes du DNS Un espace de nommage Une base de données (spécification des ressources) Un protocole pour interroger la base Une architecture: resolver (client) et serveur Configuration du client et server Plusieurs RFCs décrivent l’annuaire Internet: RFC 883 et 884 ensuite 1034 et 1035 1984: Paul Mockapetris définis le DNS RFC 1032, 1033, 1034, 1035, 1101, 1122, 1123, 1183, 1713, 1794, 1912, 1995, 1996, 2010, 2136, 2137, 2181, 2308, 2317, , 2606, etc. Optional readings RFC1034 et RFC1035

7 Espace de nommage Structure d’arbre avec une racine
La racine (root) est représentée par un point « . » Un nœud représente un domaine À chaque nœud de l’arbre est associé un label Les informations associées à chaque nœud du domaine sont contenus dans une base et gérées par ce nœud (en fait, cela est simpliste… plus de details dans la suite) Chaque nœud peut avoir des fils, dont le labels doivent etre différent (pour garantir l’unicité) Label Désigné par des caracteres alphanumériques et « - » En fait, limitation de praticité, car 255 valeurs seraient possibles… mais ne sont pas sur le clavier ! La taille maximum d’un label est de 63 caractères Pas de sensibilité à la casse (case insensitive) A nouveau, pratique courante et pas limitation technologique . it fr x z y

8 Espace de nommage Nom de domaine
Concatenation de labels sur un chemin donné Séparé par des dots « . »  du point de vue des etres humains Suite de pair (longueur, label) du point de vue des messages du reseau La taille d’un nom de domaine est au maximum de 255 characterès La profondeur de l’arbre est limitée par cette taille Nom de domaine complet Fully Qualified Domain Name (FQDN ) doit etre unique dans le reseau (pas d’ambiguité dans la resolution) est composé de l’ensemble des labels d’un feuille de l’arbre jusqu’à la racine Par default, le DNS ajoute le nom de domaine locale (e.g., www deviens Le « . » finale est souvent omis (mais deviens ) Hormis la premiere, le choix des labels est laissé aux besoins des usages Le choix de est pour retrouver intuivement le nom de la machine de l’ENST qui supporte une application WEB.

9 Espace de nommage . root tld edu mil gov com net int org ch fr … ca
ddn ibm hp enst nic www www infres tsi siav rms

10 Root Root server Par definition, au plus haut de la hierarchie
points d’entrée dans le système de résolution Souvent anycast au niveau IP Ils ont un rôle de « reroutage » des résolutions Connaissent tous les autres root server Connaissent tous les TLDs [a-m].root-servers.net Essayez: dig b.root-servers.net Site de référence

11 Top-Level Domain Les Top-Level Domain (TLD): Deux types
Domaines de premier niveau (RFC1591) Connaissent tous les root server Connaissent les serveur delegués de sous-domaine Deux types ccTLD: country code TLD ex. fr, ca, ma, us, de, … gTLD: generic TLD ex. com, org, net, …+ 7 nouveaux biz, aero, name, pro, musuem, info et coop et encore récemment mobi

12 Domaine vs Zone Domains et zones
Un domain identifie une sous arborescence de l’espace de nommage (Domain = lieu topologique) Une zone contient une base avec l’ensemble des informations associées à ce nœud (Zone = borne administrative) La délégation Un nœud délégue la gestion à un nœud fils, ceci devient une zone Ce qui confère la distribution des donnés au sein du DNS Ceci permet aux TLD de deleguer toutes les nombreuses sous-zones (e.g., plusieurs millions de site.com.) Le nœud père doit être en possession des adresses où se trouvent la base d’information des fils auxquels il a delegué des zones ‘‘Glue records’’ pour eviter references circulaires dans la resolution

13 Espace de nommage Domaine fr Zone fr fr enst Zone enst edf rd prod
infres tsi siav … rms …

14 Espace de nommage Domaine= sous-arbre, lieu topologique
Zone= forme arbitraire, bornes administratives fr enst Zone enst edf Zone infres rd prod ses infres tsi siav … rms Domaine enst

15 Domaine vs Zone Zone Administré séparément.
Une zone peut être subdivisée en plusieurs zones. L'autorité d'une zone est déléguée à une personne qui est chargée de créer des serveurs de domaine Remarque: il existent des boites dont le business est de gerer des bases de donnés DNS pour des tiers À chaque fois qu'une zone est créé, L'administrateur alloue un nom à cette zone (verifié avec RIR), Notifie les adresses IP des serveurs DNS de sa zone à la zone père Les noms de machines dans cette zone sont inseré dans le database. Remarque: pour une zone on a obligatoirement un serveur primaire et un serveur secondaire. Le serveur secondaire copie la base du premier (zone transfer). La difference n’est que dans le nom, les deux serveurs sont pareils

16 Service DNS Le service principale du DNS consiste dans la resolution de noms: Associer une adresse IP à un nom Associer un nom à une adresse IP (résolution inverse) Associer un nom à une ressource La résolution de nom est basé sur un modèle client/serveur Le serveur est celui qui détient les informations Chaque serveur est autoritaire sur sa propre zone Il consulte d’autres serveurs DNS au delà du périmètre de sa zone Notion de serveur autoritaire Autoritaire: serveur responsable de l’information, concernant sa zone, qu’il est en train de communiquer (le secondaire est aussi autoritaire ) Non autoritaire: serveur qui détient l’information mais qui n’est à l’origine de celle-ci (information retenue temporairement)

17 Ressources et base d’information du DNS
La base d’information: Contient des enregistrements ou Ressources Records (RR) Un enregistrement représente une ressource de l’annuaire et une association entre plusieurs objets Enregistrement de type Start Of Authority (SOA) : indique l'autorité sur la zone. contient toutes les informations sur le domaine: le délai de mise à jour des bases de données entre serveurs de noms primaires et secondaires, le nom du responsable du site Enregistrements de type Name Server (NS) : les adresses des serveurs DNS responsables de la zone

18 Ressources et base d’information du DNS
Enregistrement de type Adresse (A , A6, AAAA): définit les noeuds fixes du réseau ceux qui ont des adresses IP statiques Enregistrements de type Mail eXchanger (MX) : Identifie les serveurs de messagerie (recepteur) Enregistrements de type Canonical Name (CNAME): définit des alias sur des noeuds existants. Enregistrement de type Pointeur (PTR): résolution de noms inverse dans (domaine in-addr.arpa.) Pour chaque RR, le DNS garde: Le nom, le type, la classe, la durée de vie, la valeur

19 Example enst.fr. IN SOA ns1.enst.fr. hstr.enst.fr. ( ; numéro de série ; rafraîchissement (REFRESH) ; nouvel essai (RETRY) ; Obsolescence (EXPIRE) 86400 ) ; TTL minimal de 1 jour enst.fr. IN NS ns1.enst.fr. ; commentaire enst.fr. IN NS ns2.enst.fr. ; enst.fr peut être ;remplacé @ IN NS ns1 IN NS ns2

20 Example ns1.enst.fr. IN A ns2.enst.fr. IN A smtp.enst.fr. IN A localhost.enst.fr. IN A www IN CNAME ns1.enst.fr. ftp IN CNAME ns2.enst.fr. enst.fr. IN MX smtp.enst.fr. in-addr.arpa. IN PTR ns1.enst.fr.

21 Architecture/Protocole DNS
Norme (assez) stable RFC 1034 : concepts et facilités du DNS RFC 1035 : spécification de l ’implémentation Protocole Paradigme client-server, fortement distribué Messages de type requête/réponse, format binaire Besoin primaire: rapidité, eviter lourdeur, fiabilité Transport: UDP et TCP UDP plus rapide (evite three way handshake) La taille des messages UDP est limité à 512 octets Si la réponse est supérieure à 512 octets, elle est tronquée, la requête est retransmise une deuxième fois mais basée sur TCP TCP pour transfer de zone

22 Architecture/Protocole DNS
Transfer de zone Implementé comme query DNS (ressource AXFR) Le serveur secondaire copie la base de données du server primaire avec TCP (fiabilité impérative) Debut et fin par le SOA Numero de serie incrementale pour confronter versions Policy Polling periodique effectué par le serveur secondaire Effectué chaque REFRESH secondes En cas de problemes, re-essaye chaque RETRY secondes Problemes persistent: la base est jetée après EXPIRE sec

23 Architecture/Protocole DNS
Modalités d’interrogation Mode iteratif Obligatoire Complexité sur le le client Mode récursif Optionnel Complexité sur le serveur Difficile pour troubleshooting en cas de panne Benefique pour le cache En pratique Recursif jusqu’au serveur DNS locale Iteratif depuis le serveur DNS locale

24 Resolution Resolution recursive de type A pour y.x.com Lien logique
Remarque: La reponse dans le cache du resolver pourra servir les prochaines requetes 1 2 3 4 5 6 7 8 . fr it com enst x z y.x.com Lien logique DB ns1 www y Lien physique Cache Cache Requete Reponse

25 Resolution Resolution iterative de type A pour y.x.com Lien logique
Remarque: La reponse dans le cache du resolver pourra servir les prochaines requetes 1 2 3 4 5 6 7 8 . fr it com enst x z y.x.com Lien logique DB ns1 www y Lien physique Cache Cache Requete Reponse

26 Resolution: Efficacité du cache (1/3)
Client QoE: durée resolution D Hit ratio h = P{ y.x.com in Cache } E[D] = h RTTloc + (1-h) S RTTwan Hit ratio DB de taille N noms, Cache LFU de taille C noms Arrivée des requetes IRM popularité Zipf a = 1.0 h = log(C) / log(N) DB y.x.com DB Cache Cache Resolveur locale Client RTTloc Agregat du DB DNS globale RTTwan >> RTTloc

27 Resolution: Efficacité du cache (2/3)
Independent reference model (IRM) Arrivée Poisson pour objets avec popularité i.i.d. stationnaire Popularité: Loi de Zipf premier linguiste à etudier la frequence des mots dans la langue anglaise; catalogue de N mots Le k-eme mot le plus populaire est moins populaire par rapport 1er mot d’un facteur 1/ka Probabilité d’occurrence du k-eme mot dans un “texte IRM”: P(k) = ( 1/ka) / ( SN 1/ka ) Least frequently used (LFU) Pour chaque nouveau arrivé, on remplace un objet du cache de taille C LRU: algorithme de replacement qui consiste à garder dans le cache les C objects les plus populaires parmi les N disponibles epl George Kingsley Zipf

28 Resolution: Efficacité du cache
Assumptions Independent reference model (IRM) Popularité: Loi de Zipf Least frequently used (LFU) Performance: Hit ratio LRU avec IRM Zipf probabilité qu’on objet requis soit dans le cache = somme de probabilité d’occurrence de C objets les plus populaires George Kingsley Zipf epl SC 1/ka Lorsque a=1, Harmonic number Hx =Sx 1/ka h= lim Hx - ln(x) = g (constante de Euler-mascheroni) SN 1/ka x ∞ h≈ ln(C)/ln(N) (bonne approximation pour C et N large)

29 Format des requêtes/réponses
1 32 IDENTIFICATION FLAGS NBR. DE QUESTIONS NBR. DE REPONSES NBR. DE RRs AUTORITAIRES NBR.de RRs SUPPLEMENTAIRES QUESTIONS REPONSES AUTORITAIRES INFORMATIONS SUPPLEMENTAIRES

30 Format des requêtes/réponses
Identification (16 bits): pour associer une réponse à une requête Flags (16 bits): 1 QR : Question = 0 , Réponse = 1 2 OPCODE (3 bits) 0 question standard / 1 question inverse / 2 requête de statuts du serveur 5 AA: = 1 Authorative Answer 6 TC : = 1 Truncated Response 7 RD: = 1 Recursion Desired sinon question itérative 8 RA : = 1 Recursion Allowed indique le support de la récursion 9 Reserved : = 0 10 AD Authentic Data 11 CD Checking Disabled 12 RCODE (4bits) Reponse Code 0 Pas d’erreur. 1 Erreur de format, question non interprétable. 2 Problème sur le serveur. 3 Nom dans la question n’existe pas 4 Type de la question n’est pas supporté 5 Question refusée. 6-15 Réservées

31 Format des requêtes/réponses
Question Nom Type Classe Nom 5 v e r d i 4 e n s t 2 f r FQDN

32 Format des requêtes/réponses
Type

33 Format des requêtes/réponses
Class 1 = (IN) Internet address 2 = Non attribué ou non supporté 3 = Réseau Chaos du MIT 4 = attribué au MIT pour Hesiod

34 Format des requêtes/réponses
Nom Type Classe Durée de vie de la réponse (TTL) Longueur de la donnée Donnée

35 Example Démonstration et analyse de trafic Question:
00 07 cb 4c 40 e d b9 c0 a8 00 0a d4 1b 36 fc ab a2 b c 63 6c 02 66

36 Example Démonstration et analyse de trafic Question:
00 07 cb 4c 40 e d b9 c0 a8 00 0a d4 1b 36 fc ab a2 b c 63 6c 02 66 Ethernet / IP / UDP / DNS

37 Example Démonstration et analyse de trafic Question:
00 07 cb 4c 40 e d b9 c0 a8 00 0a d4 1b 36 fc ab a2 b c 63 6c 02 66 ID / QR OPCODE AA TC RD / RA Z RCODE

38 Example Démonstration et analyse de trafic Question:
00 07 cb 4c 40 e d b9 c0 a8 00 0a d4 1b 36 fc ab a2 b c 63 6c 02 66 QDCOUNT / ANCOUNT / NSCOUNT / ARCOUNT

39 Example Démonstration et analyse de trafic Question:
00 07 cb 4c 40 e d b9 c0 a8 00 0a d4 1b 36 fc ab a2 b c 63 6c 02 66 3 www 3 lcl 2 fr 0 / TYPE / CLASS

40 Example Démonstration et analyse de trafic Réponse:
d cb 4c 40 e cd d4 1b 36 fc c0 a8 00 0a a2 b c 63 6c 02 66 c0 0c e1 00 02 c0 10 c e c1 6e 98 37

41 Example Démonstration et analyse de trafic Réponse:
d cb 4c 40 e cd d4 1b 36 fc c0 a8 00 0a a2 b c 63 6c 02 66 c0 0c e1 00 02 c0 10 c e c1 6e 98 37 Ethernet / IP / UDP / DNS

42 Example Démonstration et analyse de trafic Réponse:
d cb 4c 40 e cd d4 1b 36 fc c0 a8 00 0a a2 b c 63 6c 02 66 c0 0c e1 00 02 c0 10 c e c1 6e 98 37 ID / QR OPCODE AA TC RD / RA Z RCODE

43 Example Démonstration et analyse de trafic Réponse:
d cb 4c 40 e cd d4 1b 36 fc c0 a8 00 0a a2 b c 63 6c 02 66 c0 0c e1 00 02 c0 10 c e c1 6e 98 37 QDCOUNT / ANCOUNT / NSCOUNT / ARCOUNT

44 Example Démonstration et analyse de trafic Réponse:
d cb 4c 40 e cd d4 1b 36 fc c0 a8 00 0a a2 b c 63 6c 02 66 c0 0c e1 00 02 c0 10 c e c1 6e 98 37 3 www 3 lcl 2 fr 0 / TYPE / CLASS

45 Example Démonstration et analyse de trafic Réponse:
d cb 4c 40 e cd d4 1b 36 fc c0 a8 00 0a a2 b c 63 6c 02 66 c0 0c e1 00 02 c0 10 c e c1 6e 98 37 C0 0C = => Offset Ptr +12 (to 0x03)

46 Example Démonstration et analyse de trafic Réponse:
d cb 4c 40 e cd d4 1b 36 fc c0 a8 00 0a a2 b c 63 6c 02 66 c0 0c e1 00 02 c0 10 c e c1 6e 98 37 CNAME / Internet / TTL=8m / Size of Ptr Len / Ptr

47 Example Démonstration et analyse de trafic Réponse:
d cb 4c 40 e cd d4 1b 36 fc c0 a8 00 0a a2 b c 63 6c 02 66 c0 0c e1 00 02 c0 10 c e c1 6e 98 37 C0 10 = => Offset Ptr +16 (to 0x03)

48 Example Démonstration et analyse de trafic Réponse:
d cb 4c 40 e cd d4 1b 36 fc c0 a8 00 0a a2 b c 63 6c 02 66 c0 0c e1 00 02 c0 10 c e c1 6e 98 37 TYPE/ CLASS/ TTL / Data Len /

49 Example drossi@nonsns:~$ dig www.lcl.fr
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23398 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ; IN A ;; ANSWER SECTION: IN CNAME lcl.fr. lcl.fr IN A ;; Query time: 50 msec ;; SERVER: #53( ) ;; WHEN: Thu Dec 20 22:21: ;; MSG SIZE rcvd: 58

50 Résolution de nom inverse

51 DNS: Usage courant Partage de charge (Load balance)
TTL très petit pour éviter Caching

52 DNS: Usage courant Securité (Filtrage du contenu/advertisement, Protection contre malware/phishing/botnets)

53 DNS: Usage créatif Fun (for geeks)

54 DNS: Usages créatif Tunnel (port 53 often open even in open WiFi)

55 DNS: Usages inattendus
Caches & TTL

56 DNS: Usages inattendus
Root servers (1/2) S. Castro at al. Understanding and preparing for DNS evolution In Proc TMA’10

57 DNS: Usages inattendus
Root servers (2/2): Caching negatif pas repandu S. Castro at al. Understanding and preparing for DNS evolution In Proc TMA’10

58 DNS: Usages detournés Distributed Denial of Service (DDoS)

59 DNS: Usages detournés Malware (C&C)

60 DNS: Usages detournés Malware (Exfiltration des données)

61 Conclusions et remarques
Protocole simple et flexible Déploiement et mise en œuvre rapide Adapté à plusieurs réseaux / usages (voir SPF dans le cours SMTP) Plusieurs attaques structurelles possibles Nécessité de laisser passer le trafic DNS (pas de filtrage) Exposé aux attaques mais suffisement robuste Talon d’Achille de l’Internet 9/11 twin towers (cfr. TD) Ne supporte pas tous types de ressources Évolutions: Host Identity Protocol (HIP), DNSSEC Internet of things ?

62 References Lectures optionnelles
D.Wessel and M. Fomenkov, Wow, that’s a lot of packets, Passive and Active Measurement (PAM), 2003 S. Castro, M. Zhang, W. John, D. Wessels, and k. claffy, Understanding and preparing for DNS evolution, Traffic Monitoring and Analysis Workshop (TMA), 2010 Voir lectures concernant la Fenetre sur la recherche de cette année

63 ?? || // 63