We use cookies on our website to ensure we provide you with the best experience on our website. By using our website, you agree to the use of cookies for analytics and personalized content.This website uses cookies. More Information
It seems like your browser didn't download the required fonts. Please revise your security settings and try again.
Barracuda CloudGen Firewall

DNS

  • Last updated on

CloudGen Firewall and DNS

The Domain Name System (DNS) is organized as a hierarchical tree. This tree contains information for mapping Internet hostnames to IP addresses and vice versa. The structure is stored as information in a distributed database that is managed by multiple DNS servers. The role of the CloudGen Firewall as a DNS server (authoritative, master, slave, caching-only) depends on how and what part of the tree structure is managed by a name server and how the servers exchange information to keep the tree's information up to date.

Barracuda's implementation of the DNS extends the basic functionality of the BIND-based DNS system by additional features. Health probes provide a means to check the availability of certain target hosts. Listeners can be explicitly configured to snoop for incoming DNS resolving requests on selected interfaces. These two main features can then be combined to allow DNS load balancing depending also on the availability of certain targets.

Authoritative DNS Server vs. Caching-Only Server

The Barracuda CloudGen Firewall can act both as an authoritative (master and/or slave) or caching-only DNS server.

Based on its factory settings, the CloudGen Firewall is operating as a caching-only DNS server and takes complete care of resolving the query for a client on the LAN. For more information, see How to Configure DNS Settings and How to Configure a Caching DNS Service.
The resolving strategy for queries originating from remote networks depends on further configurations. Because of this initial configuration as a caching-only DNS server the CloudGen Firewall can query the related DNS server(s) on the Internet and do the whole license activation after being powered up for the first time.

If the firewall operates as an authoritative server (master/slave), it will return definitive answers to DNS queries about domains and domain hosts specified in its configuration (master zone / slave zone). A firewall can operate simultaneously both as a master and slave DNS server. For example, it can manage configured master zones for its own domain and slave zones for a foreign domain as copies from another master DNS server. As an authoritative DNS server, the CloudGen Firewall can also answer DNS queries from remote networks.

CloudGen Firewall as Caching-Only DNS ServerCloudGen Firewall as Authoritative DNS Server (Master/Slave)
caching_only_dns.pngauthoritative_dns.png

DNS Zones and DNS Records

DNS Records

The CloudGen DNS service manages domains and hosts. All information about hosts and associated IP addresses is defined in resource records where each record holds a key value (record type identifier) that classifies the rest of the information, e.g., information about whether the record describes a zone (SOA), a name server (NS), a web server (A / AAAA), or a mail exchanger (MX). For an easier configuration, you can select the requested record type out of a set of predefined record classes during the configuration process. In all resource records, additional information like time-to-live (TTL) or serial numbers define whether and in which periods zone information needs to be synchronized between multiple name servers in order to keep the DNS tree consistent in the distributed DNS database.

DNS Zones

A zone is a well-defined point of delegation in the DNS tree and contains contiguous parts of that tree for which a name server manages the respective information. If the CloudGen Firewall holds the master copy of the zone data (master zone), it operates as a master (or primary) server. The following image shows the record for a master zone with two subordinated resource records on the CloudGen Firewall:

master_zone_record.png

If the CloudGen Firewall loads the information from another server and holds it as a copy (slave zone), it operates as a slave (or secondary) server. If the CloudGen Firewall is configured as a master server, it is classified as an authoritative server. If the CloudGen Firewall is configured as a slave server, the slave role is indicated by a simple slave entry without the possibility of viewing the hosted information because changes to this information can be made only on the responsible master server. The following image shows the record for a slave zone on the firewall:

slave_zone_record.png

If the CloudGen Firewall also holds information about which IP address maps to which Internet hostname, this is a reverse zone. If a reverse zone is configured, feeding the DNS server with an IP address in the query (reverse lookup) returns the associated hostname of a specific host within the respective domain:

reverse_zone_record.png

For more information, see How to Configure a Zone.

Zone Transfers

Zone transfers are essential for keeping configured master zones synchronized to all slave DNS servers. In order for a CloudGen Firewall-based master DNS server to transfer a zone to a slave DNS server, two entries must be added on the master DNS server for the slave DNS server. The following example assumes that the slave DNS server can be reached on IP addresses like 5.5.5.239 and 6.6.6.239:

Record TypeExample for Entry
An A-recordA  ns2 5.5.5.239, 6.6.6.239
An NS-recordNS @ ns2.standalone.org

On the CloudGen Firewall, synchronization is basically achieved by updating the zone configuration on the master DNS server. When clicking Send Changes / Activate, the serial number of the zone record is incremented by one. Because the master zone record now has a higher serial number than the version on slave DNS server, the slave will take over new zone data from the master.

