La Fibre
Télécom => Réseau => TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: zoc le 20 septembre 2015 à 20:56:14
-
un serveur DNS qui ne ment pas ("nslookup thepiratebay.se" pour voir par vous même) devraient être de la partie aussi. Je suis prêt à payer 50€ par mois pour juste ça
Ca ils ne peuvent pas. thepiratebay est bloqué suite à une décision de justice, Orange est obligé de s'y plier. Et puis je ne vois pas vraiment le problème, il suffit de monter un serveur DNS local, ça ne coûte pas 50 euros par mois...
Edit Vivien : Étude de l'ICANN de mars 2022 sur les résolveurs DNS utilisés dans l'Europe : Le rapport donne de nombreuses statistiques - sans surprise Google est le plus utilisé des serveurs DNS publics - et le rapport liste les 32 serveurs DNS publics existants)
(https://lafibre.info/images/doc/202203_icann_resolveurs_dns_utilises_dans_ue.png) (https://lafibre.info/images/doc/202203_icann_resolveurs_dns_utilises_dans_ue.pdf)
-
Ou encore plus simple pour ce cas: DNS de Google dans les paramètres de ta carte réseau. J'y accède à ton domaine. Juste quelques dizaines de secondes d'attente, mais cela doit être le peering... et une redirection côté serveur vers thepiratebay.mn maintenant.
-
Je déconseille les DNS de Google, ils enregistrent les requêtes faites, à des fins pas très catholiques pour la vie privée. Comme OpenDNS qui a un nom gentillet comme ça, mais qui vous redirige 3 fois sur 5 sur une page de leurs partenaires publicitaires au lieu du site que vous avez demandé.
J'utilise OpenNIC (https://www.opennicproject.org/) de mon côté.
-
J'utilise OpenNIC (https://www.opennicproject.org/) de mon côté.
Moi aussi...
-
Je déconseille les DNS de Google, ils enregistrent les requêtes faites, à des fins pas très catholiques pour la vie privée. Comme OpenDNS qui a un nom gentillet comme ça, mais qui vous redirige 3 fois sur 5 sur une page de leurs partenaires publicitaires au lieu du site que vous avez demandé.
J'utilise OpenNIC (https://www.opennicproject.org/) de mon côté.
Merci ;)
-
Le cache sur les serveurs DNS de Google est de 4 ou 6 heures.
C'est combien chez OpenNIC?
La majorité des serveurs DNS sont encore à 24 heures, en général.
Et puis avec OpenNIC, pas rapide. 3 serveurs fr selon la liste complète, mais un seul fr dans les 4 les plus rapides... et 1 be et 2 lu.
Edit: 8 fr, même, dans la liste complète...
-
Le log est désactivé pour beaucoup. Côté rapidité, je n'ai rien à dire.
-
Le log, c'est pour tracer tes requêtes.
Aucun serveur d'OpenNIC ne possède de log. Ils en font une fierté...
Moi je parle de cache, ce qui sert à calculer la propagation DNS. Elle est de quelle durée ici? Ou on en sait rien?
-
max-cache-ttl 86400; un jour
http://wiki.opennicproject.org/opennicZoneScript
-
J'utilise aussi OpenNic depuis un moment et pas grand chose à dire. :)
Le cache sur les serveurs DNS de Google est de 4 ou 6 heures.
C'est combien chez OpenNIC?
Bonne question je serai intéressé aussi pour l'info, même si pour moi ça reste pas très important.
Et puis avec OpenNIC, pas rapide. 3 serveurs fr selon la liste complète, mais un seul fr dans les 4 les plus rapides... et 1 be et 2 lu.
Pourquoi ne pas prendre les 2 meilleurs be et lu si c'est vraiment important. Les serveur DNS de Google ne sont pas en France je crois, ainsi que ceux de OPENdns, donc...
-
Le cache sur les serveurs DNS de Google est de 4 ou 6 heures.
C'est combien chez OpenNIC?
Bonne question je serai intéressé aussi pour l'info, même si pour moi ça reste pas très important.
Les serveurs DNS semblent être configurés avec un max-cache-ttl de 86400 secondes.
-
Pourquoi ne pas prendre les 2 meilleurs be et lu si c'est vraiment important. Les serveur DNS de Google ne sont pas en France je crois, ainsi que ceux de OPENdns, donc...
Faux!
Rien qu'en pinguant le 8.8.8.8 (dns1 de Google), j'ai 2ms en fibre. Chose impossible si ce n'est pas à Paris ou près de Paris, pour moi qui suis en Ile-de-France.
Google et OpenDNS ne t'offrent que 2 IP chacun pour toute la planète, mais après il y a une répartition géographique transparente pour l'utilisateur à l'accès. OVH utilise le même principe sur ces offres d'hébergement en son nom propre (Kimsufi ne le fait pas par exemple).
Pour OpenNIC, c'est à nous de choisir les IP en fonction de la géographie et de la latence que l'on mesure (OpenNIC met aussi en avant l'uptime dans le top 4 de la latence).
Les serveurs DNS semblent être configurés avec un max-cache-ttl de 86400 secondes.
Et comme tu l'avais précisé auparavant, cela fait un jour, soit 24 heures.
-
Et sinon, installer un unbound ? Ça fonctionne à la fois sous windows (http://korben.info/installer-serveur-dns-unbound.html), sous linux (https://korben.info/installer-unbound-serveur-dns-sous-linux.html) et sur tous les OS respectables.
Ça peut également s'installer sur un petit routeur sous un unix quelconque qui servira les requetes pour son lan.
Et là, pas de soucis.
-
Google et OpenDNS ne t'offrent que 2 IP chacun pour toute la planète, mais après il y a une répartition géographique transparente pour l'utilisateur à l'accès. OVH utilise le même principe sur ces offres d'hébergement en son nom propre (Kimsufi ne le fait pas par exemple).
Oui enfin ça s'appelle de l'Anycast => https://fr.wikipedia.org/wiki/Anycast
Faux!
Rien qu'en pinguant le 8.8.8.8 (dns1 de Google), j'ai 2ms en fibre. Chose impossible si ce n'est pas à Paris ou près de Paris, pour moi qui suis en Ile-de-France.
Et c'est sur ça que tu te bases pour dire que Google à des serveurs en Ile de France :o, désolé je ne suis pas vraiment convaincu , et encore moins quand je vois la liste de la location des serveurs DNS de Google https://developers.google.com/speed/public-dns/faq#locations
Pour l'Europe j'ai trouvé Brussels-Belgium, Berlin-Germany, Groningen-Netherlands, Dublin-Ireland, Frankfurt-Germany ...... si tu en trouves dans la liste je suis preneur.
Pour OpenNIC, c'est à nous de choisir les IP en fonction de la géographie et de la latence que l'on mesure (OpenNIC met aussi en avant l'uptime dans le top 4 de la latence).
Mouais si je te suis en étant à Paris le serveur en Belgique n'est pas un si mauvais choix...
Mais malheureusement ça n'est pas aussi simple pour revenir au explication de la location des serveur DNS de Google, tu peux par exemple être à Paris et sortir du réseau de ton opérateur à Lyon et inversement ...... même chose pour l'accès au serveur DNS de Google, le point d'entré de son réseau peu être à Lyon et le serveur physiquement à Marseille.....
Apres je te l'accorde le fait d'avoir une adresse anycast simplifie pas mal de chose DNS....
-
Et c'est sur ça que tu te bases pour dire que Google à des serveurs en Ile de France :o, désolé je ne suis pas vraiment convaincu , et encore moins quand je vois la liste de la location des serveurs DNS de Google
Oui, et je persiste et signe!
Si tu connais la définition du résultat du ping, 2ms pour sortir de France, même en fibre optique, et étant près de Paris, c'est physiquement impossible!
https://developers.google.com/speed/public-dns/faq#locations
Pour l'Europe j'ai trouvé Brussels-Belgium, Berlin-Germany, Groningen-Netherlands, Dublin-Ireland, Frankfurt-Germany ......
Bizarre, moi j'ai ceci:
Where are your servers currently located?
Google Public DNS servers are available worldwide. Here are the subnets from which Google Public DNS sends requests to authoritative nameservers, and their associated IATA airport codes:
74.125.16.0/24 tpe
74.125.17.0/24 bru
74.125.18.0/24 grq
74.125.19.0/24 mrn
74.125.40.0/24 mrn
74.125.41.0/24 tpe
74.125.42.0/24 atl
74.125.43.0/24 tul
74.125.44.0/24 mrn
74.125.45.0/24 tul
74.125.46.0/24 lpp
74.125.47.0/24 bru
74.125.72.0/24 cbf
74.125.73.0/24 bru
74.125.74.0/24 lpp
74.125.75.0/24 chs
74.125.76.0/24 cbf
74.125.77.0/24 chs
74.125.78.0/24 chs
74.125.80.0/24 dls
74.125.113.0/24 cbf
74.125.114.0/24 mrn
74.125.176.0/24 mrn
74.125.177.0/24 atl
74.125.178.0/24 atl
74.125.180.0/24 chs
74.125.181.0/24 bru
74.125.182.0/24 cbf
74.125.183.0/24 cbf
74.125.184.0/24 chs
74.125.185.0/24 chs
74.125.186.0/24 dls
74.125.187.0/24 dls
74.125.190.0/24 sin
173.194.89.0/24 tul
173.194.90.0/24 cbf
173.194.91.0/24 scl
173.194.92.0/24 bru
173.194.93.0/24 tpe
173.194.95.0/24 tul
173.194.96.0/24 dub
173.194.98.0/24 lpp
173.194.99.0/24 tul
2001:4860:400b::/48 dls
2404:6800:4003::/48 sin
2404:6800:4008::/48 tpe
2607:f8b0:4001::/48 cbf
2607:f8b0:4002::/48 atl
2607:f8b0:4003::/48 tul
2607:f8b0:400c::/48 chs
2607:f8b0:400d::/48 mrn
2607:f8b0:400e::/48 dls
2800:3f0:4003::/48 scl
2a00:1450:400b::/48 dub
2a00:1450:400c::/48 bru
2a00:1450:4010::/48 lpp
2a00:1450:4013::/48 grq
3 lettres pour dire une ville, mais moi je ne connais pas le noms de toutes les communes de France, donc il y a en a en France, mais pas Paris, c'est tout ce que cela me dit...
-
C'est la liste mondiale que je t'ai donné ::)
Pour info => MRN Morganton, North Carolina, USA et TPE Taipei, Taiwan, donc je t'en ai donné quelque un en Europe mais pas tout ....
j'ai pas envie de tout me taper, en plus c'est à toi de démontrer qu'il y a un serveur à Paris je te mâche déjà le travail avec la liste, mais en regardant en diagonale je ne vois pas de location en France
-
Je démontre par le ping.
La requête met 2ms à arriver au serveur.
Avec la propagation de la lumière (signal dans la fibre optique), il faut déjà 8ms pour aller de Paris à Lyon (lafibre.info): https://lafibre.info/dns/smokeping.cgi?target=Orange.Fibre.turold
-
Tout bêtement, Google n'utilise pas des serveurs de cache dans tous les pays pour tous les services Google?
Cela pourrait expliquer mon ping...
-
Peut être, car le ping est court effectivement, je vais regardé s'il n'y a pas eu d'update récemment.....
-
Autant avec 2ms de ping vers 8.8.8.8 il est clair que qqch répond à Paris.
Autant la liste que tu donnes je n'y vois ni CDG, ni ORY, donc à priori pas de serveur à Paris dans le lot. Ce qui ne veut pas dire qu'un autre type de serveur n'est pas positionné sur Paris.
-
Autant avec 2ms de ping vers 8.8.8.8 il est clair que qqch répond à Paris.
Autant la liste que tu donnes je n'y vois ni CDG, ni ORY, donc à priori pas de serveur à Paris dans le lot. Ce qui ne veut pas dire qu'un autre type de serveur n'est pas positionné sur Paris.
Tout de même bizarre de faire selon les codes IATA... pour de l'informatique non lié à des activités aéronautiques.
Du coup, cela réduit la recherche. En effet, pas pensé, car ça m'a déstabilisé. Je ne vois pas le rapport, en fait.
T'as oublié les autres de la région: Le Bourget, LBG, et tout ceux que le grand public ne connait pas, une dizaine dans cette région à tout casser. Ce qui rend tout de même la recherche rapide aléatoire selon les connaissances aéronautiques de chacun...
-
Résultat d'un ping d'un serveur dedié chez Online
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=59 time=1.01 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=59 time=0.974 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=59 time=0.979 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=59 time=0.986 ms
donc la on passe en dessous de la milliseconde, ce que voudrait dire que le serveur est vraiment proche .... faudrait que je vérifie sur quelle Data center se trouve ce Dédié .
-
Google étant present sur les ix, il y a surement des serveurs caches (GCC) qui font aussi dns..
-
Résultat d'un ping d'un serveur dedié chez Online
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=59 time=1.01 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=59 time=0.974 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=59 time=0.979 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=59 time=0.986 ms
donc la on passe en dessous de la milliseconde, ce que voudrait dire que le serveur est vraiment proche .... faudrait que je vérifie sur quelle Data center se trouve ce Dédié .
Online est carrèment dans Paris, il me semble.
Google étant present sur les ix, il y a surement des serveurs caches (GCC) qui font aussi dns..
Des serveurs cache de Google à Paris, je suis presque sûr, d'où ma question plus haut. Mais ils sont censés ne faire que du cache, non?
-
Tout de même bizarre de faire selon les codes IATA... pour de l'informatique non lié à des activités aéronautiques.
Ou alors vu autrement, c'est une très bonne idée pour avoir des trigrammes uniques dans à peu près toutes les villes où ils seront susceptibles de s'installer. Moi j'approuve !
T'as oublié les autres de la région: Le Bourget, LBG, et tout ceux que le grand public ne connait pas, une dizaine dans cette région à tout casser. Ce qui rend tout de même la recherche rapide aléatoire selon les connaissances aéronautiques de chacun...
Sur le principe tu as raison. En pratique Google utilise "CDG" pour Paris/IDF donc pas besoin de s'embêter.
-
Online est carrèment dans Paris, il me semble.
DC4 n'est pas encore là.
Il y a de grandes chances que la machine soit à DC2 (Ivry) ou DC3 (Vitry). Au pire à DC1 (Bezons) mais je ne crois pas qu'il reste tant de machines d'Online là-bas.
-
Des serveurs cache de Google à Paris, je suis presque sûr, d'où ma question plus haut. Mais ils sont censés ne faire que du cache, non?
Cache-DNS ? (et c'est plutôt en IDF qu'à Paris mais bon en terme de latence ça ne change pas grand chose)
-
DC3 donc Paris pour le dédié, j'avais un doute car le DC2 est à Vitry sur Seine ....
Edit : le DC3 c'est Vitry aussi ...
-
Sur le principe tu as raison. En pratique Google utilise "CDG" pour Paris/IDF donc pas besoin de s'embêter.
Je suis en train de faire toute la liste, mais avec méthode.
Une fois enlevé les doublons dans les codes, et mis par ordre alphabétique, je suis arrivé à une bizarrerie qui confirme que l'idée est TRES mauvaise pour le grand publique:
cbf: Council Bluffs Municipal Airport, IA, États-Unis
Donc Google utilise aussi des petites infrastructures aéronautiques pour les codes...
Et municipal en anglais, c'est aussi municipal en français.
Je re pour mettre toute la liste, pas encore terminé.
-
Même chose pour le site de Google.
PING www.google.fr (216.58.211.67) 56(84) bytes of data.
64 bytes from par03s14-in-f3.1e100.net (216.58.211.67): icmp_req=1 ttl=57 time=0.949 ms
64 bytes from par03s14-in-f3.1e100.net (216.58.211.67): icmp_req=2 ttl=57 time=0.909 ms
64 bytes from par03s14-in-f3.1e100.net (216.58.211.67): icmp_req=3 ttl=57 time=0.896 ms
64 bytes from par03s14-in-f3.1e100.net (216.58.211.67): icmp_req=4 ttl=57 time=0.905 ms
--- www.google.fr ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 0.896/0.914/0.949/0.042 ms
pourtant dans les location des serveurs je ne vois rien pour l'instant.
-
Je suis en train de faire toute la liste, mais avec méthode.
Profite, si tu as le temps ;).
Une fois enlevé les doublons dans les codes, et mis par ordre alphabétique, je suis arrivé à une bizarrerie qui confirme que l'idée est TRES mauvaise pour le grand publique:
Je ne vois pas le soucis.
Donc Google utilise aussi des petites infrastructures aéronautiques pour les codes...
Il utilise le code associé à une ville où il a un DC : https://www.google.com/about/datacenters/inside/locations/council-bluffs/index.html
C'est un drame ?
Et municipal en anglais, c'est aussi municipal en français.
On va peut-être pas partir sur un cours d'anglais ? Quel rapport ?
Non vraiment, Google n'est pas le seul à utiliser les codes IATA et ça me semble vraiment une bonne idée !
-
Les serveurs caches de Google ne sont pas a Paris intra-muros, mais Courbevoie (92)
Je confirme que les réponses DNS n'ont généralement pas besoin de sortir de Courbevoie vu le temps de réponse.
-
Et voici la liste complète des localisations par code IATA des serveurs DNS Google sur cette planète (bientôt la Lune... puis Mars^^):
atl: Aéroport international Hartsfield-Jackson d'Atlanta, Géorgie, États-Unis
bru: Aéroport de Bruxelles, Bruxelles-National, Belgique
cbf: Council Bluffs Municipal Airport, IA, États-Unis
chs: Aéroport international de Charleston et Charleston Air Force Base, Caroline du Sud, États-Unis
dls: The Dalles Municipal Airport, OR, États-Unis
dub: Aéroport international de Dublin, Irlande
grq: Aéroport Groningue Eelde, Groningue, Pays-Bas
lpp: Lappeenranta, Finlande
mrn: Morganton-Lenoir Airport, NC, États-Unis
scl: Santiago de Chili (Arturo Merino Benitez), Chili
sin: Changi International Airport, Singapour
tpe: Taipei (Chiang Kai Shek), Taïwan
tul: Tulsa International Airport, OK, États-Unis
Au moins 2 infrastructures aéronautiques municipales (seul les USA mettent ce terme dans les noms, donc peut être d'autres municipaux dans les autres pays), et une base aérienne militaire (mais avec un aéroport civil associé sur le terrain).
Sacrée bonne idée pour une recherche rapide pour le grand publique, oui.....
Heureusement que je suis aussi dans l'aéronautique, moi... et vous?^^
@Badmaniak: il n'y a pas une liste publique similaire, chez Google, pour leurs (nombreux) serveurs de cache?
-
Heureusement que je suis aussi dans l'aéronautique, moi... et vous?^^
Moi je suis dans les télécom mais j'arrive à trouver le nom d'une ville dans le nom d'un aéroport associé à un code IATA.
-
Il faut surement comprendre que les serveurs DNS qui se trouvent à Paris vont surement taper dans cette liste de serveurs quand ils n'ont pas la réponse en cache.
-
Mais tu préfères surement des trigrammes propres à chaque opérateur et pour lesquels on se retrouvera avec un même trigramme qui correspond à deux villes différentes dans deux pays différents selon l'opérateur.
-
@turold j'ai cherché et rien trouvé pour l'instant, c'est un comble
Je pense que l'on a un début réponse sur le réseau France-IX => https://www.franceix.net/fr/technical/infrastructure/
le DC3 de Vitry y est connecté ainsi que le Telecity de Courbevoie:
(https://www.franceix.net/media/cms_page_media/136/infrastructure-France-ix-fr-2015.png)
(https://www.franceix.net/media/cms_page_media/136/upgrades-of-the-backbone2015.png)
-
@turold j'ai cherché et rien trouvé pour l'instant, c'est un comble
Je pense que l'on a un début réponse sur le réseau France-IX le DC3 de Vitry y est connecté ainsi que le Telecity de Courbevoie:
Tu cherches quoi ? Les serveurs sont à Courbevoie. Pas loin de TC2.
-
Une identification officiel :D après je pense que la réponse est la, mais rien sur le net qui indique la présence physique du/des serveurs, comme on a pu le voir sur la liste.
Bref turold avait raison sur la proximité du serveur DNS , mais la déduction se fait sur le ping.
-
Les serveurs caches de Google ne sont pas a Paris intra-muros, mais Courbevoie (92)
Je confirme que les réponses DNS n'ont généralement pas besoin de sortir de Courbevoie vu le temps de réponse.
Ok.
Et vu la liste des serveurs DNS de Google, en France on doit être redirigé vers les serveurs DNS en Belgique (5 en IPv4, 1 en IPv6), en cas de non-réponse ou de renouvellement du cache.
En cas de problèmes en Belgique, il y a les Pays-bas, l'Irlande, et la Finlande, en restant en Europe.
Il faut surement comprendre que les serveurs DNS qui se trouvent à Paris vont surement taper dans cette liste de serveurs quand ils n'ont pas la réponse en cache.
Je l'entends bien, en respectant le cache-max-ttl des serveurs DNS de Google bien sûr.
Mais tu préfères surement des trigrammes propres à chaque opérateur et pour lesquels on se retrouvera avec un même trigramme qui correspond à deux villes différentes dans deux pays différents selon l'opérateur.
Le plus gros problème ici, c'est l'aspect international.
Car en franco-français, il y a déjà le choix entre code postal, et code officiel géographique.
Mais c'est un débat qui mériterai un autre sujet.
Pour le moment, faisons avec IATA côté Google.
-
Et sinon, installer un unbound ? Ça fonctionne à la fois sous windows (http://korben.info/installer-serveur-dns-unbound.html), sous linux (https://korben.info/installer-unbound-serveur-dns-sous-linux.html) et sur tous les OS respectables.
Ça peut également s'installer sur un petit routeur sous un unix quelconque qui servira les requetes pour son lan.
Et là, pas de soucis.
Le seul problème que ce genre de solution me donne est le suivant:
Par défaut, où est-ce qu'Unbound va aller chercher les infos qui ne sont pas dans le cache, ou pour le renouveler?
Je viens de l'installer, et pas envie de faire un test et d'installer un logiciel de capture réseau...
Mais si c'est des DNS de tiers 1 ou 0, il est déconseillé de le faire en temps que particulier (surcharge de ces serveurs DNS). Et si c'est du tier 2, autant aller directement sur les serveurs DNS des FAI, de Google, d'OpenDNS, d'OpenNIC, etc.
-
Par défaut tu peux vérifier dans la config mais ça va surement chercher sur les root server.
-
Il faut surement comprendre que les serveurs DNS qui se trouvent à Paris vont surement taper dans cette liste de serveurs quand ils n'ont pas la réponse en cache.
Je ne suis pas sur de ça, sachant cache-max-ttl est le même sur tous les serveur DNS de Google.D'ailleurs une fois l'expiration du cache pourquoi consulter un tiers qui consultera les serveurs racines ou les serveurs faisant autorités, alors que le serveur de Courbevoie peux le faire lui même?
-
Après expiration du cache, le serveur DNS contacte lui même ceux qui ont autorité (pour vérifier si l'info a changé ou pas)
-
Le seul problème que ce genre de solution me donne est le suivant:
Par défaut, où est-ce qu'Unbound va aller chercher les infos qui ne sont pas dans le cache, ou pour le renouveler?
Par défaut il démarre avec les serveur racine normalement à vérifier dans le fichier de conf, mais tu peux les rajouter le cas écheant, je ne sais pas qu'elle est ton OS, mais sur Debian tu les récupères ftp://ftp.internic.net/domain/named.cache et les mets dans le répertoire /var/lib/unbound/ par exemple.
Sinon tu as sur le Github d'Angristan des scripts qui installent et configurent Unbound avec les serveurs Root et DNSSEC https://github.com/Angristan/Linux-DNS-server.
ps : n'oublies pas de limiter l'accès qu'a ton réseau local.( access-control: 0.0.0.0/0 refuse ; access-control: 192.168.1.0/24 allow)
@Vivien On est d’accord, ou j'ai mal compris la réponse de Nico, pour moi il ne consulte pas les serveurs DNS de Google dans la liste lorsque son cache expire.
-
Unbound va aller chercher directement les informations auprès des serveurs faisant autorité. Les root servers pour la racine, les NS des gtld ensuite, etc...
Et ne vous inquiétez pas pour la charge des serveurs dns, ils supporteront :)
-
Qu'est-ce qu'un "DNS de tiers 1"?
-
Un serveur DNS qui n'a que des peer, pas de transit.
(je sors)
-
Par défaut tu peux vérifier dans la config mais ça va surement chercher sur les root server.
Il n'y a aucune config en mode graphique.
On est censé personnaliser dans le fichier de conf, directement, et par défaut, ce ne sont que des lignes de commentaires (sauf la ligne 3 et la dernière):
service.conf
Et juste après install:
# Unbound configuration file on windows.
# See example.conf for more settings and syntax
server:
# verbosity level 0-4 of logging
verbosity: 0
# if you want to log to a file use
#logfile: "C:\unbound.log"
# on Windows, this setting makes reports go into the Application log
# found in ControlPanels - System tasks - Logs
#use-syslog: yes
server: auto-trust-anchor-file: "C:\Program Files (x86)\Unbound\root.key"
Je ne vais pas loin avec ça...
Heureusement qu'il y a ceci: https://www.unbound.net/documentation/unbound.conf.html
...Mais là non plus, pour ce que je recherche, aucune valeur par défaut indiquée (contrairement à la plupart des paramètres).
Unbound va aller chercher directement les informations auprès des serveurs faisant autorité. Les root servers pour la racine, les NS des gtld ensuite, etc...
Et ne vous inquiétez pas pour la charge des serveurs dns, ils supporteront :)
Ok merci.
Et d'accord pour la charge de ces serveurs.
Je sais que certains DNS de tiers 1 "alternatifs" refusent les connexions par défaut. C'est uniquement sur liste blanche, suite à une autorisation (je suppose par IP, donc mort en IP dynamique).
Pour les autres, pas ce soucis, mais bon, juste peur de cet aspect d'une potentielle surcharge si tout le monde se mettaient à court-circuiter les DNS de tiers 2 (voir tiers 3 mais je ne vois aucun intérêt à ce dernier, même pour les entreprises, autant qu'ils se fassent leur propre tiers 2).
-
Je sais que certains DNS de tiers 1 "alternatifs" refusent les connexions par défaut. C'est uniquement sur liste blanche, suite à une autorisation (je suppose par IP, donc mort en IP dynamique).
Pour les autres, pas ce soucis, mais bon, juste peur de cet aspect d'une potentielle surcharge si tout le monde se mettaient à court-circuiter les DNS de tiers 2 (voir tiers 3 mais je ne vois aucun intérêt à ce dernier, même pour les entreprises, autant qu'ils se fassent leur propre tiers 2).
Serveur DNS de tiers 1/2/3 ça veut rien dire, il n'y a pas de hiérarchie des résolvers. C'est pas du NTP. Et même en ntp, on dit strate.
Ensuite, soit les dns sont resolveurs (comme le unbound) et là c'est normal que ça soit limité à certaines IP, soit c'est un serveur faisant autorité (comme les serveurs dns racine, ou les serveurs dns de .fr), et ceux là sont accessibles depuis n'importe quelle IP.
-
Soit on comprend rien à ce que vous dites, comme moi ;D
-
Serveur DNS de tiers 1/2/3 ça veut rien dire, il n'y a pas de hiérarchie des résolvers. C'est pas du NTP. Et même en ntp, on dit strate.
Ensuite, soit les dns sont resolveurs (comme le unbound) et là c'est normal que ça soit limité à certaines IP, soit c'est un serveur faisant autorité (comme les serveurs dns racine, ou les serveurs dns de .fr), et ceux là sont accessibles depuis n'importe quelle IP.
Alors tous les BAC+2 français en informatique sont dans le faux.
Et il n'y a qu'à faire une rapide recherche sur internet pour voir plein de "DNS tiers" et un chiffre.
C'est juste pour info.
Ensuite, pas été plus loin dans le DNS, mais on m'a dit qu'il y avait (et ce dans 2 formations différentes tout de même):
- des serveurs DNS uniquement pour dire quels sont les IP des serveurs DNS de chaque TLD (tiers 0)
- des serveurs DNS uniquement pour dire quels sont les IP de chaque domaine de leur TLD, sinon ça renvoie au-dessus (tiers 1, et si c'est bon comme définition, cela ressemble fortement à une hiérarchie)
- des serveurs DNS comme chez les FAI, Google, OpenDNS, OpenNIC, etc, qui vont d'abord chercher l'info dans les serveurs DNS de leur TLD dans lequel il se situe (tiers 2)
- des serveurs DNS qui cherchent d’abord l'info sur ceux juste au-dessus (comme Google...), chose qu'Unbound est capable de faire en le personnalisant loin. Mais je ne vois pas d'intérêt, ou alors ce sont des cas particuliers. (edit: et là c'est le tiers 3)
Edit: manquait quelque mots pour qualifier les formations.
-
J'ai reçu le même enseignement en BTS SIO.
-
Salut Turold
Perso je n'utilises pas les mots tiers 1/2/3 pour architecture DNS, peut être juste un problème de vocabulaire, sinon je suis d’accord avec petrus.
- des serveurs DNS uniquement pour dire quels sont les IP des serveurs DNS de chaque TLD (tiers 0)
Pour moi ce sont les serveurs de noms de la racine.
- des serveurs DNS uniquement pour dire quels sont les IP de chaque domaine de leur TLD, sinon ça renvoie au-dessus (tiers 1, et si c'est bon comme définition, cela ressemble fortement à une hiérarchie)
Ce sont les serveurs faisant autorité pour les TLD (.fr, .org, .com...), normalement ça ne renvoi pas au dessus si c'est le tiers 0 dont tu parlais, mais plus tôt vers le serveur du dessous.
- des serveurs DNS comme chez les FAI, Google, OpenDNS, OpenNIC, etc, qui vont d'abord chercher l'info dans les serveurs DNS de leur TLD dans lequel il se situe (tiers 2)
Je n'ai pas trop compris la recherche d'info dans les serveur DNS de leur TLD.
Les resolveurs ( FAI ou local) ne sont pas des "tiers 2" car il ne font pas partie de l'arborescence DNS pour moi, ils consultent cette arborescence pour répondre à une requête cliente et mettent en cache les informations.
Bref ils sont juste des annuaires.
- des serveurs DNS qui cherchent d’abord l'info sur ceux juste au-dessus (comme Google...), chose qu'Unbound est capable de faire en le personnalisant loin. Mais je ne vois pas d'intérêt, ou alors ce sont des cas particuliers. (edit: et là c'est le tiers 3)
Non pour moi là ce n'est pas (tiers 3), enfin pas comme tu l'expliques, il peu y avoir une hiérarchie dans les résolveurs si on la configure, mais rien d'obligatoire.
On pourrai diviser le fonctionnement du DNS pour simplifier en trois parties :
-Le client (machine cliente)
-Le résolveur (Fai : OpenDNS Google, local: Unbound par exemple) annuaire de la machine cliente.
-L'arborescence de la structure DNS (racine, serveur faisant autorités des TLD puis les serveurs de deuxième niveau ....)
Exemple (simplifié) : si le cache du résolveur est vide => pour une requête cliente fr.wikipedia.org, le résolveur procède de cette manière selon moi:
la racine sera consulté en premier elle donnera le serveur faisant autorité de .org, qui à son tour donnera le serveur faisant autorité pour wikipedia.org, ce derniers donnera l'ip de fr.wikipedia.org.
Réponse au client avec la mise en cache dans le résolveur du serveur de .org, du serveur de wikipedia.org et l'ip fr.wikipedia.org.
Un petit schéma pour y voir plus claire...
(https://upload.wikimedia.org/wikipedia/commons/thumb/c/cc/DNS_iterations.svg/528px-DNS_iterations.svg.png)
Donc après cet exemple ou positionnes tu le tiers 1 2 et 3 ?
-
Le schéma de badmaniak est très bien. Il explique exactement comment ça fonctionne, et montre bien que bien que le dns soit hiérarchique, les serveurs ne le sont pas.
-
Mon tiers 3 est très facultatif, je le reconnais.
Pour les tiers 0/1/2, même des pros du secteur le mettent sur leurs sites officiels... difficile de louper!
Un exemple (mais j'en ai plein si les "exemples" vous contrarient, faites une recherche par Google quoi, internet, bref):
OpenNIC:
Using OpenNIC means changing your DNS settings to use one of the many public Tier-2 servers on offer.
https://www.opennicproject.org/configure-your-dns/
Carrèment dans une URL:
http://wiki.opennicproject.org/[b]Tier2[/b]
http://wiki.opennicproject.org/Tier2
Et dedans, cela parle beaucoup de tiers 2, surtout en début de page.
Et j'ai connu le terme de "tiers" exclusivement sur internet, et bien avant de connaitre OpenNIC (ce mois-ci en fait pour ce dernier).
De ma petite liste des DNS en 4 points, vous enlevez les notions de tiers, et c'est ce qui est enseigner en France par les systèmes de formations (un BTS, donc ministère de l'éducation, et une formation AFPA, donc ministère du travail).
Juste 2 précisions, car il y a eu un malentendu entre nous aussi:
Je n'ai pas trop compris la recherche d'info dans les serveur DNS de leur TLD.
Tous les serveurs DNS comme celui de Google ont aussi un accès possible par domaine (exemple.com).
Me demande pas pourquoi, je n'en sais rien vu qu'on a besoin que de l'IP...
D'après ce que l'on nous apprends, il cherche donc les résultats/correspondances d’abord dans le serveur DNS de l'extension de domaine qu'il utilise.
Et c'est aussi cela que je voulais dire entre la racine internet et les TLD. Si alors ce n'est pas le bon TLD (par cette hiérarchie des demandes), la demande remonte à la racine de l'internet.
Dans ton image, je ne comprends pas par rapport à ce qu'on nous enseigne dans les lycées et AFPA.
C'est le choc entre 2 mondes, là... :o Pourtant nous sommes censés se comprendre avec l'obtention des diplômes, en France. Cela fait peur sur comment fonctionne la France...
Tu m'étonnes que les entreprises ont peur de recruter les jeunes du marché du travail.
-
Pour vous rassurer, je comprends très bien l'image toute seule, hein.^^
Bon, je vais me risquer à une correspondance avec les tiers (certitude en quasi-sûr):
- serveur DNS récursif, tiers 2
- serveur root, tiers 0 (cela fait déjà voler en éclat l'enseignement par niveau hiérarchique vu que c'est la première demande du serveur utilisé par l'utilisateur final... Mais là, pourquoi pas, cela optimise dans la plupart des cas)
- serveur .info, tiers 1 (???, pourquoi?? On veut un site en .org!!)
- serveur .org, tiers 1 (et là non plus, je ne comprends pas pourquoi le root n'a pas mis directement vers le .org ... pour un site en .org ...)
Aucun tiers 3 dans l'image, et de toute façon cela doit être très rare, quelque soit le système de "vocabulaire" DNS utilisé.
-
Pour les tiers je donne ma langue au chat, mais franchement je l'utilise pas entreprise pour parler du DNS.
Juste 2 précisions, car il y a eu un malentendu entre nous aussi:
Tous les serveurs DNS comme celui de Google ont aussi un accès possible par domaine (exemple.com).
Me demande pas pourquoi, je n'en sais rien vu qu'on a besoin que de l'IP...
D'après ce que l'on nous apprends, il cherche donc les résultats/correspondances d’abord dans le serveur DNS de l'extension de domaine qu'il utilise.
Et c'est aussi cela que je voulais dire entre la racine internet et les TLD. Si alors ce n'est pas le bon TLD (par cette hiérarchie des demandes), la demande remonte à la racine de l'internet.
Je ne comprend pas l’intérêt du resolveur d'utiliser le serveur faisant autorité de l'extension de domaine qu'il utilise!!!( à confirmer parce que je n'ai pas vu ce genre de config)
A ma connaissance un serveur faisant autorité sur .fr ne connais que le .fr( même pas les serveurs racine), il répondra forcèment qu'il ne connait pas google.com par exemple. D'ailleurs pourquoi une tel requête lui arriverait , puisque le resolveur doit passer d’abord par le serveur faisant autorité .com s'il est dans son cache sinon par les serveurs racine.
Dans ton image, je ne comprends pas par rapport à ce qu'on nous enseigne dans les lycées et AFPA.
C'est le choc entre 2 mondes, là... :o Pourtant nous sommes censés se comprendre avec l'obtention des diplômes, en France. Cela fait peur sur comment fonctionne la France...
Tu m'étonnes que les entreprises ont peur de recruter les jeunes du marché du travail.
Effectivement ça fait peur, sinon tu as Stéphane BORTZMEYER qui explique en détails le fonctionnement du protocole DNS https://www.youtube.com/watch?v=QHVK666TFUI
-
Pour vous rassurer, je comprends très bien l'image toute seule, hein.^^
Bon, je vais me risquer à une correspondance avec les tiers (certitude en quasi-sûr):
- serveur DNS récursif, tiers 2
- serveur root, tiers 0 (cela fait déjà voler en éclat l'enseignement par niveau hiérarchique vu que c'est la première demande du serveur utilisé par l'utilisateur final... Mais là, pourquoi pas, cela optimise dans la plupart des cas)
- serveur .info, tiers 1 (???, pourquoi?? On veut un site en .org!!)
- serveur .org, tiers 1 (et là non plus, je ne comprends pas pourquoi le root n'a pas mis directement vers le .org ... pour un site en .org ...)
Aucun tiers 3 dans l'image, et de toute façon cela doit être très rare, quelque soit le système de "vocabulaire" DNS utilisé.
Tu n'a pas compris le schéma ;D :
le serveur finissant par .info est le serveur faisant autorité pour .org
et le serveur finissant par .org est le serveur faisant autorité pour wikipedia.org.
Regarde la vidéo à la minute 26 tu comprendra mieux.
-
1h16min?
Un cours complet, je suppose.
Je regarderais avec attention dans la soirée, quand j'aurai du temps pour le suivre en une seule fois. :)
Le serveur recursif (resolveur) ne peut pas être le tier2 ça voudrait dire qu'il est entre le la raicne et les serveurs faisant autorité.
Si non tu n'a pas compris le schéma ;D :
Pourtant, même en regardant à nouveau, je maintiens pour le moment.
Le tiers 2, dit autrement, c'est le serveur utilisé comme serveur DNS par un utilisateur final, comme toi ou moi. Donc généralement, les DNS des FAI, de Google, OpenDNS, Unbound par défaut côté résolution, OpenNIC, etc.
Cela a bien l'air d'être la cas dans ton schéma.
C'est bien un ordinateur pour surfer, en bas d'image, non?
-
Je confirme que chez Bouygues Telecom, les serveurs qui font autorité sur les nom de domaine de Bouygues Telecom n'ont rien a voir avec les serveurs qui répondent aux requêtes des clients et qui vont contacter les serveurs root et ceux faisant autorité sur le .com .fr ect..
Ce n'est même pas le même type de hardware (ni le même nombre de requêtes par seconde...)
-
Je confirme que chez Bouygues Telecom, les serveurs qui font autorité sur les nom de domaine de Bouygues Telecom n'ont rien a voir avec les serveurs qui répondent aux requêtes des clients et qui vont contacter les serveurs root et ceux faisant autorité sur le .com .fr ect..
Ce n'est même pas le même type de hardware (ni le même nombre de requêtes par seconde...)
Ah oui, quand même...
Merci pour la précision, cela commençait à venir dans mon esprit pour ceux qui font les 2.^^
Bon, je pense qu'il est temps pour moi de faire les correspondances avec les vocabulaires respectifs:
Tiers 0: serveur root (alias racine en français)
Tiers 1: serveurs d'autorité des TLD (.fr, .com, etc, y compris les TLD gérés par OVH, les FAI, OpenNIC, etc, et les nouveaux comme .bzh, .paris, etc)
Tiers 2: serveurs récursifs (FAI auprès des clients finaux, OpenNIC auprès des clients finaux, Google, OpenDNS, etc, ils demandent d'abord au Tiers 0, puis Tiers 1 en fonction de la réponse du Tiers 0)
Tiers 3: serveurs (faussement) récursifs (très rares, et ils demandent d'abord au Tiers 2).
Plus clair comme cela?
-
1h16min?
Un cours complet, je suppose.
Je regarderais avec attention dans la soirée, quand j'aurai du temps pour le suivre en une seule fois. :)
Pourtant, même en regardant à nouveau, je maintiens pour le moment.
Le tiers 2, dit autrement, c'est le serveur utilisé comme serveur DNS par un utilisateur final, comme toi ou moi. Donc généralement, les DNS des FAI, de Google, OpenDNS, Unbound par défaut côté résolution, OpenNIC, etc.
Cela a bien l'air d'être la cas dans ton schéma.
C'est bien un ordinateur pour surfer, en bas d'image, non?
Une conférence plus tôt, mais bien expliqué, les 15 première minutes parlent des noms de domaine, puis du protocole DNS. ;)
Sinon j'ai écris un peu vite, c'est pour cela que j'ai modifié. Oui celui que tu considères comme t2 est le resolveur donc consulté par le pc (client)
Si je te suis :
le t0 c'est les serveurs racine.
le t1 c'est l'ensemble des serveurs faisant autorité
le t2 les résolveurs
A ma connaissance les serveurs racine sont considérés comme des serveurs faisant autorité sur les TLD.
Ensuite t0 et t1 ne communiquent jamais, seul t2 est amener à communiquer avec t0 et t1, par contre t0 est bien au-dessus de t1 ( en simplifiant) , mais t2 n'est pas en-dessous de t0 et t1 si on reprend l'arborescence DNS il est en dehors.
J'e ne sais pas si ça colle à ta vision des serveurs tiers, moi j'ai du mal.
-
Les serveurs faussement récursifs, il en existe plein dans les box ADSL ! Presque tous les box intègrent un serveur DNS minimaliste qui va faire les demandes au serveur cache du FAI.
-
Les serveurs faussement récursifs, il en existe plein dans les box ADSL ! Presque tous les box intègrent un serveur DNS minimaliste qui va faire les demandes au serveur cache du FAI.
Tout à fait....
-
Une conférence plus tôt, mais bien expliqué, les 15 première minutes parlent des noms de domaine, puis du protocole DNS. ;)
Sinon j'ai écris un peu vite, c'est pour cela que j'ai modifié. Oui celui que tu considères comme t2 est le resolveur donc consulté par le pc (client)
Si je te suis :
le t0 c'est les serveurs racine.
le t1 c'est l'ensemble des serveurs faisant autorité
le t2 les résolveurs
A ma connaissance les serveurs racine sont considérés comme des serveurs faisant autorité sur les TLD.
Ensuite t0 et t1 ne communiquent jamais, seul t2 est amener à communiquer avec t0 et t1, par contre t0 est bien au-dessus de t1 ( en simplifiant) , mais t2 n'est pas en-dessous de t0 et t1 si on reprend l'arborescence DNS il est en dehors.
J'e ne sais pas si ça colle à ta vision des serveurs tiers, moi j'ai du mal.
Oui, c'est cela!
Pour le T2, même OpenNIC se présente comme T2 sur sa liste complète (lien du T2, et il y a 2 liens différents mais là je sèche sur pourquoi pour la même fonction DNS)
Pour ses TLD, pas suivi tous les liens, mais cela amène nulle part au moins sur les premiers (sic).
Donc T2 en dehors, oui, mais T2 quand même.
Pourquoi T2, alors? Je ne suis que suiveur, pas inventeur de vocabulaire... Je sèche aussi ici.
C'est peut être la cause de l'erreur dans les formations. Les formateurs, que ce soit en lycée ou AFPA, cherchent des infos sur internet. Et comme moi, ils ont dû tomber sur ces histores de tiers...
Reste à espérer qu'ils lisent l'ensemble de ce sujet pour corriger!
Le paradoxe des formateurs: ils nous disent de ne pas croire tout ce qu'il y a sur internet... mais le font eux-même pour une partie! Surtout dans l'informatique, où il n'y a pas (encore) de manuels scolaires. Donc il faut bien faire les cours à partir de quelque chose.^^
Les serveurs faussement récursifs, il en existe plein dans les box ADSL ! Presque tous les box intègrent un serveur DNS minimaliste qui va faire les demandes au serveur cache du FAI.
J'avais oublié. :-[
Mais en ADSL, jamais utilisé de box FAI.
Uniquement pour le THD (FTTLA, HFC, FTTH, pas connu le VDSL par contre). Et depuis quelques temps, j'utilise les DNS de Google.
-
Surtout dans l'informatique, où il n'y a pas (encore) de manuels scolaires. Donc il faut bien faire les cours à partir de quelque chose.^^
Mais pourvu que ça dure, je n'ai que mon laptop à emporter et j'en suis bien content ! Pendant que dans les autres secteurs mes amis se tapent 10 kg de livres ;D
-
.
-
Comment faire sans?
-
.
-
Pas d'accord. L'information transportée par le DNS n'est pas une simple donnée numérique globalement unique!
-
Exemple (simplifié) : si le cache du résolveur est vide => pour une requête cliente fr.wikipedia.org, le résolveur procède de cette manière selon moi:
la racine sera consulté en premier elle donnera le serveur faisant autorité de .org, qui à son tour donnera le serveur faisant autorité pour wikipedia.org, ce derniers donnera l'ip de fr.wikipedia.org.
Réponse au client avec la mise en cache dans le résolveur du serveur de .org, du serveur de wikipedia.org et l'ip fr.wikipedia.org.
Un petit schéma pour y voir plus claire...
(https://upload.wikimedia.org/wikipedia/commons/thumb/c/cc/DNS_iterations.svg/528px-DNS_iterations.svg.png)
Le schéma n'est pas très bon, il ne montre aucune adresse IP d'un DNS.
Le DNS sert avant tout à trouver les adresses IP des DNS!
-
Effectivement ça fait peur, sinon tu as Stéphane BORTZMEYER qui explique en détails le fonctionnement du protocole DNS
https://www.youtube.com/watch?v=QHVK666TFUI
Très bonne observation "le DNS est un détail technique pour utiliser les noms de domaines"
Je connais quelqu'un qui avait configuré une zone DNS pour son réseau local mais qui ne comprenait même pas la nature hiérarchique du DNS : il croyait que free.fr était un nom défini et dont l'existence provenait d'un serveur aux USA.
Je pense que beaucoup de profs commencent par parler du format des paquets ou du port UDP avant d'expliquer ce qu'est un domaine!
-
Le schéma n'est pas très bon, il ne montre aucune adresse IP d'un DNS.
Le DNS sert avant tout à trouver les adresses IP des DNS!
Effectivement le schéma semble incomplet sur les réponses 3 et 5, il manque l'Ip.
-
Effectivement le schéma semble incomplet sur les réponses 3 et 5, il manque l'Ip.
De plus, selon la vidéo (que j'ai regardé la nuit dernière), pour une requête vers un .org, il n'y a pas de passage sur le NS des .info. Ce qui me parait plus logique dans la vidéo.
Bon, sinon, après le combat des utilisateurs de OpenDNS vs Google (vs d'autres).
En IP dynamique, OpenDNS est une vraie merde dans sa façon de nous faire gérer dans l'espace utilisateur du site. Il y a quelques années, j'avais déjà détesté alors qu'il n'y avait aucune redirection à l'époque vers de la pub, mais déjà des blocages signés OpenDNS. Pour du OpenDNS, c'était déjà éliminatoire pour moi. En effet, quand on va dans son espace utilisateur OpenDNS (dans le site officiel donc), si on est sur une IP publique pas encore "administrée pour autoriser/bloquer des catégories entières de sites" par un autre utilisateur, on peut donc s'approprier cette IP dans OpenDNS à vie. J'ai accumulé comme ça des dizaines d'IP... avec une seule connexion en IP dynamique 3G. Et en général, la moitié du temps, impossible de l'ajouter dans mon espace OpenDNS... et j'étais alors bloqué vers une partie de l'internet (il n'y pas que le sexe dans les catégories d'OpenDNS, mais aussi les sites de jeux d'argent, ou encore les sites de jeux en général, sic, et etc).
Maintenant, c'est BIND vs Unbound (vs d'autres)....
Stéphane Bortzmeyer à l'air de trouver qu'Unbound est une alternative sérieuse à BIND, et la plus utilisée des alternatives (2ème après BIND):
Le résolveur DNS le plus courant, dans le monde du logiciel libre, est BIND. Mais il est toujours bon qu'il existe des alternatives sérieuses, pour faire face à toute éventualité. Le deuxième résolveur DNS le plus utilisé est sans doute Unbound.
http://www.bortzmeyer.org/unbound.html
La seule comparaison que j'a trouvé est dans le Wikipedia anglophone (mais un peu incomplet, voir les cases en gris, et il manque de source, surtout pour des "Partial"):
https://en.wikipedia.org/wiki/Comparison_of_DNS_server_software#Feature_matrix
Pour le moment, entre ces 2 là, j'ai installé Unbound. Mais pas encore utilisé, juste le peu de configuration dont j'ai besoin pour un éventuel usage.
-
le serveur faisant autorité pour .org dans le schéma est un .info comme il aurait pu être un .toto mais en fait on s'en fou, l'importance c'est l'adresse Ip donnée par le serveur racine pour contacter le serveur faisant autorité pour .org (et qui n'apparait pas dans le schéma).
Donc on ne consulte pas les serveurs faisant autorité de .info pour pour avoir du .org, ça c'est sur cela n'aurait aucun sens.
Je ne sais pas si j'ai été claire ;D
Perso j'utilise Bind (par habitude), après il y a encore plus simple au niveau de la configuration "dnsmasq" par exemple.
-
le serveur faisant autorité pour .org dans le schéma est un .info comme il aurait pu être un .toto mais en fait on s'en fou, l'importance c'est l'adresse Ip donnée par le serveur racine pour contacter le serveur faisant autorité pour .org (et qui n'apparait pas dans le schéma).
Donc on ne consulte pas les serveurs faisant autorité de .info pour pour avoir du .org, ça c'est sur cela n'aurait aucun sens.
Je ne sais pas si j'ai été claire ;D
En gros, je me suis attaché à un détail fictif, juste pour ajouter une requête pour donner un exemple au hasard, pas forcèment réelle dans les étapes. Juste la démarche générale qui est importante dans ton image.
Perso j'utilise Bind (par habitude), après il y a encore plus simple au niveau de la configuration "dnsmasq" par exemple.
D'après la légende, il n'est même pas récursif. :o Ou alors les noms de fonctions sont trop résumés en anglais...
Et il n'est pas sous Windows, donc pas pour moi.^^
Par contre, que ce soit BIND, Unbound, dnsmasq, et certainement d'autres logiciels DNS, il y a quelque chose que je ne comprends pas (un peu de HS désolé):
Ils se disent compatible Mac OS X (via le Wikipedia "en", un tableau plus bas dans mon lien) mais pas de .dmg sur leurs sites officiels.
Les anglophones auraient un logiciel qui compile ou convertit facilement de .tar.gz vers .dmg? Ou simple excès de zèle d'une communauté Wikipédia, comme il y en a dans d'autres langues?
-
Du moment qu'il est possible de compiler, le logiciel est dit compatible.
De nombreux logiciels sont compatibles MacOS X mais il faut les compiler soit-même.
C'est pour cela que j'ai mis un site web pour proposer des versions compilées de iperf : https://iperf.fr/iperf-download.php
-
D'après la légende, il n'est même pas récursif. :o Ou alors les noms de fonctions sont trop résumés en anglais...
Et il n'est pas sous Windows, donc pas pour moi.^^
Par contre, que ce soit BIND, Unbound, dnsmasq, et certainement d'autres logiciels DNS, il y a quelque chose que je ne comprends pas (un peu de HS désolé):
Ils se disent compatible Mac OS X (via le Wikipedia "en", un tableau plus bas dans mon lien) mais pas de .dmg sur leurs sites officiels.
Les anglophones auraient un logiciel qui compile ou convertit facilement de .tar.gz vers .dmg? Ou simple excès de zèle d'une communauté Wikipédia, comme il y en a dans d'autres langues?
Effectivement il n'est pas recursif, j'avoue aussi ne l'avoir jamais utilisé en tant que tel.
Sinon je tourne sur Linux sur tous mes pc et serveurs, je ne me suis jamais posé la question pour la compatibilité ...après peut être qu'ils parlent de compatible en tant que client.
-
Par contre, que ce soit BIND, Unbound, dnsmasq, et certainement d'autres logiciels DNS, il y a quelque chose que je ne comprends pas (un peu de HS désolé):
Ils se disent compatible Mac OS X (via le Wikipedia "en", un tableau plus bas dans mon lien) mais pas de .dmg sur leurs sites officiels.
Les anglophones auraient un logiciel qui compile ou convertit facilement de .tar.gz vers .dmg? Ou simple excès de zèle d'une communauté Wikipédia, comme il y en a dans d'autres langues?
Non, il faut juste compiler le logiciel des sources :)
Si tu n'as pas envie, Homebrew (http://brew.sh/index_fr.html) automatise les choses ...
-
Serveur DNS de tiers 1/2/3 ça veut rien dire, il n'y a pas de hiérarchie des résolvers. C'est pas du NTP. Et même en ntp, on dit strate.
Bien sur que si!
Il y a une hiérarchie :
- le résolveur du navigateur (qui a son propre cache)
interroge
- le résolveur de l'OS (qui a son propre cache)
interroge
- le résolveur de type "dnsmasq" du routeur (qui a son propre cache)
interroge
- les "serveurs DNS" (DNS récurseurs) du FAI font cache
qui vont chercher les infos à la sources :
- sur des serveurs n'autorisant pas la récursion
-
Alors tous les BAC+2 français en informatique sont dans le faux.
Si ce que tu racontes correspond à ce qu'on t'a enseigné, alors oui, carrèment, et assez sérieusement faux.
Et il n'y a qu'à faire une rapide recherche sur internet pour voir plein de "DNS tiers" et un chiffre.
C'est juste pour info.
Peut être, et en partant du principe que ça a un sens de parler en ces termes, ce que tu as cru comprendre est quand même faux.
Ensuite, pas été plus loin dans le DNS, mais on m'a dit qu'il y avait (et ce dans 2 formations différentes tout de même):
- des serveurs DNS uniquement pour dire quels sont les IP des serveurs DNS de chaque TLD (tiers 0)
Déjà il n'y a rien de particulier avec les TLD, ce sont juste des domaines très gros, les règles sont les mêmes à tous les niveaux.
- des serveurs DNS uniquement pour dire quels sont les IP de chaque domaine de leur TLD, sinon ça renvoie au-dessus (tiers 1, et si c'est bon comme définition, cela ressemble fortement à une hiérarchie)
Non, pas du tout. Il n'y a pas de hiérarchie là où tu en vois une.
Un serveur DNS "autoritatif" sur un domaine ne renvoie jamais au dessus. Personne ne renvoie au dessus.
Test avec un serveur de nom pour free.fr (en utilisant nslookup)
D'abord je choisis un NS :
> set type=NS
> free.fr
Serveur : dns1.proxad.net
Address: 212.27.40.240
Réponse ne faisant pas autorité :
free.fr nameserver = freens2-g20.free.fr
free.fr nameserver = freens1-g20.free.fr
freens2-g20.free.fr AAAA IPv6 address = 2a01:e0c:1:1599::23
freens1-g20.free.fr AAAA IPv6 address = 2a01:e0c:1:1599::22
freens2-g20.free.fr internet address = 212.27.60.20
freens1-g20.free.fr internet address = 212.27.60.19
> server 2a01:e0c:1:1599::22
Serveur par défaut : freens1-g12.free.fr
Address: 2a01:e0c:1:1599::22
Incidemment on remarque que nslookup a affiché le nom "freens1-g12.free.fr", parce qu'il a pu résoudre "2a01:e0c:1:1599::22"; en activant le débug (avant d'entrer la commande!) j'ai :
Got answer:
HEADER:
opcode = QUERY, id = 8, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 2, additional = 0
QUESTIONS:
2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.9.5.1.1.0.0.0.c.0.e.0.1.0.a.2.ip6.arpa, type = PTR, class = IN
ANSWERS:
-> 2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.9.5.1.1.0.0.0.c.0.e.0.1.0.a.2.ip6.arpa
name = freens1-g12.free.fr
ttl = 85835 (23 hours 50 mins 35 secs)
AUTHORITY RECORDS:
-> 9.9.5.1.1.0.0.0.c.0.e.0.1.0.a.2.ip6.arpa
nameserver = ns1.proxad.net
ttl = 73804 (20 hours 30 mins 4 secs)
-> 9.9.5.1.1.0.0.0.c.0.e.0.1.0.a.2.ip6.arpa
nameserver = ns0.proxad.net
ttl = 73804 (20 hours 30 mins 4 secs)
Si maintenant je répète cette commande server je vois :
> server 2a01:e0c:1:1599::22
------------
Got answer:
HEADER:
opcode = QUERY, id = 10, rcode = NOERROR
header flags: response, want recursion
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.9.5.1.1.0.0.0.c.0.e.0.1.0.a.2.ip6.arpa, type = PTR, class = IN
------------
Serveur par défaut : [2a01:e0c:1:1599::22]
Address: 2a01:e0c:1:1599::22
puisque maintenant nslookup interroge 2a01:e0c:1:1599::22 et que ce serveur ne connait pas son propre nom, puisque le domaine 2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.9.5.1.1.0.0.0.c.0.e.0.1.0.a.2.ip6.arpa est géré par les NS de type "ns*.proxad.net".
En là on voit que 2a01:e0c:1:1599::22 n'a pas dit allez voir ailleurs, allez voir plus haut. Il dit juste :
- j'accepte de répondre à cette question : rcode = NOERROR
- je ne connais aucun enregistrement de ce type : answers = 0
On peut lui demander google.com ça sera pareil :
------------
Got answer:
HEADER:
opcode = QUERY, id = 11, rcode = NOERROR
header flags: response, want recursion
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
google.com, type = A, class = IN
------------
------------
Got answer:
HEADER:
opcode = QUERY, id = 12, rcode = NOERROR
header flags: response, want recursion
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
google.com, type = AAAA, class = IN
------------
C'est demander une information à un soviétique. Il ne te donne que l'informatique qu'il doit te donner d'après le règlement. Et si tu lui demandes où est le bureau d'information, il te répond qu'il n'est pas un bureau d'information.
-
Autre test avec un serveur de noms de Google :
> free.fr
Serveur : ns1.google.com
Address: 216.239.32.10
------------
Got answer:
HEADER:
opcode = QUERY, id = 15, rcode = REFUSED
header flags: response, want recursion
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
free.fr, type = A, class = IN
------------
------------
Got answer:
HEADER:
opcode = QUERY, id = 16, rcode = REFUSED
header flags: response, want recursion
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
free.fr, type = AAAA, class = IN
------------
Le serveur de Google n'ayant pas autorité, il refuse de répondre concernant free.fr : rcode = REFUSED
Il ne "renvoie" pas ailleurs, c'est au résolveur de rechercher au bon endroit.
-
En gros, je me suis attaché à un détail fictif, juste pour ajouter une requête pour donner un exemple au hasard, pas forcèment réelle dans les étapes. Juste la démarche générale qui est importante dans ton image.
D'après la légende, il n'est même pas récursif. :o Ou alors les noms de fonctions sont trop résumés en anglais...
D'après la doc :
The DNS subsystem provides a local DNS server for the network, with forwarding of all query types to upstream recursive DNS servers and cacheing of common record types (A, AAAA, CNAME and PTR, also DNSKEY and DS when DNSSEC is enabled).
ce n'est pas du tout un vrai serveur DNS récursif, c'est un simple proxy qui se présente comme un serveur récursif mais qui a besoin d'un vrai serveur récursif en amont pour faire la résolution.
-
le serveur faisant autorité pour .org dans le schéma est un .info comme il aurait pu être un .toto mais en fait on s'en fou, l'importance c'est l'adresse Ip donnée par le serveur racine pour contacter le serveur faisant autorité pour .org (et qui n'apparait pas dans le schéma).
Donc on ne consulte pas les serveurs faisant autorité de .info pour pour avoir du .org, ça c'est sur cela n'aurait aucun sens.
Et si le NS d'un machin.org est dans info?
toto.org NS ns.rototo.info
il va bien falloir rechercher le NS de ns.rototo.info, non? Donc il va bien interroger le NS de info.
-
Non, l'info est donné avec l'IP, c'est l'IP l'information la plus importante, un NS ne répond sans IP.
Au démarrage les résolveur ne connaissent rien sauf les adresse IP des serveurs racine
Les serveurs racine et faisant autorité on juste une base de donnée avec des couples adresse et adresse IP.
Dans les réponses tu as forcèment l'IP.
Je ne vois pas le NS de .org dire au résolveur voila le NS de toto.org sans l'IP, si c'est le cas il faudrait au résolveur remonter à la racine (s'il n'est pas dans son cache) pour trouvé le .info et si le NS de .Info est un .net rebelote.
-
Tu es sûr de ça?
-
Je veux bien monter un petit lab pour vérifier, mais j'ai du mal à croire qu'un NS ne donne pas d'IP dans ces réponses.
-
Il y a deux questions :
- est-ce qu'il donne les IP dans tous les cas
- est-ce que le résolveur en tient compte
- combien de temps le résolveur conserve la réponse dans son cache
-
Pour commencer à te répondre voici la base de donnée des serveurs racine => http://www.iana.org/domains/root/db il y a toujours le couple Hostname/IP adresse.
Je pense que pour les NS des TLD c'est pareil (je n'ai pas trouvé l'info pour l'instant),
Globalement les réponses NS racine/NS TLD pour une requête fr.wikipedia.org sont: je ne connais pas la réponse pour fr.wikipedia.org mais demande a "Hostname/IP adresse" qui gère le .org/wikipedia.org.
Les NS de deuxième/troisième/N niveau peuvent ne pas renvoyer une adresse IP dans la réponse, avec des alias par exemple (CNAME) en renvoyant vers une autre cible, qui nous donnera l'ip après consultation. Dans ce cas cela implique de remonter jusqu’à la racine si la cible ne se trouve pas dans le cache, on le voit aussi pour les MX.
Pour .org par exemple :
-
'tain la liste de domaines.
Impressionant. ;)
-
Bon j'ai monté un Unbound pour faire le test vite fait.
Je confirme l'ip et le nom de machine est donné par le serveur racine et les serveurs faisant autorité.
- Sur la première demande du poste client fr.wikipedia.org, Undound contact 198.41.0.4 avec 2 requêtes de type A et AAAA (même 3!! 2 fois AAAA c'est la même demande je ne la compte pas).
- Le serveur racine 198.41.0.4 a.root-servers.net renvoie deux réponses, avec tout ce qu'il sait sur .org, les NS, les enregistrements de type A et AAAA dans chaque réponse à Unbound.
- Unbound choisit une ip 199.19.54.1 (je sais pas pourquoi celle là) dans la liste et repose ça question (qui est fr.wikipedia.org) en type A et AAAA.
-Le serveur faisant autorité pour .org 199.19.54.1 b0.org.afilias-nst.org ne connais pas la réponse et revois tout ce qu'il sait sur wikimedia.org (pourquoi ce n'est pas wikipedia.org je ne sais pas) au 2 requêtes, dans les réponses il n'y a que des enregistrements de type A et NS , Ipv6 connais pas :o
- Unbound choisit l'ip 208.80.153.231 (je sais pas pourquoi celle la aussi) dans la liste et repose ça question (qui est fr.wikipedia.org) en type A et AAAA.
- Le serveur faisant autorité pour wikimedia.org 208.80.153.231 ns1.wikimedia.org connais la réponse et donne l'IP 91.198.174.192 pour le demande en type A et pour AAAA l'IP 2620:0:862:ed1a::1.
Pourquoi c'est wikimedia.org, je ne sais pas, d'ailleurs la demande de Unbound dans les traces n'est pas fr.wikipedia.org mais login.wikimedia.org.
après si on vérifie.
dig fr.wikipedia.org
; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> fr.wikipedia.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11362
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;fr.wikipedia.org. IN A
;; ANSWER SECTION:
fr.wikipedia.org. 291 IN A 91.198.174.192
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 25 15:53:29 CEST 2015
;; MSG SIZE rcvd: 61
en Ipv6
dig AAAA fr.wikipedia.org
; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> AAAA fr.wikipedia.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37242
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;fr.wikipedia.org. IN AAAA
;; ANSWER SECTION:
fr.wikipedia.org. 366 IN AAAA 2620:0:862:ed1a::1
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 25 16:56:39 CEST 2015
;; MSG SIZE rcvd: 73
Bon c'est un peu à l'arrache, j'avais pas beaucoup de temps, je mettrai les captures d'écran plus tard.
-
-Le serveur faisant autorité pour .org 199.19.54.1 b0.org.afilias-nst.org ne connais pas la réponse et revois tout ce qu'il sait sur wikimedia.org (pourquoi ce n'est pas wikipedia.org je ne sais pas)
parce que
wikipedia.org nameserver = ns2.wikimedia.org
wikipedia.org nameserver = ns0.wikimedia.org
wikipedia.org nameserver = ns1.wikimedia.org
-
Wikipédia est un des projets de Wikimedia.
Wikimedia gère de nombreux projets / site web :Wikipedia, Wiktionary, Wikiquote, Wikibooks, Wikidata, Wikimedia Commons, Wikisource, Wikispecies, Wikinews, Wikivoyage et Wikiversity, tous développés grâce au logiciel MediaWiki.
Les DNS de tous ces projets sont hébergés par Wikimedia.
-
> wikipedia.org
Serveur : b0.org.afilias-nst.org
Addresses: 2001:500:c::1
199.19.54.1
------------
Got answer:
HEADER:
opcode = QUERY, id = 17, rcode = NOERROR
header flags: response, want recursion
questions = 1, answers = 0, authority records = 3, additional = 3
QUESTIONS:
wikipedia.org, type = A, class = IN
AUTHORITY RECORDS:
-> wikipedia.org
nameserver = ns1.wikimedia.org
ttl = 86400 (1 day)
-> wikipedia.org
nameserver = ns0.wikimedia.org
ttl = 86400 (1 day)
-> wikipedia.org
nameserver = ns2.wikimedia.org
ttl = 86400 (1 day)
ADDITIONAL RECORDS:
-> ns0.wikimedia.org
internet address = 208.80.154.238
ttl = 86400 (1 day)
-> ns1.wikimedia.org
internet address = 208.80.153.231
ttl = 86400 (1 day)
-> ns2.wikimedia.org
internet address = 91.198.174.239
ttl = 86400 (1 day)
------------
C'est un exemple intéressant : les serveurs NS de wikipedia.org ne sont pas dans le même domaine.
-
C'est le cas pour lafibre.info aussi ! (C'est OVH qui est "AUTHORITY", je n'ai pas trouvé d'utilité à gérer ça en propre)
-
Essayons de trouver lafibre :
> lafibre.info
Serveur : a.root-servers.net
Addresses: 2001:503:ba3e::2:30
198.41.0.4
info nameserver = a0.info.afilias-nst.info
info nameserver = a2.info.afilias-nst.info
info nameserver = b0.info.afilias-nst.org
info nameserver = b2.info.afilias-nst.org
info nameserver = c0.info.afilias-nst.info
info nameserver = d0.info.afilias-nst.org
(...)
a0.info.afilias-nst.info AAAA IPv6 address = 2001:500:19::1
(...)
> lafibre.info
Serveur : [2001:500:19::1]
Address: 2001:500:19::1
lafibre.info nameserver = dns10.ovh.net
lafibre.info nameserver = ns10.ovh.net
Là les IP ne sont pas indiquées, on peut le voir dans le mode debug :
------------
Got answer:
HEADER:
opcode = QUERY, id = 16, rcode = NOERROR
header flags: response, want recursion
questions = 1, answers = 0, authority records = 2, additional = 0
QUESTIONS:
lafibre.info, type = NS, class = IN
AUTHORITY RECORDS:
-> lafibre.info
nameserver = dns10.ovh.net
ttl = 86400 (1 day)
-> lafibre.info
nameserver = ns10.ovh.net
ttl = 86400 (1 day)
------------
On repart des roots :
Serveur : a.root-servers.net
Addresses: 2001:503:ba3e::2:30
198.41.0.4
Nom : dns10.ovh.net
Served by:
- a.gtld-servers.net
192.5.6.30
2001:503:a83e::2:30
net
- b.gtld-servers.net
192.33.14.30
net
- c.gtld-servers.net
192.26.92.30
net
(...)
Serveur : [192.26.92.30]
Address: 192.26.92.30
Nom : dns10.ovh.net
Served by:
- ns10.ovh.net
2001:41d0:1:1981::1
213.251.128.129
ovh.net
- dns15.ovh.net
2001:41d0:1:4a86::1
213.251.188.134
ovh.net
(...)
Les adresses IP sont indiquées, on continue :
Serveur : [2001:41d0:1:4a86::1]
Address: 2001:41d0:1:4a86::1
------------
Got answer:
HEADER:
opcode = QUERY, id = 28, rcode = NOERROR
header flags: response, auth. answer, want recursion
questions = 1, answers = 1, authority records = 0, additional = 0
QUESTIONS:
dns10.ovh.net, type = A, class = IN
ANSWERS:
-> dns10.ovh.net
internet address = 213.251.188.129
ttl = 86400 (1 day)
------------
------------
Got answer:
HEADER:
opcode = QUERY, id = 29, rcode = NOERROR
header flags: response, auth. answer, want recursion
questions = 1, answers = 1, authority records = 0, additional = 0
QUESTIONS:
dns10.ovh.net, type = AAAA, class = IN
ANSWERS:
-> dns10.ovh.net
AAAA IPv6 address = 2001:41d0:1:4a81::1
ttl = 86400 (1 day)
------------
Nom : dns10.ovh.net
Addresses: 2001:41d0:1:4a81::1
213.251.188.129
Enfin on a trouvé l'adresse du serveur qui a l'information recherchée!
-
En résumé :
- je cherche lafibre.info
1) a.root-servers.net dit "tu peux poser la question à a0.info.afilias-nst.info (au fait c'est au 2001:500:19::1)"
2) 2001:500:19::1 dit "tu peux poser la question à dns10.ovh.net" (je ne te dirai pas où c'est hi hi hi)
- je cherche dns10.ovh.net
3) a.root-servers.net dit "tu peux poser la question à c.gtld-servers.net (au fait c'est au 192.26.92.30)"
4) 192.26.92.30 dit "tu peux poser la question à dns15.ovh.net (au fait c'est au 2001:41d0:1:4a86::1)"
5) 2001:41d0:1:4a86::1 dit "la réponse que tu recherches est 213.251.188.129 petit scarabé"
On a donc trouvé!
6) 213.251.188.129 dit "la réponse que tu recherches est 46.227.16.8 petit scarabé"
On a donc trouvé!!!
Il faut seulement 6 requêtes DNS pour trouver l'adresse IP associée à un nom.
Remarque : j'ai alterné IPv4 et v6 pour le fun.
-
QUESTIONS:
lafibre.info, type = NS, class = IN
AUTHORITY RECORDS:
-> lafibre.info
nameserver = dns10.ovh.net
ttl = 86400 (1 day)
-> lafibre.info
nameserver = ns10.ovh.net
ttl = 86400 (1 day)
La question est de type NS donc pas d'IP, après s'il n'y pas d'autres infos, je vais tester lafibre.info pour voir si j'ai la même chose.
Edit: j'ai quelque chose qui se rapproche de ce que tu as, par contre la réponse m'est donné par le deuxième serveur root, mais toujours avec la même question lafibre.info, j'avais activé DNSSEC. Je vais faire un nouveau test sans DNSSEC demain à tête reposée, parce que là je ne comprends même pas comment il arrive au résultat sans passer par un des serveur faisant autorité pour lafibre.info.
-
Heu non, la question importe peu :
------------
Got answer:
HEADER:
opcode = QUERY, id = 14, rcode = NOERROR
header flags: response, want recursion
questions = 1, answers = 0, authority records = 2, additional = 0
QUESTIONS:
lafibre.info, type = A, class = IN
AUTHORITY RECORDS:
-> lafibre.info
nameserver = ns10.ovh.net
ttl = 86400 (1 day)
-> lafibre.info
nameserver = dns10.ovh.net
ttl = 86400 (1 day)
------------
Le serveur n'a pas d'autre information à donner.
-
Autre exemple : recherche de theregister.co.uk
1) Je prends c.root-servers.net :
Served by:
- dns2.nic.uk
103.49.80.1
2401:fd80:400::1
uk
- nsb.nic.uk
156.154.101.3
uk
- nsc.nic.uk
156.154.102.3
uk
- nsa.nic.uk
156.154.100.3
2001:502:ad09::3
uk
- dns3.nic.uk
213.248.220.1
2a01:618:404::1
uk
- nsd.nic.uk
156.154.103.3
uk
- dns4.nic.uk
43.230.48.1
2401:fd80:404::1
uk
- dns1.nic.uk
213.248.216.1
2a01:618:400::1
uk
2) Je prends nsb.nic.uk (156.154.102.3) :
Nom : theregister.co.uk
Served by:
- dahlia.ns.cloudflare.com
theregister.co.uk
- gerald.ns.cloudflare.com
theregister.co.uk
Aucune adresse IP n'est indiquée!
- 3) Je prends dahlia.ns.cloudflare.com :
Nom : dahlia.ns.cloudflare.com
Served by:
- e.gtld-servers.net
192.12.94.30
com
- i.gtld-servers.net
192.43.172.30
com
- b.gtld-servers.net
192.33.14.30
2001:503:231d::2:30
com
- m.gtld-servers.net
com
- d.gtld-servers.net
192.31.80.30
com
- c.gtld-servers.net
192.26.92.30
com
- g.gtld-servers.net
192.42.93.30
com
- a.gtld-servers.net
192.5.6.30
2001:503:a83e::2:30
com
- h.gtld-servers.net
192.54.112.30
com
- k.gtld-servers.net
192.52.178.30
com
4) Je prends i.gtld-servers.net (192.43.172.30) :
Nom : dahlia.ns.cloudflare.com
Served by:
- dns2.cloudflare.com
173.245.58.99
2400:cb00:2049:1::adf5:3a63
cloudflare.com
- dns3.cloudflare.com
173.245.59.99
2400:cb00:2049:1::adf5:3b63
cloudflare.com
5) Je prends dns2.cloudflare.com (173.245.58.99) :
Trouvé : 173.245.58.89
Nom : theregister.co.uk
Address: 159.100.131.165
Trouvé!!!
-
Re
Après plusieurs tests, je trouve aussi la même chose sur lafibre.info et theregister.co.uk
Mes remarques :
dans le descriptif plus bas le serveur faisant autorité de .info ne connais pas l'Ip lafibre.info mais les NS d'OVH, qui sont ceux rentrés sur l'interface de management d'OVH et faisant autorité.
Ce qui donne racine => NS .info => racine => NS .net => NS dns15.ovh.net => NS dns10.ovh.net => lafibre.info ,
Si Vivien gérait lui même son domaine nous aurions racine => NS .info => lafibre.info
En résumé :- je cherche lafibre.info
1) a.root-servers.net dit "tu peux poser la question à a0.info.afilias-nst.info (au fait c'est au 2001:500:19::1)"
2) 2001:500:19::1 dit "tu peux poser la question à dns10.ovh.net" (je ne te dirai pas où c'est hi hi hi)
- je cherche dns10.ovh.net
3) a.root-servers.net dit "tu peux poser la question à c.gtld-servers.net (au fait c'est au 192.26.92.30)"
4) 192.26.92.30 dit "tu peux poser la question à dns15.ovh.net (au fait c'est au 2001:41d0:1:4a86::1)"
5) 2001:41d0:1:4a86::1 dit "la réponse que tu recherches est 213.251.188.129 petit scarabé"
On a donc trouvé!
6) 213.251.188.129 dit "la réponse que tu recherches est 46.227.16.8 petit scarabé"
On a donc trouvé!!!
Il faut seulement 6 requêtes DNS pour trouver l'adresse IP associée à un nom.
Remarque : j'ai alterné IPv4 et v6 pour le fun.
-
Résolution tracée en utilisant unbound-host. J'ai enlevé le blabla, j'ai ajouté de la couleur, j'ai indenté, et // indique un commentaire
info: resolving lafibre.info. A IN
info: priming . IN NS
info: response for . NS IN
info: reply from <.> 128.63.2.53#53 // h.root-servers.net.
info: query response was ANSWER
info: priming successful for . NS IN
info: response for lafibre.info. A IN
info: reply from <.> 192.36.148.17#53 // i.root-servers.net.
info: query response was REFERRAL
info: response for lafibre.info. A IN
info: reply from <info.> 199.249.113.1#53 // a2.info.afilias-nst.info.
info: query response was REFERRAL
- info: resolving dns10.ovh.net. A IN
info: response for dns10.ovh.net. A IN
info: reply from <.> 199.7.91.13#53 // d.root-servers.net.
info: query response was REFERRAL
info: response for dns10.ovh.net. A IN
info: reply from <net.> 192.35.51.30#53 // f.gtld-servers.net.
info: query response was REFERRAL
info: response for dns10.ovh.net. A IN
info: reply from <ovh.net.> 213.251.188.134#53 // dns15.ovh.net.
info: query response was ANSWER
info: response for lafibre.info. A IN
info: reply from <lafibre.info.> 213.251.188.129#53 // dns10.ovh.net.
info: query response was ANSWER
-
Le protocole DNS au départ est conçu pour trouver les adresses Internet (mais on peut y mettre des tas d'autres choses comme des clés SSH); on dit l'Internet parce qu'on veut qu'il soit unique et mondial mais il y a deux Internet (IPv4 et IPv6) et en cachant les adresses Internet le DNS offre une abstraction pratique pour passer de v4 à v6.
Le protocole DNS fonctionne via Internet. Mais lequel?
On peut utiliser unbound pour vérifier qu'on nom de site peut être résolu en utilisant uniquement la v6, il suffit de passer l'option -6 à unbound-host : cela signifie résoudre via IPv6.
P.ex. unbound-host -d6tA lafibre.info explique (-d) comment il trouve l'adresse IPv4 (-t A) de ce site en utilisant IPv6 (-6) :
info: resolving for lafibre.info. A IN
info: priming . IN NS
info: response for . NS IN
info: reply from <.> 2001:500:84::b#53
info: query response was ANSWER
info: priming successful for . NS IN
info: response for for lafibre.info. A IN
info: reply from <.> 2001:500:1::803f:235#53
info: query response was REFERRAL
info: response for lafibre.info. A IN
info: reply from <info.> 2001:500:1c::1#53
info: query response was REFERRAL
info: resolving ns10.ovh.net. AAAA IN
info: response for ns10.ovh.net. AAAA IN
info: reply from <.> 2001:7fd::1#53
info: query response was REFERRAL
info: response for ns10.ovh.net. AAAA IN
info: reply from <net.> 2001:503:a83e::2:30#53
info: query response was REFERRAL
info: response for ns10.ovh.net. AAAA IN
info: reply from <ovh.net.> 2001:41d0:1:1986::1#53
info: query response was ANSWER
info: response for lafibre.info. A IN
info: reply from <lafibre.info.> 2001:41d0:1:1981::1#53
info: query response was ANSWER
Donc les DNS de ce site sont v6-ready.
-
.
-
En n'oubliant pas que la différence majuscule/minuscule ne compte pas dans le DNS,
en sachant qu'un nom de domaine peut aussi utiliser le tiret et les chiffres (et d'autres symboles mais mettons qu'on se limite à ça) :
soit 26+1+10 = 37 symboles possibles
soit :
37**3 = 50.653 mots de 3 symboles
1.874.161 mots de 4 symboles (p.ex. "free")
69.343.957 mots de 5 symboles
2.565.726.409 mots de 6 symboles (p.ex. "google")
94.931.877.133 mots de 7 symboles (p.ex. "lafibre")
3.512.479.453.921 mots de 8 symboles
>10**14 mots de 9 symboles
>10**15 mots de 10 symboles
>10**17 mots de 11 symboles
>10**18 mots de 12 symboles (p.ex. "lafourchette")
>10**23 mots de 15 symboles (p.ex. "bouyguestelecom")
En supposant que tu avances par ordre alphabétique, que chaque test d'un nom prend 4 ms, que tu procèdes séquentiellement, il te faudra plus d'un billion d'années (un billion = 1.000.000.000.000) avant d'arriver à la lettre "b" de "bouyguestelecom". Bien sûr, rien ne t'oblige à attendre la fin d'une requête DNS pour commencer la suivante, mettons que tu fais en parallèle un million de requêtes DNS, il te faudra quand même un million d'années pour arriver au "b".
-
Remarque complèmentaire : plutôt qu'en puissances de 10, on peut exprimer les résultats en puissance de deux. Un calcul approximatif (minimisant) peut même se faire de tête en prenant 32 comme approximation de 37 parce que 32 = 2**5.
Donc si vous vous souvenez de vos égalités apprises à l'école : (a**b)**c = a**(b*c)
32**x = (2**5)**x = 2**(5*x)
ce qui permet d'exprimer le résultat en nombre de bits, comme un chiffrement avec une clé quelconque de x bits (*). Ici on serait devant un chiffrement qu'on ne pourrait attaquer que par force brute.
(*) donc excluant les chiffrements asymétriques (comme RSA, DSA, DH...) dont les clefs ne sont pas du tout quelconques, mais des entiers choisis pour leurs propriétés arithmétiques (p.ex. un produit de très grands nombres premiers)
32**15 = 2**75
Il est impensable de craquer par force brute une clé de 75 bits.
-
D'un point de vue algorithmique, c'est un arbre, avec un algorithme récursifs on peut parcourir tout l'arbre ( c'est ce que doit implèmenter Google dans son bot ).
Non, pas du tout :
Un robot d'indexation (ou littéralement araignée du Web ; en anglais web crawler ou web spider) est un logiciel qui explore automatiquement le Web. Il est généralement conçu pour collecter les ressources (pages Web, images, vidéos, documents Word, PDF ou PostScript, etc.), afin de permettre à un moteur de recherche de les indexer.
(...)
Pour indexer de nouvelles ressources, un robot procède en suivant récursivement les hyperliens trouvés à partir d'une page pivot. Par la suite, il est avantageux de mémoriser l'URL de chaque ressource récupérée et d'adapter la fréquence des visites à la fréquence observée de mise à jour de la ressource. Toutefois, si le robot respecte les règles du fichier robots.txt, alors de nombreuses ressources échappent à cette exploration récursive. Cet ensemble de ressources inexploré est appelé Web profond ou Web invisible.
https://fr.wikipedia.org/wiki/Robot_d%27indexation
-
.
-
WikiLeaks ? (non je plaisante)
Sur l'origine de ce nom :
Wikileaks is an uncensorable version of Wikipedia for untraceable mass document leaking and analysis. It combines the protection and anonymity of cutting-edge cryptographic technologies with the transparency and simplicity of a wiki interface.
Source : capture Internet Archive de http://www.wikileaks.org/wiki/Wikileaks:About (16/1/2008)
https://web.archive.org/web/20080116115132/http://www.wikileaks.org/wiki/Wikileaks:About
Il y a aussi :
http://www.wikistrike.com/
Slogan : "Rien ni personne n'est supérieur à la vérité"
Bon, en réalité c'est une immonde bouillie alter-comprenante.
-
Par ailleurs,
Fut un temps où on passait directement des root-servers vers les TLD,maintenant il y a les G-TLD.
Tu pourrais donner un exemple avant/après?
-
.
-
Pour ceux qui veulent avoir une idée du code en jeu dans la résolution de nom, dans unbound ça se joue dans iterator/iterator.c