302 – F5 Certified Technology Specialist

(BIG-IP GTM – DNS Specialist)

Parham Emam Jomeh

(F5 SME / Application Delivery & Security)
/parhamemamjomeh

(May, 2023)
v1.0.0

THIS DOCUMENT IS PROVIDED BASED ON MY EXPERIENCE AND BY REVIEWING OTHER F5

ARTICLES AND DOCUMENTS. HOWEVER, SINCE THAT IS MY OWN PERSONAL NOTES,
THERE IS NO WARRANTIES OF ACCURACY OR COMPLETENESS.
TO ME, THIS DOCUMENT WOULD BE VERY USEFUL ONLY AS THE KEYNOES, BEFORE YOUR
EXAM. SO, IT IS HIGHLY RECOMMENDED TO REVIEW ALL THE OTHER MATERIALS
(OFFICIAL STUDY GUIDE DOCUMENTS / ARTICLES) BEFORE READING THIS ONE. ALL THE
KEYNOTES HERE COULD BE CONSIDERED INSIGHTFUL AS A QUICK SUMMARY OF THE
MOST IMPORTANT TIPS ABOUT DIFFERENT TOPICS OF F5 “302” EXAM.
What is “DNS”?
❑ DNS is considered as one of the key solutions which is used on IP-based networks. Generally,
there are two types for Look-up process:

• Forward Lookup (FQDN → IP)

o Example: “A” Record

• Backward / Reverse Lookup (IP → FQDN)

o Example: “PTR” Record

❑ When a client wants to access one specific FQDN, below steps should be done:
1. Checking the content of local “Hosts” file (In Windows OS → C:\Windows\System32\drivers\etc\)
2. Checking the content of it Local “Resolver Cache”
3. Asking its “Local Domain Name System (LDNS)” to resolve that Recursively / Iteratively

❑ Normal clients can NOT understand Referrals, so can NOT perform Iterative operation
❑ Normal Clients ONLY send Recursive DNS Requests, and wait for the Response
❑ Comparisons and Lookups in the name server database are NOT "Case-sensitive"

