fin du service domain/53 aka DNS début mai

Pour discuter des différentes offres de connexion à Internet, par les différents fournisseurs d'accès. Il peut être question de l'ADSL dégroupé ou non, du cable, des offres numéris, RTC.

Modérateur: modos Ixus

fin du service domain/53 aka DNS début mai

Messagepar Franck78 » 18 Avr 2010 23:50

Salut

bon j'exagère un peu, le service existera toujours. Mais....
il risque d'être complètement cassé pour quelques-un

Comme tout le monde le sait, les serveurs racines vont se mettre à signer leurs réponses (en mai).

Donc ne soyez pas surpris, lisez, essayez de comprendre ceci

dig @8.8.8.8 +dnssec +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.228.94 DNS reply size limit is at least 1257"
"209.85.228.94 sent EDNS buffer size 1280"
"Tested at 2010-04-18 21:14:33 UTC"

8.8.8.8 est un serveur dns de google. Cette réponse serait bonne mais quelques part il y a de la fragmentation (d'après ce que j'ai compris). Le normal est un buffer de 4096 et des réponses de 4000 octets!


dig @x.x.x.130 +dnssec +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.
"x.x.x.130 sent EDNS buffer size 4096"
"Tested at 2010-04-18 21:46:36 UTC"
"x.x.x.130 DNS reply size limit is at least 3843"
nickel, mais qui ne valide pas IPCop au passage (=>blockout user: domain c'est udp ET tcp 53)

tandis que celui d'un fai grand public n'est pas à jour....

dig @86.64.233.85 +dnssec +short rs.dns-oarc.net txt
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"86.64.233.85 DNS reply size limit is at least 490"
"Tested at 2010-04-18 21:25:06 UTC"
"86.64.233.85 lacks EDNS, defaults to 512"



Liens:
google : "dns dnssec may 2010"
https://www.dns-oarc.net/oarc/services/replysizetest
http://www.system-linux.eu/index.php?po ... -!-%282%29
http://groups.google.com/group/public-d ... bdcd8bc679
Dernière édition par Franck78 le 19 Avr 2010 01:09, édité 1 fois au total.
Avatar de l’utilisateur
Franck78
Amiral
Amiral
 
Messages: 5625
Inscrit le: 20 Fév 2004 01:00
Localisation: Paris

Messagepar jdh » 19 Avr 2010 00:06

Merci de nous rappeler cette info Franck78 : mai c'est juste dans 12 jours !

(Pour ceux qui ne comprendrais pas, c'est Neuf/Sfr qui est cité.
Sauf patch de la Neufbox/Sfrbox, il faudra changer de serveur dns, si je comprends bien !)

La règle habituelle "la box fournit le dns, et particulièrement chez Orange/Wanadoo" risque d'être à remettre en cause ...

Et si c'est le DC Windows qui est le dns local, aura-t-il été mis à jour ?
Avatar de l’utilisateur
jdh
Amiral
Amiral
 
Messages: 4741
Inscrit le: 29 Déc 2002 01:00
Localisation: Nantes

Messagepar Franck78 » 19 Avr 2010 00:17

le test numéro 2 (celui à 4000) est fait avec un serveur Albanais. :lol: :lol:

nous avons le même FAI. D'ailleurs vu qu'il n'y en a que trois en france....



dig @86.64.233.85 -c CH -t txt version.bind

; <<>> DiG 9.6.1-P3 <<>> @86.64.233.85 -c CH -t txt version.bind
;; ANSWER SECTION:
version.bind. 86400 CH TXT "PowerDNS Recursor 3.2"


Etonnement, si ils n'ont pas mis n'importe quoi dans version.bind, ils ont mis à jour leur serveur très récemment et auraient pu configurer correctement la chose. Sacrés petits gars de chez n9uf/sfr :shock:
Franck
L'art de poser une question sur ce site afin d'obtenir la réponse
A LIRE
Avatar de l’utilisateur
Franck78
Amiral
Amiral
 
Messages: 5625
Inscrit le: 20 Fév 2004 01:00
Localisation: Paris

Messagepar jdh » 19 Avr 2010 00:49

Le document intitulé DNSSEC Impact on Broadband Routers and Firewalls à la fin de la page de OARC fait juste un peu peur !

Je ne maitrise pas du tout la syntaxe de "dig" mais en effet PowerDNS gère dnssec depuis la 2.9.21 !

Cela va m'obliger à inspecter firewall et serveur dns interne pour toutes les sociétés que je suis ...
Avatar de l’utilisateur
jdh
Amiral
Amiral
 
Messages: 4741
Inscrit le: 29 Déc 2002 01:00
Localisation: Nantes

Messagepar Franck78 » 19 Avr 2010 01:28

jdh a écrit:Je ne maitrise pas du tout la syntaxe de "dig" .


tout est dans le -c CH => class Chaosnet.

Jamais entendu parler! En gros, ca interroge autre chose que des 'zones' ;-)

