Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP DNS
Known Affected Versions:
12.1.1, 12.1.2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 13.1.3.2, 13.1.3.3, 13.1.3.4, 13.1.3.5, 13.1.3.6, 13.1.4, 13.1.4.1, 13.1.5, 13.1.5.1
Fixed In:
14.0.0
Opened: Feb 23, 2017 Severity: 3-Major
BIG-IP software has long supported TSIG-style transaction security for zone transfers. It has not supported them for standard queries, however. A third-party DNS server requesting a zone transfer may first perform a standard SOA query to determine if a zone has changed prior to requesting a full transfer. This is vendor specific. When this request is TSIG signed, a BIG-IP system fails to properly respond.
This change affects DNS messages containing TSIG signatures. Those messages that do not contain these signatures are not affected. The handling of TSIG-signed messages has changed as described in the fix text.
A TSIG-signed DNS standard query arrives at a BIG-IP system, intended to be properly answered by the BIG-IP system itself, rather than being proxied to a pool member.
This defect's workaround is limited to the case of a zone transfer client issuing a signed SOA query prior to conducting the actual transfer. In this case, it may be possible to configure the zone transfer client (DNS server requesting the transfer) to directly perform IXFR requests, rather than first issuing an SOA query first. If possible, this would avoid sending the BIG-IP a signed standard query (SOA), and thus allow transfers to occur.
This fix corrects this defect, by adding support for properly handling queries of all types containing TSIG, as long as BIG-IP system possesses the correct TSIG key used to sign the received request. When the request is received, if the key is found, the signature validates, and the signature is within the validity timespan, the request is handled, and the response is properly signed with the key. If any of this fails, an error response (BADKEY, BADSIG, or BADTIME) is returned. The only exception to this behavior is: If the query contains a TSIG signature, and the key used is not found in the BIG-IP configuration, and the DNS profile's unhandled query action is 'allow', then the query is not touched, but rather simply proxied. This is done based on the possibility that some back-end server does have the needed key, and can therefore respond to the request. This fix also impacts the handling of zone transfer NOTIFY messages that lack a TSIG. In past versions, these messages were allowed and acted upon even if the zone setting 'Verify Notify TSIG' was enabled. NOTIFY messages lacking a TSIG are now dropped if this setting is enabled.