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