Alors au vu du test décrit dans le doc cité par toi, je déclare que IPCop peut ne pas être OK. Je ne me mouille pas.
dnsmasq ipcop=2.45
dsnmasq avril 2010=2.52; utile pas utile?

@Gilles enfin l'occasion de sortir le patch Ipcop 1.4.22 ?
Franck
L'art de poser une question sur ce site afin d'obtenir la réponse
A LIRE
Avatar de l’utilisateur
Franck78
Amiral
Amiral
 
Messages: 5625
Inscrit le: 20 Fév 2004 01:00
Localisation: Paris

Messagepar hacksi » 21 Avr 2010 16:21

Les commandes dig me disent que je ne suis pas bon mais quand je vais tester sur le site http://n1.netalyzr.icsi.berkeley.edu/analysis/ je peux lire :

"No transport issues were discovered which could affect the deployment of DNSSEC"

Pas très clair tout ça...
Avatar de l’utilisateur
hacksi
Quartier Maître
Quartier Maître
 
Messages: 20
Inscrit le: 17 Fév 2010 10:45
Localisation: Reims

Messagepar Franck78 » 22 Avr 2010 13:59

Bon, faut quand même pas prendre ça au pied de la lettre. C'est un peu un remake du bug de l'an2000 mais autant savoir avant, que le jour J et suivant on y pense si il y a un problème :lol:
Franck
L'art de poser une question sur ce site afin d'obtenir la réponse
A LIRE
Avatar de l’utilisateur
Franck78
Amiral
Amiral
 
Messages: 5625
Inscrit le: 20 Fév 2004 01:00
Localisation: Paris

Messagepar tomtom » 30 Avr 2010 10:44

deux excellents articles sur le sujet :

Une introduction :
http://www.bortzmeyer.org/dns-size.html

et une description plus technique et complète :
http://www.bortzmeyer.org/risques-reels-dns-limite.html


D'une manière générale, les articles de Stéphane Bortzmeyer sont excellents. Si vous êtes twitteraddict, n'hésitez pas à suivre ses commentaires, pour tout ce qui touche à l'Internet en général....


Je sais, je suis d'une humeur publicitaire ce matin.

t.
One hundred thousand lemmings can't be wrong...
Avatar de l’utilisateur
tomtom
Amiral
Amiral
 
Messages: 6035
Inscrit le: 26 Avr 2002 00:00
Localisation: Paris

Messagepar tomtom » 30 Avr 2010 11:21

