Journal xip.io pour une infinité de domaines gratos !

Posté par (page perso) . Licence CC by-sa
Tags :
16
3
fév.
2015

Salut à tous !

Un pote m'a fait découvrir un truc que je trouve absolument génial et que je tenais à partager avec vous : xip.io

Ca vous permet d'utiliser une "infinité" de nom de domaines différents à partir d'une IP. Pour reprendre leur exemple :

10.0.0.1.xip.io   resolves to   10.0.0.1
www.10.0.0.1.xip.io   resolves to   10.0.0.1
mysite.10.0.0.1.xip.io   resolves to   10.0.0.1
foo.bar.10.0.0.1.xip.io   resolves to   10.0.0.1

En tant que développeur, ça va changer ma vie ! Et même sans être dev, si vous voulez pas acheter un domaine, c'est certes moins sexy à cause de l'IP dedans, mais ça fait le job ! Et pas besoin d'attendre la propagation DNS !

Bref, j'espère que ça pourra servir à certains d'entre vous ;)

  • # Commentaire supprimé

    Posté par . Évalué à 10.

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

  • # marche pas chez moi

    Posté par . Évalué à 4.

    ca ne marche pas chez moi (OSX)

    ping www.192.168.1.243.xip.io
    ping: cannot resolve www.192.168.1.243.xip.io: Unknown host

    ca ne marche pas non plus avec un linux dans une VM sur mon reseau (DNS de Free)
    dig ne renvoie rien meme avec les DNS de Google.

    mais ca fonctionne depuis un linux chez Ovh (DNS OVH)

    bref c'est quand meme pas gagné cette affaire.

    • [^] # Re: marche pas chez moi

      Posté par . Évalué à 2.

      Pourtant normalement avec les DNS de Google ça marche. Pour free, il filtre les domaines qui retournent une IP non publique visiblement.

      • [^] # Re: marche pas chez moi

        Posté par (page perso) . Évalué à 8.

        Oui, Free fait cela et pas mal d'autres résolveurs d'enterprise également. C'est pour empêcher les attaques par changement

        • [^] # Re: marche pas chez moi

          Posté par (page perso) . Évalué à 1.

          Je suis surpris que Google ne le fasse pas, comme tu le dis dans ton article sur le sujet Google l'implémente dans d'autres de ses outils.
          Il y a une raison pour ne pas le faire? (j'ai compris que ce n'est pas forcément le boulot du DNS, mais bon, si il peut aider à la sécurité)

  • # ?

    Posté par . Évalué à 10.

    Désolé je vois pas à quoi ça sert.
    Si quelqu'un peut éclairer ma lanterne…

    • [^] # Re: ?

      Posté par (page perso) . Évalué à 7.

      Quand tu as plusieurs site à tester en local, et que sur ton ipad/telephone/autre tu ne peux pas editer le fichier de hosts, il faut passer par ce genre d'astuces: avoir un virtualhost different par site (chose que tu pourrais pas faire si tu accedes directement avec l'adresse ip).

      • [^] # Re: ?

        Posté par . Évalué à 1. Dernière modification le 04/02/15 à 10:17.

        Merci pour l'explication.

      • [^] # Re: ?

        Posté par (page perso) . Évalué à 3.

        Quand tu as plusieurs site à tester en local, et que sur ton ipad/telephone/autre tu ne peux pas editer le fichier de hosts, il faut passer par ce genre d'astuces: avoir un virtualhost different par site (chose que tu pourrais pas faire si tu accedes directement avec l'adresse ip).

        Ou que t'es sur un desktop conventionnel mais que t'as pas envie de toucher à ce fichier dégueulasse à chaque fois que tu veux tester un truc.

      • [^] # Re: ?

        Posté par . Évalué à 0.

        Il faut aussi que le device utilisé ne soit pas sur le réseau local pour que ça ait un intérêt non ? Sinon quelle différence avec :

        http://localIP/site1
        http://localIP/site2
        etc

        • [^] # Re: ?

          Posté par (page perso) . Évalué à 5.

          Sinon quelle différence

          avoir un virtualhost different par site (chose que tu pourrais pas faire si tu accedes directement avec l'adresse ip).

          « 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

          • [^] # Re: ?

            Posté par . Évalué à 2. Dernière modification le 04/02/15 à 14:14.

            Toujours pas compris désolé,

            http://localIP/site1 n'est pas un virtual host, c'est un simple dossier nommé site1 dans le répertoire web. Je comprends l'utilité si l'on n'est pas sur le réseau local, mais sinon quel avantage ?

            • [^] # Re: ?

              Posté par . Évalué à 2.

              Si les contenus hébergés sur /site1 et /site2 imposent tous deux d'être à la racine du serveur, tu fais comment?

              • [^] # Re: ?

                Posté par . Évalué à 1.

                Ben tu écris une ligne dans ton .htaccess non ? Je serais curieux de connaître un cas de figure ou cette solution ne fonctionne pas.

                • [^] # Re: ?

                  Posté par . Évalué à 5.

                  Dans le cas où les deux doivent tourner en même temps?

                  Je veux lier une appli (pas écrite par mes soins) qui s'attend à être sur / à une autre qui s'attend à la même chose. Je manque d'imagination, mais je ne vois pas tellement en quoi un .htaccess va t'aider ici, si?

                  • [^] # Re: ?

                    Posté par . Évalué à -2.

                    Que veut dire "qui s'attend à être sur /" au juste ? La racine est une abstraction. Pour moi une app "qui s'attend à être sur /" est mal codée. Par curiosité dans quel contexte rencontres-tu ça ?

                    • [^] # Re: ?

                      Posté par . Évalué à 6.

                      Mal codee, mal codee, c'est vite dit.
                      Si ta resource c'est /api/v1/user/1234 et que tu lui balances /appli/api/blabla, t'as de grande chances de te prendre un 404 quand meme, a juste titre.
                      Alors, oui, rewrite rules, context path et tout le tralala, mais ca fait chier de faire des configs one off en permanence. Sans parler des applis natives ou t'as autre chose a faire que de changer ton base path toutes les 15 minutes.

                      Ya le header Host, il est pas fait pour les chiens, il a meme ete cree specialement pour ca.
                      Dit autrement, ton routage de requetes est plus simple a gerer par virtual host que par url paths.

                      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                      • [^] # Re: ?

                        Posté par (page perso) . Évalué à 5.

                        Et c'est aussi plus proche de ce qui se retrouvera en prod, ce qui n'est pas plus mal pour tester.

                        « 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

                      • [^] # Re: ?

                        Posté par . Évalué à -4.

                        Et une application qui ne marche plus si on la met dans /usr/local au lieu de /usr, c'est normal aussi ? Et une application qu'il faut absolument mettre dans C:\Program Files, c'est bon aussi ?

                        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                        • [^] # Re: ?

                          Posté par . Évalué à 1.

                          Ca a pas grand chose a voir.

                          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                    • [^] # Re: ?

                      Posté par . Évalué à 3.

                      Pour moi une app "qui s'attend à être sur /" est mal codée.

                      Je partage assez cela, mais là n'est pas la question : les applis mal codées ça existe, et on n'a pas toujours le loisir de mettre les mains dedans.

                      Plus concrètement, ce que j'ai pu rencontrer un peu plus souvent, ce sont des applis qui acceptent de passer sur un sous-répertoire, mais au prix d'une configuration un peu exotique qui risque de sauter à chaque mise-à-jour.

                • [^] # Re: ?

                  Posté par . Évalué à 3.

                  T'as un load balancer qui front plusieurs services et se base sur le header Host pour savoir ou faire suivre la requete.
                  Ca va typiquement etre le cas dans un envinronement de dev interne ou tu veux pas te faire chier a avoir 1 LB par service..

                  Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                  • [^] # Re: ?

                    Posté par (page perso) . Évalué à 4.

                    Je commence à un perdu : jouer avec des load balancers et ne pas avoir accès à son fichier host (sujet initial), c'est un cas qui existe?

                    • [^] # Re: ?

                      Posté par . Évalué à 5.

                      Oui. Les applis natives et les personnes non techniques/qui ont autre chose a faire que de branler le mamouth avec des hostfiles. Genre tu veux montrer un prototype a un product manager ou a ton vp/cto, ca le fait pas du tout de lui filer un qui va resoudre vers tout sauf ce que tu veux.

                      Rajoutes par dessus que t'as aucun moyen de savoir si tu parles reellement a l'environment auquel tu parles (et paf, tu modifies des donnees en prod au lieu de dev. C'est pas une question de si, c'est une question de quand), et tu te tapes des barres de rires avec chrome qui va garder la resolution de nom d'hote en memoire, mais pas toujours (et du coup, tu sais encore moins ou tes requetes vont).

                      Les fichiers hosts, c'est l'incarnation du demon. A chaque fois que tu edites ce fichier, dieu bute un dessinateur de chez charlie hebdo.

                      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

              • [^] # Re: ?

                Posté par (page perso) . Évalué à 1.

                Si les contenus hébergés sur /site1 et /site2 imposent tous deux d'être à la racine du serveur, tu fais comment?

                J'engueule leur développeur respectif.

                • [^] # Re: ?

                  Posté par . Évalué à 5.

                  Faut arreter de monter sur ses grand chevaux 2 minutes.
                  T'as un service RESTful. Comme t'es un bon gars, tu met des liens vers tes autres resources dans tes reponses, en clair, genre /api/v1/user/1234 te file un lien vers /api/v1/comments/1234 pour voir les commentaires de cet utlisateur (exemple totalement fictif :)).
                  Ces liens sont relatifs a l'hote, parce que t'as pas envie que ton appli doive savoir sur quel nom d'hote elle est hebergee, et ca, c'est bien (decouple le routage de l'appli).

                  Paf, tu viens de peter ton appli, ta resource /folder/api/v1/user/1234 te dit d'aller voir /api/machin, et tu l'as dans l'cul lulu (turlututu chapeau pointu). C'est dur de gueuler sur le developeur, parce qu'il a fait ce qu'il fallait, c'est toi qui a deploye ca comme un goret.

                  Accessoirement, ya des developeurs, tu peux les engueuler tout ce que tu veux, ca resoudra pas ton probleme.

                  Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                  • [^] # Re: ?

                    Posté par (page perso) . Évalué à 0.

                    Accessoirement, on peut regarder l'URL appelée et adapter la réponse.
                    C'est un choix que d'empécher (non volontairement) les gens de poser l'appli où ils veulent/peuvent.
                    Que le dév ai la flemme / pas le temps, OK, que "il a fait ce qu'il fallait", hum… Désolé, je ne prend pas.

                    • [^] # Re: ?

                      Posté par . Évalué à 6.

                      2 choses:
                      - les url ont une semantique, tu peux pas te permettre de les changer comme tu veux quand tu veux. Une url, c'est standardise, en l'occurence un hote, un path et des query params. T'es libre de penser le contraire, mais la spec parle de path, et pas de prefixe plus path. Accessoirement, bon courage pour faire rentrer ca dans un concept REST ou le path (tout le path) represente l'identite de la resource. On peut aussi citer "cool uris dont change".
                      - partant de la, le developeur n'a aucune raison de gacher du temps et de l'energie et compliquer son design pour accomoder des pratiques grouik qui vont a l'encontre des specs et des fondements d'http. Surtout quand t'as des outils te permettant de faire les choses proprement plus facilement que de les faire a la rache.

                      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

            • [^] # Re: ?

              Posté par (page perso) . Évalué à 4.

              Justement, si tu veux faire des config avec les virtualhost, c'est là que ça devient intéressant (sinon, je ne vois pas la différence avec le réseau local).

              « 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

              • [^] # Re: ?

                Posté par . Évalué à 2.

                Comme, par exemple, avoir deux certificats différents pour SSL, ou autoriser les accès aux clients authentifiés par des certificats émis par des autorités différentes…

    • [^] # Re: ?

      Posté par . Évalué à 5.

      Je suppose que cela permet d'accéder à une même IP avec plusieurs noms. il faut savoir que dans une requête HTML (entre autre), le serveur web n'utilise pas l'IP mais le nom pour décider quel site web il soit afficher. Cela permet à plusieurs sites webs de partager la même IP.

      Je connais 4 autres façons d'associer rapidement un nom à une IP sans avoir à attendre la propagation mais chacune avec ses avantages et inconvénients.

      La première est évidemment d'avoir son propre serveur DNS sur le réseau local pour définir des alias. Si vous êtes chez vous, il est probable que votre 'box internet' puisse faire cela.
      La seconde est d'ajouter des entrées dans /etc/hosts (voir man 5 hosts). Il faut être root mais cela marche toujours.
      La 3eme est d'utiliser HOSTALIASES (voir man 7 hostname) mais cela ne marche pas toujours bien.
      La 4ieme est d'utiliser LD_PRELOAD pour redefinir gethostbyname() et autres fonctions systèmes (l y a plein d'exemples sur le net. Par exemple http://www.wensley.org.uk/c/libdivert.c )

      • [^] # Re: ?

        Posté par . Évalué à 3.

        Si vous avez le controle d'une zone DNS, une autre possibilité consiste à créer un 'wildcard record' pointant vers l'IP de votre serveur de test. Quelque chose du genre.
        *.xxx.mydomain.org 3600 A 101.111.121.131

        • [^] # Re: ?

          Posté par (page perso) . Évalué à 3.

          Comme ça, ça permet à n’importe qui de te faire passer pour un pédonazi : « ha bah tiens, la-gallerie-du-pedo.example.com résout ».

      • [^] # Re: ?

        Posté par (page perso) . Évalué à 1.

        La première est évidemment d'avoir son propre serveur DNS sur le réseau local pour définir des alias. Si vous êtes chez vous, il est probable que votre 'box internet' puisse faire cela.

        Je ne sais pas chez quel opérateur tu est, et encore moins quel modem tu utilise. Mais de tout les modem sur les quels j'ai eu l'occasion de bricoler, notamment les *box opérateurs, aucun ne propose plus d'option que de juste désactiver les fonctions DNS, mais jamais sans configuration.

        Après reste l'option de coller un RPi (ou équivalent) au cul du modem pour lui faire assurer certaines fonctions qui lui son normalement dédié de façon correcte et souple (DNS et DHCP).

        • [^] # Re: ?

          Posté par . Évalué à 1.

          Je n'étais pas assez clair. Pour les boxes, je parlais juste d'associer un (ou plusieurs) noms à une IP du réseau local. Cela ne résout pas évidemment pas le problème si le serveur en question est externe.

          La solution la plus flexible reste évidemment d'installer un serveur DNS sur un RPi ou tout autre machine. Pour ceux qui ne seraient pas trop bidouilleurs, un Synology (et probablement tout les NAS un peu évolués) permet d'installer un serveur DNS local en quelques clics.

      • [^] # Re: ?

        Posté par . Évalué à 2.

        A noter que gethostbyname est "deprecated".

      • [^] # Re: ?

        Posté par . Évalué à 5.

        Une autre solution pour avoir plusieurs noms sur une IP, sans modifier quoi que ce soit, est d’utiliser les noms alternatifs pour une IP.
        Par exemple, “127.0.0.1”, “127.00.0.1”, “127.1”, “2130706433”, “0x7f000001” vont tous être résolus (par getaddrinfo) vers l’IP 127.0.0.1, mais le nom d’hôte indiqué par le navigateur sera différent.

        • [^] # Re: ?

          Posté par . Évalué à 4.

          Merci c'est une excellente astuce, probablement meilleure que celle du journal (bloquée par tous les FAI sérieux).

        • [^] # Re: ?

          Posté par (page perso) . Évalué à 5.

          Une autre est d'utiliser 127.0.0.2

  • # dans le même esprit

    Posté par . Évalué à 3.

    https://github.com/zapty/echoipdns

    We needed a way to use wildcard domain DNS in our dev environment. The requirements are,

    Work on local machine as well as central server (Can use it in disconnected mode or from office central server).
    Can be used by any developer / tester to access there own system or someone else's system for development with wild card domain names without explicitly provisioning the domain in DNS. i.e if Dev 1 needs to access Dev 2 system, (typically all solutions required provisioning the other system IP in the DNS, or some solutions always returned 127.0.0.1 for any domain.)
    Can be used across Mac, Linux, Windows

Suivre le flux des commentaires

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