DNS Header Structure (Ref. → https://notes.shichao.io/)

1
DNS Message Format
Blow is the DNS Message Format which could be useful to have better understanding of DNS
Requests and Responses Message structure.

2
DNS Resource Records
Here are some of the most Important DNS RRs which could be popular in most scenarios.

❑ SOA (Start of Authority) → The SOA record starts every ZONE File and containing “Administrative
Information“ about a particular zone (including the Primary Name Server, the Email of the
Domain Administrator, the Domain Serial Number, and Several Timers relating to Refreshing
the ZONE). There must be exactly “ONE“ SOA Record per zone.

❑ A (IPv4 Address) → This Record lists the 32-bit IPv4 address for a given host name.

❑ AAAA (IPv6 Address) → This Record lists the 128-bit IPv6 address for a given host name.

❑ CNAME (Canonical Name) → This record specifies an Alias or Nickname for the official, or
canonical, host name. This record must be the only one associated with the alias name. It is an
Alias for another 'Tree Element' which could be in the same Zone or even other Zone.

➢ EXAMPLE --> js.example.org. 3600 IN CNAME javas.example.com.

❑ DNAME (Delegation Name) → This record is an Alias for any specific Sub-tree of a ZONE.

➢ EXAMPLE --> example.org. 3600 IN DNAME example.com.

❑ HINFO (Host Information) → This record contains information of the hardware and operating
system relevant to BIG-IP DNS or other DNS.

❑ MX (Mail Exchanger) → This record defines the Mail System for a given domain.

❑ NS (Name Server) → This record defines an Authoritative Name Server for a given Domain (Zone)
/ Host. Every zone needs at least ONE Name Server.

❑ PTR (Pointer) → This Record associates a host name with a given IP address. These records are
used for reverse name lookups thru IPv4. [ IPv4/6 - to - Name (X.in-addr.arpa / X.ip6.arpa) ]

❑ SRV (Service) → This record is a pointer with which an Alias for a given service is redirected to
another domain. For example, if the company “Site Request” has an FTP archive hosted on
archive.siterequest.com, the IT department can create an SRV record with which the alias
ftp.siterequest.com is redirected to archive.siterequest.com.

❑ TXT (Text) → This record allows you to supply any string of information, such as the location of a
server or any other relevant information that you want available.

3
DNS Zones
Generally, there are several different DNS Zone Types as below:

❑ Primary (Master)
• It Contains, at minimum, the "SOA" and "NS" RRs for the zone
• There must be exactly one 'SOA' record per Master Zone
• Unlike other RRs, you create a SOA record only when you create a new "Master Zone" file

❑ Secondary (Slave)
• It Contains a Copy of Zone file of the principal zone files
• It Responds Authoritatively for the zone provided that the zone data is valid

❑ Stub
• Similar to "Secondary" zones, except that It Contain ONLY the "NS" Records for the zone

❑ Forward
• I Contains ONLY information to Forward DNS Queries to another NS on a Per-zone (or per-domain)
basis

❑ Hint
• Specifies an Initial set of "ROOT Name Servers" for the zone
• LOCAL NS Queries a ROOT Name Server in the Hint zone file to obtain the most recent list of ROOT
Name Servers

❑ Root
• It is the Top-level DNS zone in the Hierarchical Namespace of the DNS of the Internet

4
DNS Components

✓ Authoritative Name Servers → They Publish DNS Data

✓ DNS Resolvers → They Issue Queries for DNS Data. We can assume two types of Resolver as below:

1- “Stub Resolvers”:
o They often found on Individual Hosts, and Issue Queries, but can NOT Follow DNS Referrals
o They are NOT “DNSSEC-aware”
o Example → Windows 7/8/10

2- “Recursive Resolvers”:
o They can Follow Referrals, and Provide DNS Resolution for all the Stub Resolvers
o They can be “DNSSEC-aware”
o Example → Windows Server 2016/2019/2022

Recursive vs. Iterative Resolving (Concept)

“Iterative” DNS Queries:

❑ The Name Server, will NOT Go and Fetch the Complete Answer for your Query, but it will give us
the Answer if it Has in its Records. It will give us the Referral to the Root Servers.

“Recursive” DNS Queries:

❑ A Recursive Query is a kind of Query, in which the DNS Server, who received your query Will Do
All the Job of Fetching the Answer, and giving it back to you…

5
Recursive vs. Iterative Resolving (Example)

6
“RD (Recursion Desired)” and “RA (Recursion Available)”

❑ Both the “RD (Recursion Desired)" and "RA (Recursion Available)" Bits located inside the DNS
Message
❑ Clients show their Intention for "Recursive Requests" by Setting the "RD (Recursion Desired)"
Bit in Query. When It is "SET (Enabled)", It means DNS Server is indicating to the client that it
will Query other NSs for requested domain names, if the DNS server’s zone files do not contain
the answer
❑ On the other hand, “RA” sent back by Name Resolver to show that whether the DNS Query
was resolved and answered as Recursive or not
❑ By default, DNS Recursion is "Disabled" on F5-GTM Systems (It Means that "RA=0"). Under
certain circumstances, you may want to Enable DNS Recursion on the GTM system
❑ If 'DNS Recursion' is Manually "Enabled" on the GTM system, you can create an 'ACL' to Limit
which IP Addresses or Network Addresses are 'Allowed' to make Recursive Queries to the
GTM system

OTHER DNS SERVERs

DNS QUERY
DNS QUERY
Non-Recursive DNS Transactions (RD = 0)
(RD = 0)
(Between DNS Servers)
Responds with Responds with
LOCAL DATA, LOCAL DATA,
without doing Recursive DNS Requests and Responses without doing
ANY further (Between DNS Clients and DNS Servers) ANY further
processing... processing...

DNS QUERY DNS QUERY DNS QUERY DNS QUERY

(RD = 0) LDNS - 1 LDNS - 2 (RD = 0)
(RD = 1) (RD = 1)

DNS REPLY
DNS REPLY
(RA = 1)
(RA = 1)

Laptop

DNS Clients

7
DNS Query and Response Flow

❑ The DNS model for asking DNS Queries and Receiving DNS Responses between a Client and
its Name Resolver is “RECURSIVE”. In this Case, the LDNS could be Authoritative for the
requested LOCAL Domain, or It can ask from another Upstream Resolver Iteratively, and then
Insert the Valid DNS Responses into its DNS CACHE. This LDNS can also Forward the DNS
Query toward the pre-configured Conditional DNS Forwarders. So, now that should be clear
why Clients (Stub Resolvers) try to set the “RD” bit to “1” in their DNS Queries…

❑ While the DNS model between the Recursive Name Resolver and its Upstream Name Servers
could be “ITERATIVE” which means that the LDNS will be referred to another level of Iterative
Requests after receiving the “Referral” from the Upstream Name Server. Below would be
expected Iterative behavior:

➢ LDNS <------ ITERATIVE (Referral) ----> ROOT Server (Auth. for "ROOT" Zone)
➢ LDNS <------ ITERATIVE (Referral) ----> TLD Server (Auth. for Specific "TLD")
➢ LDNS <------ ITERATIVE (Referral) ----> HOST Server (Auth. NS for Specific "Domain")

"Lame Delegation" / "Lame Referral" / "Lame Response"

All of these are interchangeable and point to specific scenarios in which a DNS Query is Answered in a way
that indicates the Responder is NOT 'Authoritative' for the expected zone or Responding with some
Delays, or even NOT Responding at all...

Processing “Recursive” DNS Queries on F5’s Local-BIND

❑ By default, processing Recursive DNS Queries is DISABLED on F5 BIG-IP GTM (DNS) Local BIND. So, If
you want to ENABLE that in any specific scenario, please follow the below steps:

1. GUI >> DNS >> Zones >> ZoneRunner >> 'named' Configuration

2. Find the "options" section of the 'named.conf' file

3. Change the 'Recursion' statement to the following:
recursion yes;

4. Click Update.

❑ Location of "named.conf" file on BIG-IP GTM (DNS) ----> "/var/named/config/named.conf"

8
❑ For GTM to return Non-Wide-IP supported records you must have "ZoneRunner" configured
❑ Additionally, we can use the "Return to DNS" Method for checking the 'BIND' Database
❑ "ZoneRunner" is the GUI for 'BIND' on BIG-IP GTM system

❑ "ZoneRunner" Provides the below:

➢ Viewing / Manipulation of "named.conf" File

➢ Viewing / Creation / Deletion of All RRs for individual Zones

9
GSLB (Global Server Load-balancing) Objects

❑ The GSLB Objects are saved into the key GTM config file which is “bigip_gtm.conf”.

❑ To Save and Load ONLY the GTM Configuration Objects, you can use the below useful Commands:

o tmsh save sys config gtm-only

o tmsh load sys config gtm-only

❑ Below would me the most Important GSLB Objects:

Data Center
All of the GSLB Resources on your Network are associated or Involved with a Data Center object. These
Objects including Server, Link, Prober Pool, Virtual Server, Wide-IP, Wide-IP Pool, Distributed Apps.

Links
It is a "Logical Representation of a Physical Device (Router)" that connects your DC to Internet. GTM
Tracks the 'Performance of Links', which influence the availability of Wide-IP Pools, Data Centers, Wide-
IPs, and Distributed Applications...

Server
A Server defines a Physical System on the network. Generally, there are 3 Type of Servers:

1- BIG-IP Systems --> Any member of the BIG-IP system product line

2- Third-party Load-balancing Systems --> A Third-party load balancing system other than F5

3- Third-party Host Servers --> A Generic Host System

For ALL Scenarios, at a minimum, you MUST define 'TWO' Server Objects:

o One that Represents the "BIG-IP GTM Module", itself

o One that Represents another Managed Server (either a 'Load-Balancer' or 'Host Server')

10
Virtual Server
Specific IP Address and Port Number that points to a Resource on the Network.

Important Tip About Configuring "Translation Address" and "Private Network Address":

❑ A "Translation Address" is used on a configuration object’s IP Address in a GTM configuration when

there is a 'NAT Performed' on that IP (by Firewall or another device)
❑ When a GTM system sends 'iQuery Probes' to a Remote BIG-IP Device that resides in an Infrastructure
that uses "Firewall NAT" Rules, you MUST configure the GTM to use the 'Firewall NAT Addresses'
(Translation Address) of the BIG-IP Device as the "Destination Addresses" for the probes
❑ On the other hand, the "Private Network Address" is the 'Stated Translation Address' of that server

Wide-IP Pool
It is a Collection of 'Virtual Servers' that can reside on Multiple Servers. When you add a VS to a Wide-IP
Pool, it becomes a "Pool Member" by considering the desired RR-type.

Wide-IP
It Maps a 'FQDN' to one or more "Wide-IP Pools" of VSs that host the content of a Domain. Totally, there
are “6” different Types of “Wide-IP” and “Wide-IP Pool” (Based on DNS Resource Records) including:

❑ NAPTR (Name Authority Pointer)

It is most commonly used for applications in Internet Telephony, e.g., mapping of “Servers” /
“User Addresses” in the SIP

❑ A
It is most commonly used to map “Hostname“ to an “IP Address“ of the host (IPv4)

❑ SRV
SRV records are often used to help with “Service Discovery”. It defines a “Symbolic Name” and
the “Transport Protocol” used as part of the Domain Name, and the “Priority”, “Weight”, “Port”
and “Target” for the service in the record content

❑ CNAME (Canonical Name)

It’s Alias of one Name (e.g. “Sub-domain Name”) to Another Name (e.g. “Domain Name”). So,
DNS lookup will continue by retrying the New Name…

❑ AAAA
It’s most commonly used to map “Hostname“ to ”IP Address“ of the host (IPv6)

❑ MX (Mail Exchange)
It Maps a “Domain Name“ to a list of “Message Transfer Agents“ for that Domain

11
Prober Pools

❑ The Actual Purpose of using 'Prober Pool' in a scenario would be "Monitoring Delegation". It is an
Ordered Collection of one or more BIG-IP systems
❑ Prober pool can be assigned to an Individual Server or a Data Center
❑ When you assign a Prober pool to a DC, by default, ALL Servers in that DC inherit that Prober pool
❑ IF all Prober Members are marked DOWN --> GTM itself Tries to Gather Data about the Servers...
❑ IF a server has NO Prober Pool assigned --> GTM itself Tries to Gather Data about the Servers...
❑ Prober Pool Members Could be only F5 BIG-IP Devices, and NOT any other third-party Server
❑ Prober Pool mechanism uses "iQuery (TCP/4353)" Protocol as its language between GTM and Probers

❑ There are TWO Load-Balancing Methods within each Prober Pool object, including:

1- "RR (Round Robin)" --> Active / Active Deployment

2- "GA (Global Availability)" --> Active / Standby Deployment

❑ Below is an Example of Prober Pool concept:

12
❑ Below is a comprehensive Figure including all the most Important logical objects:

Prober Pool (A) Prober Pool (B)

Data Center (A) Data Center (B)

SERVER 3rd Party - LB F5-LTM F5-LTM 3rd Party - LB SERVER

Server / VS Server / VS
Pool / Members R1 R2 Pool / Members

Link (A) R-X Link (B)

R-W
INFRA. R-Z DNS Queries
DNS Queries R-Y

Link (C) Link (D)

R3
R4

Data Center (C) Data Center (D) F5-DNS

F5-DNS
(CORE-DC-1) (CORE-DC-2)
SYNC Group

13
GSLB (Static / Dynamic Load-balancing Methods)

"Tier-1" (Wide IP-level)

o Choosing the Best Available "WIP-Pool" in a "WIP"
o There are "4" LB-Methods
o All the "4" LB Methods are "Static", including:
• Round-Robin
• Static Ratio
• Global Availability
• Topology

"Tier-2" (Wide IP Pool-level)

o Choosing the Best Available "Virtual Server" within that "WIP-Pool"
o There are about "19" LB-Methods (ALL Available)
o Both "Static" and "Dynamic" LB Methods are Available to use

➢ SAMPLE For "Tier-1" and "Tier-2":

❑ WIP-Pool-01:
✓ VS-01-01
✓ VS-01-02

❑ WIP-Pool-02:
✓ VS-02-01
✓ VS-02-02

❑ Last Resort Pool:

❖ LastResort-VS-01
❖ LastResort-VS-02

14
"Static" LB Methods:

❑ GTM selects a resource based on a "Pre-defined Pattern"

❑ In most cases, should be used for the "Alternate" LB Methods
❑ Below is a comprehensive Table which includes useful details about Static LB Methods:

15
"Dynamic" LB Methods:

❑ GTM selects a resource based on Current Performance Metrics collected by the "big3d" Agents
running in each data center
❑ In most cases, should be used for the "Preferred" LB Methods
❑ Below is a comprehensive Table which includes useful details about Dynamic LB Methods:

16
Region / Topology Records:

❑ It Bases the distribution of requests on the "Topology Records" and the "Weighted Scores" for each
❑ There is only ONE / Shared Topology Record List for the GTM system
❑ So, ALL Wide-IPs using the 'Topology' LB Method on the GTM, share the same Records...
❑ By Default, GTM system looks up 'Topology Records' based on the "Longest-MATCH (Most-specific)"
Logic
❑ In case of facing 'Same Records' for Specific Condition, GTM looks up based on the "ORDER" they
Appear in the GUI
❑ So, you should place MORE Specific Topology Records toward the 'TOP' of the Topology Statement
❑ You can change the "ORDER" of Existing Topology Records by using the "Change Order" Button on
the GUI
❑ You can ALWAYS Increase the Priority of Records by setting Highest "Weight (SCORE)" to that
❑ Note that the whole Idea to choose one Final Record is "First-Match"

"Weight" (SCORE):

❑ It specifies the "Score" that will be given to a 'Destination' object in the Topology Records
❑ IF Name Resolution Matches more than one 'Topology Record', the GTM system uses the
"Destination" object with the "Highest Weight" to determine which 'Statement' it uses to Load-
balance the Request
❑ In case of having more than 'ONE Similar Record' with the 'Same Weight', the one with the "Longest
Prefix Match" will be chosen with higher priority
❑ The Default Value for the "Weight" Metric on ALL New Records is "1"
❑ However, Note that below could be considered as the Final / Actual Preferred Order for "Topology
Records":

1- Highest "Weight" (SCORE) ----> Default = 1

2- Longest-Match (Most-Specific) ----> Default = ENABLED

3- Records Order in GUI / Config File

17
Using "Auto Discovery" Feature for Virtual Server Discovery:

❑ GTM system searches for the Resources on both 'LOCAL' and the 'Target (REMOTE)' BIG-IP systems
❑ Then, GTM Adds "VSs" and "Links" to the current GTM Configuration
❑ In fact, GTM system Polls the LTM's "big3d" Agent at the Auto-Discovery Request Interval setting
❑ By Default, the "Auto-Discovery Request Interval" = 30 Seconds

# tmsh list gtm all-properties

gtm global-settings general {

auto-discovery yes

auto-discovery-interval 30

❑ However, the GTM system does NOT Support 'Auto-Discovery' for BIG-IP systems and VSs that use
"Network Address Translation" settings
❑ IF the target BIG-IP system or any of its VSs employ "Address Translation", the GTM system Disables
the 'Auto-Discovery' feature for the Entire Remote BIG-IP system. So, in such cases, GTM Stops the
"Discovery" Procedure, even on those VSs for which "Address Translation” is NOT Configured!
❑ In addition, the GTM system does NOT Report any 'Messages' or 'Alerts' that log the change
❑ So, If you plan to Add BIG-IP systems with "Translated VSs" to the GTM Config, you MUST Manually
configure Each VS on the GTM system
❑ For VSs using "Address Translation", you MUST also configure the "Translation Address"
❑ Additionally, Please note that "Discovery" Feature does NOT work if you used the "MGMT" Address
of the BIG-IP DNS Module when Adding that as a SERVER object.
❑ So, you have to ONLY use any "Self-IP" Address object of your Desired BIG-IP DNS / LTM Module
❑ In fact, "iQuery" Protocol ONLY works on "TMM-Interfaces (Back-plane)"
❑ Also, please note that you are NOT Allowed to use the Loopback IP "127.0.0.1" for Adding the Local
DNS object

18
Some Important Tips about GSLB:

❑ If the "Preferred", "Alternate", and "Fallback" LB Methods of WIP Pool Fail, then the Requests Fail, or
the system 'Falls Back to DNS (Local-BIND)'
❑ "Drop Packets" should be used for "Alternate" Method to Drop the DNS Query and NOT sending
Response
❑ "Fallback IP" should be used for DR Scenarios, and for the "Fallback" Method. Please Note that the
configured "Fallback IP Address" is NOT Monitored by GTM Module for checking its Availability (by
default)
❑ "Global Availability" provides a Pre-defined / Static List of Preferred VSs in a Pool
❑ "Global Availability" Chooses the 1st VS in List as "Always-Active VS", and others as Standby ones
❑ For "None" Method, If all pools are 'Unavailable', GTM returns an Aggregate of the IP Addresses of
all the VSs in the pool using BIND
❑ Use "None" for either the 'Alternate' and 'Fallback' Methods to have a Single round of LB Method
❑ By using "Return to DNS" Method, GTM Immediately tries to use Its "LOCAL-BIND" to Resolve the
Query
❑ For "Static Persist", GTM uses the specified 'CIDR' of LDNS to choose the same VS for same Clients
❑ For "Topology" Method, the 'Proximity Information' is derived from the DNS Message and compared
to the "Topology Records" in a Topology Statement configured on GTM
❑ In "Completion Rate", GTM Prefers the VS that has the 'Least Number of Dropped / Timed-out
Packets'
❑ For "CPU" Method, GTM Prefers the VS that has the 'Most CPU Processing Time Available’
❑ For "Hops" Method, GTM Prefers the VS which has the 'Fewest Router Hops' (using 'TraceRoute'
utility)
❑ For "Kilobytes per Second" Method, GTM Prefers the VS that is processing the 'Fewest Number of
KB/S'
❑ For "Least Connections" Method, GTM Prefers the VS on LTM that 'Hosts the Fewest Connections'
now
❑ For "Packet Rate", GTM the VS that is processing the 'Fewest Number of PPS'
❑ In "Quality of Service" Method, GTM tries to use 'Sccore' that is calculated from Performance Metrics
❑ For "Round Trip Time", GTM Prefers any VS with the 'Fastest Measured RTT'
❑ For "Virtual Server Score", GTM chooses the VS on LTM based on a 'User-defined Ranking Value'
❑ For "Virtual Server Capacity" Method, GTM Prefers the VS which has the 'Most Available Pool
Members'

19
GTM Configuration Scripts (K13312)

❑ Allow you to Establish communications between the GTM systems and other external BIG-IP
systems
❑ Before Running these Scripts, you should define ALL needed Remote BIG-IP systems (via GUI)
❑ You need also to Create ONE Specific Object for your Current GTM Module on which you are
working now
❑ Next, you may need to Run one or more of the GTM configuration scripts to Complete the Task
❑ The "big3d" Daemon is normally aware both the “Management” and "TMM-Controlled
Interfaces (Back-plane Ports)". But It is Recommended to use ONLY on "TMM-Controlled
Interfaces"
❑ The "big3d" Daemon is predisposed towards NOT using "MGMT0" for “Config-Sync” in Normal
Situations
❑ So, Running “bigip_add” or “gtm_add” Scripts against a "MGMT0 Interface" will NOT work
Properly
❑ The "gtmd" Daemon Monitors the "Availability of Local/Remote BIG-IP Systems" by checking
"big3d"
❑ The "big3d" Agent Provides "Metrics Collection Data" from BIG-IP Systems for / On behalf of
"gtmd"
❑ So, "gtmd" Inquiries from its own Local "big3d" Agent as well as ALL the Remote "big3d" Agents...

20
"big3d_install" Script:

❑ The 'big3d' Runs on all BIG-IP systems, and provides "Metrics Collection" data for BIG-IP systems
❑ As an 'Interactive Script' It allows to install the current version of 'big3d' on remote F5 systems
❑ If the 'Current' or 'Newer' version of the "big3d" process is found to be running on the Remote
BIG-IP system, installation is Skipped for that BIG-IP system

❑ Use this Script ONLY thru the "TMM-Controlled Interfaces (Back-plane Ports)"
❑ At First, This Script Attempts to use "iQuery (TCP/4353)" Connection to Copy the Certificates and
Also to Check / Copy the "big3d" Process on the Remote BIG-IP
❑ If the iQuery Connection 'Fails', or the "-use_ssh" Option is specified, "big3d_install" Attempts to
use the "SCP-over-TCP/22" to Exchange SSL Certificates and Copy the "big3d" Process to the
Remote BIG-IP system
❑ This Script has to be Run on the "Most Updated DNS Module" (with Higher 'big3d' version)

❑ To Check the Current Version of "big3d" Daemon, use either the below Commands:
o # /usr/sbin/big3d –v <------ The Actual Location of "big3d" Process
o # big3d -v <------ Check from its Actual Location (/usr/sbin/)
o # /shared/bin/big3d -v <------ System checks for "big3d" Process at Start-up...

❑ For Running this Script, you can use either the "admin" or "root" Credential
❑ Below is the Syntax for Running this Script. If NO IP Addresses are specified in the Command, the
script will attempt to Install the "Current Version of the big3d Process" on ALL the BIG-IP
Controllers listed in the "bigip_gtm.conf" file, Automatically...
o # big3d_install [ <BIG-IP_Self_IP_Address> ]

❑ This script also Copies the below Files between "LOCAL / REMOTE BIG-IP Systems":
o "Trusted Device Certificate" from 'LOCAL' to the "/config/big3d/client.crt" on 'REMOTE'
o "Trusted Server Certificate" from 'REMOTE' to the "/config/gtm/server.crt" on 'LOCAL'

❑ After installing a new "big3d" version, the 'Local big3d' version reported in the output of "tmsh
show gtm iquery" command may not be updated until "gtmd" is restarted on the recently
updated device using "tmsh restart sys service gtmd"

21
"bigip_add” Script:

❑ As an 'Interactive Script', It Exchanges "iQuery SSL Certificates" with a remote BIG-IP system
❑ Use this Script ONLY thru the "TMM-Controlled Interfaces (Back-plane Ports)"
❑ This script uses "SSH (TCP/22)" Protocol to Exchange iQuery SSL Certificates between BIG-IP
Systems
❑ It Script has to be Run on the "New / Current DNS Modules" to ADD Other 'Remote BIG-IP
System(s)'
❑ For Running this Script, the "root" Credential should be used
❑ For "Non-root" user or as a "Remotely-authenticated" user, you have to use the "-a" Flag
❑ Below is the Syntax for Running this Script, on the 'NEW' GTM to Add other BIG-IPs on that:
o # bigip_add <Remote_Existing_LTM_Self_IP_Address>

❑ This script Appends the below 'Authorized Certificates' between "LOCAL / REMOTE BIG-IP
Systems":
o "Local SSL Certificate" from 'LOCAL' to the "/config/big3d/client.crt" on 'REMOTE'
o "Remote SSL Certificate" from 'REMOTE' to the "/config/gtm/server.crt" on 'LOCAL'

❑ In some scenarios, After Renewing one GTM's Certificate, If you want to Exchange the NEW Device
Certificates with 'ALL' the F5 Devices listed in the "/config/bigip_gtm.conf" file, you can simply
Run the following Command as a General and Automated Script:
o # bigip_add

22
"gtm_add" Script:

❑ This Script can be used to 'Integrate a New GTM System into an Existing Sync Group'
❑ It will Replace the below "Current Configuration Files" of New GTM with the Config of Remote
GTM:
o "bigip_gtm.conf"
o "named.conf"
o "named Zone Files"

❑ Use this Script ONLY thru the "TMM-Controlled Interfaces (Back-plane Ports)"
❑ This Script has to be Run on the "New DNS Module" which is being Added to the Current Sync-
Group
❑ It uses "SSH (TCP/22)" to Copy the 'Remote BIG-IP DNS System's Certificates' to the Local BIG-IP
DNS system
❑ It uses "iQuery (TCP/4353)“ to Synchronize the Configuration Between DNS Modules

❑ For Running this Script, the "root" Credential should be used

❑ For "Non-root" user or as a "Remotely-authenticated" user, you have to use the "-a" Flag
❑ Below is the Syntax for Running this Script, on the 'NEW' GTM which is being Added to the Group:
o # gtm_add <Remote_Existing_GTM_Self_IP_Address>

23
What is "iQdump"?

❑ It is available from the command line interface on the GTM platform

❑ It can be used to view the "Data Transmitted" between systems using 'iQuery'
❑ If the remote LTM devices are marked "Green" by the GTM systems, but the GTM systems Fail to
automatically 'Discover the VS and Link objects', you can use this utility to verify that the LTM is
properly broadcasting the VS and Link objects...
❑ If the “iqdump” command returns a "Connection Refused" message, you should ensure
connectivity for the iQuery channel is allowed, such as ensuring port "TCP/4353" is allowed by
the self IP addresses on each system and devices in between. You may need to Restart the "big3d"
process to recover from the connection-refused condition
❑ For Viewing the "XML Data Transmitted Between BIG-IP Systems", use the below Command
syntax:
o # iqdump <Remote_Peer_IP_Address>
o # iqdump <Remote_Peer_IP_Address> [[-s] sync_group]

❑ Moreover, you can use the below Command to check ALL useful details about iQuery
Communications:
o # tmsh show gtm iquery

Below is one sample Output from the above Command:

--------------------------------------------------------------------------------
Gtm::IQuery: 192.168.1.4
--------------------------------------------------------------------------------
Server Local_DNS_SNG
Server Type BIGIP-DNS
Data Center Singapore
Connection Time 04/19/23 11:26:31
State connected
Connection ID 113
Reconnects 0
Backlogs 0
Bits In 219.7M
Bits Out 5.9M
Bytes Dropped 520
Cert Expiration Date 12/10/32 10:37:34
Configuration Time 04/19/23 16:50:25
Configuration Commit ID 2.5K
Configuration Commit Originator BIG-IP-LAB-VE.LOCAL
Local TMOS version 16.1.3
Remote TMOS version 16.1.3.2
Local big3d version 16.1.3.2.0.0.4
Remote big3d version 16.1.3.2.0.0.4
Cipher Name AES256-GCM-SHA384
Cipher Bits 256
Cipher Protocol TLSv1.2

24
iQuery Communication (TCP / 4353)

❑ In fact, the "big3d" Daemon is Listening on "TCP/4353" for iQuery Protocol and its
communications.

❑ Below are the Scenarios by having Local / Remote GTM and LTM Devices:

[Local-GTM] (gtmd) ----- TCP / 4353 -----> (big3d) [Local-GTM]

[Local-GTM] (gtmd) ----- TCP / 4353 -----> (big3d) [Remote-GTM]

[Local-GTM] (gtmd) ----- TCP / 4353 -----> (big3d) [Remote-LTM]

❑ Below are the needed Port Numbers between Peers:

✓ "TCP / 22" ---> Allows Local-GTM to Copy (SCP) the Newest Version of "big3d" Process to Existing
Systems, in case of "TCP/4353" Failures

✓ "TCP / 22" ---> Allows Local-GTM to Exchange the Certificates between itself and the other BIG-IP LTM
Modules as the Server objects

✓ "TCP / 4353" ---> iQuery requires this Port for its Normal Communications (Data Collection), and also
to Copy (Sync) the GTM Configurations between GTM Modules

Identifying Synchronization / iQuery Connections Issues

❑ On "GUI" / "TMSH", you can check for the below:

o Server List --> Global Traffic >> Servers >> Server List
# tmsh show gtm server all

o iQuery Statistics --> Statistics > Module Statistics > Global Traffic > Statistics Type > iQuery
# tmsh show gtm iquery [all]

o Global Traffic statistics --> Statistics >> Module Statistics >> Global Traffic

25
DNS Synchronization Group’s Requirements

❑ By Default, the "Synchronization Group" option is 'DISABLED' on All GTM Systems

❑ When you 'Enable' that, the GTM System belongs to a Synchronization Group called "default"
❑ Later, when you Change the 'Name' of a Synchronization Group, the NEW Name is Synchronized
to All GTM Systems that belong to that Synchronization Group

❑ DNS Synchronization Group Members must be running “Same TMOS Version”:

--> GUI >> System >> Software Management

# tmsh show /sys software

❑ “Synchronization Parameters” must be properly defined (ENABLED) for All Members:

[ GTM v10.0.0 - v11.4.1 ] --------> GUI >> System >> Configuration >> Device >> GTM >> General

[ GTM After v11.4.1 ] ----------> GUI >> DNS >> Settings >> GSLB >> General

# tmsh list /gtm global-settings general all-properties

❑ “NTP” must be configured on Each Device:

--> GUI >> System >> Configuration >> Device >> NTP

❑ To verify Time Synchronization and NTP configuration, perform the below command:
# date; tmsh list /sys ntp servers

❑ By using correct NTP, make sure there is NOT any 'Time Difference' between Sync-Group
Members:
# cat /var/log/gtm | grep "Time difference"

❑ “Port Lockdown” must be set properly for the relevant Self-IP Addresses:
--> GUI >> Network >> Self IPs

# tmsh list /net self allow-service

❑ “TCP/4353 – over - TLS” must be Allowed between BIG-IP GTM systems

26
❑ Local "gtmd" Establishes one Connection to its Local "big3d" Daemon, as well as other Remote
"big3d":
# netstat -pan | grep 4353

❑ “Full Mesh Cross Communication” on Port "TCP/4353" between All GTM Devices

❑ Please note that "gtmd" Daemon is Responsible for Establishing and Managing iQuery
Communications

❑ “Public Accessibility” on the Specified Ports must be Restricted:

# cat /var/log/gtm | grep "Connection complete to <iquery_peer>"

# cat /var/log/gtm | grep "No communication"

# cat /var/log/gtm | grep "Connection in progress to <iquery_peer>"

❑ Compatible “big3d Versions” must be installed on Synchronization Group Members

❑ The Default location for the "big3d" Daemon is "/usr/sbin/big3d"

❑ To Check "big3d" Compatibility and its Running status, use the below commands:
# big3d -v /usr/sbin/

# big3d -v <---------------- (It also Checks for the Default Path "/usr/sbin/")

# big3d -v /shared/bin/

# tmsh show sys service big3d

❑ A “Valid Device Certificate” must be installed on All Members

❑ The Default Device Certificate ---> "/config/httpd/conf/ssl.crt/server.crt"
❑ To check the status of "Device Certificate" or any Validity Problem, you can use the below:
--> GUI >> System >> Device Certificates

# openssl x509 -noout -text -in /config/httpd/conf/ssl.crt/server.crt

# cat /var/log/gtm | grep "certificate verify failed"

❑ The below Processes are All Critical to Synchronizing GTM Configurations:

o "tmm" <------ The main Traffic Handler on Back-plane Ports

o "mcpd" <------ The main Config Manager which works with 'TMM' directly
o "big3d" <------ The Metric Collector service which works with "gtmd' directly
o "gtmd" <------ The Main DNS/GTM Service which Handles all key Features...

27
❑ To check the Current Status of such Critical Daemons, use the below command:
# bigstart status tmm mcpd big3d gtmd

❑ The following lists the relevant Configuration Objects are Synchronized within Sync-Group. It
means that which Objects are included with “bigip_gtm.conf” file (K45907236):

+ Wide IP Addresses --> Yes

+ Data Centers --> Yes
+ Servers --> Yes
+ Virtual Servers --> Yes
+ Links --> Yes
+ GSLB iRules --> Yes
+ Topology Records / Regions --> Yes
+ Distributed Applications --> Yes
+ GSLB Global Settings --> Yes
+ GSLB Monitors --> Yes
+ DNSSEC Zones / Keys --> Yes
- DNS Zone Files --> Not synchronized by default
- Named Configuration --> Not synchronized by default
- Listener Addresses --> No
- Listener-related Objects --> No
- DNS Profile --> No
- DNS Express Zones --> No
- DNS Cache --> No

❑ Once Any Config Change Occurs on Local-DNS, the below would be correct Config
(Synchronization Flow):

--> (New-Change) --> [Local-mcpd] --> [Local-gtmd] --> [Local-big3d] -->

======= (TCP/4353) =======>

--> [Remote-gtmd] --> [Remote-mcpd] --> (Change-Affected)

❑ So, we can Conclude that both the "gtmd" and "big3d" Services are Listening on "TCP/4353", as
below:

➢ "gtmd" --> To Receive any Config-Change updates from the "big3d" of the Other DNS Modules
➢ "big3d" --> To Receive any Data Collection Request from the Local / Remote "gtmd" of DNS Modules

28
How to ADD / REMOVE Devices from iQuery Mesh (Sync-GROUP)

If you attempt to Remove a member from the GTM Synchronization Group only by "Changing the Name
of the GTM Synchronization Group" for that Member, ONLY the New Name will be Synchronized to the
remaining Members instead!

So, to properly 'Remove' a Member from the GTM Synchronization Group:

1- Clear the Synchronization and Synchronize DNS Zone Files check-boxes in the GUI:

➢ On BIG-IP "v10.x - v11.4.1" ----> GUI >> System >> Configuration >> Global Traffic >> General >>
Configuration Synchronization)

➢ After BIG-IP "v11.4.1") ----> GUI >> DNS >> Settings >> GSLB >> General >> Configuration
Synchronization)

