Custom CNAMEs (defined via GUI, not Chart's values) aren't saved after pod restarts.

[perfectra1n]

If you define CNAMEs via the GUI instead of the chart's values, as the file located at /etc/dnsmasq.d/05-pihole-custom-cname.conf isn't backed by any PVC, the file disappears.

1. Import some CNAMEs
2. Delete pod
3. CNAMEs gone

I'm happy to make a PR, but I was curious what you thought the best way to tackle the issue was - I've just mounted an additional NFS PVC at /etc/dnsmasq.d/ for now lol.

        extraVolumes:
          dnsmasq-conf:
            persistentVolumeClaim:
              claimName: pihole-backup-dnsmasq-pvc

        extraVolumeMounts:
          dnsmasq-conf:
            mountPath: /etc/dnsmasq.d

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pihole-backup-dnsmasq-pvc
  namespace: pihole-backup
spec:
  storageClassName: "truenas-csi-nfs"
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      # NFS Subdir Provisioner doesn't care at all abou this
      storage: 1Gi

[dfoulkes]

Personally I've just been mainitaining my own custom values.yml file that has my preffered dnsmasq settings: Doing this you can perist your custom settings between deployment plus ideal for automating the helm deployment.

  customDnsEntries: 
    - address=/s1.mydomain.cloud/10.10.10.123
    - address=/s2.mydomain.cloud/10.10.10.124
    - address=/s3.mydomain.cloud/10.10.10.125
    - address=/s4.mydomain.cloud/10.10.10.126

Although you are right this will not show in the GUI console fustratingly, it will at least make them persist between deployments.

Alternatively, you can use the environment variable PIHOLE_DNS_ if you which to externalise the local DNS mechcanisim for Pihole or conitnue to use a NFS lol.

[dfoulkes]

Just seen you wanted CNAME not A record lol.

Ok, good point personally haven't hit this issue. Curiously, what's the usecase a ingress class?

[dfoulkes]

Looking through the spec, there's option todo this the same way I proposed for A records.

have you tried this in the values.yml

dnsmasq: 
    customCnameEntries::
       # Here we specify custom cname entries that should point to `A` records or
       # elements in customDnsEntries array.
       # The format should be:
       - cname=cname.foo.bar,foo.bar
       - cname=cname.bar.foo,bar.foo

[perfectra1n]

Gotchya, I prefer to manage CNAME / A records via the GUI so that I don't have them publicly facing (public GitOps repo) and the A records are already saved across restarts, I thought it would be useful to have CNAME's records persisted as well to match user expectations.

[dfoulkes]

Fare point, if its the public facing element that concerns you and you're not overally bothered by the cosmetics, you could just supply a different value file that's not in public source control at runtime.

[perfectra1n]

Understood, however as a user, if I make a change in the GUI, I would expect that change to persist across "restarts". Since A records do, I would expect CNAME records to as well.

[MoJo2600]

Maybe we should make sure to persist all the data to one pvc when persistence is enabled. I don't think it makes sense to have multiple pvc.

[perfectra1n]

Fair, I could make that happen. I’ll submit a PR for it :)