From time to time, I write an article for the Oopsilon web site. While the article is being written, I like to check that it's displaying correctly on the web site, which involves loading it up in a browser. This is perfectly fine, except that my working computer is on the same network as the web server, and the network is internal.
Anyone coming from outside the network (outside my house, in other words)
will be able to view the article without a problem: a request is made to
Oopsilon, which resolves (currently) to 87.194.101.173, and a
connection request is made to that IP address. My firewall translates that to
the web server's internal IP of 192.168.0.1, and maintains the
translation both ways.
From inside the network, it's another story. Oopsilon resolves to
87.194.101.173 as before, but when the firewall receives that
connection request, it sees a connection from the internal network to
the outside world, and immediately back into the network. As a result, the
firewall refuses to connect the request, and I end up unable to see my
article.
Standard BIND Configuration
The problem inside the network is caused by Oopsilon resolving to an external IP. This happens because BIND is configured with a simple DNS zone, as follows:
oopsilon.zone: External zone file
IN SOA adhocbox.oopsilon.com. tf.oopsilon.com. (
2008042701 ; Serial
28800 ; Refresh
14400 ; Retry
604800 ; Expire
86400 ) ; Minimum
NS adhocbox.oopsilon.com.
MX 10 oopsilon.com.
oopsilon.com. IN A 87.194.101.173
adhocbox IN CNAME oopsilon.com.
www IN CNAME oopsilon.com.
BIND is then told to use this zone for requests relating to the domain in question, as follows:
named.conf: BIND master configuration
zone "oopsilon.com" IN {
type master;
file "oopsilon.zone";
allow-update { 88.192.91.15; };
notify yes;
};
The configuration above states that any requests for the domain will be serviced by the zone file given. This includes requests from inside the LAN, which should resolve to the LAN address of the web server. This can be fixed by using not one, but two zone files.
View-Specific BIND Configuration
For external requests, the zone file above is sufficient: serving the external IP is what these clients will expect. For internal requests, a seperate zone can be used:
oopsilon.zone.int: Internal zone file
IN SOA adhocbox.oopsilon.com. tf.oopsilon.com. (
2008042701 ; Serial
28800 ; Refresh
14400 ; Retry
604800 ; Expire
86400 ) ; Minimum
NS adhocbox.oopsilon.com.
MX 10 oopsilon.com.
oopsilon.com. IN A 192.168.0.1
adhocbox IN CNAME oopsilon.com.
www IN CNAME oopsilon.com.
In order to select between the two zone files, a series of "views" can be set up in the configuration file, where each view is matched against a series of IP addresses. This is done by nesting zones inside view blocks:
named.conf: Master configuration with views
view "internal" {
match-clients { 192.168.0.0/24; };
zone "oopsilon.com" IN {
type master;
file "oopsilon.zone.int";
allow-update { none; };
notify no;
};
};
view "external" {
match-clients { any; };
zone "oopsilon.com" IN {
type master;
file "oopsilon.zone";
allow-update { 88.192.91.15; };
notify yes;
};
};
In the above configuration, there are two views: internal for
clients from the internal network (192.168.0.x), and
external for everyone else. A view can have any number of zones
inside, but in this case I only need one zone in each.
One this configuration has been put in place, its operation is automatic: anyone from the LAN will receive the LAN IP of the web server, and will be able to view the web site. Clients outside the network will receive an external IP, and also be able to see the web site. Everyone wins.
Copyright Imran Nazar <tf@oopsilon.com>, 2008