OR

2- Set the Synchronization and Synchronize DNS Zone Files options to 'NO' in the “tmsh” utility

To 'Re-ADD' the Member to its Previous GTM Synchronization Group:

❑ At first, create your desired "SERVER" Objects for your Remote/Current DNS Modules
❑ Then, try to use the "gtm_add" utility on the 'New DNS Module' to be joined to the DNS Sync Group

29
“DNS” Profile (Properties)

➢ “Rapid Response Mode” and “Rapid Response Last Action”

✓ This option is used to PROTECT the network from DNS Flood Attacks. Rapid Response mode works by
performing a designated action (Rapid Response Last Action), when a DNS query does NOT MATCH a
“DNS Express Zone“.

✓ When “Rapid Response Mode” is Enabled, and if the “GSLB” option is also Enabled on the DNS Profile,
and the query name matches a “WIDE-IP“ object, the DNS query will bypass Rapid Response.

✓ By Default, If you Enable the Rapid Response Mode, ONLY the “GSLB” and “DNS Express” features will
function in the DNS profile. So, to Running/Allowing the other configured DNS profile options, such as
“DNS Cache”, “DNSSEC”, “DNS IPv6 to IPv4”, you need to choose “ALLOW” option for the “Rapid
Response Last Action”.

➢ “Protocol Validation” and “Response Cache”

