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

[Franck78]

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

[jdh]

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 ?

[Franck78]

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

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

[jdh]

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 ...

[Franck78]

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 ?

[hacksi]

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...

[Franck78]

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

[tomtom]

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.

[tomtom]

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.