This is a similar question to this Dockerfile versioning best practice but not the same.
I do keep the Dockerfile for a project with that project's source code. That makes sense and seems good practice.
However I also have a Dockerfile image for software such as the Jenkins master server that will change quite often as I start to implement CI/CD and tweak things like agents etc. I need to version control it for that reason. Jenkins Agents will also have Dockerfiles to build those respectively.
The Jenkins Dockerfiles don't belong with any project because many projects will use Jenkins. The only way forward I can think of is to have a separate repo for Jenkins but at the moment its only 1 file.
I may also have a Dockerfile for the database software, say Postgresql. Does that need its own repo again seeing as the database can be used by many apps.
So is it normal to have a repo for just one file? Will I run into any problems in the future if I go down that route?
Generally speaking, having a repository with just a single file is uncommon, indeed.
Depending on whether you're acting by yourself or as part of an organization, you either have the freedom of choice or should consult coworkers on how to structure your organization's repositories.
Both in an organization and as a single person, it makes a lot of sense to have a common repository for those files e.g. with a name of shared-infrastructure. Especially if you have many other repositories and don't want to clutter up the repositories list.
But if it's just you and you feel like starting out with a separate repo for each file, just do it.
You can put them together later still even without loosing the history (if that's important to you), when switching repos starts to become too tedious - no problem.