I am afraid it is not that simple.  There are two prerequisites for
triggering this bug:

 1. The master_servers array has to contain more than one address.

 2. The SOA query has to be responded to properly, while sending the
    TKEY query has to elicit a dispatch error.

Your comment prompted me to spend most of yesterday on trying to find a
way to satisfy both of these prerequisites within the limitations of our
system test infrastructure, i.e. without making any assumptions about
the capabilities and configuration of the host running the tests.

The executive summary is that I failed.  However, my attempts led me to
two other issues:

  - the return value of the next_master() call in the same code branch
    as the original problem is ignored,

  - when running in local-only mode ("-l") or when /etc/resolv.conf
    contains no name server addresses, nsupdate primes the master server
    address list with localhost addresses; however, 127.0.0.1 is tried
    before ::1 (perhaps this one deserves a separate ticket to avoid
    confusion?).

I pushed fixes to both of the above issues to the rt45380 branch, please
review.  Following is a discussion of why I was unable to prepare a
system test.

IIUC, the first requirement can only be satisfied in three cases:

 a) No "server" command is provided and SOA MNAME resolves to multiple
    addresses.
 
 b) A "server" command is provided and the given server name resolves to
    multiple addresses.

 c) Local-only mode ("-l") is used and the host is dual-stacked.

Problems with each of these cases:

 a) In order to direct SOA queries to localhost, we would either need to
    control /etc/resolv.conf or _assume_ the latter contains either only
    ::1 or only 127.0.0.1.

 b) We could use "server localhost" and _hope_ the host is dual-stacked.
    Though even if it was, there would still be no easy way to satisfy
    the second requirement:
    
      - If the local server listened on both ::1 and 127.0.0.1, it would
	have to correctly respond to the SOA query and then immediately
	close the socket used to receive that query, so that sending the
	TKEY query elicits a dispatch error.  

      - If the local server listened on just ::1 or just 127.0.0.1, the
	dispatch error would already had been triggered by the time
	recvsoa() is called, so recvgss() would not get a chance to fail
	over to another address.

 c) Local-only mode not only requires a session key to be installed
    beforehand in the location defined by the SESSION_KEYFILE constant,
    but is also subject to the same limitations as case b) _and_ assumes
    the host is dual-stacked.

My original reproduction scenario is based on case a), but it _requires_
/etc/resolv.conf to contain only 127.0.0.1 and _requires_ the host to be
dual-stacked.  Combined with a test server listening only on 127.0.0.1,
this results in the SOA query being sent to 127.0.0.1 and successfully
responded to with MNAME set to "localhost.", followed by sending a TKEY
query to ::1, which causes recvgss() to fail over to 127.0.0.1.

I could not find any way to achieve the same effect using a system test.
All checks performed in the tsiggss system test use "server 10.53.0.1",
which prevents any failover from occurring.