1. Product Owner is the main responsible for writting Product Backlog Items (this duty can be delegated), so he must come to the Sprint Planning meeting with an idea of the acceptance criteria, as it will help dev team to understand and estimat stories. So yes, before an item is selected during the Sprint Planning to be taken into a Sprint by the dev team, it must have acceptance criteria. Not necessarily the PO must write all the criteria before the Sprint Planning as during the Planning, however, dev team can challange the criteria and them and PO can adjust or adapt.
2. The first difference is that definition of done (DoD) are common to all Product Backlog Items (PBIs) of a product, while acceptance criteria is specific to each item (and will be different).
The DoD exists to ensure that the dev team members agree on what means when an item (story) is « done ». It is there to ensure quality of work they’re attempting to produce. It serves as a checklist that is common to all items and is respected. When we see an item as « done », team, Product Owner, Scrum Master know what this notion of « done » mean (all items in the definition of done have been respected). It is transparent, and no one will invetigate if team has actually respected it. If you see that product starts having lot of bugs, issues, technical debt increasing, it may indicate that definition of done is not being respected (best time to update the DoD is during the Sprint Retrospective).
Acceptance criteria are s set of statements that describes conditions an item must respect in order for it be accepted by the Product Owner. It is normally different from story to story, as it represents some behaviours or cases we want to achieve by building the functuinality described in the item.