✓ These options on supported platforms indicate whether the HARDWARE will “Accelerate“ DNS Query
Validation, and whether the HARDWARE will “Cache“ Responses, respectively.

➢ “DNSSEC”
✓ When you configure “DNSSEC” (including DNSSEC ZONE and ZSK/KSK) on the BIG-IP system, you MUST
Enable DNSSEC in the DNS profile.

✓ For Performance reasons, you should DISABLE the DNSSEC setting in the DNS profile, if you do NOT
have any DNSSEC Zones configured, and are NOT using the DNSSEC feature.

✓ The DNSSEC feature requires a “DNSSEC License”.

➢ “GSLB”
✓ Indicates whether the system uses BIG-IP DNS / GTM features to Manage DNS responses.

✓ For Performance reasons, you should DISABLE the GSLB setting in the DNS profile if you are NOT using
BIG-IP DNS / GTM features such as WIDE-IPs to Manage DNS responses.

➢ “DNS Cache”
✓ The BIG-IP system Caches “DNS Responses” handled by the Listener associated with the DNS profile.

✓ When you Enable the “DNS Cache“ setting, you MUST also select a Cache Object from the “DNS
Cache Name List”. The “DNS Cache“ feature is Available in TMOS v11.2.0 and later…

30
➢ “DNS Express”
✓ Specifies whether the “DNS Express“ feature is Enabled. The DNS Express feature receives “ZONE
TRANSFERS” from the Authoritative DNS Server for the zone.

