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:

LOCAL
STATIC NAT ROUTER
SERVER

192.168.1.100 ISP1 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 SOA ns.company.com
IN MX mail
WWW IN NS linkproof1
WWW IN NS linkproof2
MAIL 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).