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).
© Copyright 2024 Paperzz