• Encore un #Seenthis_help à propos de #DNS ! Avec un peu de #viePrivée dedans.

    C’est à propos d’#autorité DNS public et privé dans un réseau local.

    Je possède le domaine tc2.fr. Que j’utilise entre autre pour mon serveur SMTP. J’aimerais utiliser ce domaine aussi dans mon réseau local, mais si possible sans avoir un sous-domaine (type local.tc2.fr) dédié à cela.

    Problème : je n’ai pas non plus envie que des informations privées (par exemple nom de mes machines avec machine.tc2.fr, service avec service.tc2.fr) sois révélées à tout le monde à travers le fichier de zone. J’aimerais donc pouvoir avoir une séparation entre la zone DNS publiquement disponible, et celle du réseau privé.

    Mes questions sont donc :

    – Est-ce que ce que je dis à du sens ?
    – Est-ce un usage « courant » ou est-ce que je chipote un peu trop ? Ou est-ce que je me complique la vie ?
    – Comment réaliser ça de manière assez propre ?
    – Quel est votre avis sur la solution suivante :

    La solution que j’ai en tête consiste à mettre en place deux autorités, une accessible publiquement et l’autre accessible de manière uniquement dans mon réseau local ; et de faire en sorte que mon résolveur local pointe toujours vers mon autorité privée lorsqu’il cherche à résoudre la zone tc2.fr. L’idéal dans ma tête serait de ne pas avoir à gérer deux fichier de zones différent pour un seul domaine.

    Merci d’avance pour toute aide ou pointeur sur le sujet :)

    • 1) Oui, cela fait sens :-)

      2) C’est courant, encore que la grande majorité des gens choisissent la solution propre, un sous-domaine.

      3) La solution sale, avec BIND, est d’utiliser les vues (truc compliqué que je déconseille).

      4) Cette solution fonctionne (confession : j’ai mis ça en place sur un site et c’est toujours en production...) mais elle complique le déboguage (un dig NS tc2.fr ne donnera pas le même résultat partout).

    • Wow, merci pour cette réponse ultra rapide !

      Je vais faire quelques tests sans sous-domaine dédié pour voir, et si ça me complique trop la tâche et le déboguage je dédierais un sous-domaine au réseau. La complexité du réseau n’est pas très grande, du coup ça devrait aller !

      Merci encore pour ce retour sur le sujet.


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

    • 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

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

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

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