Should the domain model document/account for these queries to the DB, or is there a better way to do this?
Real answer - it's fine.
There's no rule that says all of your domain code needs to be implemented in the same code, run in the same process, or located at a single host.
Udi Dahan frequently emphasizes the differences between logical and physical; you can have code that is logically part of your domain that is located at a different physical server.
It's not without its challenges, of course -- even in the database separating your domain code from "the plumbing" is a good idea, and the fact that you've got domain code running in your storage appliance means that you've got some extra architectural constraints, and those constraints may not be obvious -- so you'll want to have some architectural decision records that explain the real capabilities that you need from your storage appliance.
the domain model is supposed to be independent of IO and other external systems.
"Independent" might be misleading you.
I normally describe the separation this way: the domain model is concerned with representing the manipulation of information within the domain. But it isn't normally concerned with storage and transmission of that information.
In the ideal case, we can pick up the domain model, as is, and move it to host, and everything should still just work. For instance, if we take the domain model and move it from a command line tool to something accessed via a web interface, that doesn't change how the domain model itself manipulates information. Similarly, the domain rules don't change when we shift storage from one appliance to another.
aka: "Separation of concerns".
And yeah, sometimes it happens that we move our domain model (or part of our domain model) to a platform that doesn't support the current implementation of our model, and we have to rewrite.