En résumé pour savoir si tout va bien :
(source : http://www.bortzmeyer.org/files/dns-size-pseudocode.txt )

Code: Tout sélectionner
-- Pseudo-code (syntax more or less Ada-like) to show what happens to
--  a DNS resolver when the root is signed and the responses become
--  larger.

-- Background information:
--    https://www.dns-oarc.net/oarc/services/replysizetest
--    RFC 5625
--    SSAC report #35 http://www.icann.org/committees/security/sac035.pdf

-- Stephane Bortzmeyer <bortzmeyer@nic.fr>

-- Variables used:
--   EDNS0: boolean, indicates if the resolver sends EDNS0 requests
--   EDNS0_Size: positive integer, the buffer size advertised by EDNS0
--   DO_DNSSEC: boolean, the DO flag indicating DNSSEC support by the resolver
--   Min_Response_Size: integer, the minimum (after dropping
--     unnecessary RR) size of the DNS response sent by the authoritative
--     server
--   Clean_path_for_fragments: boolean, indicates that UDP fragments
--     can travel from the authoritative name server to the resolver
--   Clean_Path_For_EDNS0: boolean, indicates that EDNS0 responses
--     (which may be larger than 512 bytes) can travel from the
--     authoritative name server to the resolver
--   Can_TCP: boolean, indicates that the resolver can ask through TCP
--     (which implies a clean TCP patch and an authoritative name server
--     which accept TCP)

-- The code can be executed several times for one request, for
--  instance because a resolver tries first with UDP, then retries
--  with TCP.

if UDP then -- MOst common transport protocol for DNS
   if EDNS0 then
      if EDNS0_Size > MTU then
         -- BIND default, EDNS0_size = 4096 bytes
         if DO_DNSSEC then
            -- BIND default, even if not configured for validation
            if Min_Response_Size > MTU then -- Not the case today with the root
               if Clean_Path_for_fragments then
                  OK;
               else
                  -- After a while BIND will switch to no-EDNS0, start over
                  Retry("Responses not received may be because of EDNS0");
               end if;
            elsif Min_Response_Size > 512 then
               -- No fragmentation will occur
               if Clean_Path_For_EDNS0 then
                  OK; -- That's the normal and typical case for a BIND
                      -- resolver today, with the signed root
               else
                  Retry("Responses not received may be because of EDNS0");
               end if;
            else -- Won't occur today, responses from the root are already > 512
               OK;
            end if;
         else
            -- Without DNSSEC, responses wil be shorter but some
            --  responses from the root already are > 512
            if Min_Response_Size > MTU then
               -- Unlikely, without DNSSEC
               if Clean_Path_for_fragments then
                  OK;
               else
                  Retry("Responses not received may be because of EDNS0");
               end if;
            elsif Min_Response_Size > 512 then
               if Clean_Path_For_EDNS0 then
                  OK;
               else
                  Retry("Responses not received may be because of EDNS0");
               end if;
            else -- Most common case today, the typical unsigned
                 -- answer is 100-200 bytes
               OK;
            end if;
         end if;
      elsif EDNS0_Size >= 512 then -- But lower than the MTU
         if DO_DNSSEC then
            if Min_Response_Size > EDNS0_Size then
               -- This assumes that DNS packets with TC bit set arrive
               -- safely, not always true
               Retry("Truncation");
            elsif Min_Response_Size >= 512 then
               if Clean_Path_for_EDNS0 then
                  OK;
               else
                  Retry("Responses not received may be because of EDNS0");
               end if;
            else -- Won't often occur today, some responses from the root are already > 512
               OK; -- Not always, some middleboxes may block EDNS0
                   -- responses, even with size <= 512
            end if;
         else
            -- No DNSSEC, so replies will probably be under EDNS0_Size
            if Min_Response_Size > 512 then
               if Clean_Path_For_EDNS0 then
                  OK;
               else
                  Retry("Responses not received may be because of EDNS0");
               end if;
            else
               OK;
            end if;
         end if;
      else -- EDNS0 with size < 512
         Error("Stupid value");
      end if;
   else -- No EDNS0 at all
      if Min_Response_Size > 512 then
         Retry("Truncation");
      else
         OK;
      end if;
   end if;
else -- TCP
   if Can_TCP then
      OK; -- But higher latency and higher load on authoritative name servers
   else
      Error("Fallback to TCP failed"); -- Complete and total failure
   end if;
end if;


t.
One hundred thousand lemmings can't be wrong...
Avatar de l’utilisateur
tomtom
Amiral
Amiral
 
Messages: 6035
Inscrit le: 26 Avr 2002 00:00
Localisation: Paris


Retour vers Accès Internet et FAI

Qui est en ligne ?

Utilisateur(s) parcourant actuellement ce forum : Aucun utilisateur inscrit et 1 invité

cron