✓ If the “Zone Transfer” setting is also Enabled on this profile, the DNS Express feature also responds to
“Zone Transfer Requests“ made by the Name Servers that are configured as Zone Transfer Clients for
the DNS Express zone.

✓ For Performance reasons, you should DISABLE the DNS Express setting in the DNS profile, if you do
NOT have any DNS Express Zones configured, and are NOT using the DNS Express feature.

✓ The DNS Express feature requires a “DNS Express License”.

➢ “Unhandled Query Actions”

✓ Specifies How / When the system should React respect to the Unhandled DNS Queries...

✓ When you choose “Allow”, the BIG-IP system Forwards queries to a DNS Server or Pool Member.

✓ If a “POOL“ is NOT associated with a Listener and the “Use BIND Server on BIG-IP” setting is set to
Enabled, requests are Forwarded to the “LOCAL-BIND Server”.

✓ When you choose “Hint”, the BIG-IP system Returns the query with a List of “ROOT Name Servers”.

➢ “Use BIND Server on BIG-IP”

✓ Specifies whether the system Forwards “NON-WIDE IP” queries to the “LOCAL-BIND Server” on the
BIG-IP system.

✓ For best Performance, “Disable” this setting when you use a “DNS Cache”.

➢ “Zone Transfer”
✓ Indicates whether the system Answers “Zone Transfer Requests” for a DNS Zone created on the BIG-
IP system.

✓ The “DNS Express” and “Zone Transfer” settings on a DNS profile affect how the system responds to
zone transfer requests.

➢ “DNS Security” and “DNS Security Profile”

✓ Indicates whether “DNS Firewall“ capability is Enabled.