Synchronization of Zone Transfers

Sometimes, however, the serial number of the master is lower than the serial of a slave DNS server. For instance, if your current master and slave DNS servers are non-Barracuda products and you want to use your CloudGen Firewall as your new master DNS server, the serial number of the slave DNS server might still be higher because it most probably uses a different numbering scheme for the serial number than the CloudGen Firewall. In such a case, you must add a serial number offset to the CloudGen Firewall's serial number so that the sum of the serial and the offset is at least one higher than the old serial number of the slave DNS server.

For converting, use a time-stamp converter, e.g., https://www.unixtimestamp.com/.

The usage of the Serial Number Offset might become clearer in the following example:

DNS Server TypeBIND Numbering SchemeExample SerialSerial Offset
Slave DNS Serverserial-update-method 'date'

Assumed time of last zone transfer
from old master to slave DNS server:
2019-04-30, 00:00

YYYYMMDDnn, e.g.,
2019043000

-
New DNS Master
Server e.g.,
CloudGen Firewall
serial-update-method 'unixtime'

Assumed time for zone transfer
from new DNS master to old slave
DNS server: 2019-05-01, 00:00

Number of seconds since
the Unix epoch January 1st 1970,
e.g., equivalent to 2019050100
(YYYYMMDDhh) =
1556668800 (unixtime)

On the old slave server,
the Unix timestamp
representation of the real
time 2019-05-01-00 of the
zone-transfer will be received
as a numerical value of 1556668800.

However, in order to accept
new zone information, the slave
DNS server must receive a serial
which is effectively 2019043001,
so the difference between
2019043001 and 1556668800
must be transmitted as the serial
offset. In this example, the value will be
462374201.

2019043001 - 1556668800 =
462374201
If you want to run your Barracuda CloudGen Firewall as a DNS master server with non-Barracuda DNS slave servers, you must set the serial number offset so that it is always higher than the serial of a slave DNS serial at the moment when you click Send Changes / Activate. Therefore, it is recommended to increase the difference by adding enough seconds to the serial number offset. This must only be done when doing a zone transfer for the first time.
Zone-to-Host Record Relation

When a master zone is created, the CloudGen Firewall offers the option to automatically create the corresponding first two entries that are essential for setting up a base configuration. If this option is selected, two DNS records will be created automatically for the configured zone:

auto_creation_of_first_two_dns_records_for_zone.png

The first record is of type NS and delegates the zone example.com to the name server with the hostname ns1. The second record is of type A and maps the hostname ns1 to the DNS service's IP address.

When automatically creating these two records, the first manually configured service IP address is always used.

For some DNS records, the configuration window offers the option to automatically create reverse entries within the corresponding reverse zone.

Before a reverse DNS record can be created automatically, the reverse zone must be configured first. Otherwise, the reverse DNS record will be discarded.

For more information, see How to Configure a Zone.

Processing of Hostnames within Zones

For the new DNS implementation, Barracuda has focused on an optimal compromise to address a correct handling of DNS-specific configuration data and a high level of usability.

Example:

  • host1.example.com in the zone example.com will be expanded to be host1.example.com. (note the trailing colon) because the hostname host1.example.com conforms to the ending of the domain name example.com. where both have example.com  in common.
  • host1.example.com in the zone example.at will not be expanded but rather prepended to example.at resulting in host1.example.com.example.at. (note the trailing colon) because the hostname and the domain name end with different partial names (at and com).

Split DNS: The Classification of DNS Service IPs / Listeners

The DNS service listens to incoming requests on all configured service IP addresses and handles them with the same priority. Sometimes, however, it is advantageous to respond to resolving requests from a LAN differently than from a WAN. When creating an explicit DNS Listener, you must assign either the tag INTERNAL or EXTERNAL to a special DNS service IP address. Such a listener is identified by its Listener Name and can later be selected by one of the following tags:

  • EXTERNAL – The set of DNS-served IP addresses is limited to public IP addresses.
  • INTERNAL – The set of DNS-served IP addresses is limited to private IP addresses.
  • ALL – EXTERNAL + INTERNAL.
  • <User defined> – Choose any name that describes best the selected DNS service IP address.

The following figure shows a network setup with multiple IP addresses connected both to the WAN and the LAN. The subsequent table shows how the DNS listener considers special service IP addresses depending on the classification and Listener Name.

example_network_for_DNS_01.png

Configuration Tree...

Listener Name

Listener
Classification

Example Service IPs Used by DNS Listener
...Assigned Services > DNS >
Service Properties
--213.80.1.1, 214.90.0.1, 10.0.10.1, 172.16.1.1, 192.168.0.1

