BigGrizzly

Groumpf

  • 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 ?

    • 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

    • 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 !

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

    • 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

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

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

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

    • 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

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

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