We listed in a previous entry the new features of Avalanche 3.80. There are more, and I discovered one just last week while running an Avalanche training. It’s called “DNS Continuation.”
Let’s recapitulate first how DNS look-ups work in Avalanche. If you use hostnames in your Action Lists, Avalanche will have to translate to IP in order to connect. A DNS resolution (look-up) for that hostname will automatically be started, as it should, unless your created a Host File under Client/Profile.
By default, we do the DNS resolution from the management port of the appliance/STC chassis using the management port DNS servers IP info. This is because, unless otherwise specified, we assume that the user doesn’t want to “pollute” the test bed with DNS resolutions.
Note that a hostname will be resolved only once, at the beginning of the test, unless you checked the “Enable Round Robin DNS” under Client/Network. In that case, a new DNS resolution will be done for each SimUsers created during the test. You could potentially kill your office/management network so be careful.
If you check “Test DNS” under Client/Port, then the DNS resolutions will be done from the given test port instead of the management port, using the DNS server IPs you specify. The same rules apply when you enable “Round Robin DNS.”
You can still, of course, manually type in the Action List the DNS look-up actions. Avalanche will automatically remember (read: cache) the look-up information (hostname-IP address pairing) retrieved from the DNS stack in the other protocols’ stack.
That was for the lay of the land. But we improved on that behavior. In the past, if one of the DNS look-up couldn’t be successful for any reason (incorrect DNS server IP, failed look-up, etc…), the test would abort and ask the user to fix the issue. This is because we tend do avoid negative testing (where you expect fails). But customers asked for a change of behavior there, and that’s what DNS Continuation is.
As per the help file:
Select to verify if a host name can be resolved in each action of an Action list, before the action is executed. If not, Avalanche considers the action unsuccessful, and continues to execute the next action in the Action list. However, if the Action list contains a host name, but no DNS server address is configured, a configuration error results, and the test is aborted.
To illustrate, I created an Avalanche test with two HTTP actions: one to http://www.spirent.com, one to this blog. I created a Client host file with the IP information only of the second domain name. If DNS Continuation is not enabled, you get this error message:
: [2011/12/12 09:45:01] 10.7.2.244:cpu0: (3239) Unknown Host thrown by ProtocolActionBase::ResolveHostName: Can’t resolve hostname: http://www.spirent.com
And this screen (no action is even attempted) is what you also get:
I then created a second Client Profile, this one with DNS Continuation enabled (it’s a check box at the bottom of the Client/Profile/DNS window), and ran the exact same test. In that case, you don’t see the DNS look-up error in the event log (we wouldn’t ‘spam’ the event log with constant “can’t resolve hostname” messages, since this is negative testing).
However in that case, the whole test is not aborted – the one transaction with the error is flagged as “Unsuccessful”, but the second HTTP GET is attempted, and successful:
The SPF I used is available here.