RESOLV::lookup

Description

RESOLV::lookup performs a DNS query, returning one or more addresses (A records) for a hostname, a domain name (PTR record) for an IP address, or optionally one or more values for records of other types. Multiple values are returned as a list, so to obtain a single IP address the construction

[lindex [RESOLV::lookup $hostname] 0]
may be used.

Warning

This command has been deprecated with the release of version 15.1 in favor of the RESOLVER and DNSMSG namespaces.

The key difference between this command and the older NAME::lookup command is that RESOLV::lookup briefly suspends execution of the current iRule (event) then returns the result inline, whereas NAME::lookup is asynchronous (the current rule continues and eventually another event NAME_RESOLVED fires when the result is available. In each NAME_RESOLVED event you must call NAME::response to obtain the result). RESOLV::lookup is almost always more convenient than the older NAME::lookup function.
By default RESOLV::lookup queries the BIG-IP’s local caching nameserver (bind) which you must configure in advance. If your RESOLV::lookup queries don’t seem to work you should adjust your BIG-IP configuration as explained inf5 Solution Note SOL12224.
RESOLV::lookup lets you optionally specify a DNS resolver to query. You may give either a single nameserver’s IP address or the name (e.g., /Common/myDNS) of a virtual server which sends DNS queries to some pool of nameservers. You may use this feature to implement external DNS-query-based services such as large real time IP block lists.
By default, TMM will make up to 4 consecutive query attempts (1 original with 3 retries) with an individual query timeout of 5 seconds. These parameters are globally configurable using these database keys:
b db tmm.resolv.retry
b db tmm.resolv.timeout

Or via tmsh:

tmsh modify /sys db tmm.resolv.retry value < value >
tmsh modify /sys db tmm.resolv.timeout value < value >

Syntax

RESOLV::lookup [@<IP>|@<virtual name>] [inet|inet6] [-a|-aaaa|-txt|-mx|-ptr|] <name|ip>

-naptr and -srv added in 11.5.0
If you send queries to a virtual server using an argument of the form @/Common/myDNS and expect those queries to leave the BIG-IP, ensure that you SNAT traffic via that virtual server so the remote nameservers will have a routable address to send replies to (otherwise the query source address will be one of the BIG-IP’s loopback addresses, 127.1.x.y). Either set SNAT Automap or assign a SNAT pool to the virtual server, or add a selective-SNAT iRule which triggers when client IP matches 127.1.0.0/16.
The [inet|inet6] arguments are most useful when querying non-address records. The -a option (query for type A IPv4-address records) is incompatible with ‘inet6’ and -aaaa (query for type AAAA IPv6-address records) is incompatible with ‘inet’.
The RESOLV::lookup function sets the RD (Recursion Desired) flag in the DNS queries that it sends, so with a typical nameserver you will obtain any available address records for the final domain a chain of CNAME’s.

Examples

when CLIENT_ACCEPTED {
  log local0. "devcentral.f5.com is currently at IP [RESOLV::lookup @10.10.20.1 "devcentral.f5.com"]"
}

Results in log entry:
Jan 21 20:21:22 local/tmm info tmm[5018]: Rule resolv_test <CLIENT_ACCEPTED>: devcentral.f5.com is currently at IP 65.61.115.213

# Select the first returned IP address as the destination IP (inherits the destination port from the client's destination port).
when RULE_INIT {
   set static::dns_vs my_dns_vs
}
when CLIENT_ACCEPTED {

   # Get IP(s) for hostname www.example.com against 4.2.2.1 name server
   set ips [RESOLV::lookup @$static::dns_vs -a "www.example.com"]

   # Log result. If there are multiple IP's it could be a TCL list like {1.1.1.1 2.2.2.2 3.3.3.3}.
   log local0. "Looked up www.example.com and found $ips, parsed first element: [lindex $ips 0]"

   # Check if the first list element was empty
   if {$ips eq ""}{
      # Input wasn't an IP address, take some default action?
   } else {
      # Select the IP
      node [lindex $ips 0]
   }
}

Note: The results for all query types should be cached according to the Time To Live on the response. Subsequent calls using RESOLV::lookup will use the cache. However, due to a bug noted in ID360270 (fixed in 11.4,) PTR (reverse) records are not cached. You could work around this issue by saving the PTR response in a table. Please open a case with F5 Support if you would like to see this issue fixed.

Note: There was a known issue for RESOLV::lookup where a “wrong # args” runtime error occurs if 4 arguments are supplied. This issue was being tracked as CR 135777 / Bug 243140 and was fixed in 10.2.0.

Note: There was a known issue for RESOLV::lookup when using the -ptr flag. A hostname will not be returned even a valid PTR record for the IP address exists. This was tracked as Bug 340659 (SOL12378) and was fixed in 10.2.2. Contact F5 Support for a hotfix in 10.2.0 and 10.2.1.

Note: RESOLV::lookup won’t work with a virtual server address as the destination. Use the virtual server name instead as this is the expected format. In V11, the virtual server name must include the /Common/ designation, exactly as the VIP appears in bigip.conf

Note: In v15.1.3.1 and v16.1.0 and later, RESOLV::lookup fails to connect to the specified target virtual server when the virtual server specifies a certain ‘source’ IP range. Workaround: Use ‘source 0.0.0.0/0’. This was tracked as ID 1037005.

Note: In v15.1.3.1 and v16.1.0 and later, RESOLV::lookup may fail to connect to the specified target virtual server when the virtual server has the same IP/Port/Route Domain combination as other virtual server. Make the virtual servers distinguishable by factors like IP/Port/Route Domain. This was tracked as ID 1010697.

Note: In v15.1.3.1 and v16.1.0 and later, RESOLV::lookup fails to connect to the specified target virtual server after the destination of the virtual server is modified. Workaround: Ensure the RESOLV::lookup iRule command is not called against the modified virtual server for about a minute, or restart tmm. This was tracked as ID 1038921.