Sorry, misuse of terminology. It sends an update to the reverse
server signed in the private half of the SIG key from its forward
FQDN.
The reverse server has to know to do step 6 to validate the update.
because my laptop has a relationship to the server for psg.com, and
can put something kinky into the forward name should not mean that
the owner of the reverse zone should trust the data in the forward
zone or that the laptop asserts. is the attack not pretty obvious?
It was a rough outline. Obviously the checking the reverse server has
to do to make it work is more than what I said, but it's totally
doable. The validation I described prevents a random host on the
network from trivially stuffing the DNS server with bogus PTR records.
You could do an additional validation where if someone wants to stuff
a new valid into an old PTR record, the DNS server looks to see if the
old FQDN in that PTR record still points back to the address referred
to by the PTR record, and if it does, refuses the update. This
prevents PTR record stealing.