RSS: city:dnssec

city:dnssec

  • @stephane
    Stéphane Bortzmeyer CC BY-SA

    Vous ne lisez pas des #RFC tous les jours ? Si vous vous intéressez au #DNS et notamment à #DNSSEC, il faut au moins lire celui-ci, qui permet de comprendre enfin la mystérieuse « négation d’existence ».

    RFC 7129 : Authenticated Denial of Existence in the DNS

    Voilà une expression un peu effrayante, « la négation d’existence authentifiée ». C’est en fait un terme utilisé dans le DNS et notamment dans DNSSEC, pour indiquer qu’un résolveur DNS a pu prouver qu’un nom n’existe pas, ou bien qu’il existe mais qu’il n’a pas de données de tel type. Dans DNSSEC, cela se fait typiquement avec des enregistrements NSEC et NSEC3, dont la définition n’est pas toujours claire pour tout le monde. Ce RFC a donc pour but d’expliquer « tout ce qu’il faut savoir sur la négation d’existence authentifiée ». C’est une lecture indispensable pour les programmeurs qui vont mettre en œuvre DNSSEC, mais aussi pour les étudiants ou ingénieurs qui veulent comprendre DNSSEC y compris dans ses tréfonds les plus obscurs.

    ▻http://www.bortzmeyer.org/7129.html

    Stéphane Bortzmeyer CC BY-SA
    Écrire un commentaire
  • @mayeu
    Mayeu CC BY-SA
    2
    @stephane
    @severo
    2

    Problème de (resolution ?) DNS :
    Je possède des machines sur les réseaux suivant :
    – 1 serveur sur réseau OVH
    – 1 serveur sur réseau Online
    – 1 serveur sur réseau Digicube
    – Ma machine perso chez UPC Cablecom (FAI Suisse)

    J’essaye d’envoyer un e-mail depuis ma machine OVH vers le domaine hefr.ch (Université Suisse). Or la résolution DNS pour obtenir les champs MX échoue.

    Si je fais un dig depuis mes différentes machines j’obtiens :

    – OVH :
     ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> mx hefr.ch
     ; ; global options : +cmd
     ; ; Got answer :
     ; ; ->>HEADER<<- opcode : QUERY, status : SERVFAIL, id : 17260
     ; ; flags : qr rd ra ; QUERY : 1, ANSWER : 0, AUTHORITY : 0, ADDITIONAL : 0

     ; ; QUESTION SECTION :
     ;hefr.ch. IN MX

     ; ; Query time : 1278 msec
     ; ; SERVER : 213.186.33.99#53(213.186.33.99)
     ; ; WHEN : Thu Jan 9 10:13:09 2014
     ; ; MSG SIZE rcvd : 25

    À noter que j’ai aussi essayé avec un resolver local (unbound), et les DNS de Google sans succès non plus.

    – Online :
     ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> hefr.ch ANY
     ; ; global options : +cmd
     ; ; Got answer :
     ; ; ->>HEADER<<- opcode : QUERY, status : SERVFAIL, id : 7759
     ; ; flags : qr rd ra ; QUERY : 1, ANSWER : 0, AUTHORITY : 0, ADDITIONAL : 0

     ; ; QUESTION SECTION :
     ;hefr.ch. IN ANY

     ; ; Query time : 359 msec
     ; ; SERVER : 62.210.16.7#53(62.210.16.7)
     ; ; WHEN : Thu Jan 9 09:52:49 2014
     ; ; MSG SIZE rcvd : 25

    – Digicube :
     ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> mx hefr.ch
     ; ; global options : +cmd
     ; ; Got answer :
     ; ; ->>HEADER<<- opcode : QUERY, status : NOERROR, id : 21739
     ; ; flags : qr rd ra ; QUERY : 1, ANSWER : 2, AUTHORITY : 0, ADDITIONAL : 2

     ; ; QUESTION SECTION :
     ;hefr.ch. IN MX

     ; ; ANSWER SECTION :
    hefr.ch. 28800 IN MX 10 hefrmc01.hefr.ch.
    hefr.ch. 28800 IN MX 10 hefrmc02.hefr.ch.

     ; ; ADDITIONAL SECTION :
    hefrmc02.hefr.ch. 28800 IN A 160.98.8.126
    hefrmc01.hefr.ch. 28800 IN A 160.98.8.125

     ; ; Query time : 144 msec
     ; ; SERVER : 95.130.11.1#53(95.130.11.1)
     ; ; WHEN : Thu Jan 9 09:57:52 2014
     ; ; MSG SIZE rcvd : 107

    Ici j’ai bien un retour pour les champs MX qui correspondent à ce que me retourne MXToolbox (▻http://mxtoolbox.com/SuperTool.aspx)

    – Connexion UPC Cablecom
    Comme OVH et Online, pas de champs MX

    Ma question est donc la suivante, qu’est ce qui peu expliquer que depuis ces diffèrents réseaux certainnes machine voient les champs MX, et d’autres non ?
    Des pistes pour débogguer la chose est voir les MX partout ?

    Merci d’avance.

    Mayeu CC BY-SA
    • @stephane
      Stéphane Bortzmeyer CC BY-SA

      Première chose à tester : hefr.ch étant signé, refaire les tests dig avec l’option +cd (Checking DIsabled). Si ça marche avec +cd et que ça SERVFAIL sans +cd, c’est que le problème est lié à DNSSEC.

      Deuxième piste : les deux serveurs de hefr.ch sont dans le même réseau, donc un problème de routage peut les éliminer tous les deux. traceroute -n 160.98.8.126

      Stéphane Bortzmeyer CC BY-SA
    • @mayeu
      Mayeu CC BY-SA

      Avec l’option +cd toutes mes machines me retourne les champs MX. À noter que lorsque j’avais fait l’essai avec Unbound j’avais l’option

      auto-trust-anchor-file: “/var/lib/unbound/root.key”

      dans mon fichier de configuration.

      Du coup il me manque un certificat pour cette zone DNS ? Ou alors il y a une mirriade de possibilité qui ferait que ça ne fonctionne pas ?

      Pour les traceroutes, que je teste l’ip 160.98.8.126, ou directement les ip (v4 et v6) des serveurs de mail j’obtiens des timeout une fois passé ce qui semble être le point d’entré du réseau de l’université. Du coup je n’ai plus qu’à contacter les administrateurs du réseau en question !

      Merci pour ces pointeurs en tout cas !

      Mayeu CC BY-SA
    • @mayeu
      Mayeu CC BY-SA

      /var/lib/unbound/root.key contient :
      ; autotrust trust anchor file
      ;;id: . 1
      ;;last_queried: 1389263596 ;;Thu Jan 9 11:33:16 2014
      ;;last_success: 1389263596 ;;Thu Jan 9 11:33:16 2014
      ;;next_probe_time: 1389302531 ;;Thu Jan 9 22:22:11 2014
      ;;query_failed: 0
      ;;query_interval: 43200
      ;;retry_time: 8640
      . 172800 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ;{id = 19036 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0 ;;lastchange=1389256274 ;;Thu Jan 9 09:31:14 2014

      Par contre depuis quelques minutes maintenant, le dig sans +cd me retourne bien les MX de hefr.ch. J’ai fait un flush du cache avec «sudo unbound-control flush hefr.ch» avant de réessayer le dig.

      Mayeu CC BY-SA
    • @mayeu
      Mayeu CC BY-SA

      « Je viens de remarquer qu’un des tests était fait avec ANY : ne jamais faire cela, surtout sur un résolveur. »

      En effet, je n’ai pas copié la sortie de la bonne commande. C’est noté en tout cas sur le fait de ne pas le faire.

      Mayeu CC BY-SA
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer CC BY-SA
    4
    @02myseenthis01
    @loloster
    4

    « Peut-être vous demandez-vous pourquoi mes résolutions #DNS échouent alors que celles de milliers de freenautes réussissent. La raison est simple : je comprends le protocole DNS, et de ce fait, je connais son insécurité, et j’utilise donc #DNSSEC. J’utilise donc un logiciel nommé DNSSEC-Trigger qui s’installe sur mon poste de travail, et valide DNSSEC en tant que relais (forwarder) envoyant l’intégralité de mes requêtes avec le bit DO aux serveurs récursifs de Free.

    Le problème de Free n’a cependant rien de spécifique à DNSSEC, mais à une incompréhension du protocole de LEUR part.

    Voici les détails techniques : »

    ▻https://x-cli.eu/free/free-notcp.txt

    Notez également la présentation très épurée de ce blog.

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