LinkProof DNS Quick Start Guide

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 A RECORD RESOLUTION TO LINKPROOF... 4 3.2 ADDING A REDUNDANT (BACKUP) LINKPROOF DEVICE... 5 4 COMPLETE SETUP REDUNDANT LINKPROOF DEVICES WITH MULTIPLE INTERNAL SOAS...6

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 typical (simple) scenario for configuring LinkProof with an external SOA (see Figure 1). 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. Figure 1 Single LinkProof with External SOA Page 3

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: COMPANY.COM @ IN SOA ns.company.com IN MX mail WWW IN A 192.168.1.100 MAIL IN A 192.168.1.101 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 Page 4

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: Client (to ISP): ISP DNS: Client (to ISP): Where is www.company.com? Does not know, ask LinkProof 1.company.com or LinkProof 2.company.com. (This is the delegation) 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 LINKPROOF2 IN A 10.1.1.11 Page 5

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). Page 6

Page 7