Usage
Private address mappings are used when the Ecessa appliance is to provide DNS functionality while installed behind a NAT device (such as a firewall or other device upstream which handles the private to public address translation). In such a scenario, the WAN interface of the Ecessa will be configured with a non-routable IP address but will need to answer incoming DNS queries with the proper public IP address(es) on the firewall or NAT device.
Configuration
The following diagram illustrates the example network used for this article.
Log into the web interface on the Ecessa appliance and go to the Authoritative DNS page. Click [Configure] next to the domain.
In the zone configuration page, click the Add Mapping button under the Private Address Mapping section. Private address mappings can be added in two ways:
Range – This will create one-to-one mappings in sequential order.
- Enter the starting public IP address configured on the firewall or NAT device.
- Enter the starting private IP address on the Ecessa’a WAN interface.
- Enter the number of addresses that need to be mapped.
Individually – This will create a unique one-to-one mapping between the private and public address; useful for non-sequential mappings.
- Enter a public IP address configured on the firewall or NAT device.
- Enter the private IP address on the Ecessa’s WAN interface that should be mapped to the public address.
- The Number of Addresses should be set to 1 for every mapping.
The following screenshot shows an example of individual address mappings.
For this example, the address mappings were made in sequential order so the range method was used.
For the NS and A records, enter the corresponding public IP address and enable the Mapped setting. This will allow the Ecessa appliance to correlate its WAN with the associated public IP address so load balancing and redundancy can be performed properly.
Load Balanced Host Records are not affected by the use of private address mappings.
Here is an example of DNS resolution from the Ecessa appliance.
C:\>dig @203.0.113.194 www.example.com
; <<>> DiG 9.9.1-P3 <<>> @203.0.113.194 www.example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1672
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 30 IN A 192.51.100.67
www.example.com. 30 IN A 203.0.113.195
;; AUTHORITY SECTION:
example.com. 900 IN NS ns1.example.com.
example.com. 900 IN NS ns2.example.com.
;; ADDITIONAL SECTION:
ns1.example.com. 900 IN A 192.51.100.66
ns2.example.com. 900 IN A 203.0.113.194
;; Query time: 4 msec
;; SERVER: 203.0.113.194#53(203.0.113.194)
;; WHEN: Tue Sep 03 13:25:06 2013
;; MSG SIZE rcvd: 159
And if the private WAN was to experience an outage, the DNS response would be updated like so:
C:\>dig @203.0.113.194 www.example.com
; <<>> DiG 9.9.1-P3 <<>> @203.0.113.194 www.example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12923
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 30 IN A 203.0.113.195
;; AUTHORITY SECTION:
example.com. 900 IN NS ns1.example.com.
example.com. 900 IN NS ns2.example.com.
;; ADDITIONAL SECTION:
ns1.example.com. 900 IN A 192.51.100.66
ns2.example.com. 900 IN A 203.0.113.194
;; Query time: 8 msec
;; SERVER: 203.0.113.194#53(203.0.113.194)
;; WHEN: Tue Sep 03 13:23:02 2013
;; MSG SIZE rcvd: 143
0 Comments