Forum général.hors-sujets Résolution DNS et serveurs publics qui ne donnent pas de réponses quand la réponse est une ip locale

Posté par  . Licence CC By‑SA.
Étiquettes :
1
18
sept.
2018

Bonjour le forum,
je viens de toucher du doigt un truc étrange … ça fait des années que j'utilise mon propre serveur DNS (oui c'est pas bien) ou celui de FDN (c'est mieux, ça serait encore mieux si je pensais à leur donner des ronds de temps en temps, note à faire pour plus tard).

Bref, ayant des secousses sur mes connexions perso je me retrouve avec un truc free temporaire qui marche pas trop mal sauf que mes IP locales ne sont soudainement plus résolues !!!

Alors après avoir rapidement poussé tout ce que je voulais dans mon /etc/hosts j'ai cherché un peu pourquoi mes copains ont le même soucis y compris quand leur VPN est lancé … pour finalement me rendre compte que c'est tout simplement une histoire de DNS.

J'ai quelques enregistrements DNS bien pratiques:

servecole.dev          IN   A   192.168.10.1
proxy.dev          IN   A   192.168.10.2
imprimante.dev         IN   A   192.168.10.10
poste-01.dev           IN   A   192.168.10.20
poste-02.dev           IN   A   192.168.10.21

Ces enregistrements sont publiés sur la zone abuledu.org.

Ils nous permettent de nous connecter sur nos serveurs locaux tout en ayant une homogénéisation pour les captures d'écrans, la doc, les références etc. (en bref "connectez vous sur servecole.dev.abuledu.org" et lancez les commandes suivantes …

Mais quand on a une connexion par free je constate le problème suivant:

nslookup servecole.dev.abuledu.org 212.27.40.240
Server:     212.27.40.240

Non-authoritative answer:
*** Can't find servecole.dev.abuledu.org: No answer

Alors que la même requête vers les dns de FDN donne la réponse attendue:

nslookup servecole.dev.abuledu.org
Server:     80.67.169.40

Non-authoritative answer:
Name:   servecole.dev.abuledu.org
Address: 192.168.10.1

Question, existe-t-il une bonne raison à ça ?

Comment contourner le problème ?

Quels sont les opérateurs qui font ça ? (étant uniquement chez free je ne peux pas trop tester les autres)

Merci d'avance

  • # Commentaire supprimé

    Posté par  . Évalué à 4. Dernière modification le 18 septembre 2018 à 11:54.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Pas normal de résoudre des IP locales publiquement

      Posté par  . Évalué à 2.

      Hmmm mouééé disons que c'est bien pratique mais effectivement ça se discute en haut lieux :

      https://www.ietf.org/proceedings/52/I-D/draft-ietf-dnsop-dontpublish-unreachable-01.txt

      In section 5 of [RFC 1918] there is a prohibition of the appearance of
      private addresses in publicly visible DNS records. It says: 
      
        If an enterprise uses the private address space, or a mix of
        private and public address spaces, then DNS clients outside of
        the enterprise should not see addresses in the private address
        space used by the enterprise, since these addresses would be
        ambiguous.
      
      The wording "should not" is not a very strong prohibition, 
      considering the interworking problems that ignoring it can cause.
      Therefore, this document makes a stronger statement:
      
      Public DNS zones MUST NOT contain [RFC 1918] addresses, or any other
      addresses designated by IANA as private, in any resource records.
      

      C'est bien dommage car c'est pourtant intéressant dans plein de situations tout a fait compréhensibles … d'un autre côté j'imagine bien le bordel pour les SMTP et autres si on commence à jouer au con avec ça :-(

      Il ne me reste plus qu'à … quoi … tiens, comment faire pour avoir une solution "propre" ? Je vais faire tourner les neurones pour voir comment faire !

      Merci

      eric.linuxfr@sud-ouest.org

      • [^] # Re: Pas normal de résoudre des IP locales publiquement

        Posté par  (site web personnel) . Évalué à 4.

        Il y a au moins deux solutions propres possibles :

        • maintenir un fichier /etc/hosts et le tenir à jour (via rsync ou autre outil similaire). Cela peut fonctionner pour des besoins simples (peu de machines, pas d'enregistrement DNS "évolué").

        • maintenir un serveur DNS interne, faisant autorité pour le réseau interne. Il faudra un accès VPN ou quelque chose de similaire pour permettre à des personnes sur un autre réseau d'utiliser ce résolveur.

        Il existe beaucoup de documentation sur ce sujet, en voici une parmi d'autres : https://calomel.org/dns_bind.html

      • [^] # Re: Pas normal de résoudre des IP locales publiquement

        Posté par  . Évalué à 3.

        public/privé, 'split view dns'

        en gros, tu as un DNS à toi (ce qui est le cas apparemment, puisque c'est ns1 et ns2.rycks.com qui reponde pour le domaine abuledu.org)

        et tu configure du split view pour que

        • quand la requete vient du public, tu fournisses les IPs publiques
        • quand la requete vient de l'interne, tu fournisses les IPs internes
        • [^] # Re: Pas normal de résoudre des IP locales publiquement

          Posté par  . Évalué à 1.

          Sauf que c'est pas uniquement chez moi … en fait je voudrais proposer à n'importe quel contributeur éventuel de bénéficier de ces noms dans son intranet.

          Pour faire simple: une personne qui souhaite utiliser abuledu serveur installe la VM et ensuite peut se rendre sur servecole.dev.abuledu.org zoup c'est la VM qui réponds

          Idem il souhaite tester le poste client il sera en poste-01.dev.abuledu.org et le poste élève ? ben en poste-02.dev.abuledu.org

          Autre cas de figure, je souhaite proposer à des gens de découvrir abuledu sans rien installer: ils installent un client VPN, le site abuledu.org leur fournis un accès VPN à un vrai réseau abuledu de démo.

          Pour ne pas leur foutre le bordel le client VPN ne leur impose ni la route pas défaut ni de serveur DNS et on a accès à poste-01.dev poste-02.dev, servecole.dev etc. etc. etc.

          Voilà … bon j'ai compris que bof bof mais dans mon cas particulier c'était quand même 'achement pratique, je n'ai pas la main sur un éventuel /etc/hosts des utilisateurs, je n'ai pas la main sur leur IP / Serveur intranet (voir même s'ils en ont un) etc.

          eric.linuxfr@sud-ouest.org

          • [^] # Re: Pas normal de résoudre des IP locales publiquement

            Posté par  . Évalué à 2.

            Pour faire simple: une personne qui souhaite utiliser abuledu serveur installe la VM et ensuite peut se rendre sur servecole.dev.abuledu.org zoup c'est la VM qui réponds

            sauf que dans SON reseau, la VM n'aura peut-etre pas la meme adresse que chez toi
            donc non, ca ne fonctionnera pas

            sauf evidemment s'il utilise abuledu-dhcp-server, et abudeldu-dns-server
            qui seront 2 paquets que tu vas bientot proposer pour qu'il ait un DHCP qui enregistre le nom des VMs quand elle demande un bail dhcp, et qui fait pointer les machines en DHCP vers le DNS de abuledu

            et pour ton histoire de VPN,
            comment tu vas gerer que le reseau de ton "client" pourrait etre le meme que ton reseau de dev (et donc comment ce client va pouvoir router son trafic vers ton reseau)

  • # j'avais eu la même mauvaise idée

    Posté par  (site web personnel) . Évalué à 2.

    J'avais fait ça, et j'était revenu en arrière car j'utilise un routeur qui tourne sous pfsense et que le resolveur de pfsense refuse également de résoudre un nom qui point sur une ip non routable (par contre le résolveur de google ça lui causait pas de problème).

    • [^] # Re: j'avais eu la même mauvaise idée

      Posté par  . Évalué à 4.

      Beaucoup de serveurs recursifs ont une option pour les accepter ou non.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.