LinkProof DNS Quick Start Guide

TABLE OF CONTENTS

1 INTRODUCTION ...3

2 SIMPLE SCENARIO – SINGLE LINKPROOF WITH EXTERNAL SOA ...3

3 MODIFYING DNS ON THE EXTERNAL SOA ...4

3.1 REFERRING THE ARECORD RESOLUTION TO LINKPROOF ... 4

3.2 ADDING A REDUNDANT (BACKUP)LINKPROOF DEVICE ... 5

4 COMPLETE SETUP – REDUNDANT LINKPROOF DEVICES WITH MULTIPLE INTERNAL SOAS ...6

Page 3

1

Introduction

To provide inbound load balancing and redundancy, LinkProof uses DNS resolution to control the flow of incoming traffic. This document describes how to configure LinkProof with DNS. It assumes that:

 You are familiar with configuring LinkProof ’s interface addresses and Next Hop Routers. For more information on setting up LinkProof, refer to the LinkProof User Guide.

 You have a working knowledge of DNS. For more information on DNS, refer to DNS and Bind, published by O’Reilly & Associates.

 You have familiarity with setting up redundancy.

Although 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 record requests that match URLs listed in the LinkProof DNS > Name to Local IP table receive a response.

2

Simple Scenario – Single LinkProof with External SOA

This section describes a

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 device.

Note: The examples in this document use non-routable addresses. An actual installation would require public, routable addresses.

To set up a single LinkProof device with external SOA

1. Set up static NAT addresses for the Web server using the following LinkProof panes:

 LinkProof > Global Configuration > Enable Smart Nat  LinkProof > SmartNAT > Static NAT > Insert rows

Because LinkProof handles the public addresses in this example, use the following static NAT settings:

STATIC NAT ROUTER LOCAL SERVER

192.168.1.100 ISP1 172.16.1.100 10.1.1.100 ISP2 172.16.1.100

2. Configure DNS to Local IP using 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 enables LinkProof to answer queries for www.company.com, and lookups directed to the LinkProof device interfaces return static NAT addresses (such as 192.168.1.10 and 10.1.1.10). Because most of the world will be querying ISP1’s DNS server, you have to modify the zone file so that the requests go to the LinkProof device.

3

Modifying DNS on the External SOA

The original zone file for COMPANY.COM on ISP1’s DNS server might look like the following example:

3.1

Referring the A Record Resolution to LinkProof

Make the following changes to the zone file:

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.10

LINKPROOF2 IN A 10.1.1.10

COMPANY.COM

@ IN SOA ns.company.com

IN MX mail

WWW IN A 192.168.1.100

Page 5

This delegates the final answer to LinkProof. Initially, the client queried the DNS server and received the IP address. Now, the client queries the DNS server, which tells the client to query the LinkProof device at one of the ISP interface addresses. The client then queries the LinkProof interface IP address, and is given the static NAT address for www.company.com, choosing the best route to establish the connection based on load balancing or proximity.

Two NS records are used and returned to the client because the external DNS server is not aware if either of the links is down. Providing both ISP interfaces for LinkProof as A records is necessary to properly delegate the query. The SOA can be made to round robin the NS records it provides so that DNS queries are actively sent to each ISP.

Note: In Windows 2000, adding an NS record is called “New Delegation.”

The following is a summary of the query flows in this configuration:

ISP DNS: Does not know, ask LinkProof 1.company.com or LinkProof 2.company.com. (This is the delegation)

Client (to ISP): Where is LinkProof 1.company.com?

ISP DNS: 192.168.1.10

Client (to LP1): Where is www.company.com? LinkProof 1: 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).

3.2

Adding a Redundant (Backup) LinkProof Device

Adding a backup LinkProof is straightforward and does not require many changes to the configuration as described in Section 3.1 Referring the A Record Resolution to LinkProof. The changes entail duplicating on the backup device

 the static NAT addresses that exist on the primary device (setting them to backup mode)

 the DNS to Local IP table.

To add a redundant (backup) LinkProof device

1. Create a DNS virtual IP address. This is an additional, unique IP address for each ISP subnet. On the primary device, you create the following entries using LinkProof > DNS > DNS Virtual IP:

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

2. On the backup device, the same entries are created, but the mode is set to backup. The zone file shows that the LINKPROOF 1 and LINKPROOF 2 IP addresses are now n.n.n.11 instead of n.n.n.10.

4

Complete Setup – Redundant LinkProof Devices with Multiple Internal

SOAs

If COMPANY.COM requires adding a second firewall and bringing the SOA in-house, the firewalls themselves run DNS services, and DNS requests should be load-balanced between them.

Note: This also applies if the DNS servers are behind a DMZ.

Figure 2 illustrates the configuration for such a network. This configuration 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 address. In this way, LinkProof can differentiate outbound LAN traffic from inbound DNS or Web requests. While it is possible that all traffic (in and out) can be translated to the firewall’s interface address, such a setup is covered separately in this document.

Figure 2 Redundant LinkProof Devices with Multiple Internal SOAs

The following are the interface, DNS, and NAT settings for this configuration:

Name

Interface Address

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

To configure a redundant LinkProof device with multiple internal SOAs

1. Create a Virtual IP rather than the static NATs configured in Section 3.1 Referring to A Record Resolution to LinkProof. From the LinkProof > Virtual IP pane, define a single, private IP address (172.168.1.100) which is mapped to the DNS addresses on each firewall (172.168.1.40 and 172.168.1.41).

2. Create a Static NAT address for each ISP subnet, and use the Virtual IP as the local server using the LinkProof > Smart NAT > Static NAT pane. These two static NAT entries are registered as the SOA name servers with Network Solutions.

Note: If you are using internal DNS servers, you need to modify the LinkProof proximity parameters. Because an internal DNS server queries LinkProof for the A record, you configure LinkProof to ignore proximity calculations to these servers (otherwise, LinkProof calculates proximity for the internal subnet).

When DNS requests from the Internet arrive at 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 Section 3.1 Referring to A Record Resolution to LinkProof, so that the handling of the A record (the final, destination IP address) is referred to LinkProof’s interface (or virtual DNS address).