✓ You MUST create a “DNS Security (DNS Protocol Security) Profile”, before you configure this option in
the DNS profile.

✓ The “DNS Security (DNS Protocol Security) Profile” allows you to Filter DNS to ALLOW or DENY specific
“DNS Query Types”, and to DENY specific “DNS Opcodes”.

31
➢ “Recursion Desired Set”
✓ Specifies whether to process Client-side DNS Packets with “Recursion Desired Set (RD-flag)” in the
header.

✓ If set to DISABLED, processing of the packet is subject to the “Unhandled Query Action” option.

✓ If you want to configure “DNS CACHE” option on this profile, you MUST “Disable” the “Recursion
Desired Set” option, and also set the value of “Unhandled Query Action” option to “ALLOW”.

✓ F5 recommends that you leave “Recursion Desired” ENABLED in the DNS profile, ONLY when the
system deploys as an “Internal DNS Resolver”. This setting Enables the system to answer Recursive
DNS Queries from Internal Clients.

➢ “Logging Profile”
✓ Specifies whether to Enable “HSL (High Speed Logging)” for DNS Queries and Responses.

✓ When it is set to Enabled, you MUST also specify a “DNS Logging Profile” to configure what events get
logged and their message format.

Some IMPORTANT TIPs:

The BIG-IP DNS system can use the “Local Instance” of “BIND Server”, based on the below conditions:

❖ A “Listener“ is associated with a “DNS Profile” Enabled with the “Use BIND Server on BIG-IP” option. (This
option is Enabled by default for the DNS Profile)

❖ A BIG-IP DNS “Wide-IP Pool“ uses the “Return to DNS” LB method, for Preferred, Alternate or Fallback
level.

❖ The Alternate and Fallback LB methods are set to “NONE”, and all Pools associated with the “Wide-IP” are
“UnAvailable”...

❖ The Preferred and Alternate LB methods are set to “Round Robin”, and the Fallback LB method is set to
“Return to DNS” (DEFAULT Settings of WIP Pool), and all Pools associated with the “Wide-IP” are
“UnAvailable”...

32
“DNS” Profile (Algorithm)

33
ZONE TRANSFER (DNS EXPRESS)

"Zone Transfer" Concept:

❑ A Zone Transfer is a "TCP-based Client/Server Request (TCP/53)”

❑ By default, GTM Allows BIND to perform zone transfers ONLY from the "Localhost"
❑ However, GTM can be configured to allow zone file transfers to other DNS servers
❑ Zone Transfer starts to lookup of the "SOA (Start of Authority)" for the desired ZONE
❑ Inside "SOA" RR, the "Serial Number" field determines if the actual data transfer need occur at all
❑ Client Compares the "S/N" of the "SOA" with the "S/N" in the last copy of that RR that it has
❑ If the "S/N" of the new Record is 'Greater', the Slave proceeds to request 'Actual Zone Transfer'
❑ Otherwise, the client may continue to use the copy of the Database that it already has
❑ Some Clients perform the Normal DNS Query Resolution for "SOA", instead of Establishing TCP/53
Connection
❑ And IF there is any Need for 'Actual Zone Transfer', then try to Establish TCP/53 Connection

Full Zone Transfer (AXFR):

The "Full Zone Transfer" process is as following:

1- Client sends a "Query (opcode 0)" with the special "QTYPE AXFR (value 252)" over TCP/53 to Server

2- The Server responds with a series of Response Messages:

2-1- The First Response comprises the "SOA" RR for the Zone

2-2- The other data follows in no specified order

2-3- The end of the data is signaled by Repeating the "SOA" RR for the Zone

Incremental Zone Transfer (IXFR):

The "Incremental Zone Transfer" process is as following:

1- Client uses the Special "QTYPE IXFR (value 251)", instead of the "AXFR" QTYPE

2- Client sends the "SOA" RR for the Zone that it currently has, in the "IXFR" Message, letting the Server
know which version of the "Zone" it believes to be current

3-1- The Server may respond in the "Normal AXFR Manner" with the Full Data for the Zone

OR

3-2- The Server may respond with an "Incremental Data Transfer" (based on Zone Serial Number order)

34
Zone Transfer Initiation & Schedule:

❑ Zone Transfer is normally a "Client-initiated" procedure

❑ Servers can send a "NOTIFY" Message to clients to informing about a change to the Zone Data
❑ After receiving the "NOTIFY" Message from Server, the Client sends back the Ack of NOTIFY Message
❑ Next, the Clients sends its current "SOA" RR to the Server
❑ Then, the Server sends back with the most recent changed "SOA" RR to the Client
❑ Lastly, the Client compares these two "SOA" RRs, and try to Initiate TCP/53 Zone Transfer (IXFR)
❑ Clients Schedule Zone Transfers initially, after the Zone Transfer feature is configured
❑ After receiving the Initial "SOA" RR from the Server, further Schedules are Controlled by the values of
below Fields in the "SOA" RR of the Zone:

➢ "Refresh" --> The number of Sec. between Update Requests from Secondary and Master NS. If a
Primary NS Issues a “NOTIFY”, the Secondary Server will Immediately Perform a Zone Transfer and NOT
Wait

➢ "Retry" --> The number of Sec. the Secondary Server will Wait Before Retrying when the Last Attempt
between itself and the Primary Server has Failed

➢ "Expire" --> The number of Sec. the Secondary will Wait Before Considering the ZONE Data Stale
(INVALID), if it can NOT Reach the Master NS. It should be a “Multiple of the Refresh Value”

✓ So, you can Assume the Standard Relation as: ----> [ "Retry" < "Refresh" < "Expire" ]

➢ "Minimum" --> This is used for "Non-DNSSEC Negative Caching". This is ALSO the 'Default TTL', if the
Domain does NOT specify a TTL Value

➢ "TTL" --> The number of Sec. a Domain Name is "Valid" and 'Cached' Locally before Expiration and
return to Authoritative NSs for updated information

"Zone Drift":
If the “Refresh” and “Retry” Fields are set 'Too High' and the Zone File is 'Changed Frequently', there may
be a Mismatch of Data between the Primary and Secondary NSs.

"Zone Thrash":
If the “Refresh” and “Retry” Fields are set 'Too Low' and the Secondary Server Initiates Zone Transfers
Frequently, it results in More Workload on both NSs.

35
"DNS EXPRESS" Feature on BIG-IP GTM/DNS:

❑ Allows you to transfer DNS zones from your current infrastructure to the BIG-IP
❑ BIG-IP can then answer Requests for those Zones as a High-speed, Authoritative Secondary DNS Server
❑ It does NOT run Full BIND, so it’s not as vulnerable as a typical BIND infrastructure
❑ This allows the BIG-IP to perform 'Zone Transfers' from "Multiple Primary DNS Servers", at once
❑ It can perform Zone Transfer from the "Back-end DNS Servers" to the BIG-IP
❑ It can perform Zone Transfer EVEN from the "Local-BIND Server" on the BIG-IP
❑ You can use "dnsxdump" command (DNS-EXPRESS DB DUMP) to verify that all the Resource Records
were in the “DNS Express Database”

Scenario (1):
[Back-end Primary DNS Server] <--------> [BIG-IP DNS-EXPRESS] <--------> [Other Secondary Server(s)]

Scenario (2):
[Local-BIND of BIG-IP] <--------> [BIG-IP DNS-EXPRESS] <--------> [Other Secondary Server(s)]

36
DNSSEC (DNS SECURITY)
❑ Domain Name System Security Extensions (DNSSEC) is an industry-standard protocol that functions
as an extension to the DNS protocol (RFC “4033”, “4034”, “4035”).

❑ BIG-IP DNS uses DNSSEC to Guarantee “Secure Zone Signing“ and the “Authenticity of DNS
Responses”, including “ZONE Transfers”, and also protecting your network against DNS Protocol and
DNS Server Attacks.

❑ So, “DNSSEC” feature provides “Chain-of-Trusted Entities” in DNS systems, from the “Root Domain“
toward our “BIG-IP DNS Servers”.

❑ BIG-IP DNS, uses two types of DNSSEC Keys to “Return DNSSEC-compliant Responses”, and both of
them should be “Enabled” to be usable thru DNSSEC Zone.

❑ As same as DNS Express feature, for “DNSSEC“ we need “2” types of Listeners to handle both the
“IPv4” and “IPv6” traffic. Each of them should be configured for both “UDP/53 (DNS Queries)” and
“TCP/53 (DNS Zone Transfer)”.

