This confusion is not your fault. The literature sucks.
Some state that is ok to put this query in repository others say is not good because is not an entity
"Repository", in a DDD discussion, refers back to the REPOSITORY pattern described by Eric Evans in Chapter 6 of the original domain driven design book.
Evans, in that chapter, explicitly opens the possibility of Repositories returning values rather than entities.
... usually ENTITIES, sometimes VALUE OBJECTS with complex internal structure, sometimes enumerated VALUES.
The core motivation of the REPOSITORY pattern is to create a facade, so that the complexity of reconstituting the objects you need is delegated to the plumbing, allowing your application code to express its needs in the language of the model.
Therefore...
If you have a report, perhaps based on some complex inner join, it is a perfectly reasonable application of the pattern to create a REPOSITORY that represents a collection of those reports, with methods to allow the client to request a specific report (or subset of the collection).
These reports are, of course, values -- meaning that the implementation of the report doesn't include affordances that allow you to change the report. Similarly, the report collection (ie, the repository) does not include affordances for adding or updating reports. (In effect, the reports are a view into the information managed by the domain model; you can look, but if you want to change anything you need to send messages to the domain entities).
So basically DTO's should live not in Business Layer but in Domain Model Layer?
No, I don't think that follows. DTO are, in effect, an in memory representation of a message schema, where a schema is a representation of information that can be sent across time and space. That's a communication concern, not a domain modeling concern. That sort of thing normally makes sense out at the boundaries of our application, not in the core of our domain.
Message schema typically change much more slowly than our domain dynamics, and for different reasons.
If DTO and domain models change for different reasons, do you really want to design your solution so that these two different things are in the same pile of stuff?
Design is what we do to get more of what we want than we would get by just doing it.
So you need to think about which of the "what you want"s should have priority here.