Are Repositories implementations part of my domain? Should repositories have SQL queries?

If you're using a hexagon, onion or ports and adapters style architecture, then the normal practice is to put your repository interfaces in your domain model and your repository implementations in your persistence layer/adapter. You would then wire them up using an IoC container and add a reference from your persistence layer to your domain model. This allows you to use your domain model entities and value objects in your persistence layer, but also have access to your repositories in your domain model via IoC.

Where you put your SQL is up to you, this isn't particularly a DDD thing, but it probably belongs in your repositories. Standard practice is to use a stored procedure or a LINQ style query using ORM like Entity Framework or NHibernate. In the later case, the query would exist in the repository.

Good practice is for your repositories to accept domain entities (i.e. for creating/updating) and also return domain entities (i.e. for queries). Any auto-generated entities generated by an ORM would normally be hidden by your repositories. This might appear to do-away with a lot of the 'goodness' you get from an ORM (like lazy-loading and 2-way navigation properties), but these things are often a hindrance to good DDD and particularly good object/entity design.

Extra Detail

The repository pattern's goal is to 'act like a list' in order to hide persistence details. So the goal when designing a repository is to make it a simple collection where items can be added, removed and changed. Behind the scenes, your repository can (should) know about where it is storing the data, i.e. a SQL database, flat files, XML files etc.

In DDD you'd ideally want one repository per aggregate root. For example persisting a single Customer aggregate root (an aggregate root may be a single entity, or an entity made up of other entities or value objects) may result in writing to 4 separate tables.