I set up a series of realm R1.MIT.EDU .. R4.MIT.EDU with cross-realm
keys, got a ticket as principal x@R1, and ran "kvno
service2@R4.MIT.EDU" with the current 1.4 branch sources, under
valgrind on x86-linux.  So intermediate TGTs were needed for R1->R2,
R2->R3,
R3->R4.

Aside from the leaks related in ticket 2541, this one showed up.  Some
experimentation with different service principal realms and different
sets of existing tickets indicates that the number of leaked blocks
varies, presumably with the number of KDC requests.

==30513== 280 bytes in 10 blocks are definitely lost in loss record 7 of 7
==30513==    at 0x1B903D38: malloc (vg_replace_malloc.c:131)
==30513==    by 0x1B9D118B: __libc_res_nsend (in /lib/libresolv-2.3.2.so)
==30513==    by 0x1B9CFE19: __libc_res_nquery (in /lib/libresolv-2.3.2.so)
==30513==    by 0x1B9D056A: __libc_res_nquerydomain (in /lib/libresolv-2.3.2.so)
==30513==    by 0x1B9D0131: __libc_res_nsearch (in /lib/libresolv-2.3.2.so)
==30513==    by 0x1B9D0479: __res_nsearch (in /lib/libresolv-2.3.2.so)
==30513==    by 0x1B9787EC: krb5int_dns_init (dnsglue.c:106)
==30513==    by 0x1B978C34: krb5int_make_srv_query_realm (dnssrv.c:106)
==30513==    by 0x1B97BAB1: krb5_locate_srv_dns_1 (locate_kdc.c:518)
==30513==    by 0x1B97BC45: krb5int_locate_server (locate_kdc.c:595)

At first glance, I think it may be a glibc bug.  There is a res_nclose
routine that we aren't calling, but I don't think it'll fix this.

Ken