Issues with sending TSIG updates

[Brian Wellington]

On Sat, 4 Sep 1999, Paul A Vixie wrote:

> > 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?).

There is a reason that I didn't write res_nupdatesigned() in the first
place.  res_nupdate() communicates with the normal server, and then sends
an update to (potentially) another server.  There's no guarantee that both
servers are the same,so multiple keys may be needed.  The caller might not
even know the final destination of the update when res_nupdatesigned() is
called, so it couldn't know the key to use. The split was done so the
caller could:

- call res_nfindprimary, using the key it shares with its server
- get the result, see if it has a shared key with the primary
- call res_nsendupdate, specifying the key if there is one

res_nupdate could be retrofitted to call res_nfindprimary and
res_nsendupdate, but this might not be trivial.  I haven't looked for a
while.

> > 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.

I don't fully understand the algorithm either.  res_nfindprimary() and
res_nsendupdate() were more or less written by lifting blocks of code from
res_nupdate() (which fails the requirement above) until I could modify a
program that called res_nupdate to use the newer functions and send signed
updates (and signed queries looking for the primary server).

Brian