Attention à la migration des DNS racines (qui arrive demain…)
Par Korben le 26 janvier 2010 | Nb visites : 809

Jusqu’en 1999, la RFC 1035 (manuel de référence) qui documente le protocole DNS, stipulait que la taille des paquets DNS ne pouvait dépasser 512 octets… Mais après cette date (1999 pour ceux qui suivent), la RFC 2671 a permis de supprimer cette limite, autorisant ainsi les paquets DNS plus volumineux.
La plupart des équipement réseaux ont donc suivi le mouvement et permettent actuellement le passage de paquets DNS supérieurs à 512 octets… Mais « la plupart » ne veux pas dire « tous ». Et c’est là qu’il risque d’y avoir du grabuge. En effet, à partir de demain (je sais, je vous préviens tard), une migration des serveurs DNS racines débutera afin de pouvoir diffuser les zones en les signants avec DNSSEC. DNSSEC permet de chiffrer les transactions DNS d’un bout à l’autre de la chaine, afin d’éviter qu’un serveur DNS parasite modifie la requête et transmette une résolution DNS vérolée au client. Je ne vais pas m’étendre sur le sujet car le DNSSEC c’est pas non plus mon coeur de métier mais allez jeter un oeil ici.
Du coup, d’ici juillet, les 13 serveurs DNS racines auront été migrés et diffuseront tous des paquets DNSSEC… Ce qui signifie vous l’aurez compris, des paquets supérieurs à 512 octets, que dis-je, supérieurs à 1500 octets ! Et c’est là que ça coince. Car il existe encore pas mal de vieux routeurs, firewalls et équipements réseaux divers et variés qui trainent un peu partout sur cette planète et que personne n’a mis à jour. Ces derniers n’acceptent donc pas les paquets DNS > 512 octet ou même si ils les acceptent, ne sont pas capables de les fragmenter correctement, privant le réseau derrière cet appareil, à un accès internet. Il risque donc d’y avoir quelques surprises.
Pour tester si votre réseau est impacté par ce problème, j’ai trouvé un série de tests expliqués ici. Il suffit de faire un dig sur ce serveur de test (ça se fait très bien dans une console sous linux) :
dig +short rs.dns-oarc.net txt
Et pour les windowsiens (Merci Dju) :
nslookup -q=txt rs.dns-oarc.net
Et voici la réponse que vous devez avoir :
rst.x4001.rs.dns-oarc.net.
rst.x3985.x4001.rs.dns-oarc.net.
rst.x4023.x3985.x4001.rs.dns-oarc.net.
« 192.168.1.1 sent EDNS buffer size 4096″
« 192.168.1.1 DNS reply size limit is at least 4023 bytes »
Les 2 dernières lignes indiquent que l’équipement réseau supporte des paquets de plus de 4000 octets. C’est super cool, ça veut dire que vous n’aurez pas de soucis. Si vous êtes en dessous des 4000, ça risque de poser des petits soucis. Voici ce que moi j’ai eu via ma freebox :
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
« 208.69.xxx.xxx DNS reply size limit is at least 490″
« 208.69.xxx.xxx lacks EDNS, defaults to 512″
« Tested at 2010-01-26 20:40:36 UTC »
On voit bien que par défaut le routeur auquel je suis connecté n’accepte pas de paquets supérieur à 512 … gloups. Mais en lisant cet article, j’ai complété mes tests avec cette requête DNS en forçant le DNSSEC. Et j’ai bien reçu la réponse (!!), ce qui semblerait indiquer que ma situation n’est pas si gloups que ça. (Mais au final, je n’en sais foutre rien !)
dig +dnssec @192.134.0.49 DNSKEY ripe.net
Je pense de toute façon que Free et les FAI en général ont bien fait leur boulot. Mais qu’en est il des petits réseaux d’entreprises ou d’université ? On le saura entre demain et juillet 2010. Mais si vous n’avez plus internet pour une raison inexpliquée, pensez à vérifier le MTU de vos machines sur le réseau (pare-feu, middlebox, routeur and co…)
En attendant, si vous souhaitez plus de matière à ce sujet, je vous recommande d’aller lire :
- System-Linux (ma source ! Merci Jeremy pour l’info !)
- Le plan d’action de cette migration en PDF
- Le site officiel du passage au DNSSEC
- La petite appli java pour tester la taille de vos paquets
- La liste des tests cités précédemment
- Et les explications de Bortzmeyer, le gourou français du DNS !
Je vous recommande aussi la lecture des sujets suivants
- 12 applications iPhone pour les admins réseaux
- Comment pirater Home sur Playstation 3 et supprimer les publicités
- Free censure mon site ?
- AirSnare – Pour savoir si votre voisin utilise votre réseau Wifi
- DNS Google – Mais pour quoi faire ?
- Un CDN (Content Distribution Network) rien que pour vous, offert par Google
- Google SPDY et Google GO
- Un seul hébergeur produisait les 2/3 du spam mondial
- ItsHidden – Le VPN gratuit enfin accessible en Beta
- Le pot de miel Google







