Bonjour,
si le problème de fond est d'autoriser ou pas d'atteindre une cible suivant d'où on vient, une des solutions serait de rajouter des adresses IPv6 (unicast) partout. Tu aurais une seule entrée dans le fichier de zone et le plus important est d'avoir des règles de filtrage correctes ;) Le 08/02/2019 à 15:27, AYANIDES, Jean-Philippe a écrit : > Bonjour, > > je n'arrive pas à trouver une réponse justifiée à la question suivante, alors > je m'adresse à vous sur conseil de mes collègues (désolé si ce sont des > questions bêtes et rebattues, je n'ai rien trouvé dans les archives de la > frnog) : > > dans le cadre d'une organisation example.com, à supposer que la zone > corp.example.com ne soit pas répliquée dans les DNS publiques example.com > ouverts sur internet, est-il possible et/ou non déconseillé, dans les DNS > internes > > - de résoudre un enregistrement A a.corp.example.com en adresse privée ? (de > façon générale, on a tendance à utiliser des noms locaux avec un TLD .local > mais l'IETF ne le recommande pas, cf. > https://tools.ietf.org/html/rfc6762#appendix-G). > > - de résoudre un même SOA corp.example.com avec une adresse IP privée depuis > le DNS interne privé et une adresse publique depuis le serveur DNS interne > publique ? > > - de résoudre certains enregistrements A du domaine corp.example.com en > adresses publiques et d'autres en adresses privées ? > > Si rien n'est possible proprement, quelle alternative peut-on trouver ? > faut-il segmenter en nommant par exemple tout ce qui est adressage publique > en pub.corp.example.com et tout ce qui est en adressage privé en > priv.example.com ? > > Je vous avoue que je ne suis pas familier avec la RFC… > > Merci > > Jean-Philippe -- Willy Manga @ongolaboy https://ongola.blogspot.com/
signature.asc
Description: OpenPGP digital signature
