Where I work, which has a very enlightened approach to QA/Dev, we actually have a report that details every bug found at customer sites, why it was missed in QA and what steps are being taken to ensure that similar bugs will not be missed.
We understand that everyone is human. If we expect developers to occasionally wirte a bug into the code, we should expect QA to occasionally miss a bug too.
The trick is to have a process that catches these things as best we can. This is why we report coverage for tests, and test plans are checked periodically.
Blame is not a useful idea to work with. What we try to do is find all the failures that occurred in the process that caused the bug to escape. It usually takes 3-4 failures in the same path for this to happen. Then each failure is dealt with using the Kai-Zen method of 5-whys, if somewhat haphazardly applied.
Obviously, if one of the failures is a test that was reported as done but wasn't really done, we might need to give the person involved a stern talking to. The same goes for changes made in code without notifying QA that they should re-test.
As ever, this varies with the type of software, company size and culture and a thousand other things, so your mileage may vary.