2 votes

Pointer *.local vers 127.0.0.1 dans le réseau

La plupart de nos développeurs travaillent donc avec une configuration MAMP/XAMPP en utilisant des règles de réécriture pour pointer vers username.project.local à une racine de document de /Users/username/Projects/project/public_html . Cette partie fonctionne, mais le problème est de faire pointer *.local sur leur machine. Au lieu de s'attaquer à ce problème sur la machine de chaque développeur, je pensais ajouter une règle sur notre DNS interne, puisque nous en avons déjà un de configuré.

Actuellement, dans /var/named/example.com, je vois

@       IN      SOA     SERVER1.EXAMPLE.COM.   dns.example.com.(
                        2013020501      ; Serial yyyymmddnn
                        3h              ; Refresh After 3 hours
                        1h              ; Retry Retry after 1 hour
                        1w              ; Expire after 1 week
                        1h)             ; Minimum negative caching of 1 hour

; NS Records
@                       3600    IN      NS      DNS1.STABLETRANSIT.COM.
@                       3600    IN      NS      DNS2.STABLETRANSIT.COM.

; MX Records
@                       3600    IN      MX      10      ASPMX.L.GOOGLE.COM.
@                       3600    IN      MX      20      ALT1.ASPMX.L.GOOGLE.COM.
@                       3600    IN      MX      20      ALT2.ASPMX.L.GOOGLE.COM.
@                       3600    IN      MX      30      ASPMX2.GOOGLEMAIL.COM.
@                       3600    IN      MX      30      ASPMX3.GOOGLEMAIL.COM.
@                       3600    IN      MX      30      ASPMX4.GOOGLEMAIL.COM.
@                       3600    IN      MX      30      ASPMX5.GOOGLEMAIL.COM.

; Google
mail                    3600    IN      CNAME   ghs.google.com.
docs                    3600    IN      CNAME   ghs.google.com.
mail                    3600    IN      CNAME   ghs.google.com.
calendar                3600    IN      CNAME   ghs.google.com.
sites                   3600    IN      CNAME   ghs.google.com.

; A Records
@                       3600    IN      A       ***.***.***.***

; CNAME Records
www                     3600    IN      A       ***.***.***.***

; Staging Environment
server2              3600    IN      A       192.168.1.1
*.server2            3600    IN      CNAME   server2.example.com.
server3              3600    IN      A       192.168.1.2
*.server3            3600    IN      CNAME   server3.example.com.

Est-il possible d'ajouter une règle pour que *.local soit résolu à 127.0.0.1 ?

4voto

voretaq7 Points 78924

Comme Michael Dillon a souligné , en utilisant .local pour un TLD interne est une mauvaise chose -- il interrompt les services spécifiques au RFC ( RFC 6762 si vous êtes curieux).

Je pousserais sa réponse un peu plus loin et dirais que l'utilisation de tout domaine de premier niveau arbitraire est une mauvaise chose.
L'ICANN autorise désormais l'enregistrement de domaines de premier niveau arbitraires. . Cela signifie que vous pouvez utiliser .secret aujourd'hui et qu'il n'y a pas de collisions, mais demain la NSA peut acquérir ce TLD pour publier le linge sale d'autres personnes, et vous seriez alors en conflit avec tous les autres TLD de la NSA, et vous seriez en conflit avec tous les TLD de la NSA. .secret domaines sur l'internet. C'est une situation déplorable.

La meilleure pratique actuelle pour exposer des "choses internes" avec un nom DNS est d'utiliser un sous-domaine d'un domaine enregistré que vous contrôlez. Par exemple, si vous possédez example.com vous pouvez placer vos sites de développement sous dev.example.com .


D'après votre question, il semble que vous souhaitiez des noms de domaine "locaux" qui renvoient toujours à 127.0.0.1 Dans votre cas, je recommanderais donc de créer deux enregistrements pour local.example.com sur votre DNS interne :

local.example.com.    IN  A  127.0.0.1
*.local.example.com.  IN  A  127.0.0.1

Les développeurs pourraient alors accéder aux foo.local.example.com et ils seront dirigés vers leur machine locale ( 127.0.0.1 ). Cela nécessite davantage de saisie (que vous pouvez éliminer en modifiant l'ordre de recherche des suffixes DNS sur les clients), mais cela permet d'éviter les erreurs de saisie. garanties votre espace de noms est à l'abri des collisions avec des gTLD arbitraires et est conforme aux meilleures pratiques.

Si vous avez besoin d'un document à citer pour convaincre d'autres personnes de votre organisation que c'est la bonne chose à faire, je vous suggère ce qui suit L'excellent article de blog de MDMarra sur les raisons pour lesquelles vous ne devriez pas utiliser le .local pour votre domaine Active Directory -- les raisons qui y sont exposées s'étendent très bien aux n'importe quoi En rapport avec le DNS.

1voto

benjismith Points 8739

En général, c'est une mauvaise idée d'utiliser .local pour les domaines internes. Il se confond avec l'utilisation de .local par les services Bonjour/Rendezvous. Il est préférable de choisir un autre nom comme .secret

Ensuite, vous traitez le .secret de la même manière que le .mycompany.com et vous hébergez vous-même le DNS (maître/esclave). Vous créez un fichier de zone pour .secret et le diffusez en interne. Au lieu de SERVER1.EXAMPLE.COM dans votre exemple, vous auriez un SOA pour SECRET.

0voto

Jonathan J Points 594

En tenant compte des autres messages suggérant de ne pas utiliser un TLD non valide, c'est certainement possible.

Ce que vous cherchez à mettre en œuvre est connu sous le nom de enregistrement DNS de type "wildcard . Les recherches sur l'internet permettent d'acquérir beaucoup de sagesse.

Je m'attendais à ce qu'il soit mis en œuvre de cette manière :

*    IN  A  127.0.0.1

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X