I have released a new version of the Hesiod library, containing minor enhancements. Please consider integrating this into Fedora Core. The new version contains a couple of new functions, including one which allows Hesiod to be used with an alternate resolver library (such as ares) for non-blocking or thread-safe name resolution. We use the new functions in local applications at MIT, and would like to be able to use the native Hesiod component on Red Hat systems. hesinfo has also been split into a separate source tree for this release. Thanks for your time!
Congratulations on the new release! I see that NEWS mentions that support for HS class queries has been dropped -- I know of at least one site where that's totally going to break things, and that gives me pause.
It's a pretty rare name server which can even handle class HS queries these days, so I'm surprised to hear that. But I don't think it would be too hard to hack that support back in if it's important.
It's not a factor in Red Hat's internal test zone, but unless I'm mistaken ncsu.edu still uses HS exclusively. I'll CC Jack and Elliot, who can hopefully add fresh info; maybe they don't need that feature any more. I'll probably have 3.1.0 in Raw Hide tomorrow. Support for multiple classes can come in later, and it's very early in the FC6 development cycle, so we have time.
Created attachment 127068 [details] Output from the dig command Yeah, NCSU exclusively uses the HS class. I believe Duke did as well but they recently migrated completely to LDAP. NCSU's LDAP migration seems perminately held up in politics. :-)
I'll note that it should be relatively easy to advertise those records in the IN class as well as the HS class.
Greg, I'd actually thought that upstream development had stopped, so the Fedora package has been carrying some patches which are probably better included upstream. Would you like to review them? If so, do you prefer attachments here, mail to hesiod, or some other delivery method?
With nine years between releases, I should think that's reasonable! My goal in this release was to quickly push out what we already had, so I didn't make any changes beforehand, but I did look at the Red Hat patches and compare them to what we had already done. Reactions: dnsparse.patch: Still necessary if there was a real issue there. I've never heard of Hesiod being used with long records. env.patch: Still necessary under your assumptions, though of course Hesiod data is usually obtained over the net unprotected. libresolv.patch: Still necessary. Our local workaround is dumb (set ac_cv_lib_resolv_res_send=yes in config.site) and we should have a better one. shlib.patch: No longer necessary; MIT's tree now installs a shared library using libtool. We are both using the same soname, which should be okay since no incompatible changes are made. str.patch: Hunk by hunk: Hunk 1: Independently fixed. Hunk 2: Independently fixed. Hunk 3: Unnecessary; if *s1 is non-zero and *s2 is zero, tolower(*s1) will be unequal to tolower(*s2) and the loop will terminate. (Though it may be worth changing for the sake of being less alarming.) Hunk 4: Still necessary for paranoia (current code is safe if sizeof(int) == 4, but that's not a great assumption). Hunk 5: See hunk 3. I will plan to incorporate the still-necessary parts here.
I went back and reexamined them today as well, and the dnsparse patch as it was needed work -- it was initially written during a storm of bug reports against packages which didn't handle large DNS responses well (most would attempt to parse past the end of the buffer in which they'd stored their responses), and it may well be unnecessary. The env.patch file mirrors a similar change to glibc's (forked?) copy. You're right that the data comes from the network is trusted without being authenticated, though. As for the "classes=" option, we both missed the hesiod.conf man page, which still mentions the setting. I'll attach a suggested patch to re-add it, though it'll probably look quite different from what was there in 3.0.2. Both hesiod and hesinfo 3.1.0 will show up in tomorrow morning's Raw Hide tree, with the above-mentioned "classes" patch included in the source package but not applied. The anoncvs server will also have the contents at http://cvs.fedora.redhat.com/viewcvs/devel/hesiod/, once it updates. Thanks for taking the time to review the Fedora package!
Created attachment 127092 [details] one way to reintroduce support for the "classes" directive Changing the default to "IN" and quietly adding support for "ANY" may be a mistake, because it puts us subtlely out of sync with glibc's copy of the library, which defaults to "IN,HS" and doesn't support "ANY".
Just to confirm this HS class mess on FC6t1. Glibc is able to access hesiod information but not the hesinfo tool: [root@rpath ~]# id jjneely uid=18536(jjneely) gid=108(ncsu) groups=4294967295,107(pcostaff),108(ncsu),110(cccadm),133(pamsstaff),320(cc-staff),324(ncsu_staff) [root@rpath ~]# hesinfo jjneely PASSWD hesiod_resolve: Hesiod name not found.
While not a big site, I have been using HESIOD for quite a few years. I just did an upgrade from Fedora Core 5 to Fedora 8, and got the new HESIOD hesiod-3.1.0-9 package which broke my usage of HESIOD. I'm gathering that there is no plan to revert to supporting HS, and that my only option is to move everything to IN.
Actually, I'm still open to the idea of enabling the patch to re-enable support for retrieving data using the HS class, though I'd personally discourage its use in new deployments.
There are advantages to separating this information into different classes, and it made the distribution easier. The machines that secondary my zones in the IN class aren't the same machines that need to secondary my zones in the HS class. Since I needed a quick fix, I ended up writing some PERL scripts to set up an alternative way to distribute the email forwarding tables I was using HESIOD for. This was far easier than trying to reconfigure everything to move to the IN class, and I didn't want to be compiling my own versions of HESIOD. It's just an unfortunate situation that an increase in the version number of a package ended up being enough of a downgrade in functionality to make me drop usage of the software after more than a decade of usage.