Where do open file handles go when they die?

The inodes still persist on disk, although no more hard links to the inodes exist. They will be deleted when the file descriptor is closed. Until then, the file can be modified as normal, barring operations that require a filename/hard link.

debugfs and similar tools can be used to recover the contents of the inodes.

The kernel does reference counting on references to the inode. See my answer to What happens when I close() a file descriptor?.

Deleting open files is likely no more effective a DOS mechanism than just opening files. The ulimit on open files provides some protection against this DOS attempt. It applies to all open files, deleted or not.

A file is only erased on the filesystem once every reference to it has disappeared. Both names and open handles count as references. As long as the file is open in a program, it is not deleted, although most systems don't allow you to recreate a name for it.

The data is still on the drive, but the file is marked as having a link count of 0. If the system crashes, fsck on the next reboot knows that it must delete the data. This doesn't lead to a denial of service any more than a non-deleted file does.

You cannot recreate a link to the file on a stock Linux system as far as I know (short of bypassing the filesystem driver with debugfs or similar methods), but you can recover the contents easily: cat /proc/12345/fd/42 where 12345 is the process ID that has the file open and 42 is the file descriptor number.

Over NFS, when you delete a file that's still open in some client, the NFS server renames the file on the server but does not delete it until all clients have released the file. In my experience, the new name is .nfs…, though I don't know if the name is the same in all NFS implementations.