DNSSEC Resource Records:

o "RRSIG" :
✓ It contains a Cryptographic Signature (based on Private ZSK or KSK)
✓ These records hold the signatures for a specific record type
✓ One RRSIG record will be generated per ZSK
✓ "ZSK" is used to sign all of the records in a DNSSEC Record set
✓ "KSK" is used to sign only the DNSKEY record of a DNSSEC record set (ZSK)
✓ One RRSIG record will be generated per KSK
✓ There is one RRSIG per-key per-RRSET, not per RR
✓ Example: [RRSET (A)] -----> Private (ZSK) =====> [RRSIG (A)]

o "NSEC (Next Secure Record)" :

✓ It is used in "Negative Answers" to prove that a name does not exist
✓ Zones Signed with NSEC are “Walkable”
✓ It is suspected to "Zone-Walking" Security Issue!
✓ Below is a sample of NSEC Record:

37
o "NSEC3 (Next Secure Record Version 3)" :
✓ It is somehow like the "NSEC" Record
✓ It is also used in “Negative Answers” to prove that a name does not exist
✓ NSEC3 uses "Cryptographic Hashes" to prevent "Zone Walking"
✓ It Protects against the "DoE (Denial of Existence)" Attacks
✓ Below is a sample of NSEC3 Record:

o "CDNSKEY (Child DNSKEY) / CDS (Child Delegation Signer)" :

✓ It is for a Child-Zone requesting updates to “DS Record(s)” in the Parent-Zone.

✓ You need to make sure to “Enable” this feature in the DNSSEC Zone Settings to ensure that “CDS/CDNSKEY
Records“ signal to a Non-BIG-IP DNSSEC Parent-Zone, when “New KSKs“ are generated, and then “Disable”
it once those records are published in the Parent-Zone.

o "SEP (Security Entry Point) Records" :

Each DNSSEC Zone has a list of Read-only SEP Records. The system creates these records Automatically when you
create a zone. These records are “DS” and “DNSKEY” Records as following:

❖ “DNSKEY” :

✓ It contains a Public Signing Key (including Public ZSK or KSK)

❖ “DS (Delegation Signer)” :

✓ That is "Hash [DNSKEY Record (Public KSK)]"

✓ It references the "Public KSK" for the Zone
✓ These are records that are submitted to your "Zone’s Parent"
✓ They are included only in the "Parent"
✓ Provides a linkage between your parent and your zone
✓ Part of the DNSSEC chain of trust from your Zone’s parent to your zone
✓ After you create a DNSSEC Zone, you must submit the "DS" Record of zone to the Admin of Parent Zone
✓ Then, your Parent Zone signs the "DS" Record with their own key and upload it to their Zone

38
 ✓ Also, Each time a New Generation of a "KSK" is Created, you must provide the updated "DS" Record to the
Admin of the Parent Zone
✓ At most, you have some time Equals to "Overlap Period ([Expiration Period] - [Rollover Period])", before
the old generation of the key Expires to provide the new DS record to the Admin of the Parent Zone
✓ "DS" Record of your F5's DNSSEC Zone is located under: "/config/gtm/dsset-<dnssec.zone.name>"

DS (Delegation Signer):
❑ DNSSEC introduces DS Record to allow the Transfer of “TRUST” from a Parent-Zone to a Child-Zone.

❑ A Zone Operator Hashes the DNSKEY Record (Public KSK) and gives it to the Parent-Zone to ‘Publish’ as a “DS
Record”.

❑ Every time a Resolver is referred to a Child-Zone, the Parent-Zone also provides a DS Record. This DS Record is
how resolvers know that the Trusted Child-Zone is DNSSEC-enabled.

❑ To check the Validity of the Child-Zone’s Public KSK, the resolver Hashes it and Compares it to the DS record
from the Parent. If they Match, the resolver can assume that the Public KSK hasn’t been tampered with. This is
how a “Chain of Trust” is established in DNSSEC.

❑ Any change in the KSK also requires a change in the Parent-Zone’s DS Record.

❑ Below Figure can show the whole idea about DS Record:

5
6 4

Parent-Zone
HASH (Public-KSK)
==
DS Record ???

Resolver
1
2
3

Child-Zone

39
DLV (DNSSEC Look-aside Validation):

❑ It is used when your parent is not signed or not prepared to accept DS record submissions
❑ It is used to provide others with a trusted relationship to your zone
❑ These are in most ways identical to "DS" records
❑ The only difference is the name on the DLV record
❑ A DS record has your zone’s name (example.com)
❑ While a DLV record has an additional name (example.com.dlv.isc.org.)
❑ It is also called as "DLV-Anchor" or "Trust-Anchor"

DNSSEC Keys
➢ ZSK (Zone-signing Key):

o “Private ZSK“ → It is Used to generate a Digital Signature for each “RRSET” (e.g. A, AAAA) in a Zone.
o “Public ZSK → It is Stored as “DNSKEY Record” to be used to Authenticate “RRSIG Record” (ZSK).

➢ KSK (Key-signing Key):

o “Private ZSK“ → It is Used to generate a Digital Signature (“RRSIG Record”) for signing the “ZSK”.
o “Public ZSK → It is Stored as “DNSKEY Record” to be used to Authenticate “RRSIG Record” (KSK).

40
Automatic Key Rollover in DNSSEC
Below is two Important mathematical relations between the Key Rollover Metrics:

➢ Overlap = [ "Expiration Period" - "Rollover Period" ]

➢ Always, we can expect: [ "TTL" < "Overlap" ]

DNSSEC & BIND

❑ Your configuration of BIND is independent of the configuration of DNSSEC on GTM
❑ If you want to use BIND for delegation or other tasks, you must add the DNSSEC resource records to your BIND
❑ By default, BIND is NOT aware of DNSSEC Records
❑ If create DNSSEC Records in BIND, you can view the DNSSEC resource records in Zone Runner

41
DNS CACHE :
❑ You can configure a DNS cache on the BIG-IP DNS to allow the system to “MORE Quickly RESPOND to
Repeated DNS Queries”

❑ There are three types of DNS cache configurations available on the BIG-IP system:

1) Transparent Cache → Transparently caches the Requests and related Responses

2) Resolver Cache → Resolves DNS requests, and immediately Stores the responses in the DNS
Cache

3) Validating Resolver Cache → Resolves DNS requests, and then Verifies the responses by
using a “DNSSEC Key”, and finally Stores the verified responses in the DNS Cache

❑ DNS Cache feature enhances DNS Performance in two significant ways:

1) Answering a DNS Query from the CACHE is “Faster“ and has a very “Short Latency”

2) Caching DNS Responses Reduces the “Number of Queries” that have to be Resolved

Different DNS Cache Types:

42
Local Zone

❑ You can configure all the three DNS Cache types “Transparent”, “Resolver” or “Validating Resolver” with “Local
Zones“, to resolve queries for small local zones with “Authoritative Responses”.

❑ A “Local Zone” contains Resource Records that a DNS cache uses to resolve matching DNS queries, with
“Authoritative DNS Responses”.

❑ The “Type“ attribute of the local zone determines how the cache Handles a DNS query that does NOT match
the local zone (Non-matching Queries).

➢ Deny → The cache Drops the DNS query.

➢ Redirect → When the query is for a subdomain of the local zone, the cache Returns the Same Response
that it would for the Local Zone.

➢ Refuse → The cache returns a REFUSED message in the DNS response.

➢ Static → The cache returns a NoData or NXDOMAIN in the DNS response.

➢ Transparent (DEFAULT) → The cache performs a Pass-through or Iterative Resolution of the DNS query.

➢ Type Transparent → For a non-matching query, or EVEN a query for a matching domain name, but with a
request for a Record of a “Different Type”, the cache performs a Pass-through or Iterative Resolution of
the DNS query.

❑ In the “Name” field, you must type the “Domain Name” of local zone. For example, you could name a local zone
“siterequest.com”, and add Resource Records for the members wiki.siterequest.com. and
download.siterequest.com. In the below sample, by resolving queries for wiki.siterequest.com, the local zone
effectively Supersedes the Cache.

❑ In the “Records” area, specify your desired Resource Records to identify the local zone, including Domain Name,
TTL, Class, Type, and Record Data, separated by “Spaces”. Sample:

o wiki.siterequest.com. 300 IN A 10.10.10.10

o ftp.siterequest.com. 300 IN A 10.10.10.11

o wiki.siterequest.com. 300 IN AAAA 2002:0:1:12:123:c:cd:cdf

