ltm rule command RESOLV lookupΒΆ

iRule(1)		      BIG-IP TMSH Manual		      iRule(1)



RESOLV::lookup
       The commands for making a DNS lookup.

SYNOPSIS
       RESOLV::lookup (
		       (
			(RESOLV_NS)
			('inet' | 'inet6')
			('-a' | '-aaaa' | '-txt' | '-mx' |'-srv' | '-naptr' |
       '-ptr')
		       )#
		      )?
		      QUERY

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.

       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 in f5 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 >

RETURN VALUE
       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 will not chase through a chain of CNAME
       records.

VALID DURING
       ANY_EVENT

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 : 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]
	    }
	}

HINTS
       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, 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

SEE ALSO
CHANGE LOG
       @BIGIP-10.1.0 --First introduced the command.



BIG-IP				  2017-01-31			      iRule(1)