...Assigned Services > DNS >

DNS Service > DNS Settings >

DNS Listeners Classification

 

INTERNALINTERNAL10.0.10.1, 172.16.1.1, 192.168.0.1
EXTERNALEXTERNAL213.80.1.1, 214.90.0.1
toISP1EXTERNAL213.80.1.1
toISP2EXTERNAL214.90.0.1
PRIV1INTERNAL10.0.10.1
PRIV2INTERNAL192.168.0.1
DMZINTERNAL172.16.1.1
It is recommended to configure listeners prior to zones because they will be required during the configuration of DNS records within the zone.
Using DNS Listeners for Recursive Lookups from Remote Networks

By default, the DNS service is listening to requests on all configured DNS service IP addresses. However, recursive DNS lookups are only answered for requests originating from a network that is directly configured on a local interface. DNS requests from a remote network (reachable only via a gateway) are not answered by default.

In case you want to permit answering requests from a remote network, you must configure an explicit listener for that network and allow recursive lookups:

Queries originating from a......direct-attached network... remote network
Requires listener
  • NO (recursive lookups
    allowed by default setup)
  • YES
Response for hosted zones
  • YES
  • YES
Response for foreign (=non-hosted) zones
  • YES
  • NO (default)
  • YES: requires explicit listener +
    recursive lookups allowed

For more information, see How to Configure a DNS Listener.

Availability of Target Hosts (Health Probes)

On the CloudGen Firewall, health probes can be configured to test the reachability of certain targets. Health probes can be attached to a DNS resource record to confirm the validity of a configured IP address. In case the health probe confirms the reachability of a certain target, the associated IP address in the DNS resource record will be returned as a valid IP address for the query. If the configured target does not respond, the configured IP address will not be sent as a valid answer for the probed target.

Probing provides the following options:

Probe TypeAnnotation
ICMP

Probes a target using the ICMP protocol (ping).
Suitable for general probing if only physical presence must be verified.

HTTP/S

Probes a target using the HTTP and HTTPS protocol.
Suitable for web servers that either respond on port 80 or 443.

TCP + Port Number

Probes a target using the TCP protocol and a special port number.
Suitable for any arbitrary combination of TCP protocol and port.

For more information, see How to Configure a Split DNS Setup and How to Configure a DNS Health Probe.

Probe Pattern and Timing

By default, probing is done every 30 seconds. If the target is reachable, the next probing is done in 30 seconds. If a probing fails, two subsequent probes will follow within the period of a few seconds. If the second probing in sequence (which effectively is the third probing within 30 seconds) also fails, the associated IP address will be removed from the list of valid IP addresses and will therefore not be sent in the response of valid IP addresses for the last resolving query. Probing will be continued in the period of 30 seconds until the target is available again. From this time on, probing will start over according to this pattern.

probe_timing_diagram.png

Responding Queries with Multiple IP Addresses, Simple Load Balancing, and Failover

If you are running multiple servers, e.g., web servers at different ISPs and/or redundant web servers in your DMZ, you must associate multiple IP addresses with the same hostname, e.g., www.example.com, 62.99.0.11, 212.86.0.11, 213.47.0.11. In case a query asks for the resolution of the web server's hostname (www.example.com), all IP addresses (62.99.0.11, 212.86.0.11, 213.47.0.11) will be sent to the querying client if no other options limit this rule. However, the order of the IP addresses will alter each time the same query is made. By default, this order applies to a cyclic rotation:

# Query

QueryResolving Result Returned by DNS Server
(first | second | third | fourth position in list)
Effective Load Balancing
IP Address
1.nslookup www.example.com62.99.0.11 | 212.86.0.11 | 213.47.0.1162.99.0.11
2.nslookup www.example.com

212.86.0.11 | 213.47.0.11 | 62.99.0.11

212.86.0.11
3.nslookup www.example.com

213.47.0.11 | 62.99.0.11 | 212.86.0.11

213.47.0.11
4. = 1.nslookup www.example.com

62.99.0.11 | 212.86.0.11 | 213.47.0.11

62.99.0.11

This cyclic rotation will cause the querying clients to contact another target each time after a resolution, thus distributing requests between multiple targets. When attaching a health probe to a set of configured IP addresses, failover scenarios can be handled in case a configured host becomes unavailable.

For more information, see How to Configure Simple DNS Load Balancing with Failover .

DNS Interception

DNS Interception allows redirection or blocking of DNS queries for specific domains. This is achieved by applying policies. When creating a policy, you can also specify whitelisting for certain domains.

For more information, see How to Configure DNS Interception .

Last updated on