avec Bind 9.2.1, il y a ce qu'on appelle des 'views' :
cf
http://www.isc.org/products/BIND/bind9.html
Views
One server process can provide multiple "views" of the DNS namespace, e.g.
an "inside" view to certain clients, and an "outside" view to others.
je ne sais comment cela se configure exactement, mais ca de devrait pas etre
tres dificile je presume.
un petit tout sur manuel de bind doit repondre a ta question.
The BIND 9 Administrator Reference Manual is also available in PDF format.
http://www.nominum.com/resources/documentation/Bv9ARM.pdf
voici la partie qui devrait t'interesser:
pages 26 et suivantes :
4.3. Split DNS
Setting up different views, or visibility, of DNS space to internal and
external resolvers is usually referred
to as a Split DNS setup. There are several reasons an organization would
want to set up its DNS this way.
One common reason for setting up a DNS system this way is to hide "internal"
DNS information from
"external" clients on the Internet. There is some debate as to whether or
not this is actually useful.
Internal DNS information leaks out in many ways (via email headers, for
example) and most savvy
"attackers" can find the information they need using other means.
Another common reason for setting up a Split DNS system is to allow internal
networks that are behind
filters or in RFC 1918 space (reserved IP space, as documented in RFC 1918)
to resolve DNS on the
Internet. Split DNS can also be used to allow mail from outside back in to
the internal network.
Here is an example of a split DNS setup:
Let's say a company named Example, Inc. (example.com) has several corporate
sites that have an internal
network with reserved Internet Protocol (IP) space and an external
demilitarized zone (DMZ), or
"outside" section of a network, that is available to the public.
Example, Inc. wants its internal clients to be able to resolve external
hostnames and to exchange mail
with people on the outside. The company also wants its internal resolvers to
have access to certain
internal-only zones that are not available at all outside of the internal
network.
In order to accomplish this, the company will set up two sets of
nameservers. One set will be on the
inside network (in the reserved IP space) and the other set will be on
bastion hosts, which are "proxy"
hosts that can talk to both sides of its network, in the DMZ.
The internal servers will be configured to forward all queries, except
queries for site1.internal,
site2.internal, site1.example.com, and site2.example.com, to the servers in
the DMZ.
These internal servers will have complete sets of information for
site1.example.com,
site2.example.com, site1.internal, and site2.internal.
To protect the site1.internal and site2.internal domains, the internal
nameservers must be
configured to disallow all queries to these domains from any external hosts,
including the bastion hosts.
The external servers, which are on the bastion hosts, will be configured to
serve the "public" version of
the site1 and site2.example.com zones. This could include things such as the
host records for
public servers (
www.example.com and
ftp.example.com), and mail exchange (MX)
records
(a.mx.example.com and b.mx.example.com).
In addition, the public site1 and site2.example.com zones should have
special MX records that
contain wildcard ('*') records pointing to the bastion hosts. This is needed
because external mail servers
do not have any other way of looking up how to deliver mail to those
internal hosts. With the wildcard
records, the mail will be delivered to the bastion host, which can then
forward it on to internal hosts.
Here's an example of a wildcard MX record:
* IN MX 10 external1.example.com.
Now that they accept mail on behalf of anything in the internal network, the
bastion hosts will need to
know how to deliver mail to internal hosts. In order for this to work
properly, the resolvers on the bastion
hosts will need to be configured to point to the internal nameservers for
DNS resolution.
Queries for internal hostnames will be answered by the internal servers, and
queries for external
hostnames will be forwarded back out to the DNS servers on the bastion
hosts.
In order for all this to work properly, internal clients will need to be
configured to query only the internal
nameservers for DNS queries. This could also be enforced via selective
filtering on the network.
If everything has been set properly, Example, Inc.'s internal clients will
now be able to:
* Look up any hostnames in the site1 and site2.example.com zones.
* Look up any hostnames in the site1.internal and site2.internal domains.
* Look up any hostnames on the Internet.
* Exchange mail with internal AND external people.
Hosts on the Internet will be able to:
* Look up any hostnames in the site1 and site2.example.com zones.
* Exchange mail with anyone in the site1 and site2.example.com zones.
Here is an example configuration for the setup we just described above. Note
that this is only
configuration information; for information on how to configure your zone
files, see Section 3.1
Internal DNS server config:
acl internals { 172.16.72.0/24; 192.168.1.0/24; };
acl externals { bastion-ips-go-here; };
options {
...
...
forward only;
forwarders { // forward to external
servers
bastion-ips-go-here;
};
allow-transfer { none; }; // sample allowtransfer
(no one)
allow-query { internals; externals; }; // restrict query access
allow-recursion { internals; }; // restrict recursion
...
...
};
zone "site1.example.com" { // sample master zone
type master;
file "m/site1.example.com";
forwarders { }; // do normal iterative
// resolution
(do not forward)
allow-query { internals; externals; };
allow-transfer { internals; };
};
zone "site2.example.com" {
type slave;
file "s/site2.example.com";
masters { 172.16.72.3; };
forwarders { };
allow-query { internals; externals; };
allow-transfer { internals; };
};
zone "site1.internal" {
type master;
file "m/site1.internal";
forwarders { };
allow-query { internals; };
allow-transfer { internals; }
};
zone "site2.internal" {
type slave;
file "s/site2.internal";
masters { 172.16.72.3; };
forwarders { };
allow-query { internals };
allow-transfer { internals; }
};
External (bastion host) DNS server config:
acl internals { 172.16.72.0/24; 192.168.1.0/24; };
acl externals { bastion-ips-go-here; };
options {
...
...
allow-transfer { none; }; // sample allowtransfer
(no one)
allow-query { internals; externals; }; // restrict query access
allow-recursion { internals; externals; }; // restrict recursion
...
...
};
zone "site1.example.com" { // sample slave zone
type master;
file "m/site1.foo.com";
allow-query { any; };
allow-transfer { internals; externals; };
};
zone "site2.example.com" {
type slave;
file "s/site2.foo.com";
masters { another_bastion_host_maybe; };
allow-query { any; };
allow-transfer { internals; externals; }
};
In the resolv.conf (or equivalent) on the bastion host(s):
search ...
nameserver 172.16.72.2
nameserver 172.16.72.3
nameserver 172.16.72.4
> -----Message d'origine-----
> De : sCALP [mailto:scalp@tibone.com]
> Envoyé : jeudi 31 octobre 2002 11:01
> À : guilde@???
> Objet : dns multi-reseaux
>
>
> Bonjour, cette question sort du domaine strictement linux,
> mais je vous
> demande votre aide car je vais me perdre si je vais sur les
> forums bind.....
> je viens de decouvrir avec bonheur qu'il est possible
> d'associer plusieurs
> IPs a un alias dans une definition de zone
>
> dev.mondomaine.com. A 192.168.1.15
> dev.mondomaine.com. A 10.0.1.15
>
> mais je desirerai que lorsque une machine du reseau 10.x
> interroge le DNS,
> il n'obtienne que l'IP concernant son reseau (donc la
> 10.0.1.15), et la meme
> chose pour le reseau 192.x qui obtiendra 192.168.1.15.....
> est-ce possible ?
>
> actuellement, je fais tourner 3 bind9, chacun sur une
> interface reseau
> differente. mais pour les mises a jour, c'est horrible... je
> prefere gerer 3
> lignes dans un seul fichier de zone, qu'une ligne dans 3
> fichiers pour la
> meme zone.... ;-)
>
> merci pour votre aide.
> sCALP
>
