Q: Config extensibility with wildcard include?

[benurb]

Hi @MatthewVance,

I started using your unbound image for my pi hole server coming from a locally installed unbound instance. So far it works greats, so thank you very much for that.

One question that came up though: I have a bit of custom configuration (forwarders, logging, private-domains, ...)
Currently I mount my custom config to /opt/unbound/etc/unbound/forward-records.conf to be able to keep your default configuration and enrich it with my custom settings. I guess that's a workaround though, because my config does not contain forwarders only. What do you think about adding a wildcard include, e.g. include: "/opt/unbound/etc/unbound/unbound.conf.d/*.conf" at the end of the unbound.conf? This would add more flexibility for custom configs, while still leaving forward-records.conf in place as a default. It would render a-records.conf and srv-records.conf pretty useless though.

Best regards,
Ben

[MatthewVance]

Thanks Ben. I hear what you're saying. I'm curious though, does the existing ability to provide a fully custom unbound.conf not meet your need? https://github.com/MatthewVance/unbound-docker

…

On Mon, Jan 4, 2021, 5:02 AM Benjamin Urban ***@***.***> wrote: Hi @MatthewVance <https://github.com/MatthewVance>, I started using your unbound image for my pi hole server coming from a locally installed unbound instance. So far it works greats, so thank you very much for that. One question that came up though: I have a bit of custom configuration (forwarders, logging, private-domains, ... Currently I mount my custom config to /opt/unbound/etc/unbound/forward-records.conf to be able to keep your default configuration and enrich it with my custom settings. I guess that's a workaround though, because my config does not contain forwarders only. What do you think about adding a wildcard include, e.g. include: "/opt/unbound/etc/unbound/unbound.conf.d/*.conf" at the end of the unbound.conf? This would add more flexibility for custom configs, while still leaving forward-records.conf in place as a default. It would render a-records.conf and srv-records.conf pretty useless though. Best regards, Ben — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#8>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUMHOUTOAOG6VTRRYD6U5LSYGN4BANCNFSM4VS3JVYA> .

[benurb]

Well theoretically it does, but that also means I have to maintain the whole unbound.conf with a lot of settings I don't want to change from your sane defaults just to change a few configs.
What I did now is btw mount a forward-records.conf file with content include: "/opt/unbound/etc/unbound/unbound.conf.d/*.conf" into the container.

These are the configs I placed there, so that you can get an impression of my use case:

/opt/unbound/etc/unbound/unbound.conf.d/logging.conf

server:
    # Log to stderr
    logfile: ""

/opt/unbound/etc/unbound/unbound.conf.d/dns-rebind-protection.conf

server:
    # Ensure privacy of local IP ranges
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10

    # Allow certain domains to return private IP ranges
    private-domain: [redacted].de

/opt/unbound/etc/unbound/unbound.conf.d/forwarders.conf

forward-zone:
    name: "."

    forward-tls-upstream: yes
    # Google Public DNS
    forward-addr: 8.8.8.8@853#dns.google
    forward-addr: 8.8.4.4@853#dns.google
    forward-addr: 2001:4860:4860::8888@853#dns.google
    forward-addr: 2001:4860:4860::8844@853#dns.google
    # Cloudflare DNS
    forward-addr: 2606:4700:4700::1111@853#cloudflare-dns.com
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 2606:4700:4700::1001@853#cloudflare-dns.com
    forward-addr: 1.0.0.1@853#cloudflare-dns.com

[MatthewVance]

Thank you for the additional information. I'm open to the idea of adding a wildcard include.

I'll probably keep the a-records.conf and srv-records.conf as well. It may not be strictly necessary, but will keep those in place for anyone who has special reliance on the existing implementation.

It may take me a few days to get to this. Feel free to submit a PR in you want.

King regards,
Matt

[erik-h]

@MatthewVance I'm a bit confused - is the wildcard include meant to not be commented out? Currently it is: https://github.com/MatthewVance/unbound-docker-rpi/blob/master/1.15.0/data/unbound.sh#L356

[MatthewVance]

I want it to be commented out. After re-reading the relevant section of the README anew, I see how it is confusing so I should clarify that an example is provided in unbound.sh, but the image should be re-built to take advantage of that feature. I recognize this is not the most user friendly default. I'm intentionally making this tradeoff right now because I'm not a fan of * includes loading files by default. I'd rather this be an intentional decision by the user. On Feb 26, 2022, at 1:19 AM, Erik Haugrud ***@***.***> wrote:  @MatthewVance <https://github.com/MatthewVance> I'm a bit confused - is the wildcard include meant to *not* be commented out? Currently it is: https://github.com/MatthewVance/unbound-docker-rpi/blob/master/1.15.0/data/unbound.sh#L356 — Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUMHOSTTJ3SYH4RWFEJKK3U5B5G3ANCNFSM4VS3JVYA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>