Bonsoir,
Il y a quelques temps, je me suis offert un nom de domaine avec site web,
serveur de mail et gestion de dns chez ovh. Cela fonctionne parfaitement.
Donc si je veux pinger "mon serveur web", je fais un ping www.asgardian.be
et cela fonctionne.
Je configure maintenant un DNS local pour mon lan, un petit réseau qui
s'appel biensur asgardian.be.
Afin de pouvoir continuer à pinger www.asgardian.be qui se trouve toujours
chez ovh, j'ai du ajouter ces lignes dans le fichier de config de mon dns
pour la zone asgardian.be.
60gp.ovh.net IN A 213.186.33.19
www IN CNAME 60gp.ovh.net
Cela veut dire que je dois "recréer" la structure de DNS de ovh pour que
cela fonctionne.
Le DNS de mon lan, ne répond qu'a des requêtes locales. Comme mon réseau
n'héberge aucun serveur accessible du net, les requêtes externes sont
gérées par ovh.
L'idéal, pour moi, serait de dire à mon DNS que www n'est pas une machine
locale mais une machine gérée à l'extérieur et qu'il doit simplement
forwarder les requètes vers le net. Ceci est-il possible ?
Bonsoir,
Il y a quelques temps, je me suis offert un nom de domaine avec site web,
serveur de mail et gestion de dns chez ovh. Cela fonctionne parfaitement.
Donc si je veux pinger "mon serveur web", je fais un ping www.asgardian.be
et cela fonctionne.
Je configure maintenant un DNS local pour mon lan, un petit réseau qui
s'appel biensur asgardian.be.
Afin de pouvoir continuer à pinger www.asgardian.be qui se trouve toujours
chez ovh, j'ai du ajouter ces lignes dans le fichier de config de mon dns
pour la zone asgardian.be.
60gp.ovh.net IN A 213.186.33.19
www IN CNAME 60gp.ovh.net
Cela veut dire que je dois "recréer" la structure de DNS de ovh pour que
cela fonctionne.
Le DNS de mon lan, ne répond qu'a des requêtes locales. Comme mon réseau
n'héberge aucun serveur accessible du net, les requêtes externes sont
gérées par ovh.
L'idéal, pour moi, serait de dire à mon DNS que www n'est pas une machine
locale mais une machine gérée à l'extérieur et qu'il doit simplement
forwarder les requètes vers le net. Ceci est-il possible ?
Bonsoir,
Il y a quelques temps, je me suis offert un nom de domaine avec site web,
serveur de mail et gestion de dns chez ovh. Cela fonctionne parfaitement.
Donc si je veux pinger "mon serveur web", je fais un ping www.asgardian.be
et cela fonctionne.
Je configure maintenant un DNS local pour mon lan, un petit réseau qui
s'appel biensur asgardian.be.
Afin de pouvoir continuer à pinger www.asgardian.be qui se trouve toujours
chez ovh, j'ai du ajouter ces lignes dans le fichier de config de mon dns
pour la zone asgardian.be.
60gp.ovh.net IN A 213.186.33.19
www IN CNAME 60gp.ovh.net
Cela veut dire que je dois "recréer" la structure de DNS de ovh pour que
cela fonctionne.
Le DNS de mon lan, ne répond qu'a des requêtes locales. Comme mon réseau
n'héberge aucun serveur accessible du net, les requêtes externes sont
gérées par ovh.
L'idéal, pour moi, serait de dire à mon DNS que www n'est pas une machine
locale mais une machine gérée à l'extérieur et qu'il doit simplement
forwarder les requètes vers le net. Ceci est-il possible ?
Thierry Leurent wrote:Bonsoir,
Il y a quelques temps, je me suis offert un nom de domaine avec site
web,
serveur de mail et gestion de dns chez ovh. Cela fonctionne
parfaitement.
Donc si je veux pinger "mon serveur web", je fais un ping
www.asgardian.be
et cela fonctionne.
Je configure maintenant un DNS local pour mon lan, un petit réseau qui
s'appel biensur asgardian.be.
Afin de pouvoir continuer à pinger www.asgardian.be qui se trouve
toujours
chez ovh, j'ai du ajouter ces lignes dans le fichier de config de mon
dns
pour la zone asgardian.be.
60gp.ovh.net IN A 213.186.33.19
www IN CNAME 60gp.ovh.net
pourquoi utiliser un nom aussi long que 60gp.ovh.net? un petit
ovh IN A 213.186.33.19
www IN CNAME ovh
mail IN CNAME ovh
...
suffirait.Cela veut dire que je dois "recréer" la structure de DNS de ovh pour que
cela fonctionne.
Le DNS de mon lan, ne répond qu'a des requêtes locales. Comme mon réseau
n'héberge aucun serveur accessible du net, les requêtes externes sont
gérées par ovh.
L'idéal, pour moi, serait de dire à mon DNS que www n'est pas une
machine
locale mais une machine gérée à l'extérieur et qu'il doit simplement
forwarder les requètes vers le net. Ceci est-il possible ?
si ton DNS local gère asgardian.be, il faut reproduire toutes les
données de la zone dedans, et si besoin est, ajouter des entrées locales
(c'est un peu du "split dns").
si tu peux autoriser ta machine à être faire du transfer de zone, tu
peux alors configurer ton dns local en secondaire juste pour qu'il
récupère tout, et ensuite le remettre en primaire après avoir rajouté
les entrées locales. il faut refaire la procédure à chaque fois que le
dns "officiel" change, ce qui peut être pénible.
le plus simple est d'utiliser un domaine local sur ton lan
("asgardian.private" par exemple), comme ça il n'y a rien à copier entre
les deux serveurs.
l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
dns officiel, mais bon, "tout le monde" saura quelles IPs internes
correspondent à tes serveurs, ce qui n'est pas super top (à moins
d'ajouter des entrées pour toutes les IPs privées possibles, ou un grand
nombre du moins, histoire de noyer les bonnes infos).
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Thierry Leurent wrote:
Bonsoir,
Il y a quelques temps, je me suis offert un nom de domaine avec site
web,
serveur de mail et gestion de dns chez ovh. Cela fonctionne
parfaitement.
Donc si je veux pinger "mon serveur web", je fais un ping
www.asgardian.be
et cela fonctionne.
Je configure maintenant un DNS local pour mon lan, un petit réseau qui
s'appel biensur asgardian.be.
Afin de pouvoir continuer à pinger www.asgardian.be qui se trouve
toujours
chez ovh, j'ai du ajouter ces lignes dans le fichier de config de mon
dns
pour la zone asgardian.be.
60gp.ovh.net IN A 213.186.33.19
www IN CNAME 60gp.ovh.net
pourquoi utiliser un nom aussi long que 60gp.ovh.net? un petit
ovh IN A 213.186.33.19
www IN CNAME ovh
mail IN CNAME ovh
...
suffirait.
Cela veut dire que je dois "recréer" la structure de DNS de ovh pour que
cela fonctionne.
Le DNS de mon lan, ne répond qu'a des requêtes locales. Comme mon réseau
n'héberge aucun serveur accessible du net, les requêtes externes sont
gérées par ovh.
L'idéal, pour moi, serait de dire à mon DNS que www n'est pas une
machine
locale mais une machine gérée à l'extérieur et qu'il doit simplement
forwarder les requètes vers le net. Ceci est-il possible ?
si ton DNS local gère asgardian.be, il faut reproduire toutes les
données de la zone dedans, et si besoin est, ajouter des entrées locales
(c'est un peu du "split dns").
si tu peux autoriser ta machine à être faire du transfer de zone, tu
peux alors configurer ton dns local en secondaire juste pour qu'il
récupère tout, et ensuite le remettre en primaire après avoir rajouté
les entrées locales. il faut refaire la procédure à chaque fois que le
dns "officiel" change, ce qui peut être pénible.
le plus simple est d'utiliser un domaine local sur ton lan
("asgardian.private" par exemple), comme ça il n'y a rien à copier entre
les deux serveurs.
l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
dns officiel, mais bon, "tout le monde" saura quelles IPs internes
correspondent à tes serveurs, ce qui n'est pas super top (à moins
d'ajouter des entrées pour toutes les IPs privées possibles, ou un grand
nombre du moins, histoire de noyer les bonnes infos).
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
Thierry Leurent wrote:Bonsoir,
Il y a quelques temps, je me suis offert un nom de domaine avec site
web,
serveur de mail et gestion de dns chez ovh. Cela fonctionne
parfaitement.
Donc si je veux pinger "mon serveur web", je fais un ping
www.asgardian.be
et cela fonctionne.
Je configure maintenant un DNS local pour mon lan, un petit réseau qui
s'appel biensur asgardian.be.
Afin de pouvoir continuer à pinger www.asgardian.be qui se trouve
toujours
chez ovh, j'ai du ajouter ces lignes dans le fichier de config de mon
dns
pour la zone asgardian.be.
60gp.ovh.net IN A 213.186.33.19
www IN CNAME 60gp.ovh.net
pourquoi utiliser un nom aussi long que 60gp.ovh.net? un petit
ovh IN A 213.186.33.19
www IN CNAME ovh
mail IN CNAME ovh
...
suffirait.Cela veut dire que je dois "recréer" la structure de DNS de ovh pour que
cela fonctionne.
Le DNS de mon lan, ne répond qu'a des requêtes locales. Comme mon réseau
n'héberge aucun serveur accessible du net, les requêtes externes sont
gérées par ovh.
L'idéal, pour moi, serait de dire à mon DNS que www n'est pas une
machine
locale mais une machine gérée à l'extérieur et qu'il doit simplement
forwarder les requètes vers le net. Ceci est-il possible ?
si ton DNS local gère asgardian.be, il faut reproduire toutes les
données de la zone dedans, et si besoin est, ajouter des entrées locales
(c'est un peu du "split dns").
si tu peux autoriser ta machine à être faire du transfer de zone, tu
peux alors configurer ton dns local en secondaire juste pour qu'il
récupère tout, et ensuite le remettre en primaire après avoir rajouté
les entrées locales. il faut refaire la procédure à chaque fois que le
dns "officiel" change, ce qui peut être pénible.
le plus simple est d'utiliser un domaine local sur ton lan
("asgardian.private" par exemple), comme ça il n'y a rien à copier entre
les deux serveurs.
l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
dns officiel, mais bon, "tout le monde" saura quelles IPs internes
correspondent à tes serveurs, ce qui n'est pas super top (à moins
d'ajouter des entrées pour toutes les IPs privées possibles, ou un grand
nombre du moins, histoire de noyer les bonnes infos).
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
dns officiel, mais bon, "tout le monde" saura quelles IPs internes
correspondent à tes serveurs, ce qui n'est pas super top
l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
dns officiel, mais bon, "tout le monde" saura quelles IPs internes
correspondent à tes serveurs, ce qui n'est pas super top
l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
dns officiel, mais bon, "tout le monde" saura quelles IPs internes
correspondent à tes serveurs, ce qui n'est pas super top
On Sun, Dec 30, 2007 at 01:25:40PM +0100, mouss wrote:l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
dns officiel, mais bon, "tout le monde" saura quelles IPs internes
correspondent à tes serveurs, ce qui n'est pas super top
Quel problème ça pose?
On Sun, Dec 30, 2007 at 01:25:40PM +0100, mouss wrote:
l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
dns officiel, mais bon, "tout le monde" saura quelles IPs internes
correspondent à tes serveurs, ce qui n'est pas super top
Quel problème ça pose?
On Sun, Dec 30, 2007 at 01:25:40PM +0100, mouss wrote:l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
dns officiel, mais bon, "tout le monde" saura quelles IPs internes
correspondent à tes serveurs, ce qui n'est pas super top
Quel problème ça pose?
Salut,
Yves Rutschle a écrit :On Sun, Dec 30, 2007 at 01:25:40PM +0100, mouss wrote:l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
dns officiel, mais bon, "tout le monde" saura quelles IPs internes
correspondent à tes serveurs, ce qui n'est pas super top
Quel problème ça pose?
C'est contraire aux Ecritures. Il est dit dans RFC 1918 - Address
Allocation for Private Internets, verset 5 :
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.
Pour répondre à la question initiale, c'est peut-être faisable en
créant une zone "www.asgardian.be" de type forward sur le serveur DNS
local. Je ne peux rien garantir, n'ayant jamais utilisé ce type de zone.
Mais personnellement je créerais plutôt sur le serveur DNS local un
sous-domaine de asgardian.be dédié aux machines du réseau local, par
exemple local.asgardian.be.
Salut,
Yves Rutschle a écrit :
On Sun, Dec 30, 2007 at 01:25:40PM +0100, mouss wrote:
l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
dns officiel, mais bon, "tout le monde" saura quelles IPs internes
correspondent à tes serveurs, ce qui n'est pas super top
Quel problème ça pose?
C'est contraire aux Ecritures. Il est dit dans RFC 1918 - Address
Allocation for Private Internets, verset 5 :
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.
Pour répondre à la question initiale, c'est peut-être faisable en
créant une zone "www.asgardian.be" de type forward sur le serveur DNS
local. Je ne peux rien garantir, n'ayant jamais utilisé ce type de zone.
Mais personnellement je créerais plutôt sur le serveur DNS local un
sous-domaine de asgardian.be dédié aux machines du réseau local, par
exemple local.asgardian.be.
Salut,
Yves Rutschle a écrit :On Sun, Dec 30, 2007 at 01:25:40PM +0100, mouss wrote:l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
dns officiel, mais bon, "tout le monde" saura quelles IPs internes
correspondent à tes serveurs, ce qui n'est pas super top
Quel problème ça pose?
C'est contraire aux Ecritures. Il est dit dans RFC 1918 - Address
Allocation for Private Internets, verset 5 :
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.
Pour répondre à la question initiale, c'est peut-être faisable en
créant une zone "www.asgardian.be" de type forward sur le serveur DNS
local. Je ne peux rien garantir, n'ayant jamais utilisé ce type de zone.
Mais personnellement je créerais plutôt sur le serveur DNS local un
sous-domaine de asgardian.be dédié aux machines du réseau local, par
exemple local.asgardian.be.
une autre solution est de splité le dns avec une vue externe et une vu
interne.
une autre solution est de splité le dns avec une vue externe et une vu
interne.
une autre solution est de splité le dns avec une vue externe et une vu
interne.
Pascal Hambourg a écrit :Salut,
Yves Rutschle a écrit :On Sun, Dec 30, 2007 at 01:25:40PM +0100, mouss wrote:l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
dns officiel, mais bon, "tout le monde" saura quelles IPs internes
correspondent à tes serveurs, ce qui n'est pas super top
Quel problème ça pose?
C'est contraire aux Ecritures. Il est dit dans RFC 1918 - Address
Allocation for Private Internets, verset 5 :
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.
Pour répondre à la question initiale, c'est peut-être faisable en
créant une zone "www.asgardian.be" de type forward sur le serveur DNS
local. Je ne peux rien garantir, n'ayant jamais utilisé ce type de zone.
Mais personnellement je créerais plutôt sur le serveur DNS local un
sous-domaine de asgardian.be dédié aux machines du réseau local, par
exemple local.asgardian.be.
Bonjour et bonne année,
une autre solution est de splité le dns avec une vue externe et une vu
interne.
acl my_network {
172.16.0.0/16;
};
view "interne" {
match-clients { "my_network"; };
recursion yes;
zone "asguardian.be" {
type master;
file "db.asguardian.be.lan";
};
//etc ...
view "externe" {
match-clients { any; };
recursion no;
zone "asguardian.be" {
type master;
file "db.asguardian.be";
allow-transfer {x.x.x.x;};
};
//etc...
a+
Pascal Hambourg a écrit :
Salut,
Yves Rutschle a écrit :
On Sun, Dec 30, 2007 at 01:25:40PM +0100, mouss wrote:
l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
dns officiel, mais bon, "tout le monde" saura quelles IPs internes
correspondent à tes serveurs, ce qui n'est pas super top
Quel problème ça pose?
C'est contraire aux Ecritures. Il est dit dans RFC 1918 - Address
Allocation for Private Internets, verset 5 :
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.
Pour répondre à la question initiale, c'est peut-être faisable en
créant une zone "www.asgardian.be" de type forward sur le serveur DNS
local. Je ne peux rien garantir, n'ayant jamais utilisé ce type de zone.
Mais personnellement je créerais plutôt sur le serveur DNS local un
sous-domaine de asgardian.be dédié aux machines du réseau local, par
exemple local.asgardian.be.
Bonjour et bonne année,
une autre solution est de splité le dns avec une vue externe et une vu
interne.
acl my_network {
172.16.0.0/16;
};
view "interne" {
match-clients { "my_network"; };
recursion yes;
zone "asguardian.be" {
type master;
file "db.asguardian.be.lan";
};
//etc ...
view "externe" {
match-clients { any; };
recursion no;
zone "asguardian.be" {
type master;
file "db.asguardian.be";
allow-transfer {x.x.x.x;};
};
//etc...
a+
Pascal Hambourg a écrit :Salut,
Yves Rutschle a écrit :On Sun, Dec 30, 2007 at 01:25:40PM +0100, mouss wrote:l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
dns officiel, mais bon, "tout le monde" saura quelles IPs internes
correspondent à tes serveurs, ce qui n'est pas super top
Quel problème ça pose?
C'est contraire aux Ecritures. Il est dit dans RFC 1918 - Address
Allocation for Private Internets, verset 5 :
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.
Pour répondre à la question initiale, c'est peut-être faisable en
créant une zone "www.asgardian.be" de type forward sur le serveur DNS
local. Je ne peux rien garantir, n'ayant jamais utilisé ce type de zone.
Mais personnellement je créerais plutôt sur le serveur DNS local un
sous-domaine de asgardian.be dédié aux machines du réseau local, par
exemple local.asgardian.be.
Bonjour et bonne année,
une autre solution est de splité le dns avec une vue externe et une vu
interne.
acl my_network {
172.16.0.0/16;
};
view "interne" {
match-clients { "my_network"; };
recursion yes;
zone "asguardian.be" {
type master;
file "db.asguardian.be.lan";
};
//etc ...
view "externe" {
match-clients { any; };
recursion no;
zone "asguardian.be" {
type master;
file "db.asguardian.be";
allow-transfer {x.x.x.x;};
};
//etc...
a+
>>l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
>>dns officiel, mais bon, "tout le monde" saura quelles IPs internes
>>correspondent à tes serveurs, ce qui n'est pas super top
>
>Quel problème ça pose?
C'est contraire aux Ecritures. Il est dit dans RFC 1918 - Address
Allocation for Private Internets, verset 5 :
>>l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
>>dns officiel, mais bon, "tout le monde" saura quelles IPs internes
>>correspondent à tes serveurs, ce qui n'est pas super top
>
>Quel problème ça pose?
C'est contraire aux Ecritures. Il est dit dans RFC 1918 - Address
Allocation for Private Internets, verset 5 :
>>l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
>>dns officiel, mais bon, "tout le monde" saura quelles IPs internes
>>correspondent à tes serveurs, ce qui n'est pas super top
>
>Quel problème ça pose?
C'est contraire aux Ecritures. Il est dit dans RFC 1918 - Address
Allocation for Private Internets, verset 5 :
On Mon, Dec 31, 2007 at 12:24:29PM +0100, Pascal Hambourg wrote:l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
dns officiel, mais bon, "tout le monde" saura quelles IPs internes
correspondent à tes serveurs, ce qui n'est pas super top
Quel problème ça pose?
C'est contraire aux Ecritures. Il est dit dans RFC 1918 - Address
Allocation for Private Internets, verset 5 :
Je comprend qu'il ne faut pas le faire, je ne comprend pas
pourquoi c'est un problème de sécurité ("risqué").
On Mon, Dec 31, 2007 at 12:24:29PM +0100, Pascal Hambourg wrote:
l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
dns officiel, mais bon, "tout le monde" saura quelles IPs internes
correspondent à tes serveurs, ce qui n'est pas super top
Quel problème ça pose?
C'est contraire aux Ecritures. Il est dit dans RFC 1918 - Address
Allocation for Private Internets, verset 5 :
Je comprend qu'il ne faut pas le faire, je ne comprend pas
pourquoi c'est un problème de sécurité ("risqué").
On Mon, Dec 31, 2007 at 12:24:29PM +0100, Pascal Hambourg wrote:l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
dns officiel, mais bon, "tout le monde" saura quelles IPs internes
correspondent à tes serveurs, ce qui n'est pas super top
Quel problème ça pose?
C'est contraire aux Ecritures. Il est dit dans RFC 1918 - Address
Allocation for Private Internets, verset 5 :
Je comprend qu'il ne faut pas le faire, je ne comprend pas
pourquoi c'est un problème de sécurité ("risqué").
On Mon, Dec 31, 2007 at 12:24:29PM +0100, Pascal Hambourg wrote:>>l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
>>dns officiel, mais bon, "tout le monde" saura quelles IPs internes
>>correspondent à tes serveurs, ce qui n'est pas super top
>
>Quel problème ça pose?
C'est contraire aux Ecritures. Il est dit dans RFC 1918 - Address
Allocation for Private Internets, verset 5 :
Je comprend qu'il ne faut pas le faire, je ne comprend pas
pourquoi c'est un problème de sécurité ("risqué").
On Mon, Dec 31, 2007 at 12:24:29PM +0100, Pascal Hambourg wrote:
>>l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
>>dns officiel, mais bon, "tout le monde" saura quelles IPs internes
>>correspondent à tes serveurs, ce qui n'est pas super top
>
>Quel problème ça pose?
C'est contraire aux Ecritures. Il est dit dans RFC 1918 - Address
Allocation for Private Internets, verset 5 :
Je comprend qu'il ne faut pas le faire, je ne comprend pas
pourquoi c'est un problème de sécurité ("risqué").
On Mon, Dec 31, 2007 at 12:24:29PM +0100, Pascal Hambourg wrote:>>l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le
>>dns officiel, mais bon, "tout le monde" saura quelles IPs internes
>>correspondent à tes serveurs, ce qui n'est pas super top
>
>Quel problème ça pose?
C'est contraire aux Ecritures. Il est dit dans RFC 1918 - Address
Allocation for Private Internets, verset 5 :
Je comprend qu'il ne faut pas le faire, je ne comprend pas
pourquoi c'est un problème de sécurité ("risqué").