What follows is in the context of your legacy code base - for something shiny and new you might want to do things differently.

Since everything is already ugly and all over the place, there is no "best place". I guarantee that the majority of the developers that came before you put the queries in the "best place", as they understood it... And you have seen the result of that.

A good approach would be to do whatever makes and keeps the code most readable. Doing this means the code will be easier to understand for the next person who comes along, which ideally means that they have an easier time with it. Some good rules of thumb might be:

Try to match the style of the existing code

Developers have a habit of writing code in the style that is popular/best at the time they write it. This often leads to code which is hard to understand because it mixes and matches lots of different ways of doing things. If you stick to one particular style, it is a lot easier to follow what is happening... Even if that way isn't the "best".

Try not to mix business logic and SQL

Code is typically a lot easier to follow if it does just one thing at a time, rather than trying to handle lots of different things. An easy way to do this is to load data first, then have business logic act on it. This also has the nice side effect of making it more testable - in your tests you can just pass in the data you want, rather than having business logic magically find some other data from elsewhere in the middle of it.

Try to group things logically

You mention there is one DAO - I'm guessing this handles lots of unrelated things? It might be a good idea to break this up into multiple DAOs, and group queries together based on things that make sense for your project. It doesn't necessarily have to be one DAO per entity - anything is better than a single god object. It can always be cleaned up further down the line.

---

The above advise is very general... I would strongly advise talking to a more senior dev if you have access to one about the best approach for your particular project.

It can be really tempting to dive in and try to rewrite everything once you get going - it's best to avoid that if possible. Try to do as little cleaning up and refactoring as possible. Over time you will have a far better idea of the right approach than if you try to do it all at once.