Docker is becoming a popular tool used by developers and end-users to deploy and run software applications. Dockerfiles are now found alongside projects' source code. Several projects are even starting to maintain families of Dockerfiles, like the Python project that maintains a family of 43 Dockerfiles, each for a specific Python version on a specific Linux distribution. In some situations, Dockerfiles family maintainers have to propagate a change to several, if not all, Dockerfiles of the family (for instance a bugfix applying on all Dockerfiles targeting Python 2.7). This need to propagate changes is usually due to the presence of duplicates between several Dockerfiles of the family. In this paper, our goal is to provide practitioners a clear explanation for why Dockerfile duplicates arise in projects, and what are the different means to handle duplicates with their pros and cons. To perform a grounded analysis, we observe the practices of expert Dockerfile maintainers of Official Docker projects, which are setting the best-practices for Dockerfile maintenance. We show that duplicates in Dockerfiles are frequent in our corpus, that maintainers are aware of their existence, are frequently facing them and have a mixed opinion regarding them (error-prone when not using any tool, but easy to maintain with the right tools). Finally, we describe and analyse the tools used by maintainers to handle duplicates.