43
Forward Zone

❑ You can ONLY configure a “Resolver” or “Validating Resolver” DNS cache with “Forward Zones“ to forward DNS
queries that match the Forward Zones to “Specific Name Servers”.

❑ When a DNS cache configured with both Local and Forward zones receives a DNS query, the system checks the
Local Zones first, if Fails, checks the Forward Zones for a match.

❑ When a Forward Zone is configured with more than one NS, the BIG-IP system forwards the first query to a
Randomly selected NS, and Records the RTT of a successful response to have Better Decision Making based on
the “Fastest RTT” for later forwarding decisions.

RPZ (Response Policy Zone)

❑ The BIG-IP DNS can utilize “DNS Response Policy Zone (RPZ)“ as a Firewall mechanism.

❑ An RPZ is a “ZONE” that contains a list of “Known Malicious Internet Domains”.

❑ The list includes a RRset for each Malicious Domain. Each RRset includes the Names of the Malicious Domain
and any Subdomains of the domain.

❑ In order to Configure RPZ, you have “2” different Options:

1) Manual Configuration + Manual Maintenance / Update → If you do NOT want to “Purchase a

Subscription“ from a Vendor, you can use “ZoneRunner” on the BIG-IP GTM/DNS system to create a
Custom Malicious RPZ.

2) Manual Configuration + Automatic Update → There are a number of Vendors that Host RPZs. The
BIG-IP system supports RPZ vendors including:

1. “SPAMHAUS” (https://www.spamhaus.org/organization/dnsblusage/) → “rpz.spamhaus.org”

2. “SURBL” (http://www.surbl.org/df) → “rpz.surbl.org”

44
DNS Query Handling Precedence Order in CACHE:

F5 BIG-IP DNS Module

Local Zones
LDNS (1)
+ CACHE Forward Zones

Response Policy Zones

Client

LDNS (2)

Resolver (1) Resolver (2)

Some Useful Commands for DNS CACHE

❑ Displaying 'Resource Record Entries':

1) Displaying all Resource Records:

# tmsh show ltm dns cache records rrset cache <DNS Cache name>

2) Displaying Resource Records by Type:

# tmsh show ltm dns cache records rrset type <resource record type> cache <DNS Cache name>

3) Displaying Resource Records by Owner:

# tmsh show ltm dns cache records rrset owner <zone or domain name> cache <DNS Cache name>

4) Displaying Resource Records by Type and Owner:

# tmsh show ltm dns cache records rrset type <resource record type> owner <zone or domain name> cache <DNS Cache name>

45
5) Displaying Resource Records by TTL-Range:

# tmsh show ltm dns cache records rrset ttl-range <integer:integer> cache <DNS Cache name>

❑ Displaying 'Message Entries':

1) Displaying Messages by Query Name:

# tmsh show ltm dns cache records msg qname <Query-Name> cache <DNS Cache name>

2) Displaying Messages by Response Code:

# tmsh show ltm dns cache records msg rcode <former | noerror | notauth | notzone | nxdomain | nxrrset | refused | servfail |
yxdomain | yxrrset> cache <DNS Cache name>

❑ Displaying 'Name Server Entries':

1) Displaying All Name Servers the BIG-IP DNS Cache has Queried:

# tmsh show ltm dns cache records nameserver cache <DNS Cache name>

2) Displaying Name Servers by Zone:

# tmsh show ltm dns cache records nameserver zone-name <zone> cache <DNS Cache name>

❑ Additional 'Display Options':

1) Displaying All RR Details in the Specific TMM Instance:

# tmsh show ltm dns cache records rrset type <RR-Type> tmm <TMM-ID> cache <DNS Cache name>

2) Reporting the Total Number of Entries, Instead of the Entries Themselves:

# tmsh show ltm dns cache records rrset cache <DNS Cache name> count-only

❑ 'Deleting Entries':

1) Deleting All Components Cache Entries:

# tmsh delete ltm dns cache records <rrset | msg | nameserver | key> cache <DNS Cache name>

2) Deleting One Specific Entry or Subset of Entries:

# tmsh delete ltm dns cache records <rrset | msg | nameserver | key> <property> <property-Value> cache <DNS Cache name>

46
DNS Security-related Features

❑ RPZ (Response Policy Zones):

➢ You can install a third-party "Domain Filtering Service" such as 'SURBL' or 'Spamhaus'
➢ It Prevents client Infection or intercept infected Responses to known sources of malware and viruses

❑ DNS "PSP (Protocol Security Profile)":

➢ It is Available via "DNS Firewall" option
➢ To Filter the Allowed / Disallowed DNS Query + Response "Opcodes"

❑ DNS "DDoS Protection":

➢ It Protects against almost "18" DNS Attack Vectors

47
DNS-related iRule Commands & Evetns

❑ DNS-related iRule Commands:

➢ DNS::Disable --> Sets the service state to Disabled for the current DNS packet
➢ DNS::Enable --> Sets the service state to Enabled for the current DNS packet
➢ DNS::len --> Returns the DNS packet message Length
➢ DNS::name --> Gets or Sets the Resource Record Name field
➢ DNS::origin --> Returns the Originator of the DNS message (the last module which modified DNS message)
➢ DNS::ptype --> Returns the Type of the DNS packet
➢ DNS::question --> Gets (v11.0+) or Sets (v11.1+) the Question field value
➢ DNS::rrname --> Returns the Requested Name by the client
➢ DNS::rrtype --> Returns the Resource Record Type requested by the client
➢ whereis --> Returns Geographical Information on an IP address
➢ DNS::edns0 --> To Access all Fields of DNS "ECS (EDNS Client Subnet)" Extension:
o DNS::edns0 subnet address
o DNS::edns0 subnet source
o DNS::edns0 subnet scope

❑ DNS-related iRule Events:

➢ DNS_REQUEST --> Triggered when the system Receives a DNS Request

➢ DNS_RESPONSE --> Triggered when the system Responds to a DNS Request

48
Restoring "UCS" Archive File on a GTM System with Sync-Group :

❑ Before installing a UCS archive on a GTM system that will be added to an existing sync group, note the
following information:

➢ When the GTM system loads the UCS, the MCP daemon generates a NEW Configuration Change
"Commit ID"
➢ New 'Commit ID' causes the GTM system to synchronize the contents of UCS file to the GTM
Sync-Group, but in wrong manner!

❑ To Prevent from any Unwanted Changes on other Sync-Group Members, you can Partially
Disconnected ALL TMM-Interfaces of your Desired GTM System temporarily. After Restoring the UCS
Archive File on that GTM System, you can Try to Add this GTM System to the Current GTM
Synchronization Group by typing the following command:

# gtm_add <IP address of a member of the target GTM synchronization group>

❑ So, the "gtm_add" script tries to Replaces the GTM Configuration of the Current GTM System with
the Configuration of the REMOTE GTM System in the specified Sync-Group...

49
Some Troubleshooting Tips

❑ "CheckCert" Utility:

✓ It is available from the command line interface on the GTM platform

✓ It Examines all "Certificates" in the "/config/ssl/ssl.crt", including 'Bundled Certificates' file
✓ It is called from "/etc/cron.weekly/5checkcert"
✓ It Examines the "Expiration Date" of each Certificate on the system
✓ If It finds a Certificate that has Expired or will Expire within 30 days, it Logs an 'Error Message' to
the "/var/log/ltm" file
✓ The "checkcert" utility has been mostly deprecated in newer versions of TMOS.
✓ Instead, you can use the below Command which checks "/Common/ca-bundle.crt":

# tmsh run sys crypto check-cert Before

❑ Checking "Global Settings" of DNS / GTM Module:

In this regard, you can use the below command:

# tmsh list gtm all-properties

50
Some Useful “dig” Commands

Below is the actual Command Syntax:

# dig [server] [name] [type]

To have Short Answers:

# dig [name] +short
# dig google.com +short

To Specify your desired Name Server:

# dig [server] [name]
# dig @8.8.8.8 google.com

To ask for ALL Available RRs on Auth. Name Server:

# dig [server] [type]
# dig google.com ANY

To ask for your desired RR on Auth. Name Server:

# dig example.com txt
# dig example.com cname
# dig example.com ns
# dig example.com A

To ask for Tracing the DNS Lookup Procedure (Root → TLD → Host Name Servers):
# dig [server] +trace
# dig example.com +trace

To perform Reverse Lookup (Resolving “PTR” Record):

# dig +answer -x [IP-Address]
# dig +answer -x 172.217.166.46

51