How do I set up DNS with my Linkproof?
Document ID: 1000001
Published: 30/03/2006 10:31:32 a.m.
To provide inbound load balancing and redundancy, the Linkproof utilizes DNS resolution to control the flow of incoming traffic. This
document is intended to give a step-by-step overview of configuring Linkproof with DNS. It assumes that you are familiar with configuring
the Linkproof’s interface addresses and Next Hop Routers (for further information on setting up the Linkproof, refer to the Linkproof
User’s Guide). It also assumes you have a working knowledge of DNS (for further information on DNS, refer to DNS and Bind published
by O’Reilly & Associates).
Although the Linkproof has a built-in DNS agent, it is not a full DNS server. It cannot answer queries for NS records, CNAMES, or MX
records. Only A record requests that match URLs listed in the DNS > Name to Local IP table will receive a response.
1: Simple Setup – Single Linkproof with External SOA
A typical (simple) scenario might be the following:
COMPANY.COM has one Internet link, ISP1. This ISP currently answers all requests for
www.company.com. With the installation of a new Internet link, COMPANY adds a Linkproof.
(For the examples we will use non-routeable addresses. An actual installation would require
public, routeable addresses)
The first step is to set up static nat addresses for the webserver. Since the Linkproof will be
handling the public addresses, we’ll use the following static nat settings:
STATIC NAT ROUTER
192.168.1.100
ISP1
LOCAL
SERVER
172.16.1.100
10.1.1.100
ISP2
172.16.1.100
(Linkproof > Global Configuration > Enable Smart Nat)
(Linkproof > SmartNAT > Static NAT > Insert rows)
Next, we configure DNS to Local IP (Linkproof > DNS > Name to Local IP)
URL
LOCAL IP
ADDRESS
www.company.com
172.16.1.100
*Note: Use the internal address of the server,
not the static nat addresses.
This alone is enough to allow the Linkproof to answer queries for www.company.com, and
lookups directed to the interface address (i.e., 192.168.1.10 & 10.1.1.10) will return static nat
addresses. However, since most of the world will be querying ISP1’s DNS server, we will have
to modify the zone file to get the requests to the Linkproof.
2: Modifying DNS on the External SOA
The original zone file for COMPANY.COM on ISP1’s DNS server might look like Figure 2.1 (this
is highly simplified):
To refer the A record resolution to the Linkproof, we make the following changes.
What this does is to delegate the final answer to the Linkproof. Initially the client queried the
DNS server and received the IP. Now, the client queries the DNS server, who tells the client to
ask the Linkproof at one of the ISP interface addresses. The client then queries the interface IP
on the Linkproof, and is given the static nat address for www.company.com, choosing the best
route to bring in the connection based on load balancing (or proximity).
Two NS records are used and returned to the client because the external DNS server will not
know if either of the links is down. Providing both ISP interfaces for the Linkproof as A records is
necessary to properly delegate the query. The SOA can be made to round robin the NS records
it gives out, so that DNS queries are actively sent to each ISP. *Note: In Windows2000, adding
an NS record is called “New Delegation.”
The flow of queries is something like this:
Client (to ISP): Where is www.company.com?
ISP DNS: I don’t know, ask Linkproof1.company.com or Linkproof2.company.com. (This is the
delegation)
Client (to ISP): Where is linkproof1.company.com?
ISP DNS: 192.168.1.10
Client (to LP1): Where is www.company.com?
Linkproof1: 192.168.1.100
The same zone file would apply to multiple DNS servers, so that company.com can register
ISP1’s DNS server, as well as ISP2’s DNS server as the SOA (thus eliminating an additional
point of failure).
We do not recommend delegating your root-level domain name (company.com) as this could
potentially cause clients to come to the Linkproof asking for MX records. It is advisable to use
two static A records for the domain root, ensuring clients are able to connect via either link. It is
possible (in some cases) to create a CNAME for the root domain to point to a subdomain (i.e.,
company.com = www.company.com) and then delegate the subdomain, but doing this may limit
the zone’s ability to delegate other records (specifically MX records).
Adding a Redundant Linkproof
The addition of a backup Linkproof is simple and does not require much deviation from the
above settings. Obviously, the static nat addresses that exist on the primary should be
duplicated on the backup (but set in backup mode) as well as the DNS to Local IP table. This
paper also assumes familiarity with redundancy setup in general. Here we focus on the changes
in relation to DNS.
The main deviation from the first setup is the creation of a DNS Virtual IP. This is an additional,
unique IP address on each ISP subnet. On the primary unit above, we will create the following
entries (Linkproof > DNS > DNS Virtual IP)
On the backup unit, the same entries are made, but the mode is backup. The zone file above
would simply reflect that LINKPROOF1 and LINKPROOF2 IP addresses are now .11 instead of
.10 (See Figure 2.3)
Figure 2.3
COMPANY.COM
IN
@
IN
SOA
ns.company.com
MX
NS
mail
WWW
IN
linkproof1
WWW
NS
linkproof2
MAIL
IN
IN
NS
linkproof1
MAIL
IN
NS
linkproof2
LINKPROOF1 IN
A
192.168.1.11
LINKPROOF2 IN
A
10.1.1.11
3: Complete Setup – Redundant Linkproofs with Multiple Internal SOAs
Now let’s suppose Company.com wants to add a second firewall and bring the SOA in-house.
The firewalls themselves run DNS services, and DNS requests should be load balanced
between them (this would also apply if the DNS servers were behind a DMZ).
Figure 3.1 illustrates the layout of the network. For simplicity’s sake, we will assume the firewalls
answer DNS on a unique IP address (rather than their interface addresses), and NAT traffic
from the internal LAN to a unique IP. In this way the Linkproof can differentiate outbound LAN
traffic from inbound DNS (or web) requests. While it is possible that all traffic (in and out) can be
natted to the firewall’s interface address, such a setup will be covered separately.
Name
Interface Addr
DNS Address
NAT address
FIREWALL-A
172.168.1.30
172.168.1.40
172.168.1.50
FIREWALL-B
172.168.1.31
172.168.1.41
172.168.1.51
The first step is to create a Virtual IP rather than the static NATs covered in the first example.
Under Linkproof > Virtual IP we define a single, private IP (172.168.1.100) which is mapped to
the DNS addresses on each firewall (172.168.1.40 and 172.168.1.41). We can then create a
Static NAT address for each ISP subnet, and use the Virtual IP as the local server (Linkproof >
Smart NAT > Static NAT). These two static NAT entries will be registered as the SOA
nameservers with Network Solutions. *Note: If using internal DNS servers, be aware of changes
needed to proximity parameters on the Linkproof. Since an internal DNS server will query the
Linkproof for the A record, we need to tell the Linkproof to ignore proximity calculations to these
servers (otherwise he will calculate proximity for the internal subnet).
When DNS requests from the internet enter the static nat addresses, they are load balanced
between the two firewalls (using the same algorithm that is used for NHR load balancing). Each
firewall is configured with a zone file similar to the first example, so that the handling of the A
record (the final, destination IP) is referred to the Linkproof’s interface (or Virtual DNS Address).