Issues with sending TSIG updates
Paul A Vixie
vixie at mibh.net
Sat Sep 4 17:43:12 UTC 1999
> First of all, there does not seem to be a "res_nupdatesigned()"
> counterpart to "res_nupdate()". It would seem that to send a signed
> update one must resort to "res_nsendupdate()" which also requires the
> caller to hunt down the primary nameserver. Is all of this intentional?
> Should there not be a "res_nupdatesigned()" which would work just like
> "res_nupdate()" with the addition of taking a key and signing the
> update? If the answer is yes, I will write one. Actually I think I
> have one I can dig out of another branch on my CVS tree.
yes, there should be a res_nupdatesigned(). at least one other person has
written one, but i rejected it since it failed the "one should call the other"
requirement that most of res_n*() meets with regard to res_*(). i.e., don't
duplicate code, find or make a common simple function and have the API-visible
functions call that (those?) simple function(s?).
> In dealing with the above, I found "res_nfindprimary()". This function
> does not seem to work quite right. First of all, right at the start of
> the function the following happens:
> ...
> I would simply fix "res_nfindprimary()" and report here with a patch,
> but I am not even sure of the algorithm/methodology. What is it
> expecting to be included in "rrecp_in" such that it's rrecp->r_dname
> will successfully find the SOA. A "S_PREREQ" section with a "YXDOMAIN"
> would provide the rrecp->r_dname needed to get an SOA, but is that the
> requirement of "res_nfindprimary()"?
i think it's probably dead code.
More information about the bind-workers
mailing list