Interactions of ntpdate with DNS round robin

To follow up on my last post of ntpdate interactions with DNS round robin,  I wanted to find if the shortest path fails, whether ntpdate will take the second path as backup.  The answer is affirmative. I have tested it with firewall blocking the reachability of the shortest path. Some captures are given below for reference.

Test : 118.143.17.82 is blocked by firewall to stimulate the shortest path failure

# ntpdate -4 time.hko.hk
13 Jun 08:53:48 ntpdate[3578]: sendto(118.143.17.82): Operation not permitted
13 Jun 08:53:49 ntpdate[3578]: sendto(118.143.17.82): Operation not permitted
13 Jun 08:53:50 ntpdate[3578]: sendto(118.143.17.82): Operation not permitted
13 Jun 08:53:51 ntpdate[3578]: sendto(118.143.17.82): Operation not permitted
13 Jun 08:53:52 ntpdate[3578]: adjust time server 223.255.185.2 offset -0.000177 sec

More details by :

#ntpdate -4 -d time.hko.hk
13 Jun 09:01:15 ntpdate[3699]: ntpdate 4.2.4p5@1.1541-o Wed Oct  8 11:22:55 UTC 2008 (1)
Looking for host time.hko.hk and service ntp
host found : 118.143.17.82
transmit(118.143.17.82)
13 Jun 09:01:15 ntpdate[3699]: sendto(118.143.17.82): Operation not permitted
transmit(223.255.185.2)
receive(223.255.185.2)
transmit(223.255.185.2)
receive(223.255.185.2)
transmit(223.255.185.2)
receive(223.255.185.2)
transmit(223.255.185.2)
receive(223.255.185.2)
transmit(223.255.185.2)
transmit(118.143.17.82)
13 Jun 09:01:16 ntpdate[3699]: sendto(118.143.17.82): Operation not permitted
transmit(118.143.17.82)
13 Jun 09:01:17 ntpdate[3699]: sendto(118.143.17.82): Operation not permitted
transmit(118.143.17.82)
13 Jun 09:01:18 ntpdate[3699]: sendto(118.143.17.82): Operation not permitted
transmit(118.143.17.82)
118.143.17.82: Server dropped: no data
server 118.143.17.82, port 123
stratum 0, precision 0, leap 00, trust 000
refid [118.143.17.82], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036 14:28:16.000
originate timestamp: 00000000.00000000  Thu, Feb  7 2036 14:28:16.000
transmit timestamp:  d38264de.bd2b5c2c  Wed, Jun 13 2012  9:01:18.738
filter delay:  0.00000  0.00000  0.00000  0.00000
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

server 223.255.185.2, port 123
stratum 1, precision -19, leap 00, trust 000
refid [GPS], delay 0.03297, dispersion 0.00114
transmitted 4, in filter 4
reference time:    d38264db.09591159  Wed, Jun 13 2012  9:01:15.036
originate timestamp: d38264db.fb344598  Wed, Jun 13 2012  9:01:15.981
transmit timestamp:  d38264db.fa50e9ce  Wed, Jun 13 2012  9:01:15.977
filter delay:  0.04730  0.03297  0.03494  0.03299
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.006902 -0.00027 0.000801 -0.00029
         0.000000 0.000000 0.000000 0.000000
delay 0.03297, dispersion 0.00114
offset -0.000275

13 Jun 09:01:19 ntpdate[3699]: adjust time server 223.255.185.2 offset -0.000275 sec

***** End of Capture ******

As can be seen, "ntpdate -4 -d time.hko.hk"  will first establish handshakes  with all available IP addresses to determine which one is the best for time sync.  If the best IP address is broken, the other will be taken up.