Nath
Les pauvres root. Si peu de répits.
Merci de l’info Korben
Posté le 26 janvier 2010 à 22:13:39
Dexter
Entre ça et le passage au tout numérique TV, avec un peu de (mal)chance, y en a qui vont plus avoir internet et plus de TV… lol et bonne année :p
Posté le 26 janvier 2010 à 22:13:53
swats
et pour nous autres utilisateur lambda d’internet, ca va nous toucher de quelle maniere ????
Posté le 26 janvier 2010 à 22:21:05
ExploZe
Mais FU, c’est quoi encore ça chez moi (NUMERICABLE 100Mbits) j’ai 512 en retour mais la requete qui est :
dig +dnssec @192.134.0.49 DNSKEY ripe.net
Fonctionne donc a priori (a priori) c’est bon !
Huhu
On vera bien :S
Posté le 26 janvier 2010 à 22:21:50
Nath
Rien du tout si ton FAI opère à le matériel nécessaire ( j’espère ) et que ta box sait le gérer ( j’espère bis )
Posté le 26 janvier 2010 à 22:22:10
ExploZe
C’est la fin SkyNet va prendre le contrôle de toute nos box :S…
sur les 3/4 de la planète ça srai plutôt drôle
PS : ça sent les truc qui va merder
EDIT : Chez moi uniquement dig +dnssec @192.134.0.49 DNSKEY ripe.net Passe!
L’autre m’indique également 512 :S
Posté le 26 janvier 2010 à 22:25:38
ExploZe
Mais fu C’est quoi ce truc anti spam dans les commentaire je met simplement une commande dig …
Zubair
Posté le 26 janvier 2010 à 22:28:18
krg
hummm sur du matos récent, cela devrait le faire,non ? lol va falloir que je me renseigne au taf voir si ils ont prévu le coup, ( même si on est relier direct a renater j’ai tout de meme un doute )
Posté le 26 janvier 2010 à 22:34:56
rafarinarde argentee
>nslookup
Default Server: resolver1.opendns.com
Address: 208.67.222.222
> rs.dns-oarc.net
Server: resolver1.opendns.com
Address: 208.67.222.222
Non-authoritative answer:
Name: rst.x490.x485.x476.rs.dns-oarc.net
Address: 67.215.65.132
Aliases: rs.dns-oarc.net, rst.x476.rs.dns-oarc.net
rst.x485.x476.rs.dns-oarc.net
avec openDNS.
Bon ça veut dire que ça marche po ?
Posté le 26 janvier 2010 à 22:42:38
Phantom
dig +short rs.dns-oarc.net txt
rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
« 213.228.56.17 DNS reply size limit is at least 3843″
« 213.228.56.17 sent EDNS buffer size 4096″
« Tested at 2010-01-26 21:14:25 UTC »
Impec pour moi
Posté le 26 janvier 2010 à 22:44:56
sly
arg je viens de vérifier plusieur réseau ils sont inférieur a 4000 :/
Posté le 26 janvier 2010 à 22:48:25
transforcom
avec ma freebox j’obtiens la même chose que toi mes connectés derrière un VPN (its hidden) j’obtient les lignes suivantes qui laisse présager que du bon :
rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
« 94.75.220.1 DNS reply size limit is at least 3843″
« Tested at 2010-01-26 21:50:47 UTC »
« 94.75.220.1 sent EDNS buffer size 4096″
Je sais pas ce que tu en pense mais c’était juste pour te le dire…
Posté le 26 janvier 2010 à 22:51:49
Sergio
Je sens que demain va etre une longue et dure journée.. Merci pour l’info Korben je n’en avais meme pas entendu parler!
Posté le 26 janvier 2010 à 23:01:28
Sass
J’ai vu pas mal de fossiles à l’INSA de Lyon, je sens qu’on va avoir du travail :/
Posté le 26 janvier 2010 à 23:06:15
titoune
Et genre moi qui utilise un routeur perso DLINK depuis 2005, ca veut dire quoi ? que si DLINK ne fournit ce qu’il faut pour rendre mon routeur compatible je l’ai dans l’os ? Que puis je faire ?
Posté le 26 janvier 2010 à 23:09:24
Sahl
Un modem classique peut être impacté par ce problème ? Du genre mon Speedtouch 330 va cesser de fonctionner sous peu ? Woot, ça promet
Posté le 26 janvier 2010 à 23:16:54
guilde
Pour plus avoir d’internet aussi y’a Hadopi et le firewall open office.
Posté le 26 janvier 2010 à 23:17:00
GanGan
Je me demandais qui avait fait péter les records de notre blog… je crois que j’ai trouvé
Posté le 26 janvier 2010 à 23:21:44
Sahl
DNS Aol ( SFR ) 486; insuffisant donc et sur itshidden j’ai les mêmes résultats que transforcom.
Bref, on verra ça
Posté le 26 janvier 2010 à 23:26:33
Kevin
dig +dnssec @192.134.0.49 DNSKEY ripe.net
; <> DiG 9.6.1-P2 <> +dnssec @192.134.0.49 DNSKEY ripe.net
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
c’est pas bon ça, c’est-ce pas … ?
(VirginMedia@Londres powaa)
Posté le 26 janvier 2010 à 23:30:32
bartounet
J’ai dut mal à comprendre.
Je fais un peu de réseau, et j’ai du mal à comprendre en quoi les routeurs et les switchs vont être impactés.
DNS n’est qu’un transfert de paquets udp, après c’est au niveau de la couche 7 que ca se passe.
Peut etre que certains routeurs fonctionnent dans des couches supérieures, les firewall par exemple oui, mais un pauvre routeur basique comme les box ne fait a mon avis que router les paquets non??
Posté le 26 janvier 2010 à 23:31:20
Dju
marrant, avec mon routeur sous ‘nux qui a le dernier bind, la 1e ligne ne passe pas et répond « lacks EDNS, default to 512″ … argh !
mais en forçant avec +dnssec ça passe donc c’est bon
et pour tous les utilisateurs de Bind ayant une version récente, la taille maximale par défaut d’un buffer EDNS est à 4096. ( –> http://www.zytrax.com/books/dns/ch7/hkpng.html#edns-udp-size )
Posté le 27 janvier 2010 à 00:04:31
Arnaud E.
Y’a pas une ligne de commande pour Windaube ?
Posté le 27 janvier 2010 à 00:04:57
Dju
@Arnaud E.: si
nslookup -q=txt rs.dns-oarc.net
Posté le 27 janvier 2010 à 00:11:57
Arnaud E.
@Dju: Nikel tu gère.
Free Dégroupé à Bordeaux:
« 213.228.63.13 DNS reply size limit is at least 3843″
rst.x3843.x3837.x3827.rs.dns-oarc.net text =
« 213.228.63.13 sent EDNS buffer size 4096″
rst.x3843.x3837.x3827.rs.dns-oarc.net text =
« No soussaille » visiblement
Posté le 27 janvier 2010 à 00:32:02
Liane
merci pour l’info,
Il semble que pour free (Paris), cela ne pose pas de problème:
« 213.228.63.13 DNS reply size limit is at least 3843″
« 213.228.63.13 sent EDNS buffer size 4096″
« Tested at 2010-01-26 23:32:18 UTC »
Posté le 27 janvier 2010 à 00:40:44
JoEyInBoX
Damn!
Même résultat que Korben… So wait & see.
Merci pour l’info
Posté le 27 janvier 2010 à 00:51:50
LordJerem
jerem@jerem-desktop:~$ dig +short rs.dns-oarc.net txt
;; connection timed out; no servers could be reached
Pas de chance chez moi ><
Posté le 27 janvier 2010 à 01:19:38
Deadeye
Ca va couper!!!
Ha, c’est pas zhadopi? Zut alors…. bon je recommence…
Ca va Bugger!!!!
Posté le 27 janvier 2010 à 01:26:32
Khady
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
« 89.2.3.82 lacks EDNS, defaults to 512″
« Tested at 2010-01-27 00:53:08 UTC »
« 89.2.3.82 DNS reply size limit is at least 490″
Numéricable 100M, ca va faire mal
Posté le 27 janvier 2010 à 01:51:26
babelkot
Chez Belgacom(pour les belges)ça donne »defaults to 512″.
Nous sommes le 27 et la connexion + télé fonctionnent parfaitement…Ceci dit si c’est entre 19 et 21 heures comme prévu,c’est mal barré…
Posté le 27 janvier 2010 à 02:02:28
Tsukasa
Je vais vous dire! moi je verai bien quand ca bloquera! je peterai mon scandale a orange en leur parlant des autres verités comme des debits en baisse, etc!
donc au final quand ils auront 100 000/150 000 plainte de ce genre ils se bougerot peut etre!
mais perso j’espere que j’aurai pas ce probleme!
Posté le 27 janvier 2010 à 02:38:03
Sam
Yep ca roule
Merci très intéressant.
Posté le 27 janvier 2010 à 02:40:51
DNSSE va remplacer DNS « vinylourson.com
[...] de Domaines qui à l’heure actuelle présente des risques de sécurité (voir article sur korben.info). Pour faire simple, les paquets contenant la résolution DNS, qui vous indique vers quel adresse IP [...]
Posté le 27 janvier 2010 à 04:32:15
BlackKrystal
Serveur : dns2.proxad.net
Address: 212.27.40.241
Réponse ne faisant pas autorité :
rs.dns-oarc.net canonical name = rst.x3827.rs.dns-oarc.net
rst.x3827.rs.dns-oarc.net canonical name = rst.x3837.x3827.rs.dns-oarc.net
rst.x3837.x3827.rs.dns-oarc.net canonical name = rst.x3843.x3837.x3827.rs.dns-oa
rc.net
rst.x3843.x3837.x3827.rs.dns-oarc.net text =
« 213.228.63.32 DNS reply size limit is at least 3843″
rst.x3843.x3837.x3827.rs.dns-oarc.net text =
« 213.228.63.32 sent EDNS buffer size 4096″
rst.x3843.x3837.x3827.rs.dns-oarc.net text =
« Tested at 2010-01-27 07:00:58 UTC »
x3843.x3837.x3827.rs.dns-oarc.net nameserver = ns00.x3843.x3837.x3827.rs.d
ns-oarc.net
ns00.x3843.x3837.x3827.rs.dns-oarc.net internet address = 149.20.58.136
Chez Free, ligne flambant neuve installée dans mon ancien lycée ou je fais actuellement mon stage.
Dans l’aprem je teste avec la vieille Livedaube de mes parents, le matos date de 2006. C’est pas gagné…
Posté le 27 janvier 2010 à 08:01:47
stakhanov
Même résultats que Arnaud E, bien que chez un FAI suisse. Donc à priori pas de soucis non plus……
Et merci à Dju pour la ligne de commande sous windaube ! Et bien sûr à Korben pour l’info !
Posté le 27 janvier 2010 à 08:04:36
Philippe
Ca va encore faire du bizness tout ca …
Posté le 27 janvier 2010 à 08:13:42
MrGSM
Pour les tests sur Windows???
Posté le 27 janvier 2010 à 08:15:31
stakhanov
@ MrGSM : si tu lisais les comms correctement, tu verrais que Dju a donné la ligne de commande pour Windaube…..
Posté le 27 janvier 2010 à 08:22:32
Keizo
Soucis chez moi j’ai une livebox chez moi j’ai fait la commande @Dju et petit soucis j’obtient ça :
Serveur : HSIB.home
Address: 192.168.1.1
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Le délai de la requête sur HSIB.home est dépassé.
quelqu’un aurait une piste sur laquelle m’éclairer ? après 5 tentative jvient vous demander votre aide
Posté le 27 janvier 2010 à 09:05:42
Cekage
Et pour ceux qui ont Mac OS ou FreeBSD, la ligne est identique à celle de linux.
Orange PRO ADSL :
$ dig +short rs.dns-oarc.net txt
rst.x1247.rs.dns-oarc.net.
rst.x1257.x1247.rs.dns-oarc.net.
rst.x1228.x1257.x1247.rs.dns-oarc.net.
« 209.85.128.94 DNS reply size limit is at least 1257″
« 209.85.128.94 sent EDNS buffer size 1280″
« Tested at 2010-01-27 08:06:50 UTC »
Orange SDSL :
$ dig +short rs.dns-oarc.net txt
rst.x476.rs.dns-oarc.net.
rst.x905.x476.rs.dns-oarc.net.
rst.x1086.x905.x476.rs.dns-oarc.net.
« 80.12.2.8 DNS reply size limit is at least 1086″
« 80.12.2.8 sent EDNS buffer size 4096″
« Tested at 2010-01-27 08:13:10 UTC »
Y’a 2 vitesses chez orange, les forfaits a quelques dizaines d’euros et les forfaits a quelques centaines d’euros ….
Posté le 27 janvier 2010 à 09:15:51
Cekage
Je n’arrive pas a forcer 80.12.2.8 sur la ligne ADSL et 209.85.128.94
Sur une ligne avec une freebox v4 ND depuis une gentoo :
$ dig +short rs.dns-oarc.net txt
rst.x1247.rs.dns-oarc.net.
rst.x1257.x1247.rs.dns-oarc.net.
rst.x1228.x1257.x1247.rs.dns-oarc.net.
« Tested at 2010-01-27 08:24:50 UTC »
« 209.85.228.94 sent EDNS buffer size 1280″
« 209.85.228.94 DNS reply size limit is at least 1257″
mais également, dans les memes condition :
$ dig +short rs.dns-oarc.net txt
rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
« 213.228.63.26 DNS reply size limit is at least 3843″
« 213.228.63.26 sent EDNS buffer size 4096″
« Tested at 2010-01-27 08:23:26 UTC »
Le test est peut être fiable au niveau des données entrées par une extrémité du tuyau, mais il y a trop de variables entrant en jeu jusqu’au moment où ça sort …
Si qqn a une explication technique à a ce que je reçois comme résultat, je suis preneur !
Posté le 27 janvier 2010 à 09:26:46
DeathWarrior
Chez Orange avec Livebox pro
Réponse ne faisant pas autorité :
rs.dns-oarc.net canonical name = rst.x1002.rs.dns-oarc.net
rst.x1002.rs.dns-oarc.net canonical name = rst.x1222.x1002.rs.dns-oarc.net
rst.x1222.x1002.rs.dns-oarc.net canonical name = rst.x1403.x1222.x1002.rs.dns-oa
rc.net
rst.x1403.x1222.x1002.rs.dns-oarc.net text =
« 80.12.255.9 DNS reply size limit is at least 1403″
rst.x1403.x1222.x1002.rs.dns-oarc.net text =
« 80.12.255.9 sent EDNS buffer size 4096″
rst.x1403.x1222.x1002.rs.dns-oarc.net text =
« Tested at 2010-01-27 08:33:36 UTC »
1403… ça sent pas bon ou ça sent bon?
Posté le 27 janvier 2010 à 09:33:26
fabulon
Pour moi chez le neuf:
Serveur : neufbox
Address: 192.168.1.1
Réponse ne faisant pas autorité :
rs.dns-oarc.net canonical name = rst.x476.rs.dns-oarc.net
rst.x476.rs.dns-oarc.net canonical name = rst.x485.x476.rs.dns-oarc.net
rst.x485.x476.rs.dns-oarc.net canonical name = rst.x490.x485.x476.rs.dns-oarc.net
rst.x490.x485.x476.rs.dns-oarc.net text =
« 86.64.xxx.xx DNS reply size limit is at least 490″
rst.x490.x485.x476.rs.dns-oarc.net text =
« 86.64.xxx.xx lacks EDNS, defaults to 512″
rst.x490.x485.x476.rs.dns-oarc.net text =
« Tested at 2010-01-27 09:01:39 UTC »
C’est pas tôoop!
Posté le 27 janvier 2010 à 10:01:19
suredj
ca m’étonne qu’a peine de la part de orange …
Sinon comme il est dit plus haut je ne voit pas trop en quoi cela va impacter le petit particulier étant donné que le routage se fait en amont.
Il faut juste que l’opérateur ou le prestataire par lequel il passe ai du matériel de moins de 10 ans (?) … ce qui est certainement le cas pour tous (ou pas)
Bon les DNS c’est pas non plus mon dada alors je peux aussi ne pas avoir tout compris
Posté le 27 janvier 2010 à 10:06:19
Gourmet
Ouais, euh.
il y a quelques confusions.
L’Internet s’accomode parfaitement de la fragmentation IP, encore heureux.
Des paquets UDP ou TCP voire ECP (ipsec) de longueur > plusieurs milliers d’octets sont courants tout de même.
Pour ce qui est de DNSSEC, des racines signées ne signifie pas qu’un client va DEVOIR les prendre en compte (ces signatures).
Heureusement ! Vous imaginez le bordel si, Ã partir du 1er juillet 2010, TOUS les clients et serveurs DNS du monde devaient migrer.
Ce ne sont pas 6 mois qu’il faudrait mais des années (ou des siècles) !
C’est aussi pour cela que l’on n’en entend pas parler. Ca ne concerne, au mieux, que les administrateurs scrupuleux souhaitant valider les signatures.
Ce qu’il ne pourront faire, de toutes les manières, qu’à partir du 1/07/2010.
Ca peut concerner également quelques bidouilleurs Unix voulant s’amuser avec leur bibliothèque resolv.
En clair, si vous n’administrez pas de serveurs ou si vous en administrez mais n’êtes pas sérieux (ou préoccupés par le poisonning des serveurs) alors vous n’êtes pas concernés.
db
Posté le 27 janvier 2010 à 10:11:26
Kekounet
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
« 92.141.124.237 DNS reply size limit is at least 490″
« 92.141.124.237 lacks EDNS, defaults to 512″
« Tested at 2010-01-27 09:03:08 UTC »
Hum, ça sens pas bon pour moi demain :s (livebox dans ma boîte)
Posté le 27 janvier 2010 à 10:12:29
Kekounet
Pas mieux dans mon autre boîte qui est pourtant en offre sdsl pro. Etre chez ORANGE/OLEANE ça me fait de plus en plus flipper avec le temps… Sont de plus en plus mauvais :s
Posté le 27 janvier 2010 à 10:17:13
Francois.l
Cool, j’avais vu passer l’info nul-part
Posté le 27 janvier 2010 à 10:22:50
Stéphane Bortzmeyer
@Gourmet: Non, c’est tout à fait faux. Même si on n’envisage pas de déployer DNSSEC, on peut être impacté. Les résolveurs (notamment BIND) mettent le bit DO (« je veux du DNSSEC ») par défaut et recevront (ou pas) donc les réponses signées même s’ils ne les valident pas.
Donc, ne vous croyez pas tranquille même si vous ne voulez pas faire de DNSSEC.
Posté le 27 janvier 2010 à 10:59:48
Stéphane Bortzmeyer
@suredj: Ce n’est pas tant un problème de matériel que de logiciel. Il y a par exemple des tas de pare-feux qui sont *capables* de recevoir les réponses DNS de plus de 512 octets mais qui n’ont pas été *configurés* pour cela (par ignorance ou incompétence).
Posté le 27 janvier 2010 à 11:01:12
Stéphane Bortzmeyer
@DeathWarrior: Pas génial : votre résolveur gère EDNS et reçoit les réponses supérieures à 512 octets mais ne reçoit pas celles de plus de 1500 octets, probablement suite à un problème de MTU (filtrage ICMP par un parefeu configuré avec les pieds ?)
Posté le 27 janvier 2010 à 11:02:32
[Tutoriels] Comment tester un serveur DNS pour DNSSEC ? | Bastien Louche
[...] Sources et Informations supplémentaires : [1] [2] [...]
Posté le 27 janvier 2010 à 11:08:27
Stéphane Bortzmeyer
@Cekage: Free a plusieurs machines qui jouent le rôle de résolveur derrière chaque adresse IP vue par le client (regardez l’adresse IP du résolveur dans la sortie de dig, ce n’est pas la même). Il est bizarre que ces machines n’aient pas la même configuration mais, bon, c’est Free
Posté le 27 janvier 2010 à 11:09:53
Stéphane Bortzmeyer
@babelkot: De toute façon, ce soir, ce n’est que le premier serveur racine qui bascule. Les résolveurs mal configurés ou mal connectés vont se rabattre sur les autres. S’il y a un problème, il se produira en juillet, quand *tous* les serveurs racine diffuseront des informations signées.
Posté le 27 janvier 2010 à 11:11:43
Stéphane Bortzmeyer
@bartounet: Non, la plupart des boxes ne sont *pas* des routeurs basiques et elles font beaucoup de conneries. Voir le RFC 5625 http://www.bortzmeyer.org/5625.html
Dans un réseau bien fichu, les routeurs ne travaillent que sur la couche 3. Mais, dans le monde réel…
Posté le 27 janvier 2010 à 11:14:04
Stéphane Bortzmeyer
@titoune: Déjà , il faut tester, comme indiqué par le message original. Après, on verra.
Posté le 27 janvier 2010 à 11:15:25
Carmin.D
« Il a Free, il a tout compris »
Posté le 27 janvier 2010 à 12:00:54
Esquire
Aie ! au taff, le pix est configuré a 512…
on va essayer de le reconfigurer mais la doc n’indique pas si on peut passer outre les 1500 octets et comme il est vieillissant, on se pose des questions.
Une idée de la taille du paquet?
Posté le 27 janvier 2010 à 12:01:21
Raito Kun
rs.dns-oarc.net canonical name = rst.x3827.rs.dns-oarc.net
rst.x3827.rs.dns-oarc.net canonical name = rst.x3837.x3827.rs.dns-oarc.net
rst.x3837.x3827.rs.dns-oarc.net canonical name = rst.x457.x3837.x3827.rs.dns-oar
c.net
rst.x457.x3837.x3827.rs.dns-oarc.net text =
rst.x457.x3837.x3827.rs.dns-oarc.net text =
« 62.251.230.71 sent EDNS buffer size 4096″
rst.x457.x3837.x3827.rs.dns-oarc.net text =
« 62.251.230.71 DNS reply size limit is at least 3837″
w0000t
Posté le 27 janvier 2010 à 12:13:13
Stéphane Bortzmeyer
@Esquire: Virer l’administrateur du PIX me parait un bon point de départ. Après cela, on peut regarder la doc de Cisco http://www.cisco.com/web/about/security/intelligence/dns-bcp.html Le PIX est pénible car il a toujours cette limite à 512 octets, plus de dix ans après sa suppression ! Mais, au moins, Cisco fournit une documentation détaillée pour le reconfigurer proprement.
Posté le 27 janvier 2010 à 12:14:31
Obo
Bonjour à tous !
Questions : est-ce que le plan d’action de migration concerne
l’Europe uniquement ?
Qu’en est-il du Canada par exemple ?
Merci pour vos réponses !
Posté le 27 janvier 2010 à 12:17:35
GanGan
ça concernera le monde entier quant ils auront basculer tous les serveur DNS racine.
Posté le 27 janvier 2010 à 12:52:19
Obo
@GanGan : merci pour la précision !
Posté le 27 janvier 2010 à 13:16:10
le hollandais volant
flute !
je vais encore devoir lui expliquer pendant 3 heures pourquoi elle doit changer un truc dans la box (c’est elle qui a le MDP
).
À la maison c’est ma mère qui gère la box, et elle y connait rien
La dernière fois, j’ai du lui expliquer ce qu’étais une adresse IP, un nom de de domaine et comment fonctionnent les serveurs DNS, et lui expliquer pourquoi je voulais configurer la box avec OpenDNS, pour qu’elle daigne venir me taper le mot de passe afin que je configure tout ça.
Ma box (un netgear) indique 512
»
nooooooooooooooooooooon !!!!!!
Posté le 27 janvier 2010 à 13:30:53
Dr.pepper
Idem, je rectifie le problème au plus vite.
Merci pour l’info, Korben !
Posté le 27 janvier 2010 à 13:48:28
Vouze
>> « la plupart » ne veux pas
C’est « veut » ou « veulent » (les deux sont admis), mais pas « veux ».
Posté le 27 janvier 2010 à 14:09:21
exdeus
Effectivement la box neuf ou je me connecte en « invite » est inopérante aujourd’hui
Posté le 27 janvier 2010 à 14:31:00
Michel Moustache
Ceux qui vont en ch… c’est surtout les MILLIONS d’utilisateurs de Qmail. Pourquoi ? Parce que le SMTP croit bon de faire des requêtes any en udp au lieu d’un simple mx, ne lit pas le bitflag qu’il faut passer en tcp, et ignore tous les messages de plus de 512o. Et les devs sont têtus. On va bien rire.
Posté le 27 janvier 2010 à 14:33:21
Dixours
J’ai un peu de mal à croire que ça va foutre le bouzin cette histoire. Mais n’étant pas non plus un pro dans le domaine….
En tout cas, chez Orange, ça ne passe pas chez moi. Mais je ne suis pas très soucieux
Posté le 27 janvier 2010 à 14:36:03
mattt
C:\>nslookup -q=txt rs.dns-oarc.net
Serveur : ***.***.intra
Address: **.**.**.**
Réponse ne faisant pas autorité :
rs.dns-oarc.net canonical name = rst.x476.rs.dns-oarc.net
rst.x476.rs.dns-oarc.net canonical name = rst.x485.x476.rs.dns-oarc.net
rst.x485.x476.rs.dns-oarc.net canonical name = rst.x490.x485.x476.rs.dns-oarc.net
rst.x490.x485.x476.rs.dns-oarc.net text = « 213.56.26.133 DNS reply size limit is at least 490″
rst.x490.x485.x476.rs.dns-oarc.net text = « 213.56.26.133 lacks EDNS, defaults to 512″
rst.x490.x485.x476.rs.dns-oarc.net text = « Tested at 2010-01-27 15:08:19 UTC »
je suis dans une « grosse » boite publique à Lyon, et ca peut expliquer les problemes qu’on erncontre depuis ce matin
Posté le 27 janvier 2010 à 16:12:32
Vlad
Petite question juste comme ca :
une attaque DNS (réflexion) consiste à spoofer son IP avec celle d’une victime afin qu’il reçoive la réponse UDP. En faisant une requête qui aura une grosse réponse on fait de l’amplification et donc là commence le Denial Of Service.
Avec DNSSEC, on a une petite requête (normale, en UDP) qui reçois une grosse trame qui peut même être fragmentée.
Ca sent le DOS facile ca, non ?
Posté le 27 janvier 2010 à 16:16:38
PulpVision
Hello tous !
Je viens d’essayer la commande sur win et voici ce que j’ai :
————————–
C:\Documents and Settings\*USER*>nslookup -q=txt rs.dns-oarc.net
Serveur : livebox.home
Address: 192.168.1.1
DNS request timed out.
timeout was 2 seconds.
*** Le délai de la requête sur livebox.home est dépassé
————————–
J’ai absolument pas les mêmes résultats… que pensez vous faire pour bien effectuer ce test avec une connec orange et une livebox ?
Posté le 27 janvier 2010 à 16:58:38
Stéphane Bortzmeyer
@mattt: Non, ça n’explique rien puisque la diffusion des réponses signées ne commence qu’à 2100 heure française. Et,d e toute façon, le déploiement sera progressif (un serveur à la fois). S’il y a des problèmes, ce sera lors du basculement du dernier serveur, en juillet.
Posté le 27 janvier 2010 à 16:59:04
Stéphane Bortzmeyer
@Vlad: Nul besoin de DNSSEC pour cela. Comme l’attaquant choisit la requête, il peut la mettre pour un domaine qu’il contrôle, avec un enregistrement TXT de 4096 octets…
Posté le 27 janvier 2010 à 17:00:04
Manu1400
@Korben : « DNS > 512 octet » au lieu de « DNS > 512 octets »
Posté le 27 janvier 2010 à 17:37:34
titou
Arf… je suis chez orange et j’ai encore la première livebox inventel… on m’en dis que du bien mais je donnerai pas mal pour avoir la dernière et virer cette @#~%ù…
Korben, comme toi le premier test a échoué mais le second (sur ton lien) fonctionne… On va bien voir demain…
Posté le 27 janvier 2010 à 18:12:07
Doc_XP
Lol…
nslookup -q=txt rs.dns-oarc.net
Serveur : dns-adsl-gpe1-a.wanadoo.fr
Address: 80.10.246.1
DNS request timed out.
timeout was 2 seconds.
*** Le délai de la requête sur dns-adsl-gpe1-a.wanadoo.fr est dépassé.
Oups… Les DNS Orange merdouillent ou c’est le pare-feu intégré à la LB ?
Posté le 27 janvier 2010 à 18:34:31
Nosco
Mmmh! Effectivement avec les vieux matériels ça va merdouiller :/ !
Heuresement j’ai une solution (ou plutôt j’avais envie de coder un petit script) quoi qu’il en soit l’ami Nosco est lÃ
…
Alors la solution fasse à des erreurs de DNS, c’est de ne pas utiliser les DNS mais plutôt les adresse IP! La vous allez me dire, mais c’est chian heuuuuu. Effectivement ça peut paraître lourd, mais quand vous verrez « http://korben.info » inconnu au bataillon parce que orange n’aura pas upgradé votre matériel depuis l’an 8, vous serez bien embetté!
C’est la que vient à la rescousse mon charmant script! Son fonctionnement se résume à :
1) Vous entrez l’url (ce qui nécessite que les DNS fonctionne à ce moment là hein)!
2) Le script vous renvoie l’adresse ip correspondant au site!
3) Il vous propose d’enregistrer la correspondance « url – ip » dans un fichier « list.ip » spécialement créé pour l’occasion dans le dossier depuis lequel vous executez le script.
4) Vous répondez « 1″ (oui), il enregistre. « 2″ (non), il quitte et ne sauvegarde rien.
Si vous reexecutez le script et que vous reenregistrez le résultat, il sera inscrit à la fin du fichier. Cela veut dire que vous executez autant de fois que nécessaire (selon le nombre de site dont vous voulez l’ip) et à la fin, vous aurez un beau fichier list.ip contenant vos ip chérie! Et là , plus besoin de DNS
.
Bon le système à ses limites je le reconnais, par exemple vous pouvez pinguer 30 fois http://google.fr, vous n’aurez jamais la même ip qui ressortira, mais pour des sites hébergé à une seule et même adresse sur un seul et même serveur, ça roule
!
Aussi rien ne vous empêche d’améliorer le script pour que le list.ip soit mis à jour en cas de changement, ou encore de faire une boucle pour ne pas à avoir à réexecuter le script si l’on veut rajouter plusieurs adresses en même temps, aussi plus important faire en sorte que le programme n’attende pas bêtement dans le cas ou le nom de domaine n’existe pas (ou que les requêtes DNS sont mal traitées, ce qui ici pourrait être le cas!) enfin le choix est large… Si j’ai le temps je corrigerai surtout le dernier point pour éviter que le programme ne réponde rien si l’url entrée ne peut être pinguée.
Voilà le script:
#!/bin/bash
echo ‘######################URL TO IP TRANSFORMER#######################’
read -p « Je veux l’ip correspondant à http:// » url
ip=$(ping -c 1 $url | grep ‘(‘ | cut -d ‘(‘ -f 2 | cut -d ‘)’ -f 1 | uniq)
echo « L’ip de « $url » est « $ip
echo » »
echo « Rediriger le resultat vers le fichier list.ip ? »
read -p « -1 Oui // -2 Non. Reponse: » reponse
if [ $reponse = 1 ]
then
echo « L’ip de « $url » est « $ip >> list.ip
echo « Terminé. »
elif [ $reponse = 2 ]
then
echo « Terminé. »
else
echo « Mauvais choix. »
fi
_____
Pour les débutants je rajoute comment le rendre fonctionnel (executable):
1) On le rend executable avec:
-En ligne de commande: chmod +x nom_du_script
-Avec nautilus (ou autre): clic droit > droits > possibilité d’execution // (bon les noms peuvent varier mais vous voyez l’idée!)
2) On execute le script depuis un terminal:
./nom_du_script
Et ça démarre
!
_____
Amusez vous bien et au plaisir
!
Posté le 27 janvier 2010 à 19:31:57
Vlad
@Stéphane Bortzmeyer: pas si on limite justement à 512 octets, ce qui était la limite « avant ».
Posté le 27 janvier 2010 à 20:04:27
Nosco
Je poste un deuxième commentaire pour corriger un petit quelque chose:
Dans mon ancien commentaire (je ne peux plus l’éditer maintenant :/) j’ai écris:
« Aussi rien ne vous empêche d’améliorer le script pour que le list.ip soit mis à jour en cas de changement, ou encore de faire une boucle pour ne pas à avoir à réexecuter le script si l’on veut rajouter plusieurs adresses en même temps, aussi plus important faire en sorte que le programme n’attende pas bêtement dans le cas ou le nom de domaine n’existe pas (ou que les requêtes DNS sont mal traitées, ce qui ici pourrait être le cas!) enfin le choix est large… Si j’ai le temps je corrigerai surtout le dernier point pour éviter que le programme ne réponde rien si l’url entrée ne peut être pinguée. »
En fait ce n’est pas tout à fait ça, pour une url non existante il met le resultat du ping (hostname not found) et ne se bloque pas. Correction donc:
Aussi rien ne vous empêche d’améliorer le script pour que le list.ip soit mis à jour en cas de changement, ou encore de faire une boucle pour ne pas à avoir à réexecuter le script si l’on veut rajouter plusieurs adresses en même temps, [CORRECTION ICI] aussi plus important faire en sorte que le programme ne continue pas comme si de rien n’était dans le cas ou le nom de domaine n’existe pas (ou que les requêtes DNS sont mal traitées, ce qui ici pourrait être le cas!) enfin le choix est large… Si j’ai le temps je corrigerai surtout le dernier point pour éviter que le programme ne renvoie « L’adresse ip est » si l’url entrée ne peut être pinguée.
Voili voilou, c’est du détail, sinon le script fonctionne à merveille
.
Bonne soirée à tous.
Posté le 27 janvier 2010 à 20:44:25
Hirsu
Pour moi c’est pas bon non plus :s
Avec et sans mon routeur Netgear :s (direct sur la tite box noire pourrie en pppoe)
A moins qu’il faille que je modifie quelquechose dans mon Win….
OK, OK je passe bientôt à Ubuntu, mais bon…
Je suis chez Neuf et j’ai envie de passer chez Numéricable, faut dire que l’immeuble est connecté.
Quelqu’un a testé en étant chez Numéricable ?
ps : merci pour le script Nosco
Posté le 27 janvier 2010 à 23:00:39
JC
Chez Orange, sur un routeur Netgear :
Serveur : dns-abo-static-a.wanadoo.fr
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Le délai de la requête sur dns-abo-static-a.wanadoo.fr est dépassé
Posté le 27 janvier 2010 à 23:05:28
D A R T H
heu je n’y comprends pas grand chose…. je précise et je ne sais pas si sa sert
à quelque chose que j’ai une livebox « INVENTEL version : v5.10″… logo wanadoo
et pas orange et que j’utilise open dns
donc je tape cmd puis nslookup -q=txt rs.dns-oarc.net
et :
Serveur : resolver1.opendns.com
Address: 208.67.222.222
Réponse ne faisant pas autorité :
rs.dns-oarc.net canonical name = rst.x476.rs.dns-oarc.net
rst.x476.rs.dns-oarc.net canonical name = rst.x485.x476.rs.dns-oarc.net
rst.x485.x476.rs.dns-oarc.net canonical name = rst.x490.x485.x476.rs.dns-oarc.
net
rst.x490.x485.x476.rs.dns-oarc.net text =
« 208.69.35.15 DNS reply size limit is at least 490″
rst.x490.x485.x476.rs.dns-oarc.net text =
« 208.69.35.15 lacks EDNS, defaults to 512″
rst.x490.x485.x476.rs.dns-oarc.net text =
« Tested at 2010-01-27 22:17:55 UTC »
c’est grave docteur ? (et comme je n’ai pas trout compris je balise)
Alors ?
Posté le 27 janvier 2010 à 23:22:14
D A R T H
est ce que c’est spécifique au routeur ou à la box, ou aussi à notre config tcp ip (j’ai des réglages tweaké avec par exemple un mtu à 1492…) est ce que une mise à jour du firmware suffit ou faudra il changer de matos ?
Posté le 28 janvier 2010 à 00:04:06
babelkot
En tout cas nous sommes le 28 et malgré une réponse négative…pas de problème.
Posté le 28 janvier 2010 à 00:50:32
Hirsu
J’ai trouvé ça :
http://www.dslvalley.com/dossiers/mtu/mtu.php#modification (sans faire de recherche plus poussée)
Et chez moi, dans la base de registre, la valeur du MTU est à 514 !
Je vais peut-être tester ce soir, en faisant d’abord un sauvegarde de la base de registre.
Posté le 28 janvier 2010 à 08:00:35
eromog
J’ai eu droit à une réponse négative, je sais pas si c’est moi mais j’ai plein de problèmes de connexion… laptop spirit et pcinpact sont down, je peux pas me connecter à http://ftp.fr.debian.org Ca sent mauvais cette histoire…
Edit2: la migration doit être en cours, ya 10 minutes j’avais : « 213.228.63.46 DNS reply size limit is at least 490″
« 213.228.63.46 lacks EDNS, defaults to 512″
maintenant j’ai :
« 213.228.63.32 DNS reply size limit is at least 3843″
« 213.228.63.32 sent EDNS buffer size 4096″
« Tested at 2010-01-28 08:13:05 UTC »
arf et après ça revient à 512, c’est à y perdre son latin…
Posté le 28 janvier 2010 à 09:08:17
Stéphane Bortzmeyer
@eromog: 213.228.63.32 est un résolveur de Free. Chacun d’eux est composé de plusieurs machines, qui sont configurées différemment (pourquoi ? Mystère). D’où cette impression d’incohérence.
Cela n’a évidemment rien à voir avec la migration des serveurs racine. Ce test teste votre résolveur et ne dépend en rien des serveurs racine.
Posté le 28 janvier 2010 à 10:34:20
Stéphane Bortzmeyer
@babelkot: Normal, seul L.root-servers.net diffuse dorénavant des réponses signées. Les problèmes, s’il y en a, seront en mai, lorsque *tous* les serveurs racine auront migré. C’est pour cela qu’on prévient à l’avance !
Posté le 28 janvier 2010 à 10:35:17
Stéphane Bortzmeyer
@Vlad: Mais si, car la question ne venait pas réellement de la victime, elle était mensongère donc les précautions prises par la victime ne servent pas à grand’chose.
Posté le 28 janvier 2010 à 10:37:00
eromog
@Stéphane Bortzmeyer : donc si je comprend bien , tout ces sites down seraient dû à un problème technique de leur part et non pas de la mienne ? Bon sang même le pole emploi patine dans la choucroute… C’est la keynote d’apple qui les fait tous flancher ou quoi ?
Posté le 28 janvier 2010 à 10:59:16
DrWaX
C’est caca ça, je viens de tester sur notre réseau d’entreprise, je crois que je suis bon pour mettre à jour Bind et revoir la fragmentation des paquets du firewall.
Posté le 28 janvier 2010 à 11:21:20
Hirsu
Une question aux experts.
Est-t-il vraiment nécessaire de modifier la configuration de la taille des MTU de l’interface réseau ? (dans le cas biensûr où celle-ci est paramétrée sur 514 par exemple)
Et aussi, s’il en est, du MTU pour le PPPoE ou PPPoA ?
Posté le 28 janvier 2010 à 12:34:44
Edward
Dans le cas d’une interface réseau Ethernet filaire/WiFi, clairement pas (par contre, la valeur par défaut, pour ces cas, n’est pas de 514 :/(1500-> Ethernet ; 1496 -> WiFi)
Sinon, pour du PPPoE/PPPoA, ça dépend de ton matos ; ce n’est plus vrai maintenant, mais, avec du matériel (beaucoup) moins récent, la valeur par défaut pouvait ne pas être la bonne (ex un modem qui gère le PPPoE et le PPPoA et qui n’avait pas par défaut la bonne valeur) ce qui créait des soucis et il fallait donc rebasculer la valeur par défaut du MTU pour le protocole utilisé pour que les choses rentrent dans l’ordre).
Bref, la réponse est « si ça marche, laisse les valeurs par défaut du protocole » mais, en cas de problème avec les valeurs et si c’est clairement ça qui pose problème, tu peux toujours tenter une manip ou deux pour voir si une modification de la valeur du MTU n’arrange pas les choses.
A titre indicatif :
- Ethernet : MTU = 1500
- WiFi : MTU = 2272
- PPPoE : MTU = 1492
- PPPoA : MTU = 1500
Posté le 28 janvier 2010 à 13:27:44
Hirsu
@Edward
Merci beaucoup pour les infos.
Posté le 28 janvier 2010 à 15:02:10
Hirsu
En fait, si je demandais ça c’était surtout en rapport avec cette histoire de DNSSEC.
Le réglage de ces MTU (sur l’interface réseau etc…) a-t-il un rapport avec les résultats qu’on obtient en testant les paquets DNS ?
Posté le 28 janvier 2010 à 18:56:09
Philippe
Ca s’est bien passé alors ?
Posté le 29 janvier 2010 à 08:34:47
D A R T H
j’en ai parlé à beaucoup de monde et personne n’y comprend rien…
Posté le 29 janvier 2010 à 13:54:15
Korben
la migration sera terminée en juillet, donc faut être patient…
Posté le 29 janvier 2010 à 14:20:03
D A R T H
donc : je suis repassé en dns orange, c’est à dire propriété de la connexion, puis réglage de tcp/ip. A serveur DNS préféré j’ai remplacé les adresses DNS d’open DNS par celle d’orange gèrée par la livebox (inventel v1) soit : 192.168.1.1
Après avoir rebooté je tape cmd puis nslookup -q=txt rs.dns-oarc.net
et j’ai cette fois ci un message du genre :
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Le délai de la requête sur dns-abo-static-a.wanadoo.fr est dépassé
par contre tout marche nickel que ce soit en dns open dns et orange…
donc au final je ne sais rien.
Posté le 29 janvier 2010 à 15:11:28
mollo
Je vous donne deux liens complémentaires :
Rapport de tests poussés de divers équipements
http://download.nominet.org.uk/dnssec-cpe/DNSSEC-CPE-Report.pdf
Site de test, résultats par équipement
http://www.dnssec-tester.cz/
Posté le 29 janvier 2010 à 16:14:41