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

Article dated: 2nd Jun 2008

Get the RSS feed