RSS: organization:in ns

organization:in ns

  • @biggrizzly
    BigGrizzly CC BY-NC-SA

    Souci DNS www.voyages-sncf.com ?

    Question ouverte aux SeenThisiens...

    J’ai un serveur DNS sous Windows 2003 qui me plante le domaine SNCF... Du coup, sur tout le réseau, ça pourrit les caches DNS. En effet, une fois sur 10, ça remonte « NXDOMAIN », et ça le conserve pour de bon ensuite...

    Je constate que ce domaine dispose de plusieurs NS :
    voyages-sncf.com. 3600 IN NS dns.sncf.fr.
    voyages-sncf.com. 3600 IN NS indom30.indomco.fr.
    voyages-sncf.com. 3600 IN NS indom130.indomco.org.
    voyages-sncf.com. 3600 IN NS dns2.sncf.fr.
    voyages-sncf.com. 3600 IN NS dns3.sncf.fr.
    voyages-sncf.com. 3600 IN NS dns4.sncf.fr.

    Je constate aussi que les 2 indomco refusent de répondre quand on les interroge...

    A votre avis, c’est moi qui ne comprend rien aux DNS, ou bien il y a effectivement un souci dans la configuration de ce domaine ?

    BigGrizzly CC BY-NC-SA
    • @biggrizzly
      BigGrizzly CC BY-NC-SA

      Plus qu’un seul NS en erreur :

      # dig voyages-sncf.fr @indom130.indomco.org

       ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> voyages-sncf.fr @indom130.indomco.org
       ; ; global options : +cmd
       ; ; Got answer :
       ; ; ->>HEADER<<- opcode : QUERY, status : NOERROR, id : 33906
       ; ; flags : qr rd ; QUERY : 1, ANSWER : 0, AUTHORITY : 13, ADDITIONAL : 0
       ; ; WARNING : recursion requested but not available

       ; ; QUESTION SECTION :
       ;voyages-sncf.fr. IN A

       ; ; AUTHORITY SECTION :
      . 518400 IN NS a.root-servers.net.
      . 518400 IN NS b.root-servers.net.
      . 518400 IN NS c.root-servers.net.
      . 518400 IN NS d.root-servers.net.
      . 518400 IN NS e.root-servers.net.
      . 518400 IN NS f.root-servers.net.
      . 518400 IN NS g.root-servers.net.
      . 518400 IN NS h.root-servers.net.
      . 518400 IN NS i.root-servers.net.
      . 518400 IN NS j.root-servers.net.
      . 518400 IN NS k.root-servers.net.
      . 518400 IN NS l.root-servers.net.
      . 518400 IN NS m.root-servers.net.

       ; ; Query time : 93 msec
       ; ; SERVER : 209.235.192.171#53(209.235.192.171)
       ; ; WHEN : Tue Jul 12 19:05:15 2016
       ; ; MSG SIZE rcvd : 244

      BigGrizzly CC BY-NC-SA
    • @biggrizzly
      BigGrizzly CC BY-NC-SA

      A cause de ce dernier serveur DNS, je constate que je ne peux pas visiter ce site depuis mon réseau local... le cache DNS vient de mémoriser la réponse de indom130... qui dit que le domaine n’existe pas.
      C’est tout de même énorme que ce domaine possède une telle erreur sans que rien ne bouge depuis 1 semaine !

      BigGrizzly CC BY-NC-SA
    • @biggrizzly
      BigGrizzly CC BY-NC-SA

      Le log du DNS Windows parle :

      21/07/2016 17:24:01 1C28 PACKET 00000000033D7990 UDP Rcv 185.83.100.47 9795 R Q [0384 A NXDOMAIN] A (12)voyages-sncf(3)com(9)edgesuite(3)net(4)vsct(2)fr(0)

      Le serveur DNS 185.83.100.47 est indom30.indomco.fr

      Et c’est donc ce serveur que le serveur DNS Windows tente d’interroger pour résoudre le CNAME en question.

      Je passe le log en verbose... ça va être encore plus fun à lire...

      BigGrizzly CC BY-NC-SA
    • @biggrizzly
      BigGrizzly CC BY-NC-SA

      Voilà la suite de requêtes qui aboutie au NXDOMAIN...

      21/07/2016 17:36:33 3898 PACKET 0000000003429890 UDP Rcv 193.176.144.22 c1a7 R Q [0080 NOERROR] A (12)voyages-sncf(3)com(9)edgesuite(3)net(4)vsct(2)fr(0)
      UDP response info
      Socket = 4292
      Remote addr 193.176.144.22, port 53
      Time Query=339491, Queued=0, Expire=0
      Buf length = 0x0500 (1280)
      Msg length = 0x00a8 (168)
      Message :
      XID 0xc1a7
      Flags 0x8000
      QR 1 (RESPONSE)
      OPCODE 0 (QUERY)
      RCODE 0 (NOERROR)
      QCOUNT 1
      ACOUNT 0
      NSCOUNT 3
      ARCOUNT 1
      QUESTION SECTION :
      Offset = 0x000c, RR count = 0
      Name « (12)voyages-sncf(3)com(9)edgesuite(3)net(4)vsct(2)fr(0) »
      QTYPE A (1)
      QCLASS 1
      ANSWER SECTION :
      empty
      AUTHORITY SECTION :
      Offset = 0x0038, RR count = 0
      Name « [C02B](4)vsct(2)fr(0) »
      TYPE NS (2)
      CLASS 1
      TTL 172800
      DLEN 18
      DATA (7)indom30(7)indomco[C030](2)fr(0)
      Offset = 0x0056, RR count = 1
      Name « [C02B](4)vsct(2)fr(0) »
      TYPE NS (2)
      CLASS 1
      TTL 172800
      DLEN 21
      DATA (7)indom20(7)indomco(3)net(0)
      Offset = 0x0077, RR count = 2
      Name « [C02B](4)vsct(2)fr(0) »
      TYPE NS (2)
      CLASS 1
      TTL 172800
      DLEN 21
      DATA (7)indom10(7)indomco(3)com(0)
      ADDITIONAL SECTION :
      Offset = 0x0098, RR count = 0
      Name « [C044](7)indom30(7)indomco[C030](2)fr(0) »
      TYPE A (1)
      CLASS 1
      TTL 172800
      DLEN 4
      DATA 185.83.100.47

      21/07/2016 17:36:33 3898 PACKET 0000000003160D10 UDP Rcv 185.83.100.47 8ed2 R Q [0384 A NXDOMAIN] A (12)voyages-sncf(3)com(9)edgesuite(3)net(4)vsct(2)fr(0)
      UDP response info
      Socket = 2716
      Remote addr 185.83.100.47, port 53
      Time Query=339491, Queued=0, Expire=0
      Buf length = 0x0500 (1280)
      Msg length = 0x00b0 (176)
      Message :
      XID 0x8ed2
      Flags 0x8403
      QR 1 (RESPONSE)
      OPCODE 0 (QUERY)
      AA 1
      TC 0
      RD 0
      RA 0
      Z 0
      RCODE 3 (NXDOMAIN)
      QCOUNT 1
      ACOUNT 1
      NSCOUNT 1
      ARCOUNT 0
      QUESTION SECTION :
      Offset = 0x000c, RR count = 0
      Name « (12)voyages-sncf(3)com(9)edgesuite(3)net(4)vsct(2)fr(0) »
      QTYPE A (1)
      QCLASS 1
      ANSWER SECTION :
      Offset = 0x0038, RR count = 0
      Name « [C00C](12)voyages-sncf(3)com(9)edgesuite(3)net(4)vsct(2)fr(0) »
      TYPE CNAME (5)
      CLASS 1
      TTL 600
      DLEN 37
      DATA (3)www(12)voyages-sncf(3)com(4)gslb(8)cdn-vsct[C030](2)fr(0)
      AUTHORITY SECTION :
      Offset = 0x0069, RR count = 0
      Name « [C05E](8)cdn-vsct[C030](2)fr(0) »
      TYPE SOA (6)
      CLASS 1
      TTL 7200
      DLEN 59
      DATA
      PrimaryServer : (7)indom10(7)indomco(3)com(0)
      Administrator : (9)technique(5)indom[C085](3)com(0)
      SerialNo = 2015072801
      Refresh = 86400
      Retry = 7200
      Expire = 604800
      MinimumTTL = 7200
      ADDITIONAL SECTION :
      empty

      BigGrizzly CC BY-NC-SA
    • @biggrizzly
      BigGrizzly CC BY-NC-SA

      La première requête correspondrait donc à :

      ~# dig NS vsct.fr

       ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> NS vsct.fr
       ; ; global options : +cmd
       ; ; Got answer :
       ; ; ->>HEADER<<- opcode : QUERY, status : NOERROR, id : 934
       ; ; flags : qr rd ra ; QUERY : 1, ANSWER : 3, AUTHORITY : 0, ADDITIONAL : 3

       ; ; QUESTION SECTION :
       ;vsct.fr. IN NS

       ; ; ANSWER SECTION :
      vsct.fr. 7167 IN NS indom10.indomco.com.
      vsct.fr. 7167 IN NS indom30.indomco.fr.
      vsct.fr. 7167 IN NS indom20.indomco.net.

       ; ; ADDITIONAL SECTION :
      indom10.indomco.com. 3520 IN A 217.174.200.97
      indom20.indomco.net. 3520 IN A 69.170.135.194
      indom30.indomco.fr. 520 IN A 185.83.100.47

       ; ; Query time : 0 msec
       ; ; SERVER : 127.0.0.1#53(127.0.0.1)
       ; ; WHEN : Thu Jul 21 17:46:58 2016
       ; ; MSG SIZE rcvd : 169

      Et là, je ne suis pas assez calé pour savoir si le serveur DNS Microsoft a tort d’en passer par cette étape...

      BigGrizzly CC BY-NC-SA
    • @stephane
      Stéphane Bortzmeyer CC BY-SA
      @biggrizzly

      @BigGrizzly Un ENT (Empty-Non Terminal) est un domaine qui n’a pas de données, mais a des sous-domaines (comme gouv.fr, par exemple). C’est parfaitement permis dans le DNS mais certains logiciels bogués (djb, Akamai) répondent NXDOMAIN lorsqu’on les interroge pour un ENT. Grave bogue (le monde est plein de bogues).

      Ici, certains des serveurs de vsct.fr (par exemple indom20.indomco.net mais pas indom30.indomco.fr) répondent NXDOMAIN pour un ENT comme edgesuite.net.vsct.fr (domaine parent de voyages-sncf.com.edgesuite.net.vsct.fr, vers lequel pointe www.voyages-sncf.com) :

      % dig @indom20.indomco.net edgesuite.net.vsct.fr


      ; <<>> DiG 9.10.3-P4-Debian <<>> @indom20.indomco.net edgesuite.net.vsct.fr
      ; (1 server found)
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15465
      ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
      ;; WARNING: recursion requested but not available

      ;; QUESTION SECTION:
      ;edgesuite.net.vsct.fr. IN A

      ;; AUTHORITY SECTION:
      vsct.fr.                7200 IN SOA indom10.indomco.com. technique.indomco.com. (
                                     2016071900 ; serial
                                     86400      ; refresh (1 day)
                                     7200       ; retry (2 hours)
                                     604800     ; expire (1 week)
                                     7200       ; minimum (2 hours)
                                     )

      ;; Query time: 143 msec
      ;; SERVER: 69.170.135.194#53(69.170.135.194)
      ;; WHEN: Fri Jul 22 09:53:24 CEST 2016
      ;; MSG SIZE  rcvd: 104

      Travail d’amateur classique, bogue connue.

      Stéphane Bortzmeyer CC BY-SA
    • @biggrizzly
      BigGrizzly CC BY-NC-SA
      @stephane

      Merci @stephane pour tes explications.
      Je comprends que :
      a) le serveur DNS Microsoft est bogué
      et que b) la configuration DNS du domaine sncf est incomplète.

      Du coup, il est quasi-impossible d’obtenir une correction pour un tel cas... Et que l’utilisation d’un redirecteur devient indispensable quand on utilise un serveur DNS Microsoft.

      Je testerai CaptainTrain, et tâcherai d’expliquer à mes clients d’en faire autant :-D

      BigGrizzly CC BY-NC-SA
    • @stephane
      Stéphane Bortzmeyer CC BY-SA
      @biggrizzly

      @BigGrizzly Comme il y a deux problèmes sur le domaine voyages-sncf.com, il faut séparer les deux cas. Pour la longue chaîne de CNAME, ces résolveurs ont peut-être des protections plus laxistes (et donc acceptent cette chaîne). Sur l’Internet, ceux qui activent la sécurité sont toujours perdants.

      Pour le second problème, les NXDOMAIN, cela peut être que BIND n’envoie pas de requêtes pour les noms intermédiaires (qui déclenchent le NXDOMAIN) mais seulement pour les noms complets.

      Ceci dit, prudence. Il y a un zillion d’options de BIND et ça dépend peut-être tout simplement desquelles ont été activées.

      Stéphane Bortzmeyer CC BY-SA
    • @dr_titus
      Dr titus
      @biggrizzly

      @biggrizzly

      Bonjour, je suis tomber sur votre article et j’ai comme vous un gros souci concernant le site SNCF.

      Malgré l’ajout des redirecteurs de mon FAI, je n’ai toujours pas soldé mon problème.

      Par contre, il semblerait que vous ayez contourné le problème en ayant, je cite « Je m’en suis sorti dans l’immédiat en ajoutant un redirecteur vers le routeur le plus proche du serveur DNS Microsoft... Groumf. »

      Je vous serai reconnaissant si vous pouviez me donnez le nom de ce redirecteur.

      Par avance, merci de votre diligence.

      Dr titus
    • @biggrizzly
      BigGrizzly CC BY-NC-SA

      Bonjour,

      Les réseaux sur lesquels j’ai rencontré le souci disposent donc d’un serveur interne à base de serveur DNS Microsoft et d’un routeur matériel. Ce dernier dispose en général d’un serveur DNS, et c’est son adresse qu’il est possible d’utiliser comme redirecteur.

      Ceci dit, Là, je vérifie ce que j’ai fait il y a 2 mois, et je constate qu’un de mes serveurs DNS Microsoft est hébergé sur un serveur OVH, et j’ai donc utilisé « cdns.ovh.net » (213.186.33.99). Et chez un autre client j’ai utilisé le routeur local 192.168.2.250. Cf. les deux captures d’écran ci-dessous.

      ▻https://framapic.org/2CgHZwvSdsGl/aYX80J85x7Af.PNG
      ▻https://framapic.org/ja4MIifxWlw3/j8vFFtZbob6l.PNG

      BigGrizzly CC BY-NC-SA
    • @dr_titus
      Dr titus

      Bonjour,

      Tout d’abord merci pour votre réponse, j’ai donc bien mis les redirecteurs de mon FAI (Completel) ce qui revient au même que votre action de mettre celle de votre hébergeur.

      Mais le problème demeure ... :-((( car le domaine que je gère fait office d’autorité et s’appuie aussi aussi sur les serveurs racines ...

      Je vous aurais bien mis des captures mais je débute sur ce site ...

      Ça sent le fichier HOSTS sur les clients pour contourner le problème...

      J’adore le bricolage ...

      Je vais capturer un agent SNCF et le torturer jusqu’à la correction de leur cochonnerie.

      Merci quand même d’avoir pris le temps de me répondre.

      Dr titus
    • @dr_titus
      Dr titus

      Bonjour BigGrizzly,

      La solution de contournement est d’ajouter une zone de recherche directe voyages-sncf.com avec l’IP 158.58.182.229, puis d’ajouter les 3 hôtes suivants « proposition, secure, www » avec la même IP et ça fonctionne.

      c’est mieux que le fichier HOSTS sur 7000 postes ...

      Le seul hic est si l’adresse change ...

      Au plaisir.

      Dr titus
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer CC BY-SA
    2
    @supergeante
    @fil
    2

    Jeudi 20 juin vers 0000 UTC, un certain nombre de domaines ont été redirigés vers les serveurs de noms de Ztomy. Voici par exemple ce qui est arrivé au plus célèbre de ces domaines, linkedin.com, vu par DNSDB <►http://www.bortzmeyer.org/dnsdb.html> :

    first seen 2013-06-20 00:17:09 -0000
    last seen 2013-06-20 04:13:15 -0000
    linkedin.com. NS ns1617.ztomy.com.
    linkedin.com. NS ns2617.ztomy.com.

    Selon certains témoignages, 50 000 domaines sont concernés. Cisco, par observation passive du DNS (comme DNSDB), en a confirmé 5 000 <▻http://blogs.cisco.com/security/hijacking-of-dns-records-from-network-solutions>.

    Les serveurs de noms de Ztomy ne fournissant pas les réponses attendues, plus personne ne pouvait accéder aux services de ces domaines. Cela a logiquement fait du buzz <▻http://www.theregister.co.uk/2013/06/20/linkedin_dns_hijacked> <▻http://www.reddit.com/r/netsec/comments/1gpl3p/linkedin_dns_has_been_hijacked_pointing_at_rogue> <▻http://techcrunch.com/2013/06/19/linkedin-outage-due-to-possible-dns-hijacking> mais, comme souvent en ce qui concerne le DNS, sans informations techniques fiables et avec un vocabulaire très flou (« DNS poisoning » utilisé à tort et à travers).

    Le bureau d’enregistrement de linkedin.com, Network Solutions, reconnait sa faute, dans un communiqué très court en détail et contenant au moins une grosse erreur (le problème n’était pas Web mais DNS) <▻https://www.networksolutions.com/blog/2013/06/important-update-for-network-solutions-customers-experiencing-webs>

    Le meilleur article de synthèse sur ce problème, fait par des gens compétents, est celui de l’ISC <▻http://www.isc.org/blogs/hijacking-dns-error-ddos-what-happened-and-what-you-can-do>.

    Il semble donc bien que le problème soit une erreur humaine ou un bogue : voulant rediriger des domaines attaqués vers un service de mitigation des attaques par déni de service (un service qu’on paie pour que la guerre ait lieu chez eux), Network Solutions s’est trompé et a envoyé ses clients chez Ztomy. Moins sexy qu’un piratage mais plus courant. Il y a plus de maladroits que de cyberguerriers chinois ou iraniens.

    L’incident a rappelé la difficulté de la coordination dans l’Internet : une fois le problème corrigé, il a fallu vider les caches des résolveurs DNS <▻http://www.bortzmeyer.org/vider-cache-resolveur.html>, qui gardaient la mauvaise information en mémoire. Des tentatives de la part de Network Solutions, via des messages non authentifiés et ne contenant aucun détail ont suscité quelques sarcasmes <▻https://lists.dns-oarc.net/pipermail/dns-operations/2013-June/010346.html>.

    Le problème continue sans doute en ce moment, puisque les TTL des domaines sont souvent très longs (ici, deux jours) :

    craigslist.com. 172800 IN NS ns1620.ztomy.com.
    craigslist.com. 172800 IN NS ns2620.ztomy.com.

    #LinkedIn #NetworkSolutions #DNSDB #résilience #DNS #sécurité

    Stéphane Bortzmeyer CC BY-SA
    Écrire un commentaire