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
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 firstname.lastname@example.org, 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
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
[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.